Здравствуйте, GlebZ, Вы писали:

GZ>Технология с одной шиной памяти, и с кэшем — уже не срабатывает.

Дык можно было бы — давно бы сделали шину 2048 бит. Тут проблема в том, что количество проводников чрезмерно усложняет дизайн материнской платы. Решение перенести память в ядро возможно, но ещё более дорого.

Здравствуйте, GlebZ,

GN>>А вот реальная картина для одного CPU:
GN>>1. Загружается подпрограмма и блок памяти для шифрования в быструю память.
GN>>2. Проц Шифрует. Механизм prefetching'а загружает следующий блок памяти для шифрования в кэш.
GN>>3. Проц выгружает основные результаты в быструю память (остаются там для последующего использования). Данные в основную память будут выгружены из кэша контроллером "прозрачно".
GN>>Шифрование и так работает в быстрой памяти. Нет никаких сообщений между CPU.
GN>>Хорошо, если контроллер памяти успевает предоставить данные для CPU.

GZ>Я подразувал именно архитектуру Cell.

ИМХО мой пример показывает, что современная архитектура лучше подходит под задачу, чем какие-то навороты (которые наверняка имеют какие-то подводные камни) . На бумаге всегда всё хорошо выглядит, а когда дело доходит до практики — это не так. История того же x86 имеет массу примеров подобного — вспомните PIV с его супер-ядром, проигрывающем ядру предудущему.

Здравствуйте, gear nuke, Вы писали:

GN>Дык можно было бы — давно бы сделали шину 2048 бит. Тут проблема в том, что количество проводников чрезмерно усложняет дизайн материнской платы. Решение перенести память в ядро возможно, но ещё более дорого.
А никому не нужна двухкилобайтная шина. Просто двухкилобайтных данных нет. Даже если забыть о x86 и вспомнить о SIMD(которые теперь уже и в x86 есть но мало пользуются), то не наберешь столько данных. Увеличивают пропускную способность только за счет тактовой частоты, и некоторыми хаками(типа DDR).

С уважением, Gleb.

Здравствуйте, gear nuke, Вы писали:

GN>ИМХО мой пример показывает, что современная архитектура лучше подходит под задачу,
В том то и дело что нет. Во первых, проц не знает что такое шифрование, он знает только что такое инструкции и последняя использованная память. Неугаданный переход в PIV много стоит. Во вторых, он может через некоторый момент заняться обработкой прерывания(в результате заполнение кэша начнется сначало) В третьих, при многопроцессорности, у каждого своя память. И разделив расчеты, мы получаем то, что приходится бегать с промежуточными данными через более медленную память.

GN>чем какие-то навороты (которые наверняка имеют какие-то подводные камни) . На бумаге всегда всё хорошо выглядит, а когда дело доходит до практики — это не так. История того же x86 имеет массу примеров подобного — вспомните PIV с его супер-ядром, проигрывающем ядру предудущему.
Или вспомнить Cray — который изначально был параллельным, и в стародавние времена делал то куда x86 никогда не добраться.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>А никому не нужна двухкилобайтная шина. Просто двухкилобайтных данных нет.

Не важно, есть ли такие данные или нет. Передавать данные параллельно быстрее. x86 сейчас читает данные блоками по 16\32 байта. Как видите, это мало похоже на 32 бита.

GZ>Даже если забыть о x86 и вспомнить о SIMD(которые теперь уже и в x86 есть но мало пользуются), то не наберешь столько данных. Увеличивают пропускную способность только за счет тактовой частоты, и некоторыми хаками(типа DDR).

Пропускная способность = ширина канала * частота передачи.

Здравствуйте, GlebZ, Вы писали:

GN>>ИМХО мой пример показывает, что современная архитектура лучше подходит под задачу,
GZ>В том то и дело что нет. Во первых, проц не знает что такое шифрование, он знает только что такое инструкции и последняя использованная память.

А новйй проц будет знать про шифрование? И про все алго, которые придумают в будующем?

GZ>Неугаданный переход в PIV много стоит. Во вторых, он может через некоторый момент заняться обработкой прерывания(в результате заполнение кэша начнется сначало)

А когда будет много ядер, прерывания исчезнут?

GZ>В третьих, при многопроцессорности, у каждого своя память. И разделив расчеты, мы получаем то, что приходится бегать с промежуточными данными через более медленную память.

В случе одного CPU данные находятся всё время в кэше. Они будут выгружены, когда контроллер будет вынужден считать в линейку новые данные.

