Я часто привожу такой тезис — несмотря на все недостатки JavaScript, сейчас это уже довольно мощный и многоцелевой инструмент, одним из важнейший достоинств которого для бизнеса является существенно более высокая скорость разработки. То есть написать код и решить задачу на JS часто бывает намного быстрее, чем на «нормальном» языке и результат получается вполне удовлетворительным. Уменьшить количество багов помогает надстройка над JS в виде TypeScript. В качестве контр-аргумента мне часто приводят низкую производительность кода на JavaScript. Я не являюсь поклонником JS, но мне стало интересно — насколько медленным является современный JS в сравнении с «взрослыми», компилируемыми языками.
Производительность разных языков зависит от задач, но есть общие моменты, такие как управление памятью, арифметические операции, которые, как мне кажется, позволяют максимально точно получить представление о производительности реализации алгоритма на том или ином языке.
Я решил взять какой-нибудь простой алгоритм с целочисленной арифметикой и реализовать его на нескольких языках максимально идентично. Мое исследование не претендует на серьезный бенчмарк и тем более я никого не уговариваю срочно переходить на JS или C# или какой-либо другой язык.
Я выбрал задачу генерирования последовательности простых чисел. Вот так выглядит реализация на С:
#include "stdafx.h"
#include <cstdio>
#include <ctime>
int main()
{
int Max = 500000;
int nums[100000]; //100 тыщ
nums[0] = 2;
int j = 1;
clock_t t;
t = clock();
for (int cur = 3; cur < Max; cur += 2) {
int half = cur / 2;
bool isPrime = true;
for (int i = 0; nums[i] <= half; i++) {
if ((cur % nums[i]) == 0) {
isPrime = false;
break;
}
}
if (isPrime) {
nums[j] = cur;
j++;
}
}
t = clock() - t;
printf("Time to gen %d primes (up to 500 000) : %f seconds.\n", j, ((double)t) / CLOCKS_PER_SEC);
return 0;
}
Также я реализовал этот алгоритм на C#, Delphi и JavaScript полностью идентично, насколько это возможно. Я использую Windows 10, поэтому использовались следующие инструменты:
для С — компилятор из Visual Studio 2019 CommunityВыполнение вычислений из приведенной выше программки на С заняло на моем компьютере 1,2 секунды. Это лучший результат из 4-х языков, которые я сравнивал.
для C# — .NET Core SDK 2.2.300
для Delphi — Delphi XE Win32 (2010 года)
для JS — Node.js v. 10.16
Как вы думаете, в каком порядке выстроились остальные языки по увеличению времени работы и уменьшению производительности соответственно? Какой язык оказался самым медленным? Насколько сильный разрыв между между результатами других языков?
Через несколько дней я дополню статью результатами, а пока предлагаю проголосовать и написать свое мнение в комментариях.
P.S. (на следующий день)
Уже накопился достаточный результат голосования. Спасибо всем, кто проголосовал.
Спасибо тем, кто указал на недостатки данной задачи для применения ее в качестве бенчмарка.
Те кто спрашивал про «сколько раз запускались тесты» — отвечаю «не менее 10 раз» и на расстановку мест это никак не повлияло.
Теперь про результаты.
1. Компилятор Delphi хоть и достаточно старый и генерирует 32-битный код, тем не менее этот код нативный и для данной задачи достаточно оптимальный. Отставание от самого современного компилятора С/С++ составило менее 10%. Результат программы на Delphi — 1,34 секунды (против 1,2 секунды у C/C++).
2. Node.js, начиная с версии 8 довольно заметно подтянулся в скорости, это замечали многие на многих задачах. В данной задаче результат JS — 2,15 секунды. То есть данный алгоритм, будучи реализованным на JS уступает реализации на C/C++ менее чем в 2 раза.
3. Результат C# — (обновлено) 1,9 секунды при использовании списка и массива. Предыдущая моя информация тут была недостоверна, так как я забыл удостовериться, чтобы запускалась версия, собранная в релиз (запускал из командной строки). Я действительно знаком с C# на уровне «Hello World».
30,6% проголосовавших за вариант «C, Delphi, C#, JavaScript — Delphi уделывает C# и JS» — оказались правы. Другое дело, что разница результатов C# и JavaScript очень невелика.
Какими доводами можно объяснить 15% голосов за «C, C#, JavaScript, Delphi» и почти 13% за «C, Java Script, C#, Delphi» — у меня нет идей. То есть, по моему мнению, 28% проголосовало не представляя себе, что такое Delphi.
24% проголосовавших за вариант «C, C#, Delphi, JavaScript» видимо выражали надежду на то, что современные компилятор и среда исполнения C#, несмотря на свои архитектурные особенности, все таки одолеют устаревший компилятор Delphi. Были комментарии о том, как крута Java сейчас. Но тем не менее компиляторы, генерирующие нативный процессорный код, все же немного эффективнее.
Вместо вывода
В данном эксперименте меня удивили 3 пункта:
1. Довольно хороший результат JavaScript (исправлено).
2. Неадекватно-агрессивная и даже болезненная (как я считаю) реакция очень многих читателей на простое предложение порассуждать о производительности современных языков программирования. Я не знаю в чем причина — в ненависти к JavaScript или ко мне лично, но хотелось бы понимать эту причину (в комментариях мне уже разъяснили — написание Java Script — с пробелом — вызывает приступы ярости).
3. Некоторые из комментировавших потрудились написать комментарий и дать ссылки на другие бенчмарки, но при этом затруднились сформулировать собственное мнение по заданному вопросу хотя бы на основе разглядывания картинок по ссылкам, которые они привели. Если уж вы следите за бенчмарками и у вас есть мнение о языках, то почему не высказать его? А так получается, что «я знаю там есть ответ, но какой там ответ — я не знаю». Мне кажется так проявляется эффект постоянного наличия поисковика под рукой — можно не держать в голове знания и даже не иметь собственного мнения, ведь их всегда можно «погуглить».
Спасибо всем, кто принял участие в опросе!
Комментарии (109)
madison2201
12.06.2019 19:41-1А где холивар?
gbg
12.06.2019 19:43+3Тестовый пример выбран довольно-таки неудачным образом — Решето Эратосфена — это линейный алгоритм, не допускающий особых оптимизационных ускорялок, на которых компилятор либо рантайм могли бы показать себя с лучшей стороны.
Не зря же для вычислений стандартными пузомерками являются линпак/лапак и их родственники. Тут и возможность применения SIMD, и раскрутка циклов, и учет ширины кэш-линии (в ATLAS широко применено последнее).
Ну и для интеловских процессоров есть условный эталон в виде MKL — если его некто обгонит на JS, классные пацаны из Интела наверняка опустошат полки соусов Киккоман — не насухую же им есть свои подметки.igor-sheludko Автор
12.06.2019 19:49-6Ну вот как раз хотелось сделать так, чтобы без хитрых ускорений, максимально равные условия. Задача — не посмотреть, кто умеет лучше ускорять конкретные алгоритмы, а какое нынче состояние JS относительно других в самом общем случае.
Neikist
12.06.2019 21:37+3Но ведь в том и суть более низкоуровневых и статически типизированных языков что больше возможностей для оптимизаций как человеком так и компилятором…
venco
12.06.2019 23:44+2Это не Решето Эратосфена. Это вообще ужасно медленный алгоритм, в котором проверяется скорость деления.
igor-sheludko Автор
13.06.2019 07:54Справедливое замечание — деления и сравнения — основные операции там, а также работа с памятью.
Siemargl
12.06.2019 19:50+8Статья должна называться — «Если рекрутер начнет учить вас программировать»!
Ну и конечно, лучше ознакомиться с исходниками и алгоритмами на benchmarksgame хотя бы.igor-sheludko Автор
12.06.2019 20:08-5Так и все таки ваше мнение по заданному вопросу какое?
Siemargl
12.06.2019 23:45Чтобы задать правильный вопрос, надо знать хотя бы половину ответа.
Это из «Универсального ответчика» Шекли.
Заголовок спойлераЧтобы заниматься тестированием, нужно иметь некоторый опыт
Mox
12.06.2019 19:54-4Я пишу на Ruby и JS. Все таки скорость разработки на JS ниже чем на Ruby — именно потому что «так себе язык»
igor-sheludko Автор
12.06.2019 20:09-2По вашим ощущениям, насколько быстрее разрабатывается на Ruby?
igor-sheludko Автор
12.06.2019 20:11Хотелось бы увидеть обоснованные предположения уважаемых инженеров :)
Vadem
12.06.2019 20:15+4Зачем изобретать велосипед?
Есть же уже куча сравнений.
Например, Benchmarks Game и TechEmpower Benchmarks.igor-sheludko Автор
14.06.2019 12:13Зачем самостоятельно смотреть вживую несколько моделей авто и проходить несколько тест-драйвов в авто-салонах, ведь есть же обзоры в журнале За Рулем?
twinklede
14.06.2019 12:41Например, Benchmarks Game
Здесь тот, кто «за рулём» не совсем адекватен. Он не хочет меня мусорный core2 на адекватное железо, у него постоянно какие-то проблемы с принятием «спорных» решений.
sfi0zy
12.06.2019 20:19+3Не холивара ради, а интереса для задам вопрос: а какая практическая ценность подобных сравнений производительности JS и «нормальных» языков на таких алгоритмах? Можно сказать в вакууме. Сколько я видел применение JS — везде были задачи очень далекие от сложных вычислений. А когда кто-то говорил, что JS тормозит, то это либо был ужасный код, который где угодно будет тормозить, либо какие-то местные баги/фичи, которые связаны не с языком, а со средой исполнения (пример для людей из других областей — проседание fps в браузере можно получить путем простого обращения к некоторым свойствам элементов на странице). Понятно, что тот же C++ в браузере особо не запустишь, но если бы запустили, то уперлись бы в те же самые фичи и никакая теоретическая производительность не помогла бы.
greg123
13.06.2019 12:09А какова практическая ценность вычисления числа пи с точностью до миллиарда знаков?
serf
13.06.2019 13:42Понятно, что тот же C++ в браузере особо не запустишь
Еще как, и Rust и Go тоже, киворд — web assembly.sfi0zy
13.06.2019 14:15Есть небольшая тонкость: эта технология дает нам песочницу для исполнения кода, но с остальным браузером все можно связать только через прослойку из JS. Тут разные языки работают вместе и есть свои особенности, влияющие и на производительность в том числе. Я же говорю про теоретическое чистое сравнение, если бы мы полностью заменили JS на C++ и стали бы решать уже имеющиеся задачи на нем.
serf
13.06.2019 15:24Безусловно прослойка существует, как передача данных между процессами значительноо влияет на общее воприятие производительности (сериализация). Web assembly очевидно не является серебрянной пулей, но технология развивается и в некоторых случаях уже может быть полезна.
aamonster
12.06.2019 20:24Будет интересно потом посмотреть реализацию на C# – кажется, именно тут можно написать две почти одинаковые программы, работающие с сильно разной скоростью.
Ну и на JS можно и в webasm уйти :-)
Короче, увидим, насколько вы хороши в оптимизации на 4 языках :-D
igor-sheludko Автор
13.06.2019 15:12Никаких оптимизаций, максимально одинаковая реализация.
using System; using System.Linq; using System.Collections; using System.Diagnostics; using System.Collections.Generic; namespace ConsoleApp1 { class ConsoleProgram { static void Main(string[] args) { Stopwatch sw = new Stopwatch(); // список var nums4 = new List<int> {2, 3}; const int Max = 500000; sw.Start(); for (int cur=5; cur < Max; cur+=2) { int half = cur / 2; bool isPrime = true; for (int i = 0; nums4[i] <= half; i++) { if ((cur % nums4[i]) == 0) { isPrime = false; break; } } if (isPrime) { nums4.Add(cur); } }; sw.Stop(); Console.WriteLine("Время генерации {0} простых чисел (список) от 0 до {2}: {1} миллисекунды", nums4.Count.ToString(), sw.ElapsedMilliseconds.ToString(), Max.ToString() ); // массив int[] nums5 = new int[100000]; nums5[0] = 2; nums5[1] = 3; int j = 2; sw.Restart(); for (int cur = 5; cur < Max; cur += 2) { int half = cur / 2; bool isPrime = true; for (int i = 0; nums5[i] <= half; i++) { if ((cur % nums5[i]) == 0) { isPrime = false; break; } } if (isPrime) { nums5[j] = cur; j++; } } sw.Stop(); Console.WriteLine("Время генерации {0} простых чисел (статический массив) от 0 до {2}: {1} миллисекунды", j.ToString(), sw.ElapsedMilliseconds.ToString(), Max.ToString() ); } } }
picul
12.06.2019 20:59Тоже мне сравнение. Ясное дело, что к 2019 году во все широко используемые языки завезли JIT, который подобные числодробилки сразу же переведет в машинный код. А дальше уже зависит от того, на какой платформе функция получения текущего времени работает быстрее.
Как Вам уже написали выше, для того что бы ощутить преимущества нормальных без кавычек языков — нужно эти самые преимущества использовать. В даной ситуации стоило хотя бы SIMD использовать.igor-sheludko Автор
13.06.2019 08:35Вы правы в случае, когда при реализации задачи ставится критерий «максимальная производительность». Но будем честными, в большинстве случаев — работает основной критерий «сделайте фичу поскорее» и тогда все работает по дефолту и мало кто трудится над оптимизациями. И только когда прилетит задача «вот тут вот слишком медленно работает» начинается реальная работа по оптимизации.
picul
13.06.2019 14:33Ну то, что на JavaScript'е обычно пишут быдлокод по-быстрому — я не отрицаю. Но если уж Вы хотите сравнить языки в реальной ситуации, то нахождение простых чисел — не тот вариант.
zeronice
12.06.2019 21:23+1А где флаги запуска\компиляции\сборки? Можно подогнать под любое ранжирование, если умолчать, с какими опциями делали.
lostmsu
12.06.2019 21:28+2Хз как сравнить Delphi и C#, но если не налажать с опциями компиляции, то должно быть C > C# & Delphi > JavaScript с небольшой разницей. Но бенчмарк — говно, т.к. арифметика в языках — самое простое. Большая часть современных программ работает с иерархиями объектов, и вот как раз там JS соснёт по-полной, см тот же benchmarks game.
Boctopr
12.06.2019 21:36+1#include <cstdio> #include <ctime>
это C++, а то есть адаптированные C функции в область видимости std::
также по умолчанию visual studio компилирует все C++ единицу трансляции нужно делать extern «C», или вызывать компилятор с флагами для компиляции C
Nagg
12.06.2019 21:41+3C# для такого кода в LLVM бэкендом сгенерит сравнимый по выходу код с Си (Mono-LLVM, Burst). Если компилить Си через clang то собсно сравнивать не особо имеет смысла.
Короче, автор, тут такое не любят — как правило во всех статьях подобного рода на выходе получается бестолковый бенчмарк.
twinklede
13.06.2019 12:11C# для такого кода в LLVM бэкендом сгенерит сравнимый по выходу код с Си (Mono-LLVM, Burst).
На подобном коде будет почти везде одно и тоже. Даже на жаваскрипте.
Короче, автор, тут такое не любят — как правило во всех статьях подобного рода на выходе получается бестолковый бенчмарк.
Ну это просто неправда. Тут такое любят. Достаточно посмотреть на такой же хелворд в статье «хаскель может», там тысячи плюсов. Все было так же, если не хуже. Попросту неверные измерения, читы в хаскеле без указаний нюансов(т.е. манипуляция), а после неудача с многопотоком у хаскеля. Ну и, как обычно, автор выдавал свой хелворд за «показательный пример, а не очередной факториал», но это был именно он. И в нём даже нода показывала результаты уровня хаскеля.
Nagg
13.06.2019 12:16На подобном коде будет почти везде одно и тоже. Даже на жаваскрипте.
на подобном — да, но в целом думаю жс по оптимизациям очень сильно отстанет по перфу — всякие автовекторизации — это все не про жс.
Ну это просто неправда. Тут такое любят.
Все статьи такого рода заминусованы, ваш пример про Хаскель — это не про мейнстрим. А так во всех бенчмарках автор никогда не обладает глубокими знаниями во всех языках/платформах которые он тестирует
Neikist
12.06.2019 21:42Еще добавлю про скорость разработки — я без статической типизации на кодовой базе от хотя бы сотни KLOC скорее выдавал бы код медленнее и с большим количеством багов. Не говоря уж про средние и большие проекты. Говорю как человек перешедший с динамики на статику. Есть конечно тайпскрипты и дарты, но в том же дарте, например в сравнении с котлином, багов побольше можно допустить. Да и это все таки уже другие языки.
amarao
12.06.2019 22:07Rust? KLOC/hr меньше, но и багов на строку кратно меньше. Экономия времени на отладке переходит из линейной в степенную при появлении многопточности.
Neikist
12.06.2019 22:31До раста руки так и не дошли, только недавно перешел с 1с на java/kotlin. В планах пока только хаскел все таки пощупать, и то не скоро.
0xd34df00d
13.06.2019 05:36Сотни kloc? А вы хороши! Я ломаюсь на сотне loc, без всяких k.
Neikist
13.06.2019 08:11От проектов зависит. Так то первые баги я допускать начинаю очень заметно раньше даже на несложных проектах, но до какого то момента еще есть выигрыш, исправление багов немного времени занимает. Но вот на 100+ уже становится совсем грустно мне.
Atreides07
12.06.2019 23:05Как часто на практике решают проблему генерирования простых чисел? Логично что сранивать js с компилируемым языками имеет смысл при разработке серверных приложений.
Так почему бы просто не посмотреть на результаты сравнения node.js с другими фреймворками, где вы легко увидете что Node.js на порядок отстает от упомянутых вами компилируемых языков?
https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintextDarthVictor
13.06.2019 10:23Справедливости ради, в приведенном тесте рядом с нодой результаты вполне себе компилируемых Kotlin, C#, Scala, Java. Глянув исходники теста, легко заметить, что тест мереет в основном скорость веб-сервера.
GennPen
12.06.2019 23:25Производительность разных языков зависит от задач, но есть общие моменты, такие как управление памятью, арифметические операции, которые, как мне кажется, позволяют максимально точно получить представление о производительности реализации алгоритма на том или ином языке.
Я решил взять какой-нибудь простой алгоритм с целочисленной арифметикой и реализовать его на нескольких языках максимально идентично.
Не совсем верно. Много вы видели программ с чистым арифметическим расчетом? В 90% случаев подавляющее большинство в программе — чистая логика.
Сделайте тест например по созданию 100500 объектов/экземпляров различных классов и их различные вызовы методов и посмотрите как различные языки справляются с подобной нагрузкой, включая утилизацию памяти, работу сборщика мусора и т.п.
И да, можете объяснить, почему вы назвали C# «компилируемым языком»?
kruslan
12.06.2019 23:54Даже интересно стало, а поменялось-ли что-то с 2011-го года? bolknote.ru/all/3290 bolk, повторных экспериментов не было?
SerafimArts
13.06.2019 03:22Я может покажусь странным, но где PHP? Всё же с JIT он будет местами на уровне gcc -o2.
У меня даже пруфы будут:
Заголовок спойлера
Anton23
Почему столько минусов и нет комментариев?
Статья выглядит немного бредово.
Голосование внизу — очень странное.
Почему нигде нет Java на первом месте(я не говорю что быстрее, но все таки)?
Причем тут Делфи? Не очень знаком с его особенностями, но я не слышал, чтобы он был быстрее той же Java или C#.
Почему есть C, Delphi, C#, и т.п. но нет C++?
igor-sheludko Автор
Я на Java — не умею :) Но понятно, что ее результат будет точно хуже C.
Для данной задачки разницы между C и C++ практически нет.
Чисто логически — дельфи компилирует в нативный код процессора, а Java и C# — в промежуточный, что уже намекает на неоптимальность.
yarosroman
погугли, что такое .Net Native для начала. Второе, а сколько раз у тебя тест запускался? а после отработки jit тест запускался, замерялась производительность? миф о том, что .net и java в байт-код компилируются и поэтому медленнее уже опровергнут. Разработчики SO точно с тобой не будут согласны.
Neikist
Будем честными, jit и прогрев это тоже время. И если на беке с постоянно работающими сервисами норм такое, то для пользователя не очень. Именно поэтому меня радует андроид где совместили jit и aot.
Nagg
В .NET уже много лет совмещен АОТ и JIT — все базовые библиотеки проАОТченны. Компилируется только код пользователя (причем сперва без оптимизация для быстрого старта), а потом в ходе работы горячие методы могут быть перекомпилированы (даже АОТ код).
0xf0a00
Угу… все так радужно, пони бабочки… упс, тест выполнился почти в 5 раз медленее чем JS… упс, почти в 10 раз медленнее чем C.
Если все много лет так хорошо, то фигли так медленно?
Nagg
1) АОТ+JIT — это про быстрый запуск, а не перформанс
2) Про в 5 раз медленее чем жс только сейчас придумали? :) Покажите код, а то мы глупые переписываем С++ в C# и почему-то не теряем перф
0xf0a00
Код вам надо просить у ТС, а не у меня. Глупые? Не знаю, это очень субъективно, возможно вы просто дешевле чем плюсовики того же уровня.
Nagg
По правде говоря у меня нет ни малейшего сомнения в том что автор некомпетентен в вопросе. Я посмотрел asm аналогичного кода на C# и не увидел разницы с Си вообще (правда смотрел .net core 3.0).
Под "мы" я имел ввиду людей, которые пишут сам рантайм .NET если что ;-)
0xf0a00
Ну вот, у вас есть отличная возможность это доказать, да еще и опровергнуть эти позорные 9,4 секунды.
Ametrin
Собственно, у меня на шарпе за 1.8-2.1 секунд выполняется. Можно считать результат автора опровергнутым?
igor-sheludko Автор
Да, вы правы. Это была моя ошибка, я исправил данные в статье.
Nagg
Проверил на .NET Core 3.0:
C#: 0.85 секунд, если запиннить массив или заалоцировать его через stackalloc ради того, чтобы не было излишних проверок выхода за пределы массива — то 0.75 сек (т.е. сделать так же как в С/С++)
C++: 0.75 (MSVC, есть вероятность что правильно настроенный clang/LLVM смогут чуть быстрее, но надо проверять — но т.к. у C# тоже есть LLVM бэк — сделать быстрее не получится).
Larymar
а, что у вас за железо, просто мои результаты почти в 2е больше (ryzen 5 1600 (3.8GHz))
1.827 -c gcc 7.4.0
1.850 -c# netcore 3.0
1.834 -java 11
1.830 -node.js 8.10
Старался сохранить код автора на каждой платформе
к сожалению использование stackalloc не позволило догнать с, но явно ускорило со временем 1.832
(среднее время на 10 запусков, не считая холодный)
twinklede
Интел. Судя по времени что-то из последних итераций.
Это амд. У него медленнее целочисленное деление(вообще и в частности данный кейс).
Попробуйте заменить (cur % nums[i]) на modi(cur, nums[i]). fp div там должен быть примерно идентичным.
Как это собиралось?
Тут нечего догонять. Этот «бенчмарк» ничего не измеряет.
Larymar
а где можно с этим ознакомится?
gcc -o task task.c
twinklede
Есть мануалы от вендора(есть ли оно у АМД я не знаю), есть результаты полученные измерениями. Результаты подобных измерений есть и в интернете. Допустим это и это
Неправильно. godbolt.org/z/z4B1P7
habr.com/ru/post/454998/#comment_20275472 — типичное проявление «неправильно».
Можно начать c -O2/03 для начала.
Larymar
спасибо, не пишу на сях вообще, было просто интересно
почистил вам карму)
picul
У АМД медленный branch predictor (который тут эксплуатируется на полную во внутреннем цикле) — это тоже существенный повод для отставания.
igor-sheludko Автор
Спасибо за участие в эксперименте и за то, что не поленились на java потестировать.
Zam_dev
Nagg, не забрасывай, пожалуйста urhosharp)
twinklede
Покажите код.
0xd34df00d
2. Это сильно зависит от задачи. У меня есть случаи, когда переписывание числодробилки с хаскеля на плюсы вообще не меняло производительность, и есть случаи, когда она отличалась на 4-6 порядков.
twinklede
Я даже не знаю как объяснить. Если проще. Вы выбрали(специально/случайно) такую задачу, которая а) целиком и полностью не оптимизируется. б) скрывает многие негативные эффекты «не оптимальных языков». Обычно такие задачи специально выбирают приверженцы так называемых вами «не оптимальных языков» для демонстрации «разницы нет».
Приведу простой пример, тут есть «cur % nums[i]» — это деление. Оно медленная. Но дело не только в этом. Процессор устроен таким образом, что он может параллельно исполнять другие инструкции. И такие операции(на десятки/сотню тактов) очень удобны. Процессор может параллельно с ними выполнить какие-то вычисления.
Это может быть просто плохой код. Он может быть в разы медленнее. Если проще. Хороший код выполняется 10 тактов. Плохой 20. Но это абсолютно неважно потому что деление выполняется 50 и параллельно с ним можно выполнить лишние операции. Аналогично там могу стоять множество jit-ловушек, проверок границ и т.п.
Это так же помогает то, что код сам по себе компактный. Процессор может смотреть на несколько итераций вперёд.
ZurgInq
Сам по себе язык не может быть быстрее. Вот разные компиляторы могут генерировать разный код. Программы на делфи компилируется в нативный код, а Java и C# исполняются в виртуальной машине, следовательно при прочих равных, компиляция в нативный код даст большую производительность. Другое дело, что компилятор делфи сам по себе может быть далек от совершенства.
Neikist
Ну байт код жавы также можно aot компилять, можно вообще как в ART на андроид реализовано, со сбором профилей девайсов и aot компиляцией по этим профилям под конкретный девайс и сценарии использования.
MSC6502
Да, да, да, скорость компиляции 300-380 тысяч строк в секунду у Delphi это как бы медленно? А сборка проекта на C два-три часа это офигенно быстро?
ZurgInq
Про скорость компиляции никто и не говорил. Учитывая контекст статьи, речь конечно же идёт о скорости исполнения полученного кода.
Siemargl
Плохой нативный код не быстрее хорошего JITа. Кроме времени запуска/предкомпиляции.
Только разнообразные тесты и цифры дадут картинку.
Nagg
Хороший тоже. Представьте что JIT может по ходу использования приложения понять как лучше его скомпилировать — делать спекулятивные оптимизации, откатывать их если нужно. Понимать что какие-то бранчи никогда не используются, передвинуть более популярные и т.п. — всё что есть в "нативном коде" (подразумевается АОТ) — это только если у вас есть какой-то обобщенный профайл поведения программы. К тому же на высших слоях JIT может использовать тот же самый бэкенд что и С/С++ — ллвм.
Siemargl
Это только теория. Практикой не подтверждено.
Кроме того, затраты на JIT очень существенные.
Nagg
У вас огромный опыт в HotSpot/XING/Falcon чтобы так говорить или это чужое мнение?
Siemargl
У меня огромный опыт выслушивания голословных утверждений.
Может у Вас есть подтверждения?
yarosroman
Сразу видно, знакомы с программированием на уровне Hello word. Уже давно и Aot для java есть и .net native. плюс про выполнение в виртуальной машине не совсем верно. Погуглите, что такое JIT.
Siemargl
Кстати, было бы неплохо посмотреть живое сравнение (и перепроверить) с «net native» против типичной сборки без «net native».
А то я вижу пока только рекламные слоганы.
Если можно, то про AOT для java аналогично.
Не верю в бигфутов etc. Хотелось бы пощупать.
ZurgInq
Упоминание в каждом посте очевидных вещей и установка диагноза по фотографии не делает человека умнее.
FreeBa
C# никогда не исполнялся в виртуальной машине. Он всегда был JIT-компилируемым.