MO
А на русском нет? Я знаю иностранные языки просто для сверки, вдруг что упущу.
Официальной, насколько мне известно, нет.
Size: a a a
2020 April 28
MO
Rifat S
Для VLIW архитектуры нужен хороший компилятор, который может распараллеливать код, который написал программист, на параллельные команды. Такой компилятор написать гораздо сложнее, чем компилятор для обычного x86. Плюс код становится непереносимым, если у одного VLIW 4 команды одновременно могут выполняться, а у другого 19, то код будет несовместим. Возможно, поэтому эта архитектура не очень распространена.
В реальности современный суперскаляр есть рисковый влив, поверх которого построен хардварный оптимизирующий компилятор
T
Официальной, насколько мне известно, нет.
Я не приверженец всего лицензионного. Можно и просто гайд как например по C++
MO
Rifat S
А есть здесь компиляторщики, которые сами разрабатывают оптимизирующие компиляторы без LLVM?
Как показывает опыт, если стоит цель выжать максимум из архитектуры, то приходится писать компилятор без ллвм
K
Rifat S
Для VLIW архитектуры нужен хороший компилятор, который может распараллеливать код, который написал программист, на параллельные команды. Такой компилятор написать гораздо сложнее, чем компилятор для обычного x86. Плюс код становится непереносимым, если у одного VLIW 4 команды одновременно могут выполняться, а у другого 19, то код будет несовместим. Возможно, поэтому эта архитектура не очень распространена.
Есть подозрение, что типичный десктопный/сервеный код плохо паралелится на уровне инчтрукций, особоенно если у вас цепочка load-store (что крайне часто по моему не особо большому опыту)
MO
Есть подозрение, что типичный десктопный/сервеный код плохо паралелится на уровне инчтрукций, особоенно если у вас цепочка load-store (что крайне часто по моему не особо большому опыту)
Хорошо написанный оптимизирующийся компилятор умеет разрывать такие цепочки
MO
Если же они не разрываются, то тут уже не важно, влив или не влив это, помогает только многоуровневый кэш
AN
Как показывает опыт, если стоит цель выжать максимум из архитектуры, то приходится писать компилятор без ллвм
А контрибутить в ллвм не вариант?
IJ
В этом и суть)
Я думаю, котлин слишком сильно сложнее брейнфака, чтобы писать для него компилятор или даже интерпретатор следующим проектом. Тем более в одиночку
MO
А контрибутить в ллвм не вариант?
А зачем? Для кого-то может и вариант
T
Я думаю, котлин слишком сильно сложнее брейнфака, чтобы писать для него компилятор или даже интерпретатор следующим проектом. Тем более в одиночку
Я для себя. К тому же я делаю для интереса, а не для решения задачи.
SS
А на русском нет? Я знаю иностранные языки просто для сверки, вдруг что упущу.
МБ
Она распространена на суперкомпьютерах, персональным и серверным же хватает и х86
x86 эффективнее VLIW-ов, поэтому на суперкомпьютерах тоже распространена x86, ну, или POWER, которая такая же, как x86 - суперскалярный out-of-order.
У VLIW-ов проблема: промахи по кэшам первого уровня очень сильно тормозят обработку. А в самих кэшах очень много места тратится под nop-ы в длинных словах. Не все алгоритмы можно так хорошо вектоирзовывать/конвейеризировать. Есть ещё всякие мелочи с задержками делений и умножений.
Когда память быстрая и локальная VLIW - очень хорошо себя проявляет. Но в реальности нельзя за приемлемые деньги и энергетические бюджеты сделать гигабайт быстрой локальной памяти.
Самое узкое место - память, поэтому нужно, чтобы процессор умел переживать задержки доступа к ней. Поэтому рулит out-of-order исполнение, несмотря на кучу технических недостатков.
Как-то так.
У VLIW-ов проблема: промахи по кэшам первого уровня очень сильно тормозят обработку. А в самих кэшах очень много места тратится под nop-ы в длинных словах. Не все алгоритмы можно так хорошо вектоирзовывать/конвейеризировать. Есть ещё всякие мелочи с задержками делений и умножений.
Когда память быстрая и локальная VLIW - очень хорошо себя проявляет. Но в реальности нельзя за приемлемые деньги и энергетические бюджеты сделать гигабайт быстрой локальной памяти.
Самое узкое место - память, поэтому нужно, чтобы процессор умел переживать задержки доступа к ней. Поэтому рулит out-of-order исполнение, несмотря на кучу технических недостатков.
Как-то так.
MO
x86 эффективнее VLIW-ов, поэтому на суперкомпьютерах тоже распространена x86, ну, или POWER, которая такая же, как x86 - суперскалярный out-of-order.
У VLIW-ов проблема: промахи по кэшам первого уровня очень сильно тормозят обработку. А в самих кэшах очень много места тратится под nop-ы в длинных словах. Не все алгоритмы можно так хорошо вектоирзовывать/конвейеризировать. Есть ещё всякие мелочи с задержками делений и умножений.
Когда память быстрая и локальная VLIW - очень хорошо себя проявляет. Но в реальности нельзя за приемлемые деньги и энергетические бюджеты сделать гигабайт быстрой локальной памяти.
Самое узкое место - память, поэтому нужно, чтобы процессор умел переживать задержки доступа к ней. Поэтому рулит out-of-order исполнение, несмотря на кучу технических недостатков.
Как-то так.
У VLIW-ов проблема: промахи по кэшам первого уровня очень сильно тормозят обработку. А в самих кэшах очень много места тратится под nop-ы в длинных словах. Не все алгоритмы можно так хорошо вектоирзовывать/конвейеризировать. Есть ещё всякие мелочи с задержками делений и умножений.
Когда память быстрая и локальная VLIW - очень хорошо себя проявляет. Но в реальности нельзя за приемлемые деньги и энергетические бюджеты сделать гигабайт быстрой локальной памяти.
Самое узкое место - память, поэтому нужно, чтобы процессор умел переживать задержки доступа к ней. Поэтому рулит out-of-order исполнение, несмотря на кучу технических недостатков.
Как-то так.
>А в самих кэшах очень много место тратится под nop-ы в длинных словах.
что вы хотите сказать?
что вы хотите сказать?
МБ
>А в самих кэшах очень много место тратится под nop-ы в длинных словах.
что вы хотите сказать?
что вы хотите сказать?
На реальных задачах получается код, в котором очень много nop-ов в длинных словах (ну, пропусков операций). Я не знаю, как это на Эльбрусе называется, использую Itanium-терминологию.
MO
На реальных задачах получается код, в котором очень много nop-ов в длинных словах (ну, пропусков операций). Я не знаю, как это на Эльбрусе называется, использую Itanium-терминологию.
В эльбрусе эту проблему как-то решили.
МБ
В эльбрусе эту проблему как-то решили.
Интересно. А как?
MO
Интересно. А как?
Нопы часть широкой команды. За счет этого экономится место. Ну и компилятор у них крутой, поэтому на реальном коде получается эффективно разнести инструкции
МБ
Нопы часть широкой команды. За счет этого экономится место. Ну и компилятор у них крутой, поэтому на реальном коде получается эффективно разнести инструкции
Но в широкой команде всё-равно же стоит код этого nop-а, который занимает свой слот.
Про компилятор не знаю. Но когда смотрел на выставке примеры, nop-ов было много. И в исходниках очень много ручной оптимизации через intrinsic-и.
Про компилятор не знаю. Но когда смотрел на выставке примеры, nop-ов было много. И в исходниках очень много ручной оптимизации через intrinsic-и.