Персональные компьютеры Эльбрус-401 готовы к серийному производству

Да ты прав, планировщик занимает больше площади ядра.

почти на порядок меньше встроенного видео к примеру (которое в 90% случаев не юзается). смысл?

Если хочешь объективного сравнения, бери какой-нибудь GC ЯП со статической компиляцией. Потом, прогревай JIT, и делай замер.

js на v8 практически равен по производительности С-коду. хоть и статическая компиляция, и gc, да. так что мимо.

почти на порядок меньше встроенного видео к примеру (которое в 90% случаев не юзается). смысл?

Если его убрать, то можно поставить вместо него больше исполнительных устройств и/или кеша, просто экономить на тепловыделении. Ты вообще читаешь, что я тебе пишу?

js на v8 практически равен по производительности С-коду. хоть и статическая компиляция, и gc, да. так что мимо.

Потому, что JIT.

почти на порядок меньше встроенного видео к примеру (которое в 90% случаев не юзается). смысл?

Ну или сделать процессор 6 ядерным, а не 4. По бюджету почти влезает.

js на v8 практически равен по производительности С-коду. хоть и статическая компиляция, и gc, да. так что мимо.

Потому, что JIT.

Там статическая компиляция по факту: http://jayconrod.com/posts/51/a-tour-of-v8-full-compiler

Ты меня извини меня, но Compilation Just In Time, на целевой архитектуре. Просто в v8 нет стадии интерпретации, но есть полноценный JIT. Может там нет PGO? В JIT это не обязательно.

Если его убрать, то можно поставить вместо него больше исполнительных устройств и/или кеша, просто экономить на тепловыделении. Ты вообще читаешь, что я тебе пишу?

если убрать встроенное видео, можно поставить вдвое больше ядер, но почему-то большинство камней идут с видео.

если убрать л3 кеш, можно еще вдвое увеличить кол-во ядер или сделать более толстыми сами ядра. при том что л3 реально дает каких-то % 10 прибавки в среднем по палате.

Потому, что JIT.

в каком месте? он сразу компилит js в нативный код. все, никаких шаманских плясок с бубном вокруг анализа статистики переходов, как вы предлагаете.

с тем же успехом можно 8мб л3 кеша урезать до 4мб, и добавить еще 2 ядра. с околонулевым падением производительности на ядро.

чем JIT без PGO принципиально отличается от статической компиляции с последующим запуском?

если убрать встроенное видео, можно поставить вдвое больше ядер, но почему-то большинство камней идут с видео.

если убрать л3 кеш, можно еще вдвое увеличить кол-во ядер или сделать более толстыми сами ядра. при том что л3 реально дает каких-то % 10 прибавки в среднем по палате.

Боже мой, прекрати этот понос. Мы говорим про разницу между OOO и VLIW. Если из ООО его убрать, то получим VLIW. Зачем ты сюда приплетаешь видео часть и L3 кеш?

в каком месте? он сразу компилит js в нативный код. все, никаких шаманских плясок с бубном вокруг анализа статистики переходов, как вы предлагаете.

Ну это делает JIT, компилит в машкод. С бубном пляшет адаптивная (PGO) компиляция, они просто дополняют друг друга.

чем JIT без PGO принципиально отличается от статической компиляции с последующим запуском?

Статическая компиляция программы в машкод. Она не знает на какой машине будет работать. Можно явно привязать к какому-то набору расширений, который будет работать только на определённой реализации архитектуры. Можно собрать программу с PGO, а потом компилировать с ним, но это только для этого случая.

JIT - компиляция по месту небольших частей программы. В V8 сразу всё не компилируется, а только то, что вызывается. Можно компилировать с разным уровнем оптимизаций в зависимости от какой-то условий. Можно применять PGO для небольших участков избирательно.

Кстати, давно пора бы запилить крауфандинг на государственном уровне.

Уже известен тысячи лет и называется налоги

