Итак, во-первых, все представленные оптимизации являются универсальными для размеров сетки, скажем, от 100x100.
Даже в такой формулировке --- конечно же нет.
Можно начать с того, чтобы посчитать размеры обрабатываемых массивов и сравнить с размерами кэшей. В исходной формулировке используются 2 массива даблов по 1млн элементов. Они занимают чуть меньше 16MB, что сравнимо с размерами L3, точнее несколько больше 12MB L3 i7-9700K, равно L3 Э-8СВ и меньше L3 Power8. Соответственно, оптимизация "предвычисления q, F", удваивая размер обрабатывемых данных, существенно меняет ситуацию. Матрица же 100x100 это всего лишь 10тыс. элементов общим размером 160KB -- всё локализуется в L2.
Кроме написанного, есть масса других более тонких кэшевых эффектов. Например, ассоциативность. Возьмите размер матрицы, кратный большой степени двойки (2^N) -- и увидете эффект сами. Сравнивать с 2^N +- <маленькое простое число>
В отличие от двух предыдущих -- тут практически со всем согласен без оговорок.
Единственный вопрос (боюсь, риторический):
Почему за 20 лет существования микроархитектуры (например, в Verilog) и 12 лет существования Эльбрусов 6 чтоли поколений в железе так и не были реализованы указанные улучшения в микроархитектуре, а сильные стороны (FLOPs-ы) не были проявлены хотя бы в демонстрационном супере?
Про кластер в ЦИАМ знаю, но он ни разу не демонстрационный. Это всё равно как в чёрной дыре установить.
Но всё же… Пока о реальной плотности команд у нас есть только один ответ и он отрицательный.
да была статистика по числу параллельных операций в подтестах того же SPEC, я видел статью но сейчас ссылку не приведу.
Зато в одном из выступлений Волконского была приведена собственная статистика по этому поводу. Если интересно -- могу найти этот слайд. Там реально достаточно
кстати, Вы ту статью, в которой Амдал сформулировал этот свой "закон", читали? почитайте на досуге -- узнаете много интересного ;)
И закон Амдала даёт чёткие количественные оценки. Если непараллельных операций 10% — не получите более 10-кратного ускорения. Если 25% — более 4-хкратного. Для 40% — не более 2.5-кратного.
чтобы было понятно: для актуальных для меня кодов доля "параллельных" операций 99.9999999%. Впрочем, в таких задачах закон Амдала не очень интересен. Там больше подходит методология информационных графов. В этих терминах поараллельность -- это ширина графа в ярусно-параллельной форме, а последовательная часть -- его высота.
оптимизирующий компилятор строит подобный граф и таким образом находит параллельность (если грубо).
>Только в OoO архитектурах количество ALU даже близко не такое, как впихнули в Эльбрус.
Современные суперскаляры уже давно догнали, а в чём-то и переплюнули e2k в части параллельности. Например, по числу портов к ALU/FPU: в Эльбрусе их всего лишь 6 универсальных, а в Apple M1 6 портов для ALU и 4 порта для FPU, т.е. в сумме 10.
Если сравнивать по FLOP-ам, в чём e2k реально силён, то даже последние Э-8СВ/-16C могут только 24 шт DP FLOP за такт, а современные Xeon-ы 32шт.
чем меня не устраивают тесты EntityFX -- я сам ему неоднократно высказывал, пока он посещал нашу веточку на iXBT.
А по поводу SPEC 2006 (c 2016 я случайно опечатался) -- у меня есть личный шкурный интерес: 3.5 года назад я спорил на коньяк по предсказанию результатов Э-8СВ. :)
Реально независимых команд даже в существующих кодах вполне достаточно. Так что "закон сохранения энергии" выполняется. Более того, этот закон одинаково работает для VLIW и OoO, а для SIMD и вовсе гораздо сильнее всё ограничивает.
Проблема лишь в том, чтобы найти эти команды в общем потоке и спланировать их параллельное выполнение. Тут в действие вступают уже немного другие законы. Продолжая аналогию с законом сохранения энергии, ближе всего по мне теорема Гёделя о неполноте :).
В этом смысле и имеем основные различия: для VLIW и SIMD независимые команды должны быть найдены на стадии компиляции, и спланированы там же. А для OoO окончательное решение о независимости и тем более планирование -- делается на стадии выполнения кода.
я-то понял о чём Вы написали. И конечно же согласен с тем, что суть архитектурных войн в поддержке софта. Ну и что прикладной софт основан на системном. Соответственно, окончание этих войн возможно только в мире переносимого софта.
Но статья-то не о софте, а о железе. Причём в силу своей природы, либые изменения в железе делать гораздо сложнее и дольше, чем в софте. А ключевые изменения вообще невозможны часто. То есть при выборе путей развития железа на 10+ лет вперёд цена ошибки гораздо выше.
Потому автор и сравнивает разные архитектуры, выбирая оптимальные по своим критериям. Но если архитектурные войны за это время закончатся, то эти критерии станут просто неактуальными.
Собственно, эльбрус появился в то время, когда CISC испытывали кризис, различные RISC воевали между собой, а VLIW считался весьма перспективным. В этих условиях Бабаян (по его же словам) придумал неулучшаемую архитектуру (в том числе и микро), за четверть века всё это реализовали в железе. Но перспективность испарилась, и теперь имеется чемодан без ручки. Что с ним делать -- непонятно.
не, если рассматривать FPGA именно как процессор, то у него и своя архитектура, и своя микроархитектура. Хотя Вы, очевидно, лучше меня знаете различия между FPGA, микропроцессорами и ASIC.
Мой вопрос был немного другим: можно ли одну и ту же реализацию микроархитектуры микропроцессора снабдить разными FrontEnd-ами (с разными ISA), причём так, чтобы эффективность не сильно терялась?
В мире есть куча примеров, когда микроархитектура не соответствует типу архитектуры. CISC архитектура/RISC микроархитектура, RISC/VLIW и проч. Наверняка можно сделать и VLIW/RISC... Так что если ограничиться RISC/RISC, то я особых проблем не вижу.
При том, что со статьёй я в основном согласен, по её прочтении не отпускает впечатление, что автор "пускает под откос поезда", хотя "война" давным-давно закончилась. Ну или по крайней мере давно ясно чем именно она закончится.
В том числе и с точки зрения железа. Как правильно указал автор, микроархитектура уже сейчас гораздо важнее архитектуры. Более того, архитектура в основном ограничивается Front-end-ом. То есть потенциально можно делать архитектурно-независимые микроархитектуры. А почему нет, собственно?
вообще-то 1831/1723=1.06 -- какая-то ошибка, вероятно
по крайней мере
42467/16495/2=1.29
это уже ближе к 2000/1500=1.3(3)
я так и думал :(
Не нашёл log-ов SPEC2006.
Как именно в нём тестировалось?
Даже в такой формулировке --- конечно же нет.
Можно начать с того, чтобы посчитать размеры обрабатываемых массивов и сравнить с размерами кэшей. В исходной формулировке используются 2 массива даблов по 1млн элементов. Они занимают чуть меньше 16MB, что сравнимо с размерами L3, точнее несколько больше 12MB L3 i7-9700K, равно L3 Э-8СВ и меньше L3 Power8. Соответственно, оптимизация "предвычисления q, F", удваивая размер обрабатывемых данных, существенно меняет ситуацию. Матрица же 100x100 это всего лишь 10тыс. элементов общим размером 160KB -- всё локализуется в L2.
Кроме написанного, есть масса других более тонких кэшевых эффектов. Например, ассоциативность. Возьмите размер матрицы, кратный большой степени двойки (2^N) -- и увидете эффект сами. Сравнивать с 2^N +- <маленькое простое число>
Спасибо за статью.
В отличие от двух предыдущих -- тут практически со всем согласен без оговорок.
Единственный вопрос (боюсь, риторический):
Почему за 20 лет существования микроархитектуры (например, в Verilog) и 12 лет существования Эльбрусов 6 чтоли поколений в железе так и не были реализованы указанные улучшения в микроархитектуре, а сильные стороны (FLOPs-ы) не были проявлены хотя бы в демонстрационном супере?
Про кластер в ЦИАМ знаю, но он ни разу не демонстрационный. Это всё равно как в чёрной дыре установить.
объём производства Эльбрусов за всё время их существования был озвучен в прошлом году Кимом: 20 тысяч единиц.
Новости этго года существенно ничего не поменяли, навскидку:
https://nangs.org/news/it/v-2021-g-elybrusov-budet-vypushteno-v-20-raz-menyshe-chem-baykalov-no-razrabotchiki-ne-schitayut-eto-proigryshem
вот цитата из доклада:
Анализ трасс исполнения показывает значительный потенциал параллелизма Целочисленные задачи: 81 - 240 оп./такт Вещественные задачи: 36 - 4003 оп./такт
вот перечисление всех возможных команд в доке:
http://ftp.altlinux.org/pub/people/mike/elbrus/docs/elbrus_prog/html/chapter4.html#id5
да была статистика по числу параллельных операций в подтестах того же SPEC, я видел статью но сейчас ссылку не приведу.
Зато в одном из выступлений Волконского была приведена собственная статистика по этому поводу. Если интересно -- могу найти этот слайд. Там реально достаточно
эти "50" -- не совсем то, что Вы себе представляете, и уж точно не то, о чём думал Амдал :gigi:
Реально Эльбрус может выполнять 6 основных независимых команд, всё остальное либо SIMD, либо глубоко вспомогательное.
кстати, Вы ту статью, в которой Амдал сформулировал этот свой "закон", читали? почитайте на досуге -- узнаете много интересного ;)
чтобы было понятно: для актуальных для меня кодов доля "параллельных" операций 99.9999999%. Впрочем, в таких задачах закон Амдала не очень интересен. Там больше подходит методология информационных графов. В этих терминах поараллельность -- это ширина графа в ярусно-параллельной форме, а последовательная часть -- его высота.
оптимизирующий компилятор строит подобный граф и таким образом находит параллельность (если грубо).
>Только в OoO архитектурах количество ALU даже близко не такое, как впихнули в Эльбрус.
Современные суперскаляры уже давно догнали, а в чём-то и переплюнули e2k в части параллельности. Например, по числу портов к ALU/FPU: в Эльбрусе их всего лишь 6 универсальных, а в Apple M1 6 портов для ALU и 4 порта для FPU, т.е. в сумме 10.
Если сравнивать по FLOP-ам, в чём e2k реально силён, то даже последние Э-8СВ/-16C могут только 24 шт DP FLOP за такт, а современные Xeon-ы 32шт.
вторая сторона спора, кстати, пока не верит, что опубликованные результаты -- реальные. Ждёт "официальных" и коньяк отдавать не хочет :)
чем меня не устраивают тесты EntityFX -- я сам ему неоднократно высказывал, пока он посещал нашу веточку на iXBT.
А по поводу SPEC 2006 (c 2016 я случайно опечатался) -- у меня есть личный шкурный интерес: 3.5 года назад я спорил на коньяк по предсказанию результатов Э-8СВ. :)
Вот можете сравнить:
https://forum.ixbt.com/topic.cgi?id=8:25409:7904#7904
Реально независимых команд даже в существующих кодах вполне достаточно. Так что "закон сохранения энергии" выполняется. Более того, этот закон одинаково работает для VLIW и OoO, а для SIMD и вовсе гораздо сильнее всё ограничивает.
Проблема лишь в том, чтобы найти эти команды в общем потоке и спланировать их параллельное выполнение. Тут в действие вступают уже немного другие законы. Продолжая аналогию с законом сохранения энергии, ближе всего по мне теорема Гёделя о неполноте :).
В этом смысле и имеем основные различия: для VLIW и SIMD независимые команды должны быть найдены на стадии компиляции, и спланированы там же. А для OoO окончательное решение о независимости и тем более планирование -- делается на стадии выполнения кода.
я-то понял о чём Вы написали. И конечно же согласен с тем, что суть архитектурных войн в поддержке софта. Ну и что прикладной софт основан на системном. Соответственно, окончание этих войн возможно только в мире переносимого софта.
Но статья-то не о софте, а о железе. Причём в силу своей природы, либые изменения в железе делать гораздо сложнее и дольше, чем в софте. А ключевые изменения вообще невозможны часто. То есть при выборе путей развития железа на 10+ лет вперёд цена ошибки гораздо выше.
Потому автор и сравнивает разные архитектуры, выбирая оптимальные по своим критериям. Но если архитектурные войны за это время закончатся, то эти критерии станут просто неактуальными.
Собственно, эльбрус появился в то время, когда CISC испытывали кризис, различные RISC воевали между собой, а VLIW считался весьма перспективным. В этих условиях Бабаян (по его же словам) придумал неулучшаемую архитектуру (в том числе и микро), за четверть века всё это реализовали в железе. Но перспективность испарилась, и теперь имеется чемодан без ручки. Что с ним делать -- непонятно.
не, если рассматривать FPGA именно как процессор, то у него и своя архитектура, и своя микроархитектура. Хотя Вы, очевидно, лучше меня знаете различия между FPGA, микропроцессорами и ASIC.
Мой вопрос был немного другим: можно ли одну и ту же реализацию микроархитектуры микропроцессора снабдить разными FrontEnd-ами (с разными ISA), причём так, чтобы эффективность не сильно терялась?
В мире есть куча примеров, когда микроархитектура не соответствует типу архитектуры. CISC архитектура/RISC микроархитектура, RISC/VLIW и проч. Наверняка можно сделать и VLIW/RISC... Так что если ограничиться RISC/RISC, то я особых проблем не вижу.
Вот, кстати, согласен.
При том, что со статьёй я в основном согласен, по её прочтении не отпускает впечатление, что автор "пускает под откос поезда", хотя "война" давным-давно закончилась. Ну или по крайней мере давно ясно чем именно она закончится.
В том числе и с точки зрения железа. Как правильно указал автор, микроархитектура уже сейчас гораздо важнее архитектуры. Более того, архитектура в основном ограничивается Front-end-ом. То есть потенциально можно делать архитектурно-независимые микроархитектуры. А почему нет, собственно?
статью пока не читал, но сразу хочу сказать спасибо автору за публикацию результатов SPEC cpu 2016.
А то что это такое? Процессор "выпущен" в 2018г, а результатов тестов -- нет и в 2021г ;)
ну Ok. Констатирую, что моя жалкая попытка заманить автора в нашу ветку провалилась :(