История изменений

По скорости чуток более борзо только ибо DDR5.

Пока же взаимодействие между ядрами идет через кэш, что на таком количестве ядер уже не эффективно.

Да. Вешать все ядра на один кеш при таком числе ядер это уже лишено всяческого смысла.

Но и тут есть тонкость. В стандарте ARMv8-A есть понятие PE affinity. Это некий такой processing element. Т.е., это может быть что угодно, имеющее программный счётчик. Это может быть поток в многопоточном приложении, поддерживаемом аппаратно, ядро в однопоточной системе, пофиг. Главное чтобы PE в пределах системы был уникален.

Там есть 4 (согласно спеки ЕМНИП 4) поля, которые должны быть уникальны в пределах всей системы и которые позволяют однозначно идентифицировать PE в системе. PE может быть и групповым. Т.е., отдали make -j 10, заняли 10 PE и создали тем самым группу «кластер» из 10 PE. А уж что это будет – отдельные ядра или потоки на них, это по идее, вопрос десятый. Процессор знает что группа PE с ID == 0 это первый такой кластер, а core IDs == [0-9] это идентификаторы задействованных в нём ядер. Как-то так примерно, сейчас детали не особо важны, могу и напутать, спеку давно листал и не особо внимательно, чисто ознакомления ради.

Собственно, по этой причине Байкал и хочет в своём Байкал-S реализовать 48 ядер и говорит уже сейчас про какую-то «кластеризацию». Вот она, выше.

Да, для задач с ограничениями по памяти это даже с учётом DDR5 несколько в напряг. Но для задач, активно использующих кеш этого более чем достаточно. В конце-концов, именно из-за отсутствия frontend для обмолотки CISC инструкций ARM-компилю и приходится на этапе компиляции упарываться по оптимизации от души. Ну и расширенное число регистров для ARM здесь способствует тому, что какие-то вещи оптимизируются в коде проще. Ну да, китайцам придётся доточить тулчейн для поддержания всех фич процессора.

Внутренняя параллелизм памяти, по идее и даёт ответ почему 128 ядер, да. Ну и кроме того, ядра годны и для NEON и для fp. В принципе, считай чё хошь. Ну да, под VLIW конечно проц не заточен. Да и пофиг. Это именно что серверный проц.

Собственно, вот такой вот «создаваемый динамически» кеш имеет смысл, если только он создаётся под нужный «кластер» ядер и в момент когда он нужен. Но я пока не уверен что всё работает именно так.

Конечно будут промахи по кешу, просадки по шине. Но в общем и целом, при таком zerg rush ядрами для общей производительности проца это не особо важно. Ну будет какое-то число ядер тупить с кешем или гонять данные туда-сюда по шине больше чем нужно. При таком числе ядер это и не особо важно.

По скорости чуток более борзо только ибо DDR5.

Но и тут есть тонкость. В стандарте ARMv8-A есть понятие PE affinity. Это некий такой processing element. Т.е., это может быть что угодно, имеющее программный счётчик. Это может быть поток в многопоточном приложении, поддерживаемом аппаратно, ядро в однопоточной системе, пофиг. Главное чтобы PE в пределах системы был уникален.

Там есть 4 (согласно спеки ЕМНИП 4) поля, которые должны быть уникальны в пределах всей системы и которые позволяют однозначно идентифицировать PE в системе. PE может быть и групповым. Т.е., отдали make -j 10, заняли 10 PE и создали тем самым группу «кластер» из 10 PE. А уж что это будет – отдельные ядра или потоки на них, это по идее, вопрос десятый. Процессор знает что группа PE с ID == 0 это первый такой кластер, а core IDs == [0-9] это идентификаторы задействованных в нём ядер. Как-то так примерно, сейчас детали не особо важны, могу и напутать, спеку давно листал и не особо внимательно, чисто ознакомления ради.

Собственно, по этой причине Байкал и хочет в своём Байкал-S реализовать 48 ядер и говорит уже сейчас про какую-то «кластеризацию». Вот она, выше.

Да, для задач с ограничениями по памяти это даже с учётом DDR5 несколько в напряг. Но для задач, активно использующих кеш этого более чем достаточно. В конце-концов, именно из-за отсутствия frontend для обмолотки CISC инструкций ARM-компилю и приходится на этапе компиляции упарываться по оптимизации от души. Ну и расширенное число регистров для ARM здесь способствует тому, что какие-то вещи оптимизируются в коде проще. Ну да, китайцам придётся доточить тулчейн для поддержания всех фич процессора.

Внутренняя параллелизм памяти, по идее и даёт ответ почему 128 ядер, да. Ну и кроме того, ядра годны и для NEON и для fp. В принципе, считай чё хошь. Ну да, под VLIW конечно проц не заточен. Да и пофиг. Это именно что серверный проц.