Ты меня извини меня, но Compilation Just In Time, на целевой архитектуре.

JIT-ы, которые я знаю, работают с некоторым промежуточным представлением (байткод, slim binary). v8 работает непосредственно на исходном коде.

Боже мой, прекрати этот понос. Мы говорим про разницу между OOO и VLIW. Если из ООО его убрать, то получим VLIW. Зачем ты сюда приплетаешь видео часть и L3 кеш?

вы так и не объяснили - зачем его убирать? чтобы нужно было потом лепить PGO, отжирающую 50+% производительности, без которой VLIW превращается в тупую тыкву?

JIT-ы, которые я знаю, работают с некоторым промежуточным представлением (байткод, slim binary). v8 работает непосредственно на исходном коде.

Детали реализации. Скажи, чем отличается алгоритм в ЯП или в байткоде? Просто в V8 решили не делать интерпретатор.

JIT-ы, которые я знаю, работают с некоторым промежуточным представлением (байткод, slim binary). v8 работает непосредственно на исходном коде.

Детали реализации.

Термины.

Скажи, чем отличается алгоритм в ЯП или в байткоде?

Скажи, чем отличается JIT от cc?

вы так и не объяснили - зачем его убирать? чтобы нужно было потом лепить PGO, отжирающую 50+% производительности, без которой VLIW превращается в тупую тыкву?

Чтобы упростить аппаратуру. Вот смотри, если мы уберём планировщик и добавим 2 ядра, это на 33% ядер в нашем суперкомпьютере, а значит у нас купят меньше процессоров. xD

Я уже приводил пример, в котором было продемонстрировано выворачивание внутренностей Skylake наружу. Получает неплохой такой VLIW, который уделает Эльбрус и ООО вместе взятые. У Intel же хороший компилятор?

Если тебе не нравиться адаптивная компиляция, то может пользоваться статической. Посто в VLIW можно добиться ещё большей производительности, именно из-за JIT+PGO. Получится не статическое планирование, а динамическое. Его не сделать средствами ООО, так что и для ООО можно применять JIT+PGO.

Статическая компиляция программы в машкод. Она не знает на какой машине будет работать. Можно явно привязать к какому-то набору расширений, который будет работать только на определённой реализации архитектуры.

да пофиг на набор расширений, в реальных приложениях, которых 99%, это дает прирост на уровне единиц %. и только в некоторых sse/avx даст прирост...

Можно компилировать с разным уровнем оптимизаций в зависимости от какой-то условий. Можно применять PGO для небольших участков избирательно.

в V8? :)

https://www.linux.org.ru/news/hardware/13119818?cid=13133127 (комментарий)

numas13

Ты приводишь сравнение не только JIT со статической компиляцией (разница между ними только в том, когда эта компиляция произойдёт, заранее, или во время исполнения, компилятор может быть один и тот же)

Wikipedia

JIT-компиляция (англ. Just-in-time compilation, компиляция «на лету»), динамическая компиляция (англ. dynamic translation) — технология увеличения производительности программных систем, использующих байт-код, путём компиляции байт-кода в машинный код или в другой формат непосредственно во время работы программы.

Какая разница, есть у нас байткод (просто способ распространения, байткод — IR) или исходный код (а с JS он у нас имеется), или нет? По факту это компиляция по месту выполнения.

Чтобы упростить аппаратуру.

угу, и двукратно потерять в производительности на PGO :)

Получает неплохой такой VLIW, который уделает Эльбрус и ООО вместе взятые.

угу, в теории, на практике - получаете эльбрус, который где-то на уровне атома в среднем...

Посто в VLIW можно добиться ещё большей производительности, именно из-за JIT+PGO.

нельзя. из-за накладных расходов на PGO. никого не волнуют дутые мипсы, если 50-80% их будет расходоваться на PGO.

Его не сделать средствами ООО, так что и для ООО можно применять JIT+PGO.