GZ>Или вспомнить Cray — который изначально был параллельным, и в стародавние времена делал то куда x86 никогда не добраться.

x86 — это самый ужасный из процессоров всех времён и народов. Тем не менее, он жив до сих пор. Слишком дорого обойдётся переход на новые архитектуры. "Смерть" Itanium яркий тому пример.

Здравствуйте, gear nuke, Вы писали:

GN>Не важно, есть ли такие данные или нет. Передавать данные параллельно быстрее. x86 сейчас читает данные блоками по 16\32 байта. Как видите, это мало похоже на 32 бита.
Я собственно застал то время, когда был переход с 16 разрядной на 32 разрядные шины. Огромный прирост производительности был только у маркетологов. Сейчас в связи с переходом на 64 разрядную шину — все повторяется. Неважно сколько разрядов в шине, важно сколько проц сможет обработать за тик. Он же заказывает данные по последовательному алгоритму.

GN>Пропускная способность = ширина канала * частота передачи.
Добавь * на количество шин.

С уважением, Gleb.

Здравствуйте, gear nuke, Вы писали:

GN>А новйй проц будет знать про шифрование? И про все алго, которые придумают в будующем?
Нет. Программа будет знать о процах.

GN>А когда будет много ядер, прерывания исчезнут?
Нет. Но можно будет распределить нагрузку.

GN>В случе одного CPU данные находятся всё время в кэше. Они будут выгружены, когда контроллер будет вынужден считать в линейку новые данные.
Через пару лет один проц(или одно ядро) уйдут в небытье.

GN> x86 — это самый ужасный из процессоров всех времён и народов. Тем не менее, он жив до сих пор. Слишком дорого обойдётся переход на новые архитектуры. "Смерть" Itanium яркий тому пример.
Много чего живо. Но это не повод сохранять костность мышления. Всегда найдется более интересное чем mainstream. По крайней мере даже в x86 по сравнению с первоначальным вариантом много нового(начиная от тех же SIMD инструкций). Приходится перенимать.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Я собственно застал то время, когда был переход с 16 разрядной на 32 разрядные шины. Огромный прирост производительности был только у маркетологов.

Прирост и на самом деле был. Не производительности, а пропускной способности памяти. Ровно в 2 раза. А производительность CPU в общем случае не зависит от разрядности регистров — для некоторых задач оптимальна однобитная архитектура .

GZ>Сейчас в связи с переходом на 64 разрядную шину — все повторяется. Неважно сколько разрядов в шине, важно сколько проц сможет обработать за тик.

Уж проц-то без проблем выбирает возможности шины. По поводу разрядности ALU я писал выше.

for ( unsigned long i = 0; i ; i++ ); // не ускоряется при переходе на 64 бита. может даже замедлиться.
for ( unsigned long long i = 0; i ; i++ ); // ускоряется при переходе на 64 бита - арифметика проще.

GN>>Пропускная способность = ширина канала * частота передачи.
GZ>Добавь * на количество шин.

Ширина канала = количество шин * ширина шины

Здравствуйте, GlebZ, Вы писали:

GN>>А новйй проц будет знать про шифрование? И про все алго, которые придумают в будующем?
GZ>Нет. Программа будет знать о процах.

А чейчас она не знает?

GN>>А когда будет много ядер, прерывания исчезнут?
GZ>Нет. Но можно будет распределить нагрузку.

Это ничего не даст. Потери времани и загрязнания кэша не уменьшатся (могут увеличиться как раз из-за распределения и необходимости синхронизации)

GN>>В случе одного CPU данные находятся всё время в кэше. Они будут выгружены, когда контроллер будет вынужден считать в линейку новые данные.
GZ>Через пару лет один проц(или одно ядро) уйдут в небытье.

Ну будет 2 ядра, а будет ли это как-то заметно влиять на скорость? Сейчас мало влияет.

GZ>Много чего живо. Но это не повод сохранять костность мышления. Всегда найдется более интересное чем mainstream.

Я в детстве научился на своём опыте. Больше не хочу. Выкидывать кучу наработок только потому, что дяди на биржах ничего не понимают в железе, зато понимают в бизнесе. Разбитое корыто тоже интереснее чем mainstream, ни у кого такого нет .

GZ>По крайней мере даже в x86 по сравнению с первоначальным вариантом много нового(начиная от тех же SIMD инструкций). Приходится перенимать.

