Size: a a a

Compiler Development

2020 April 28

MO

Mar Ort in Compiler Development
Timur Safin
(а на практике окажется, что под Linux-ом с Итаником, использовался gcc у которого было по 1-ой инструкции на бандл. И производительность по сравнению с тем же самым кодом на x86/Windows была просто неприличная. Потому и утонул)
Я не видел компилятор итаниума, но есть подозрение, что его качество было не самое высокое
источник

TS

Timur Safin in Compiler Development
короче, моё обобщение, сделанное по результатам наблюдения со стороны и изнутри: если вы утверждаете, что сделаете лучше чем суперскаляр с Томасуло или скоребордингом но на "простом" онордер ядре с суперумным компилятором. Вы идете не той дорогой и проиграете
источник

TS

Timur Safin in Compiler Development
Mar Ort
Я не видел компилятор итаниума, но есть подозрение, что его качество было не самое высокое
интеловский/hp компилятор был хороший, но за деньги. А gcc - бесплатный, но какой уж удался
источник

МБ

Михаил Бахтерев in Compiler Development
Timur Safin
короче, моё обобщение, сделанное по результатам наблюдения со стороны и изнутри: если вы утверждаете, что сделаете лучше чем суперскаляр с Томасуло или скоребордингом но на "простом" онордер ядре с суперумным компилятором. Вы идете не той дорогой и проиграете
Niagara или как её там? Когда нитей много, можно и на in-order-е выехать.
источник

TS

Timur Safin in Compiler Development
Михаил Бахтерев
Niagara или как её там? Когда нитей много, можно и на in-order-е выехать.
и где эта Ниагара?
источник

TS

Timur Safin in Compiler Development
Timur Safin
короче, моё обобщение, сделанное по результатам наблюдения со стороны и изнутри: если вы утверждаете, что сделаете лучше чем суперскаляр с Томасуло или скоребордингом но на "простом" онордер ядре с суперумным компилятором. Вы идете не той дорогой и проиграете
дьявол в деталях. Память никогда не бесплатна и примерно одинаковая у всех
источник

MO

Mar Ort in Compiler Development
Понятно, что однопоточном с точки зрения ILP вычислении суперскаляр обыграет влив из-за частоты и дизайна самих вливов, но кажется, что таких вычислений меньшинство все-таки
источник

МБ

Михаил Бахтерев in Compiler Development
Timur Safin
и где эта Ниагара?
Ну. В этих. В GPU. Там же так и сделано. Niagara + SIMD.
источник

MO

Mar Ort in Compiler Development
На мой взгляд, ключевое место проигрыша вливов не в размере инструкции, не в уровне параллелизма вычислений или в каких-то еще внешних причинах, а в том, что суперскалярный процессор способен адаптировать вычислительные ресурсы под конкретную задачу в конкретный момент времени используя реальный профиль исполнения (AOT vs JIT), когда как влив эту информацию никак не использует.
источник

AN

Alexander Nasonov in Compiler Development
Михаил Бахтерев
Но вообще, да. Люди часто забывают, что число инструкций - это важно. Фигачат на Крестах кучи инлайнов и получают трэшинг кэшей, а потом удивляются, почему APL быстрее работает :)
Ага. Я когда в своём миникомпиляторе сделал массивный деинлайнинг, то код сократился в некоторых случаях раз в 20ть и перформанс заметно пошёл вверх.
источник

PS

Peter Sovietov in Compiler Development
Mar Ort
На мой взгляд, ключевое место проигрыша вливов не в размере инструкции, не в уровне параллелизма вычислений или в каких-то еще внешних причинах, а в том, что суперскалярный процессор способен адаптировать вычислительные ресурсы под конкретную задачу в конкретный момент времени используя реальный профиль исполнения (AOT vs JIT), когда как влив эту информацию никак не использует.
Совершенно верно. OoO-архитектуры примерно одинаково себя показывают на всем спектре выч. нагрузок. Поэтому они настолько важны в качестве GPP, для настольных вычислений.

Ну а in-order решения и, в частности, VLIW, сегодня переживают небывалый подъем в области специализированных вычислений. Начиная от manycore с GPU и заканчивая NPU, TPU и различными DSP.
источник

MO

Mar Ort in Compiler Development
Alexander Nasonov
Ага. Я когда в своём миникомпиляторе сделал массивный деинлайнинг, то код сократился в некоторых случаях раз в 20ть и перформанс заметно пошёл вверх.
Потому что инлайнинг нужно по профилю выполнять, а не как попало 😏
источник

TS

Timur Safin in Compiler Development
Mar Ort
На мой взгляд, ключевое место проигрыша вливов не в размере инструкции, не в уровне параллелизма вычислений или в каких-то еще внешних причинах, а в том, что суперскалярный процессор способен адаптировать вычислительные ресурсы под конкретную задачу в конкретный момент времени используя реальный профиль исполнения (AOT vs JIT), когда как влив эту информацию никак не использует.
о, на мою любимую мозоль наступили (когда к VLIW еще и BT добавляют) - на это у меня уже был наброс :) http://tsafin.net/blog/jit/aot/bt/Eshche-odna-istoriya-pro-binarnuyu-translyaciyu-04-07/
источник

MO

Mar Ort in Compiler Development
У вас здесь что-то про вливы и джаву ☺️
источник

MO

Mar Ort in Compiler Development
Почитаю, очень интересно
источник

AN

Alexander Nasonov in Compiler Development
Mar Ort
Потому что инлайнинг нужно по профилю выполнять, а не как попало 😏
Вообще-то и компилятор тут грешит немного тоже. Иногда приходится атрибуты noinline,noclone к функциям добавлять.
источник

TS

Timur Safin in Compiler Development
Peter Sovietov
Совершенно верно. OoO-архитектуры примерно одинаково себя показывают на всем спектре выч. нагрузок. Поэтому они настолько важны в качестве GPP, для настольных вычислений.

Ну а in-order решения и, в частности, VLIW, сегодня переживают небывалый подъем в области специализированных вычислений. Начиная от manycore с GPU и заканчивая NPU, TPU и различными DSP.
вот против специализированный вычислителей я ничего не имею против. Но вот с generic purpose процессорами на VLIW как-то дел не идет, уже пару десятилетий как...
источник

MO

Mar Ort in Compiler Development
>Также утверждается, что JIT может “пессимизировать” не такой горячий код, но зачем это если в AOT сценарии мы можем потратить немного больше времени, чем JIT может себе позволить, и соптимизировать даже холодный код?

А не может ли координально поменяется оптимизация, если холодный бранч становится резко горячим, а горячий холодным?
источник

TS

Timur Safin in Compiler Development
не настолько же. ну будет там один непредсказанный мисс на миллион переходов, дальше предиктор уже будет справляться
источник

TS

Timur Safin in Compiler Development
пессимизировать ничего никогда не стоит
источник