можно. итог - просадка производительности в 2 раза...

Как у тебя статический скомпилированный код обработает вот это?

function mul(a, b) {
   return a * b;
}

mul(null, "4")

mul(1, undefined)

mul(3, 0.0005e3)

"function parseInt() {
    [native code]
}"

а с другой стороны - какая разница, записывается результат компиляции на диск, или в память для последующего исполнения?

да пофиг на набор расширений, в реальных приложениях, которых 99%, это дает прирост на уровне единиц %. и только в некоторых sse/avx даст прирост...

Это зависит от задачи, вот в этмо примере даст солидный прирост.

numas13

Где-то в середине необходимо вызвать пару вирт. методов (через двойной указатель).

угу, и двукратно потерять в производительности на PGO :)

Ну можешь её отключить. Это не ООО, который не отключить.

угу, в теории, на практике - получаете эльбрус, который где-то на уровне атома в среднем...

Не, получается VLIW с частотой 4 ГГц. И шире оригинальной платформы, добавил только 2 порта в целочисленный RF из-за специфики SIMD в x86. Парадокс.

нельзя. из-за накладных расходов на PGO. никого не волнуют дутые мипсы, если 50-80% их будет расходоваться на PGO.

PGO делается на основе 1000 итераций цикла. После цикла проверяется статистика (кол-во ошибок ветвлений, промахи в кеш). Если их не много, то ничего не трогается. Если вдруг стало хуже, значит динамика поменялась, и можно оптимизировать цикл для других данных.

а с другой стороны - какая разница, записывается результат компиляции на диск, или в память для последующего исполнения?

Так я же говорю, что статическая и JIT компиляция — одно и тоже, просто JIT происходит уже когда программа выполняется, но зачем нам делать работу при каждом запуске? Логично его сохранить, у нас получится такой же машкод.

Просто с JIT можно компилировать сразу на эту платформу. Не нужны в исходниках foo_ssse3, foo_sse42, foo_avx2 и подобные. Если у нас умный компилятор, мы просто на месте сделаем векторизированную версию под нужное расширение. Конечно нужны хорошие компиляторы.

Как у тебя статический скомпилированный код обработает вот это?

printf вас не смущает? или динамическая типизация в objective c?

А как показывает исходник функции если из другого скрипта (может даже юзерскрипта) внезапно дернуть mul.toString()б если бы функция была откомпилированна и откомпилированная бы запускалась то и показывалось бы точно так же как

например для нативных методов таких как parseInt.toString() а как gdb показывает исходники сторонних библиотек, у которых не вырезаны отладочные символы? :)

Это зависит от задачи, вот в этмо примере даст солидный прирост.

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

Аппаратно - может быть.

Всё равно что говорить: У самолёта планер хороший, но движок слабый, от земли оторвать не может. Так что взлетает платформа или целиком, с железом, компиляторами и т.д. Или не взлетает целиком.

Были - M-20, Сетунь.

Сетунь - это 1959. Мы говорим о 70-х - 80-х. Во всяком случае @GladAlex об этих годах говорил.

Ну можешь её отключить.

и получить тупой vliw с производительностью равночастотного пентиума 1 практически везде, кроме DSP-задач. годный подход, чо :)

Не, получается VLIW с частотой 4 ГГц. И шире оригинальной платформы

а с чего вы уверены что получите 4 ГГц, а не 1.5? как минимум затык будет на SSE регистрах...

PGO делается на основе 1000 итераций цикла. После цикла проверяется статистика (кол-во ошибок ветвлений, промахи в кеш). Если их не много, то ничего не трогается. Если вдруг стало хуже, значит динамика поменялась, и можно оптимизировать цикл для других данных.

угу, при помощи магии и без каких-либо пенальти для производительности, да? :) может, пример такого единорога вживую приведете? с явой уже разобрались - -50% на ровном месте...

