Оптимизация ПО под процессор

за счёт чего можно достичь увеличения быстродействия?

За счёт оптимизаций.

Реализации JavaScript быстрые в первую очередь за счёт JIT. С JIT-ами на Эльбрусах, насколько я в курсе, не так, чтобы фантастично (по сути, их надо делать с нуля, и, насколько я слышал, делают).

написать на ассемблере, учитывая архитектуру и особенности целевого процессора. это, вероятно, потолок оптимизации.
ну и плюс численно разные эквивалентные параметры эльбруса и Intel/AMD - частота, объём кэша и его логика работы.
с другой стороны никто не стремится догнать в плане производительности топовые чипы Intel/AMD, тут скорее другие задачи.
для офисных задач и малонагруженных серверов/схд хватает и ладно

за счёт чего можно достичь увеличения быстродействия?

За счет финансирования команды разработчиков, которая проведет долгую работу по оптимизации. Но сейчас с Эльбрусами ситуация не понятная, так что даже хорошо, что не вкладывались)

так что даже хорошо, что не вкладывались

хорошо, что не все пишут здесь глупости, подобные твоей.

Но зачем? Эльбрус всегда был процессором для отчетов, раньше он стоил как крыло самолета, теперь как самолет. Никто и не планировал его использовать в реальных задачах :)

Много за счёт чего, тут перечислять устанешь у каждого своё. Выравнивание данных, ветвления, предзагрузка данных для одних лучше так для других эдак. Иногда всякими #pragma можно подсказывать компилятору то или иное.

https://www.youtube.com/watch?v=KmEyOXX5Or4

Ну например написали мы программу для 32 битного одноядерного селерона, нам обновили машину до 64 битного шестиядерного фенома, мы оптимизируем цикл под этот и подобные процессоры использовав все шесть ядер задав циклу #pragma omp parallel for если алгоритм позволяет.

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

Учитывая во внимание что компилятор эльбруса делает херову гору всего с кодом и глубоко его анализирует нужно понимать где у него слабые и сильные стороны http://ftp.altlinux.org/pub/people/mike/elbrus/docs/elbrus_prog/html/chapter8.html

А если вообще в целом по процам то тут тема для долгих бесед по вечерам с булочками и кооофэээ, но от коффэээээ у меня изжога так что я больше не буду про это говорить, а вот булочку возьму.

1. Сначала при освоение любой новой архитектуры просто пишут код, который «просто работает», т.е. он выполняет свою задачу.
2. Затем его логику оптимизируют, чтобы убрать очевидные лишние операции и лишний код(т.е. «рефакторят»)
3. Затем производятся по сменке архитектурнонезависимые оптимизации, например оптимизация локальности данных и инструкций для лучшей работы с кешем и опциональное распараллеливание на потоки.
4. На по сути крайнем этапе к архитектурной специализации в целях выжать из железа максимум и/или поднять энергоэффективность вычислений производится привязанная к архитектуре оптмимизация.

Это по сути возможные итерации, но суть в том, что как правило они могут повторятся до бесконечности(например для 1-2-ой шаги будут повторены при реализации новых фишек языка, 3-4 будут вообще происходить постоянно, как решение-реакция по результатам исследования производительности ПО, другими словами, как только будет выявлено, что что-то можно оптмизировать - это могут оптимизировать).

В случае переноса на новую архитектуру по сути почти весь этот путь нужно пройти по новой, ибо хорошо воспроизводятся только шаги 1-2(т.е. нам не нужно будет например париться над добавкой новых плюшек, т.к. будем развивать сразу актуальную версию интерпретатора), а 3-4 по сути нужно проходить по новой, собственно что и получается с интерпретатором ЖСа под Эльбрусом - перенос(накладывание 1-2 шагов) разработчики сделали, но чтобы получить производительность нужны будут длительные циклы оптимизации интерпретатора, а также как широко известно также и компилятора Си для Е2К, ибо тот также далеко не совершенен. Вообще теоретически насколько я знаю широкое слово - блажь для JIT интерпретаторов и при должной проработке вроде на Е2К можно выжать больше чем на х86, обоснование вроде как кроется в том, что интерпретатору нужно выпролнять много независимых действий, который в теории хорошо параллелятся на ширслове.

раньше он стоил как крыло самолета, теперь как самолет

Не скажи, самолёты тоже подорожали.

С JIT-ами на Эльбрусах, насколько я в курсе, не так, чтобы фантастично

Казалось бы, должно быть наоборот. Ведь эффективно использовать эту железяку можно только с jit. Они ведь даже хвастались и продвигали как фичу эффективную бинарную трансляцию (т.е. jit, вид сбоку).

Ну так трансляция-то не бинарника-же. Нужно оптимизировать jit-ы V8, Ion(Spyder)Monkey и прочее. Понятно, что они вылизаны для x86-64. Понятно, что их вылижут для ARM. Для Эльбрусов придётся также оптимизировать транслятор силами МЦСТ или партнёров. Понятно, что можно и просто «втупую» скомпилировать (какбы обычный С++ и движок соберётся), но производительность транслируемого без оптимизации под платформу отстойная, мягко говоря.

Где-то давненько на Ютубе видел семинари презентацию, где партнёры МЦСТ рассказывали, как они оптимизировали IonMonkey под Эльбрус. С наскоку не найду, но посмотреть интересно.

upd. А вот, нашёл

так трансляция-то не бинарника-же

А какая разница? Так-то все современные «интерпретаторы» на самом деле компиляют в байткод, т.е. тот же бинарник, только для виртуальной машины.

Я к тому, что если осилили эффективный in-time транслятор одного кода в другой, то значит наработки и компетенции есть. А если так, то в чём же дело? Тут как бы и все карты в руки, пилить скриптовые движки, которые рвут всё что шевелится.

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

Проблема с тем же, с чем была и при портировании LLVM. Байткод сильно «заточен» под архитектуру. И если просто тупо «собрать из сорцов» результат трансляции получается дико неоптимальным и производительность получается ЕМНИП процентов 30 в лучшем случае от оригинальной. А RTC, насколько я понимаю, работает только на уровне процесса.

Для LLVM, насколько я слышал, уже решили, транслируя байт-код (IR) из того, что делает LLVM в тот, что нужен LLC и собирая уже им. Что там решают с JS движками: вот выше ссыль нашёл.

А если так, то в чём же дело?

В людях. А точней в их количестве, бюджете и времени. Там всё МЦСТ меньше, ну может сравнимо, с тем, сколько народу пилит один V8. А задач много. Нужны партнёры. Вот UniPro JavaScript движками занялись, например.

Такой ещё вопрос, производительности тех процессоров «Эльбрус», которые можно производить на территории России, хватит для использования в банкоматах?

Мне кажется, там даже 386 хватило бы.

На счёт 386 не знаю, но тут пишут, что на 486 в своё время вполне работали:

ну ниче, вспомнят старые времена, упростят картинки на экране банкоматы на полуоси в 90е и нулевых запросто работали и на 486 компах

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

и ещё:

Ага. Кмк, производительность Эльбруса-2С3 избыточна на порядок или даже два :-).

Для половины задач банкомата — показать несколько картинок, считать сканкоды нескольких клавиш и отобразить какие-то символы на экране точно достаточно XT - 4MHz. Я это в школе делал на Turbo Pascal'е. :-)

Просто нужно делать не на Windows и не на Электроне.

Тогда вопрос в том, можно ли на территории России произвести процессор уровня 386.

Можно

Там сейчас основная нагрузка - от gui, который на джаваскрипте написан