У меня сложилось такое впечатление, что сейчас движки браузеров пишут на C (и никак иначе),
потому что важна максимальная производительность.
Никаких там C#.
В то же время, тот, кто владеет самым крутым браузером — владеет миром.
Почему тогда не оптимизируют выполнение JavaScript путём написания кода на ассемблере?
Ведь ресурсов у Яндекса/Гугла девать некуда, и
могут себе позволить соптимизировать под каждую аппаратную платформу.
Я понимаю, что "правило" 80% производительности дают 20% кода,
просто я не слышал о том, чтобы ядро браузера, те самые 20% писали бы на ассемблере.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Я понимаю, что "правило" 80% производительности дают 20% кода, ЭФ>просто я не слышал о том, чтобы ядро браузера, те самые 20% писали бы на ассемблере.
Джаваскрипт преобразуется в машинный код, который потом выполняется. Компилятор написан на C++, да, но его ускорять вряд ли получится, да и слишком он сложен и работает слишком мало, чтобы от этого была ощутимая польза. И 20% там точно не будет, т.к. все места, которые можно было бы ускорить на 20%, находятся в библиотеках и оптимизированы в крайнем случае на том же ассемблере.
Ассемблер полезен, когда процессор что-то умеет, а компилятор не умеет или никак не может догадаться задействовать эти специальные инструкции. В основном это всякие векторные инструкции. Или криптография. Тут да, может быть и 20% выигрыш и даже больше. Но это доли процента от общего кода проекта. Ещё ассемблер может быть полезен, чтобы за счёт нетрадиционных трюков сократить размер кода или размер используемой памяти. Но это нужно только в очень слабых процессорах, когда счёт идёт на килобайты. К браузерам это всё отношения не имеет. Ещё ассемблер нужен, когда не хочется иметь компилятор в виде чёрного ящика. Тут зачастую код нужен не самый быстрый, а определённый. Например в криптографии есть атаки побочных каналов. Например когда по измерению времени выполнения можно вычислить секретные данные. Программист может знать, что определённые команды процессора избавят его от этой проблемы. Но компилятор может эти команды не выдать. Или выдать сегодня, а завтра в следующей версии добавят хитрую оптимизацию, которая скомпилирует по-другому. Поэтому тут тоже могут писать на ассемлере. Это тоже к криптографии относится и находится в библиотеках.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Я понимаю, что "правило" 80% производительности дают 20% кода, ЭФ>просто я не слышал о том, чтобы ядро браузера, те самые 20% писали бы на ассемблере.
потому что даже очень хороший разработчик на ассемблере в среднем пишет менее оптимальный код чем генерирует современный компилятор.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Ну так на C# проще писать сложные программы. Его для этого проектировали. Почему не взлетает?
Оптимизацию надо начинать с алгоритмов. А тут в общем-то без разницы C# или C++. На C# проще некоторые вещи делать, так как есть готовые классы под много что, но это не принципиально.
Здравствуйте, Michael7, Вы писали:
M>Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>>Ну так на C# проще писать сложные программы. Его для этого проектировали. Почему не взлетает?
M>Оптимизацию надо начинать с алгоритмов. А тут в общем-то без разницы C# или C++.
Оптимизировать алгоритмы, конечно, надо. Но на одних и тех же алгоритмах C++ быстрее C#. Что не удивительно, т.к. C++ компилируется в машинный код, а C# — в байт-код, исполняемый виртуальной машиной.
M>На C# проще некоторые вещи делать, так как есть готовые классы под много что, но это не принципиально.
Библиотек для многих задач сейчас очень много под любой распространённый язык.
Здравствуйте, gardener, Вы писали:
МГ>>потому что даже очень хороший разработчик на ассемблере в среднем пишет менее оптимальный код чем генерирует современный компилятор.
G>Это не так. Очень хороший выбирает где писать, а где не писать, и в среднем написанный код обгоняет компилятор.
Здравствуйте, Эйнсток Файр, Вы писали: ЭФ>Я понимаю, что "правило" 80% производительности дают 20% кода, ЭФ>просто я не слышал о том, чтобы ядро браузера, те самые 20% писали бы на ассемблере.
Из первого тезиса никак не следует второй. T.e. то, что только в 20% кода боттлнек не означает, что для этих 20% надо использовать другой ЯП. Далее, в общем случае переписывание того или иного кода не грантирует прироста в производительности. Ваш капитан Очевидность.
ЭФ>Я понимаю, что "правило" 80% производительности дают 20% кода, ЭФ>просто я не слышал о том, чтобы ядро браузера, те самые 20% писали бы на ассемблере.
Современные программеры недостаточно квалифицированы, чтобы "переплюнуть" оптимизирующий компилятор.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>У меня сложилось такое впечатление, что сейчас движки браузеров пишут на C (и никак иначе), ЭФ>Почему тогда не оптимизируют выполнение JavaScript путём написания кода на ассемблере?
Еще раз, чтобы не скатываться в бессмысленное противопоставление Си и ассемблера:
современные движки JS это в первую очередь JIT-компиляторы, которые JS переводят даже не в ассемблер, а в машинные коды. И там, в переводе этом, еще как используется знание ассемблера, конечно.
Тупые интерпретаторы на С/С++ никто из браузеров в лоб не использует, поэтому и вопрос так не стоит.
Здравствуйте, AleksandrN, Вы писали: AN>Оптимизировать алгоритмы, конечно, надо. Но на одних и тех же алгоритмах C++ быстрее C#. Что не удивительно, т.к. C++ компилируется в машинный код, а C# — в байт-код, исполняемый виртуальной машиной.
ОМГ. Дотнету уже 20 лет, а чушь про него продолжает жить.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Почему тогда не оптимизируют выполнение JavaScript путём написания кода на ассемблере? ЭФ>Ведь ресурсов у Яндекса/Гугла девать некуда, и ЭФ>могут себе позволить соптимизировать под каждую аппаратную платформу.
ЭФ>Я понимаю, что "правило" 80% производительности дают 20% кода, ЭФ>просто я не слышал о том, чтобы ядро браузера, те самые 20% писали бы на ассемблере.
Потому, что ассемблер не добавляет перформанс автоматически, сам по себе. Он, кстати говоря, использовался некоторое время
1. структуры данных всё равно нужно проектировать и анализировать результат
2. распределение памяти, локальность(кеш) никто не отменял — в силу особенностей JS, здесь будет тотальный слив, пиши хоть на чем хошь. Вопрос только стоимости нового решения, см п3
3. ассемблерный код крайне тяжело анализировать, рефакторить и вообще что либо делать с ним, а следовательно он всегда кишит ошибками памяти, вычислений и тд.
4. управление регистрами, шиной уже лет 20 стало настолько сложным с т.з. перформанса, что не под силу даже продвинутому разработчику.
5. мультилатформенная разработка на ассемблере это Адский АДъ
Что бы добиться перформанса и иметь внятный перформанс, команда JS V8 давно уже нашла замену чистому ассемблеру. Критические вещи на нём и пишутся, эдакий ассемблероподобный дсл, только кроссплатформенный. Так шта всё в порядке.
Здравствуйте, gardener, Вы писали:
G>Это не так. Очень хороший выбирает где писать, а где не писать, и в среднем написанный код обгоняет компилятор.
Я так понимаю то что обгоняет это просто вера? Я ещё 15 лет назад видел потуги не самых глупых людей обогнать интеловский компилятор, и у них в лучшем случае выходило сравнимо, а если надо было оптимизировать под разные поколения процессоров вообще всё было грустно, единственное оговорюсь что при этом надо было хорошо знать возможности компилятора — аттрибуты-хинты, интринсики, и умело их применять, но это несравнимо проще и продуктивней чем писать на ассемблере, и всё переписывать с выходом новой архитектуры CPU. Вряд ли с тех пор что-то сильно поменялось.
Здравствуйте, Эйнсток Файр, Вы писали:
I>> ассемблероподобный дсл, только кроссплатформенный
ЭФ>Вроде бы язык C был как раз для этого же создан...
Почти. Код пишется на языке Си, но требует специально компилера для built-in функций, написаных на CSA.
CSA — это и есть внутренний дсл, который компилируется с помощью mksnapshot и генерирует разную начинку в зависимости от платформы: https://v8.dev/blog/csa
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, AleksandrN, Вы писали: AN>>Оптимизировать алгоритмы, конечно, надо. Но на одних и тех же алгоритмах C++ быстрее C#. Что не удивительно, т.к. C++ компилируется в машинный код, а C# — в байт-код, исполняемый виртуальной машиной. S>ОМГ. Дотнету уже 20 лет, а чушь про него продолжает жить.
В смысле чушь? У C# есть jitter, который компилирует msil в натив. То что выше написано вроде верно про яву, у них(jvm) есть jit?