Так я же говорю, что статическая и JIT компиляция — одно и тоже, просто JIT происходит уже когда программа выполняется, но зачем нам делать работу при каждом запуске? Логично его сохранить, у нас получится такой же машкод.

тогда зачем вы тут доказываете, что вся магия в v8 - из-за JIT, и то он принципиально отличается от компилируемых языков?

Если у нас умный компилятор, мы просто на месте сделаем векторизированную версию под нужное расширение

и толку? если профит менее 10% в типовых задачах?

printf у тебя в скомпилированном коде, а mul("111", []) у тебя пользователь наркоман прямо из вебконсоли сидит тренькает когда function mul давно статически скомпилированно.
Или все таки JIT позовем пусть придет посмотрит вначале «что тут за хуйня играет» ?

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

Нет же. Прирост от VLIW будет на всех задачах где ILP больше чем max ILP OOO, или есть равновероятностные мелкие ветвления. На остальном коде будет такая же производительность, но её можно поднять на обеих платформах с помощь JIT+PGO. К примеру тот VLIW который получился из Skylake, может молотить 1 итерацию цикл в такт, если уместился в это

• переход на начало цикла
• сравнение счетчика
• инкремент счётчика
• операция с целым
• 2 чтения из памяти
• 1 запись в память
• 3 использования FPU/VEC
• 4 операции с bool

ООО версия

• переход на начало цикла
• сравнение счетчика
• инкремент счётчика
• 1 операция на выбор ALU/FPU/VEC
• 2 чтения из памяти
• 1 записи в память

На всех остальных будет примерно тоже.

что вся магия в v8 - из-за JIT, и то он принципиально отличается от компилируемых языков?

Тем, что он знает железо на котором будет работать программа.

и толку? если профит менее 10% в типовых задачах?

Я тоже не сильно рад SIMD, но это очень древняя оптимизация, которая даёт выигрыш в алгоритмах, которые могут быть так исполнены. VLIW гораздо гибче в этом плане. Но SIMD очень дешев в аппаратуре. По-этому его пихают куда только можно. К примеру, все FLOPS Intel на SIMD FMA.

Ах, да я забыл про ограничение ООО в Skylake, это 4 оп/такт.

не нужен тут jit. смотрите objective c.

Нет же. Прирост от VLIW будет на всех задачах где ILP больше чем max ILP OOO

угу, где-то там в теории, а на практике - будет эльбрус с производительностью на уровне равночастотного атома (2-way in-order)...

а с чего вы уверены что получите 4 ГГц, а не 1.5? как минимум затык будет на SSE регистрах...

Потому, что я ничего не менял (ну почти, добавил только 2 порта в регистр целых). Это всё тот же Skylake, только я из него убрал те 7% планировщика, и сделал VLIW frontend. То, что раньше от нас было спрятано, стало открыто.

угу, при помощи магии и без каких-либо пенальти для производительности, да? :) может, пример такого единорога вживую приведете? с явой уже разобрались - -50% на ровном месте...

Будет, но это пенальти на 1000 итераций из миллиона.

Тем, что он знает железо на котором будет работать программа.

а толку-то? еще раз повторяю - процессорозависимая оптимизация дает единицы % в generic задачах.

Я тоже не сильно рад SIMD, но это очень древняя оптимизация, которая даёт выигрыш в алгоритмах, которые могут быть так исполнены. VLIW гораздо гибче в этом плане. Но SIMD очень дешев в аппаратуре. По-этому его пихают куда только можно. К примеру, все FLOPS Intel на SIMD FMA.

причем тут VLIW/SIMD?

речь, если вы позабыли, шла о производительности явы. и о вашем утверждении, что она тормозит из-за GC.

но по факту она таки тормозит из-за JIT байткода, потому что тот же V8 - он хоть и имеет динамическуютипизацию с динамическим прозрачным выделением памяти и GC, но работает шустро. т.к. нет извращений, по факту там статическая компиляция.