Вот это типичная маркетингавая утка. Добавили бы обычных регистров, лучше бы было. Но нет, это бы не было "революция".

Здравствуйте, gear nuke, Вы писали:

GN>Прирост и на самом деле был. Не производительности, а пропускной способности памяти. Ровно в 2 раза. А производительность CPU в общем случае не зависит от разрядности регистров — для некоторых задач оптимальна однобитная архитектура .
Именно, что не было прироста эффективной пропускной способности. Ну и нафиг мне двухкилобайтная шина, если она не работает.

GN>Уж проц-то без проблем выбирает возможности шины. По поводу разрядности ALU я писал выше.
GN>

GN>for ( unsigned long i = 0; i ; i++ ); // не ускоряется при переходе на 64 бита. может даже замедлиться.
GN>for ( unsigned long long i = 0; i ; i++ ); // ускоряется при переходе на 64 бита - арифметика проще.
GN>

Достаточно редкая конструкция. 32-разрядности вполне хватает для подавляющего числа операций.
Прирост в основном будет на memset, memcpy операциях.

С уважением, Gleb.

Здравствуйте, gear nuke, Вы писали:

GN>Здравствуйте, GlebZ, Вы писали:

GN>>>А новйй проц будет знать про шифрование? И про все алго, которые придумают в будующем?
GZ>>Нет. Программа будет знать о процах.

GN>А чейчас она не знает?
Нет. Об этом знает только операционка. Вводятся правда OpenMP команды в различные компиляторы С++. Но они меня не впечатляют.

GN>>>А когда будет много ядер, прерывания исчезнут?
GZ>>Нет. Но можно будет распределить нагрузку.

GN>Это ничего не даст. Потери времани и загрязнания кэша не уменьшатся (могут увеличиться как раз из-за распределения и необходимости синхронизации)
Опять. Я не говорю о кэше. Я говорю об абсолютно управляемой памяти.

GN>>>В случе одного CPU данные находятся всё время в кэше. Они будут выгружены, когда контроллер будет вынужден считать в линейку новые данные.
GZ>>Через пару лет один проц(или одно ядро) уйдут в небытье.

GN>Ну будет 2 ядра, а будет ли это как-то заметно влиять на скорость? Сейчас мало влияет.
С OpenMP — будет влиять.

GN>Вот это типичная маркетингавая утка. Добавили бы обычных регистров, лучше бы было. Но нет, это бы не было "революция".
Обычных регистров, уже практически избыток. Вся сложность процов x86 именно в этих обычных регистрах.(правильно говорить о регистровой памяти).

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GN>>Прирост и на самом деле был. Не производительности, а пропускной способности памяти. Ровно в 2 раза. А производительность CPU в общем случае не зависит от разрядности регистров — для некоторых задач оптимальна однобитная архитектура .
GZ>Именно, что не было прироста эффективной пропускной способности.

Вы путаете пропускную способность памяти с производительностью CPU. Pentuim при той же частоте шины имел в 2 раза более быстрые операции с памятью, чем 486.

GN>>Уж проц-то без проблем выбирает возможности шины. По поводу разрядности ALU я писал выше.
GN>>

GN>>for ( unsigned long i = 0; i ; i++ ); // не ускоряется при переходе на 64 бита. может даже замедлиться.
GN>>for ( unsigned long long i = 0; i ; i++ ); // ускоряется при переходе на 64 бита - арифметика проще.
GN>>

GZ>Достаточно редкая конструкция. 32-разрядности вполне хватает для подавляющего числа операций.

Это утрированная иллюстрация 64х битной арифметики.

GZ>Прирост в основном будет на memset, memcpy операциях.

Нет будет. Сейчас нет разницы, как копировать — по 4, 8 или 16 байт. Всё упирается в память.

Здравствуйте, GlebZ, Вы писали:

GZ>>>Нет. Программа будет знать о процах.

GN>>А чейчас она не знает?
GZ>Нет. Об этом знает только операционка.

Смотря какая программа.

GN>>Это ничего не даст. Потери времани и загрязнания кэша не уменьшатся (могут увеличиться как раз из-за распределения и необходимости синхронизации)
GZ>Опять. Я не говорю о кэше. Я говорю об абсолютно управляемой памяти.

Вот именно, что опять! Это одно и тоже. Вы меняете название, но суть не изменить. Да, у кэша не так много команд явного управления, как хотелось бы. И на то есть резон — добавим кучу команд управления кэшем, и CPU только и будет их выполнять, вместо полезной работы .

