AArch64 код компактнее чем у х86_64, раздутый за счёт префиксов и невыразительной ISA.
Плюс-минус такой же, судя по имеющимся данным. Это при том, что сейчас x86 код крайне редко оптимизируют под объем. Но и объем AArch64 достигается за счет раздутой системы команд, что тоже не очень круто.
Какие вопросы?
Латентность, штраф протокола когерентности кэша, штраф блока страничной трансляции и в частнсоти промаха страничного кэша. Happy path оптимизировать нетрудно, только доминирующая парадигма ООП порождает довольно дурацкие паттерны доступа к памяти, которые к этому happy path имеют весьма отдаленное отношение. Опять же, объем кэша сам по себе не так уж много говорит, потому что его эффективность очень сильно зависит от организации.
Что касается голых циферок - я бы подождал, пока конкуренты выкатят мейнстримное предложение для DDR5 платформы.
Ядро у M1 может качать 58ГБ/c — легко забивает 100% интерфейса к памяти.
Это умеют все современные процессоры. Дурацкое дело нехитрое.
Спасибо, я в курсе =) что они всяким сторонним занимаются. Я, правда, у них FPGA подразделения не нашел, что вызывает удивление. Но, может, плохо искал.
Вероятно именно поэтому AMD купила Xilinx, Intel купила Altera, а в рекламных буклетах появляются слова SmartNIC и SmartSSD. Это тоже HPC, просто другой, не тот, на котором сидит nVidia. И это новый рынок, поэтому там перспектив больше.
Анекдот в том, что а) такие устройства были (у интел была линейка i860, XScale) и б) есть сейчас (под эгидой Интела выпускаются разнообразные FPGA SoC с ARMами)
Три аспекта, обсуждение которых хотелось бы видеть в статьях такого рода.
Я сейчас скажу страшное, но производительность ядра в TOPS уже давно не является единственной ключевой характеристикой. Масса задач упирается в подсистему памяти, и для них архитектура CPU не является критичной. А вот минимизация задержек и расхода места в кэшах, в т.ч. за счет более компактного кода у правильных CISCов - очень даже. И если с экономными процессорами ARM работать умеет, то насчет эффективной подсистемы памяти есть вопросы.
Вопреки утверждению автора, x86 в эмбеде вполне используется. Речь идет как о промышленной автоматизации, так и о честном эмбеде. Правда, этим зачастую занимается совсем не Интел - например, Тесла недавно подписала контракт с AMD, что-то делают и совсем третьи производители, которых на десктопе и в серверной не видно и не слышно.
Плюс, при взгляде на мобильный процессоры забыт еще один крайне важный аспект - встроенные ускорители. Речь идет как об ускорителях, оформленных в виде отдельных ядер (DSP для обработки видео/звука, тензорное ядро для ML, видеокодек, еще что-нибудь), так и о расширениях системы команд под задачу. На x86 с этим довольно тухловато.
Если у вас накопилось больше запросов, чем влазит в буфер, то вы должны ждать, пока ядро их прочитает, и только потом дописывать новые
По какому признаку пользователь должен это отслеживать?
Если же у ядра накопилось ответов больше, чем влазит в буфер, то оно заполнит столько элементов, сколько влезет в буфер, и будет ждать, пока клиент не вычитает ответы.
По какому признаку ядро отслеживает, какие пакеты вычитаны и могут быть безопасно перезаписаны?
Не только и даже не столько, хоть и близко. Операции типа DFT пишут специально обученные люди, обложившись мануалами, и пишут как правило под конкретное железо и один раз. Поэтому там вполне можно писать непосредственно в асме, если уж надо (см библиотеки типа openblas, где внутренние циклы натурально написаны на асме целевой платформы).
В качестве примера - поиск среднего над большой выборкой чисел максимальной для платформы разрядности. В случае, если вам сильно повезло, вопрос решает тривиально линейным суммированием и одним делением и в ряде случаев это даже будет правильным решением. Но в общем случае вы получите бред из-за переполнения. И локально решить, какой алгоритм использовать, нельзя - нужно иметь какие-то соображения о свойствах выборки и о том, какая точность результата вам нужна.
Если нужна производительность, то в качестве примера можно рассмотреть агрегацию значений сложной в вычислении функции на целочисленной сетке, причем распределение значений на этой сетке имеют нетривиальную симметрию и про некоторые диапазоны заранее известно, что их обходить не нужно. (см wikipedia://polytope+modell)
В любом случае, речь идет о том, что вопрос оптимизации и/или корректности вычислений часто оказывается завязан на неочевидную и нетривиальную информацию о входных данных, которые в модели вычислений на уровне С/llvm asm не отображается. Некоторые современные компиляторы достаточно умны, чтобы её из кода реконструировать (напр. gcc/graphite) но то такое.
Вопрос производительной и/или тонковывернутой арифметики сильно шире вопросов ширины арифметики как таковой, имхо. Там очень много тонкостей семантики, какие-то из которых важны для корректности результата, а какие-то для производительности. И на уровне языка системного программирования и тем более llvm asm эти тонкости теряются.
Ключевая часть этого тулчейна - это форматы объектных файлов, утилиты для работы с ними плюс соглашения типа call conventions. От языка и компилятора Цэ они вполне отдираются, тот же gnu ld нормально работает c сlang
Другое дело, что Цэ - это как бы не единственный распространенный язык, символы которого один-в-один отображаются в символы объектных файлов. С этим да, надо что-то делать.
Я вот считаю, что тут нужно призывать именно к смерти Си. Для низкоуровневого языка он делает слишком много предположений о том, как нам жить. А для современноговысокоуровневого языка он не дает достаточной изоляции от платформы.
Конструкции брекетов имеют острые углы и могут натирать контактирующие с ними слизистые. Вплоть до крови. В принципе, острые углы можно скруглить и/или залепить воском.
Установленная скоба может отклеиться, если с ней случится слишком большая нагрузка. Ну, как отклеилась, так её можно и назад подклеить. Не знаю, может ли лопнуть дуга.
Под постронними конструкциями может набиваться еда, которая будет при неаккуратной гигиене гнить и потоенциально приводить к кариесу. Поэтому нужна качественная гигиена.
Теоретически, при ОЧЕНЬ сильном усилии брекет может передавить на зуб. В этом случае вместо смещения зуба в кости с сохранением связочного аппарат зуб может продавиться сквозь связку. Но я не уверен, что на сертифицированных компонентах можно добиться такого эффекта.
>Проблема перемножения матриц стара как мир и еще старше, чем MAP-REDUCE
Именно. И MAP-REDUCE с ней работает плохо.
>А можно у Вас поинтересоваться, что за область компьютерного знания требует перемножения и хранения матриц таких объемов?
Физические расчеты. Квантовая механика/химия, аэро/гидродинамика, сопромат и т.п.. Зависит от размера задачи, конечно. И IRL задача решается с использованием MPI.
Плюс-минус такой же, судя по имеющимся данным. Это при том, что сейчас x86 код крайне редко оптимизируют под объем. Но и объем AArch64 достигается за счет раздутой системы команд, что тоже не очень круто.
Латентность, штраф протокола когерентности кэша, штраф блока страничной трансляции и в частнсоти промаха страничного кэша. Happy path оптимизировать нетрудно, только доминирующая парадигма ООП порождает довольно дурацкие паттерны доступа к памяти, которые к этому happy path имеют весьма отдаленное отношение. Опять же, объем кэша сам по себе не так уж много говорит, потому что его эффективность очень сильно зависит от организации.
Что касается голых циферок - я бы подождал, пока конкуренты выкатят мейнстримное предложение для DDR5 платформы.
Это умеют все современные процессоры. Дурацкое дело нехитрое.
Спасибо, я в курсе =) что они всяким сторонним занимаются. Я, правда, у них FPGA подразделения не нашел, что вызывает удивление. Но, может, плохо искал.
Вероятно именно поэтому AMD купила Xilinx, Intel купила Altera, а в рекламных буклетах появляются слова SmartNIC и SmartSSD. Это тоже HPC, просто другой, не тот, на котором сидит nVidia. И это новый рынок, поэтому там перспектив больше.
Скаэем так, GPGPU сейчас не на острие. Недаром AMD решила купить Xilinx, да и Intel про свой FPGA бизнес не забывает.
Анекдот в том, что а) такие устройства были (у интел была линейка i860, XScale) и б) есть сейчас (под эгидой Интела выпускаются разнообразные FPGA SoC с ARMами)
Три аспекта, обсуждение которых хотелось бы видеть в статьях такого рода.
Я сейчас скажу страшное, но производительность ядра в TOPS уже давно не является единственной ключевой характеристикой. Масса задач упирается в подсистему памяти, и для них архитектура CPU не является критичной. А вот минимизация задержек и расхода места в кэшах, в т.ч. за счет более компактного кода у правильных CISCов - очень даже. И если с экономными процессорами ARM работать умеет, то насчет эффективной подсистемы памяти есть вопросы.
Вопреки утверждению автора, x86 в эмбеде вполне используется. Речь идет как о промышленной автоматизации, так и о честном эмбеде. Правда, этим зачастую занимается совсем не Интел - например, Тесла недавно подписала контракт с AMD, что-то делают и совсем третьи производители, которых на десктопе и в серверной не видно и не слышно.
Плюс, при взгляде на мобильный процессоры забыт еще один крайне важный аспект - встроенные ускорители. Речь идет как об ускорителях, оформленных в виде отдельных ядер (DSP для обработки видео/звука, тензорное ядро для ML, видеокодек, еще что-нибудь), так и о расширениях системы команд под задачу. На x86 с этим довольно тухловато.
По какому признаку пользователь должен это отслеживать?
По какому признаку ядро отслеживает, какие пакеты вычитаны и могут быть безопасно перезаписаны?
кажется, не туда ответил см тут https://habr.com/ru/company/itsoft/blog/589389/comments/#comment_23773249
О кольцевых. Ring buffer имеет конечную емкость.
Я, может быть, коряво выразился. Попробую переформулировать: за какими признаками должен следить пользователь io_uring чтобы
а) не перезаписать свой (еще) необработанный запрос
б) с гарантией успевать обрабатывать все ответы ядра.
Конкретные примеры и истории косяков приветствуются.
Не только и даже не столько, хоть и близко. Операции типа DFT пишут специально обученные люди, обложившись мануалами, и пишут как правило под конкретное железо и один раз. Поэтому там вполне можно писать непосредственно в асме, если уж надо (см библиотеки типа openblas, где внутренние циклы натурально написаны на асме целевой платформы).
В качестве примера - поиск среднего над большой выборкой чисел максимальной для платформы разрядности. В случае, если вам сильно повезло, вопрос решает тривиально линейным суммированием и одним делением и в ряде случаев это даже будет правильным решением. Но в общем случае вы получите бред из-за переполнения. И локально решить, какой алгоритм использовать, нельзя - нужно иметь какие-то соображения о свойствах выборки и о том, какая точность результата вам нужна.
Если нужна производительность, то в качестве примера можно рассмотреть агрегацию значений сложной в вычислении функции на целочисленной сетке, причем распределение значений на этой сетке имеют нетривиальную симметрию и про некоторые диапазоны заранее известно, что их обходить не нужно. (см wikipedia://polytope+modell)
В любом случае, речь идет о том, что вопрос оптимизации и/или корректности вычислений часто оказывается завязан на неочевидную и нетривиальную информацию о входных данных, которые в модели вычислений на уровне С/llvm asm не отображается. Некоторые современные компиляторы достаточно умны, чтобы её из кода реконструировать (напр. gcc/graphite) но то такое.
объясните человеку не в теме - как обрабатывается переполнение буферов?
Вопрос производительной и/или тонковывернутой арифметики сильно шире вопросов ширины арифметики как таковой, имхо. Там очень много тонкостей семантики, какие-то из которых важны для корректности результата, а какие-то для производительности. И на уровне языка системного программирования и тем более llvm asm эти тонкости теряются.
Ключевая часть этого тулчейна - это форматы объектных файлов, утилиты для работы с ними плюс соглашения типа call conventions. От языка и компилятора Цэ они вполне отдираются, тот же gnu ld нормально работает c сlang
Другое дело, что Цэ - это как бы не единственный распространенный язык, символы которого один-в-один отображаются в символы объектных файлов. С этим да, надо что-то делать.
18-битная и другая странная арифметика до сих пор встречается в DSP, AFAIK. Да, программируют их обычно не на С, но как явление их упомянуть надо.
Я вот считаю, что тут нужно призывать именно к смерти Си. Для низкоуровневого языка он делает слишком много предположений о том, как нам жить. А для современного высокоуровневого языка он не дает достаточной изоляции от платформы.
Конструкции брекетов имеют острые углы и могут натирать контактирующие с ними слизистые. Вплоть до крови. В принципе, острые углы можно скруглить и/или залепить воском.
Установленная скоба может отклеиться, если с ней случится слишком большая нагрузка. Ну, как отклеилась, так её можно и назад подклеить. Не знаю, может ли лопнуть дуга.
Под постронними конструкциями может набиваться еда, которая будет при неаккуратной гигиене гнить и потоенциально приводить к кариесу. Поэтому нужна качественная гигиена.
Теоретически, при ОЧЕНЬ сильном усилии брекет может передавить на зуб. В этом случае вместо смещения зуба в кости с сохранением связочного аппарат зуб может продавиться сквозь связку. Но я не уверен, что на сертифицированных компонентах можно добиться такого эффекта.
/ пациент.
>Безопасность
>облачной среде
Смешно, да.
>Проблема перемножения матриц стара как мир и еще старше, чем MAP-REDUCE
Именно. И MAP-REDUCE с ней работает плохо.
>А можно у Вас поинтересоваться, что за область компьютерного знания требует перемножения и хранения матриц таких объемов?
Физические расчеты. Квантовая механика/химия, аэро/гидродинамика, сопромат и т.п.. Зависит от размера задачи, конечно. И IRL задача решается с использованием MPI.
Сделайте, пожалуйста, умножение распределенно хранимых матриц (по причине, что в память одной машины влезает от силы 1/1024-я часть) на MAP-REDUCE.
Хотя эта проблема давно решена RDMA
AFAIK, Ruby и Python дают прямой доступ к словарям методов класса в рантайме для модификации. В JS даже такого понятия нет, весь код очень локальный.