Потому, что я ничего не менял (ну почти, добавил только 2 порта в регистр целых).

навскидку - объединили блок SIMD регистров с блоком целочисленных регистров, что должно заметно усложнить получившегося монстрика.

Будет, но это пенальти на 1000 итераций из миллиона.

откуда такая уверенность? примеры такой магии есть? пока что все реализации JIT говорят об обратном - получается лютый жручий монстр, который еле ворочается.

а толку-то? еще раз повторяю - процессорозависимая оптимизация дает единицы % в generic задачах.

Даёт? но не такой существенный, по крайней мере не хуже стат. компиляции. Правда с ООО у нас беда... Сложности взаимопонимания компилятора и планировщика.

Посчитай биты без popcnt/ssse3. (:

причем тут VLIW/SIMD?

речь, если вы позабыли, шла о производительности явы. и о вашем утверждении, что она тормозит из-за GC.

Потому, что вопрос был про профит векторизации? Эм. Я тебя не так понял?

numas13

Если у нас умный компилятор, мы просто на месте сделаем векторизированную версию под нужное расширение

и толку? если профит менее 10% в типовых задачах?

но по факту она таки тормозит из-за JIT байткода, потому что тот же V8 - он хоть и имеет динамическуютипизацию с динамическим прозрачным выделением памяти и GC, но работает шустро. т.к. нет извращений, по факту там статическая компиляция.

JIT — всего лишь время компиляции. Байткод используется для распространения программы. В случае с JavaScript у нас есть исходный код, по-этому в V8 его сразу компилируют (JIT) в машкод.

Опять же, извращением занимаются с байткодом, а не с JIT. Его интерпретируют, пока идёт компиляция, чтобы хоть что-то показать пользователю.

PGO вообще к байткоду не имеет никакого отношения. Это просто ещё одна оптимизация.

Даёт? но не такой существенный, по крайней мере не хуже стат. компиляции. Правда с ООО у нас беда... Сложности взаимопонимания компилятора и планировщика.

нет никаких сложностей. сложности - в ваших фантазиях.

Потому, что вопрос был про профит векторизации? Эм. Я тебя не так понял?

вопрос был в тормозах JIT с PGO, без которого VLIW превращается в тыкву.

В случае с JavaScript у нас есть исходный код, по-этому в V8 его сразу компилируют (JIT) в машкод.

угу. как и GCC. никакой разницы. ну подумаешь, код в памяти а не на винчестере образуется...

PGO вообще к байткоду не имеет никакого отношения. Это просто ещё одна оптимизация.

по факту - все эти «оптимизации» вашего любимого JIT добавляют лишь тормозов. что в яве, что в дотнете. но вы продолжаете почему-то доказывать, что лишние сущности - наше всё, и чем сложнее - тем оно быстрее будет работать...

Атомы уже некоторое время ОоО

С теми, которые ОоО, Эльбрусы пока не сравнивали :)

смотрите objective c.

objective-c - статический, компилируемый язык.
То что он типы во время компиляции расставляет не делает его динамическим.

В динамических языках программа не знает что в нее залетит, она это выясняет на этапе исполнения. Но это не все, из кода динамической программы виден контекст из которого он работает - глобальный объект window, функции, объекты и переменные (если они глобальные) из прочих подключенных скриптов, в том числе и асинхронно подгружаемых (которые подключаются к странице динамически на каком то этапе работы другого кода), но так же у отдельно взятой функции может быть свой контекст который вообще никто больше не видит кроме одной этой единственной функции. И все эти связи надо хранить иначе javascript не может работать.

навскидку - объединили блок SIMD регистров с блоком целочисленных регистров, что должно заметно усложнить получившегося монстрика.