Конечно будут промахи по кешу, просадки по шине. Но в общем и целом, при таком zerg rush ядрами для общей производительности проца это не особо важно. Ну будет какое-то число ядер тупить с кешем или гонять данные туда-сюда по шине больше чем нужно. При таком числе ядер это и не особо важно.

По скорости чуток более борзо только ибо DDR5.

Но и тут есть тонкость. В стандарте ARMv8-A есть понятие PE affinity. Это некий такой processing element. Т.е., это может быть что угодно, имеющее программный счётчик. Это может быть поток в многопоточном приложении, поддерживаемом аппаратно, ядро в однопоточной системе, пофиг. Главное чтобы PE в пределах системы был уникален.

Там есть 4 (согласно спеки ЕМНИП 4) поля, которые должны быть уникальны в пределах всей системы и которые позволяют однозначно идентифицировать PE в системе. PE может быть и групповым. Т.е., отдали make -j 10, заняли 10 PE и создали тем самым группу «кластер» из 10 PE. А уж что это будет – отдельные ядра или потоки на них, это по идее, вопрос десятый. Процессор знает что группа PE с ID == 0 это первый такой кластер, а core ID == 0 это идентификатор ядра. Как-то так примерно, сейчас детали не особо важны, могу и напутать, спеку давно листал и не особо внимательно, чисто ознакомления ради.

Собственно, по этой причине Байкал и хочет в своём Байкал-S реализовать 48 ядер и говорит уже сейчас про какую-то «кластеризацию». Вот она, выше.

Да, для задач с ограничениями по памяти это даже с учётом DDR5 несколько в напряг. Но для задач, активно использующих кеш этого более чем достаточно. В конце-концов, именно из-за отсутствия frontend для обмолотки CISC инструкций ARM-компилю и приходится на этапе компиляции упарываться по оптимизации от души. Ну и расширенное число регистров для ARM здесь способствует тому, что какие-то вещи оптимизируются в коде проще. Ну да, китайцам придётся доточить тулчейн для поддержания всех фич процессора.

Внутренняя параллелизм памяти, по идее и даёт ответ почему 128 ядер, да. Ну и кроме того, ядра годны и для NEON и для fp. В принципе, считай чё хошь. Ну да, под VLIW конечно проц не заточен. Да и пофиг. Это именно что серверный проц.

Конечно будут промахи по кешу, просадки по шине. Но в общем и целом, при таком zerg rush ядрами для общей производительности проца это не особо важно. Ну будет какое-то число ядер тупить с кешем или гонять данные туда-сюда по шине больше чем нужно. При таком числе ядер это и не особо важно.

По скорости чуток более борзо только ибо DDR5.

Но и тут есть тонкость. В стандарте ARMv8-A есть понятие PE affinity. Это некий такой processing element. Т.е., это может быть что угодно, имеющее программный счётчик. Это может быть поток в многопоточном приложении, поддерживаемом аппаратно, ядро в однопоточной системе, пофиг. Главное чтобы PE в пределах системы был уникален.

Там есть 4 (согласно спеки) поля, которые должны быть уникальны в пределах всей системы и которые позволяют однозначно идентифицировать PE в системе. PE может быть и групповым. Т.е., отдали make -j 10, заняли 10 PE и создали тем самым группу «кластер» из 10 PE. А уж что это будет – отдельные ядра или потоки на них, это по идее, вопрос десятый. Процессор знает что группа PE с ID == 0 это первый такой кластер, а core ID == 0 это идентификатор ядра. Как-то так примерно, сейчас детали не особо важны, могу и напутать, спеку давно листал и не особо внимательно, чисто ознакомления ради.

Собственно, по этой причине Байкал и хочет в своём Байкал-S реализовать 48 ядер и говорит уже сейчас про какую-то «кластеризацию». Вот она, выше.

Да, для задач с ограничениями по памяти это даже с учётом DDR5 несколько в напряг. Но для задач, активно использующих кеш этого более чем достаточно. В конце-концов, именно из-за отсутствия frontend для обмолотки CISC инструкций ARM-компилю и приходится на этапе компиляции упарываться по оптимизации от души. Ну и расширенное число регистров для ARM здесь способствует тому, что какие-то вещи оптимизируются в коде проще. Ну да, китайцам придётся доточить тулчейн для поддержания всех фич процессора.

Внутренняя параллелизм памяти, по идее и даёт ответ почему 128 ядер, да. Ну и кроме того, ядра годны и для NEON и для fp. В принципе, считай чё хошь. Ну да, под VLIW конечно проц не заточен. Да и пофиг. Это именно что серверный проц.

Конечно будут промахи по кешу, просадки по шине. Но в общем и целом, при таком zerg rush ядрами для общей производительности проца это не особо важно. Ну будет какое-то число ядер тупить с кешем или гонять данные туда-сюда по шине больше чем нужно. При таком числе ядер это и не особо важно.