GN>>Ну будет 2 ядра, а будет ли это как-то заметно влиять на скорость? Сейчас мало влияет.
GZ>С OpenMP — будет влиять.

OpenMP совершенно ни при чём. HT не позволяет выполнять однотипные операции на 2х ядрах одновременно.

GN>>Вот это типичная маркетингавая утка. Добавили бы обычных регистров, лучше бы было. Но нет, это бы не было "революция".
GZ>Обычных регистров, уже практически избыток.

Неужели??? Всего каких-то 8, причём 8й ни один компилятор не даёт по полной использовать.

GZ>Вся сложность процов x86 именно в этих обычных регистрах.(правильно говорить о регистровой памяти).

Теневые регистры не доступны программно. С точки зрания исполняемого кода их нет.

Здравствуйте, gear nuke, Вы писали:


GN>Вы путаете пропускную способность памяти с производительностью CPU.
Нет не путаю. Для общей производительности компьютера важна именно эффективная пропускная способность.
GN>Pentuim при той же частоте шины имел в 2 раза более быстрые операции с памятью, чем 486.
Ссылку в студию...

GZ>>Прирост в основном будет на memset, memcpy операциях.
GN>Нет будет. Сейчас нет разницы, как копировать — по 4, 8 или 16 байт. Всё упирается в память.
А ты попробуй. Только чтобы компилер понимал под кого memcpy.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GN>>Вы путаете пропускную способность памяти с производительностью CPU.
GZ>Нет не путаю.

Я приводил пример с 32х и 64х битной арифметикой. На 32х битной арифметике 64х битные регистры не дают выигрыша, на 64х битной дают. Каким образом это зависит от ширины шины памяти, когда все данные в кэше?

GZ>Для общей производительности компьютера важна именно эффективная пропускная способность.

"Общая производительность" — это слишком общая вещь. Есть производительность на конкретных задачах, и она уже может зависеть, может не зависеть.

GN>>Pentuim при той же частоте шины имел в 2 раза более быстрые операции с памятью, чем 486.
GZ>Ссылку в студию...

Даже теряюсь на что ссылку-то приводить. В то время интернет был широкораспространён? Для меня формула "Пропускная способность = ширина канала * частота передачи" преподавалась как аксиома по предмету "проектирование цифровых цепей" (как-то так, уже не помню).

GZ>>>Прирост в основном будет на memset, memcpy операциях.
GN>>Нет будет. Сейчас нет разницы, как копировать — по 4, 8 или 16 байт. Всё упирается в память.
GZ>А ты попробуй. Только чтобы компилер понимал под кого memcpy.

Я говорю не про то, что где-то прочитал, и даже не просто попробовал, а потратил достаточное количество времени на изучение вопроса. Безо всяких компиляторов и memcpy. ~85% от теоретической пропускной способности памяти — потолок, они почти никак не зависит от использования mmx\xmm регистров. При использовании GPR производительность теряется только из-за их малого количества.

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, gear nuke, Вы писали:


GN>>Вы путаете пропускную способность памяти с производительностью CPU.
GZ>Нет не путаю. Для общей производительности компьютера важна именно эффективная пропускная способность.
GN>>Pentuim при той же частоте шины имел в 2 раза более быстрые операции с памятью, чем 486.
GZ>Ссылку в студию...

GZ>>>Прирост в основном будет на memset, memcpy операциях.
GN>>Нет будет. Сейчас нет разницы, как копировать — по 4, 8 или 16 байт. Всё упирается в память.
GZ>А ты попробуй. Только чтобы компилер понимал под кого memcpy.

Penitum имеет 64 битную шину (хоть и пользуется 32 битными операциями), а 486 — только 32 битную. И, хотя система команд Pentium не может использовать полную разрядность шины — ей в полном объёме пользуется контроллер кэша. Так данные из кэша подгружаются и выгружаются в 2 раза быстрее, чем в 486 (при той же тактовой частоте). Потому memcpy будет работать быстрее безовсякой оптимизации.

Потому gear nuke абсолютно прав, когда показывает, что более широкая шина ускорит работу CPU. При 2-х килобитной шине, к примеру, переключение потоков будет происходить за один цикл шины. При такой разрядности шины большинство алгоритмов будут работать так, как будто скорость работы памяти равна скорости работы кэша (или составляет 96-99% последней).