Он и был объеденён, если ты не знаешь. Просто в Skylake SIMD, которому нужен RF целых, пришлось добавить 2 порта. Я и написал, что теперь ты не разгонишь его до 8 ГГц. У Skylake всё вперемешку, там на первом порту у нас может быть ALU/Vec ALU/Vec Shift/Vec Add/Vec Mul/FMA/DIV/Branch. Я просто причесал. Вот смотри схема.

------- ---------- -------
|     | |   RF   | | Int |
| VEC | ---------- -------
|     | | Vec RF | | Mem |
------- ---------- -------
--------------------------
|         Cache          |
--------------------------

откуда такая уверенность? примеры такой магии есть? пока что все реализации JIT говорят об обратном - получается лютый жручий монстр, который еле ворочается.

Поищи в интернете про PGO и адаптивную оптимизацию. Вот к примеру на первой странице в выдаче https://clearlinux.org/blogs/profile-guided-optimization-mariadb-benchmarks.

Типичная ситуация, ты запустил MariaDB. Какой-то цикл отработал 1000 и был компилирован JIT. Цикл был выполнен 100000 раз и был компилирован PGO для генерации профайла. Он выполнился 1000 раз и был откомпилирован уже с PGO и ты получил +18% с производительности. Цикл выполнился 1 млн. раз и был агрессивно оптимизирован с адаптивной оптимизацией, если цикл можно оптимизировать так, у нас под рукой AST, можно в любой момент глянуть.

ну я про древние in-order говорю, которые конкуренты эльбрусам :)

objective-c - статический, компилируемый язык.
То что он типы во время компиляции расставляет не делает его динамическим.
В динамических языках программа не знает что в нее залетит,

вы скомпилировали модуль на objc. все, модуль не меняется. и при этом вы можете из программы вызывать его функции с различными типами параметров.

чем это отличается от v8?

нет никаких сложностей. сложности - в ваших фантазиях.

Ага, мои фантазии. А 30% от бюджета ядра это так, цвяточки...

вопрос был в тормозах JIT с PGO, без которого VLIW превращается в тыкву.

Он не превращается в тыкву, откуда у тебя такие сведения? Этот подход позволяет выжимать все соки из аппаратуры, не важно VLIW или ООО.

угу. как и GCC. никакой разницы. ну подумаешь, код в памяти а не на винчестере образуется...

Опять ты несёшь бред. На винчестер он тоже из памяти попадает. Машкод это всего лишь набор байтов, какая разница, что с ним делать?

по факту - все эти «оптимизации» вашего любимого JIT добавляют лишь тормозов. что в яве, что в дотнете. но вы продолжаете почему-то доказывать, что лишние сущности - наше всё, и чем сложнее - тем оно быстрее будет работать...

И сравниваешь ты их с С, знаем, проходили.

что лишние сущности - наше всё, и чем сложнее - тем оно быстрее будет работать...

Например аппаратный планировщик... Он лишняя сущность или нет? Он делает схему сложнее или нет? Ты совсем запутался.

Типичная ситуация, ты запустил MariaDB. Какой-то цикл отработал 1000 и был компилирован JIT. Цикл был выполнен 100000 раз и был компилирован PGO для генерации профайла. Он выполнился 1000 раз и был откомпилирован уже с PGO и ты получил +18% с производительности. Цикл выполнился 1 млн. раз и был агрессивно оптимизирован с адаптивной оптимизацией, если цикл можно оптимизировать так, у нас под рукой AST, можно в любой момент глянуть.

речь шла о коде, сравнимом по скорости с нативным при исполнении в VM с JIT, не? причем тут прирост в sql запросах по сравнению с теми же sql запросами?

вы так и не смогли привести пример VM с JIT, которая бы везде (а не в полутора синтетических тестах) показала нормальную производительность - но почему-то свято уверены, что такое реально, и что оно будет нормально работать на тупом vliw...

Этот подход позволяет выжимать все соки из аппаратуры, не важно VLIW или ООО.

Даёшь transmeta-way. Всё заворачиваем в JIT.