Однако есть несколько моментов, которые мешают увеличить разрядность шины. И разводка печатной платы и количество контактов (ведь каждый контакт — потенциальный источник проблем) и наводка сигналов друг на друга. Тенденция сейчас ровно противоположная — уменьшение сигнальных проводов, с повышением тактовой частоты — последовательная передача данных. Некоторые спецы прогнозируют дальнейшее развитие (через 7-10 лет) следующим образом: шины между CPU, памятью и периферией становятся оптическими, пропускная способность таких шин и будет соответствовать 2-16 килобит. При этом по шине контроллер кэша будет обмениваться пакетами с памятью и другими CPU. Процесс формирования пакета будет достаточно медленным (как и сейчас — процесс чтения столбца/строки в чипе динамической памяти) — порядка 10 нс (100 МГц), зато скорость передачи этих пакетов будет в 100-1000 раз больше, чем сейчас. Соответственно будет более востребован большой кэш (16-32MB) и компиляторы/JIT фреймворки, учитывающие эти особенности архитектуры. Кстати, этот путь развития вполне хорошо соотносится с концепцией развития множества ядер на кристалле и одновременным доступом множества CPU к общей памяти (особенно через многопортовый мост, с собственной кэш памятью, используемой для синхронизации доступа).

С Уважением, Андрей

Здравствуйте, AndreyFedotov, Вы писали:

AF> Penitum имеет 64 битную шину (хоть и пользуется 32 битными операциями), а 486 — только 32 битную. И, хотя система команд Pentium не может использовать полную разрядность шины — ей в полном объёме пользуется контроллер кэша. Так данные из кэша подгружаются и выгружаются в 2 раза быстрее, чем в 486 (при той же тактовой частоте). Потому memcpy будет работать быстрее безовсякой оптимизации.
Действительно. Прогуглился, был неправ. Тот пентюх о котором я говорил, был с аббревитурой s. И вышел толи одновременно, то ли позже. И мог ставиться на ту же плату что и 486. Это меня и ступило. Пристрелите меня табуреткой.

AF> Потому gear nuke абсолютно прав, когда показывает, что более широкая шина ускорит работу CPU. При 2-х килобитной шине, к примеру, переключение потоков будет происходить за один цикл шины. При такой разрядности шины большинство алгоритмов будут работать так, как будто скорость работы памяти равна скорости работы кэша (или составляет 96-99% последней).
А вот здесь не понял. Если я правильно понял, это есть упреждающее чтение. И оно эффективно на 96-99%?

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

AF>> Потому gear nuke абсолютно прав, когда показывает, что более широкая шина ускорит работу CPU. При 2-х килобитной шине, к примеру, переключение потоков будет происходить за один цикл шины. При такой разрядности шины большинство алгоритмов будут работать так, как будто скорость работы памяти равна скорости работы кэша (или составляет 96-99% последней).
GZ>А вот здесь не понял. Если я правильно понял, это есть упреждающее чтение. И оно эффективно на 96-99%?

Да, это упреждающее чтение, в том смысле, что если нам нужно считать инструкцию из совершенно новой области памяти, то хотя первое чтение будет медленным (время формирования пакета), зато пакет сразу пришлёт несколько килобайт данных с которыми возможна работа со скоростью кэша. Поскольку длинные ветвления (то есть условные переходы на расстояние дальше килобайта) встречаются редко и обычно они не цикличны, получается что одним пакетом сразу будет загружен весь алгоритм (а то и несколько) или по крайней мере большая его часть. В результате если помчитать итоговую скорость работы то она и составит 96-99% от скорости работы кэша. При этом без учёта компилятором (или фреймворком) архитектурных особенностей — скорость будет ближе к нижней границе, а с учётом — к верхней.

Здравствуйте, gear nuke, Вы писали:

GN> x86 — это самый ужасный из процессоров всех времён и народов. Тем не менее, он жив до сих пор. Слишком дорого обойдётся переход на новые архитектуры.

Было бы желание — за это время можно было бы потихоньку вылечить большинство болячек. К примеру WinXP x64 не умеет ни DOS ни Win16 приложения запускать. Это означает, что после массового перехода на x64 можно смело выкидывать из процессоров реальный, 286 и V86 режимы. То же самое и с системой команд. На сегодняшний момент добавить несколько новых декодеров для нового instruction set не так уж и сложно, а значит в x64 режиме можно было выкинуть всякие несуразности вроде leave и упростить схему описания команды и ее аргументов.
Другое дело что производителям х86 процессоров выгодно наличие очень высокого порога вхождения на этот рынок.