Периодически, беседуя при найме с кандидатами, а также коллегами, слышу высказывания плохого мнения о JavaScript от «бывалых» программистов, привыкших писать на C++, Java, C#, Delphi. В дискуссиях на тему «JS — это вообще не язык» я не участвую, но когда заходит речь про эффективность, производительность, скорость разработки — я люблю послушать и высказаться.
Я часто привожу такой тезис — несмотря на все недостатки 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
для C# — .NET Core SDK 2.2.300
для Delphi — Delphi XE Win32 (2010 года)
для JS — Node.js v. 10.16
Выполнение вычислений из приведенной выше программки на С заняло на моем компьютере 1,2 секунды. Это лучший результат из 4-х языков, которые я сравнивал.
Как вы думаете, в каком порядке выстроились остальные языки по увеличению времени работы и уменьшению производительности соответственно? Какой язык оказался самым медленным? Насколько сильный разрыв между между результатами других языков?

Через несколько дней я дополню статью результатами, а пока предлагаю проголосовать и написать свое мнение в комментариях.

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)


  1. Anton23
    12.06.2019 19:30
    +3

    Почему столько минусов и нет комментариев?

    Статья выглядит немного бредово.
    Голосование внизу — очень странное.
    Почему нигде нет Java на первом месте(я не говорю что быстрее, но все таки)?
    Причем тут Делфи? Не очень знаком с его особенностями, но я не слышал, чтобы он был быстрее той же Java или C#.
    Почему есть C, Delphi, C#, и т.п. но нет C++?


    1. igor-sheludko Автор
      12.06.2019 19:45
      -8

      Почему нигде нет Java на первом месте(я не говорю что быстрее, но все таки)?

      Я на Java — не умею :) Но понятно, что ее результат будет точно хуже C.

      Почему есть C, Delphi, C#, и т.п. но нет C++

      Для данной задачки разницы между C и C++ практически нет.

      Причем тут Делфи? Не очень знаком с его особенностями, но я не слышал, чтобы он был быстрее той же Java или C#

      Чисто логически — дельфи компилирует в нативный код процессора, а Java и C# — в промежуточный, что уже намекает на неоптимальность.


      1. yarosroman
        13.06.2019 02:05
        -1

        погугли, что такое .Net Native для начала. Второе, а сколько раз у тебя тест запускался? а после отработки jit тест запускался, замерялась производительность? миф о том, что .net и java в байт-код компилируются и поэтому медленнее уже опровергнут. Разработчики SO точно с тобой не будут согласны.


        1. Neikist
          13.06.2019 08:12

          Будем честными, jit и прогрев это тоже время. И если на беке с постоянно работающими сервисами норм такое, то для пользователя не очень. Именно поэтому меня радует андроид где совместили jit и aot.


          1. Nagg
            13.06.2019 10:10

            В .NET уже много лет совмещен АОТ и JIT — все базовые библиотеки проАОТченны. Компилируется только код пользователя (причем сперва без оптимизация для быстрого старта), а потом в ходе работы горячие методы могут быть перекомпилированы (даже АОТ код).


            1. 0xf0a00
              13.06.2019 11:13
              -2

              Угу… все так радужно, пони бабочки… упс, тест выполнился почти в 5 раз медленее чем JS… упс, почти в 10 раз медленнее чем C.
              Если все много лет так хорошо, то фигли так медленно?


              1. Nagg
                13.06.2019 12:14

                1) АОТ+JIT — это про быстрый запуск, а не перформанс
                2) Про в 5 раз медленее чем жс только сейчас придумали? :) Покажите код, а то мы глупые переписываем С++ в C# и почему-то не теряем перф


                1. 0xf0a00
                  13.06.2019 12:24

                  Код вам надо просить у ТС, а не у меня. Глупые? Не знаю, это очень субъективно, возможно вы просто дешевле чем плюсовики того же уровня.


                  1. Nagg
                    13.06.2019 12:27
                    +2

                    По правде говоря у меня нет ни малейшего сомнения в том что автор некомпетентен в вопросе. Я посмотрел asm аналогичного кода на C# и не увидел разницы с Си вообще (правда смотрел .net core 3.0).


                    Под "мы" я имел ввиду людей, которые пишут сам рантайм .NET если что ;-)


                    1. 0xf0a00
                      13.06.2019 12:31
                      -1

                      у меня нет ни малейшего сомнения в том что автор некомпетентен в вопросе

                      Ну вот, у вас есть отличная возможность это доказать, да еще и опровергнуть эти позорные 9,4 секунды.


                      1. Ametrin
                        13.06.2019 13:17
                        +2

                        Собственно, у меня на шарпе за 1.8-2.1 секунд выполняется. Можно считать результат автора опровергнутым?


                        1. igor-sheludko Автор
                          13.06.2019 14:11

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


                      1. Nagg
                        13.06.2019 14:57

                        Проверил на .NET Core 3.0:
                        C#: 0.85 секунд, если запиннить массив или заалоцировать его через stackalloc ради того, чтобы не было излишних проверок выхода за пределы массива — то 0.75 сек (т.е. сделать так же как в С/С++)


                        C++: 0.75 (MSVC, есть вероятность что правильно настроенный clang/LLVM смогут чуть быстрее, но надо проверять — но т.к. у C# тоже есть LLVM бэк — сделать быстрее не получится).


                        1. Larymar
                          13.06.2019 22:39

                          а, что у вас за железо, просто мои результаты почти в 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 запусков, не считая холодный)


                          1. twinklede
                            14.06.2019 02:12

                            а, что у вас за железо

                            Интел. Судя по времени что-то из последних итераций.

                            просто мои результаты почти в 2е больше (ryzen 5 1600 (3.8GHz))

                            Это амд. У него медленнее целочисленное деление(вообще и в частности данный кейс).

                            Попробуйте заменить (cur % nums[i]) на modi(cur, nums[i]). fp div там должен быть примерно идентичным.

                            int modi(float/*double*/ a, float/*double*/ b) { return int(a) - (int(a / b) * b); }


                            1.827 -c gcc 7.4.0

                            Как это собиралось?

                            к сожалению использование stackalloc не позволило догнать с, но явно ускорило со временем 1.832

                            Тут нечего догонять. Этот «бенчмарк» ничего не измеряет.


                            1. Larymar
                              14.06.2019 10:22

                              Это амд. У него медленнее целочисленное деление(вообще и в частности данный кейс).

                              а где можно с этим ознакомится?
                              Как это собиралось?

                              gcc -o task task.c


                              1. twinklede
                                14.06.2019 10:47

                                а где можно с этим ознакомится?

                                Есть мануалы от вендора(есть ли оно у АМД я не знаю), есть результаты полученные измерениями. Результаты подобных измерений есть и в интернете. Допустим это и это

                                gcc -o task task.c

                                Неправильно. godbolt.org/z/z4B1P7

                                habr.com/ru/post/454998/#comment_20275472 — типичное проявление «неправильно».

                                Можно начать c -O2/03 для начала.


                                1. Larymar
                                  14.06.2019 13:16

                                  спасибо, не пишу на сях вообще, было просто интересно
                                  почистил вам карму)


                            1. picul
                              14.06.2019 12:48
                              +1

                              У АМД медленный branch predictor (который тут эксплуатируется на полную во внутреннем цикле) — это тоже существенный повод для отставания.


                          1. igor-sheludko Автор
                            14.06.2019 14:36

                            Спасибо за участие в эксперименте и за то, что не поленились на java потестировать.


                    1. Zam_dev
                      14.06.2019 09:51

                      Nagg, не забрасывай, пожалуйста urhosharp)


                1. twinklede
                  13.06.2019 15:30

                  Покажите код, а то мы глупые переписываем С++ в C# и почему-то не теряем перф

                  Покажите код.


                1. 0xd34df00d
                  13.06.2019 16:01

                  2. Это сильно зависит от задачи. У меня есть случаи, когда переписывание числодробилки с хаскеля на плюсы вообще не меняло производительность, и есть случаи, когда она отличалась на 4-6 порядков.


      1. twinklede
        13.06.2019 16:20

        Для данной задачки

        Я даже не знаю как объяснить. Если проще. Вы выбрали(специально/случайно) такую задачу, которая а) целиком и полностью не оптимизируется. б) скрывает многие негативные эффекты «не оптимальных языков». Обычно такие задачи специально выбирают приверженцы так называемых вами «не оптимальных языков» для демонстрации «разницы нет».

        Приведу простой пример, тут есть «cur % nums[i]» — это деление. Оно медленная. Но дело не только в этом. Процессор устроен таким образом, что он может параллельно исполнять другие инструкции. И такие операции(на десятки/сотню тактов) очень удобны. Процессор может параллельно с ними выполнить какие-то вычисления.

        Это может быть просто плохой код. Он может быть в разы медленнее. Если проще. Хороший код выполняется 10 тактов. Плохой 20. Но это абсолютно неважно потому что деление выполняется 50 и параллельно с ним можно выполнить лишние операции. Аналогично там могу стоять множество jit-ловушек, проверок границ и т.п.

        Это так же помогает то, что код сам по себе компактный. Процессор может смотреть на несколько итераций вперёд.


    1. ZurgInq
      12.06.2019 21:55

      Причем тут Делфи? Не очень знаком с его особенностями, но я не слышал, чтобы он был быстрее той же Java или C#.

      Сам по себе язык не может быть быстрее. Вот разные компиляторы могут генерировать разный код. Программы на делфи компилируется в нативный код, а Java и C# исполняются в виртуальной машине, следовательно при прочих равных, компиляция в нативный код даст большую производительность. Другое дело, что компилятор делфи сам по себе может быть далек от совершенства.


      1. Neikist
        12.06.2019 22:30
        +2

        Ну байт код жавы также можно aot компилять, можно вообще как в ART на андроид реализовано, со сбором профилей девайсов и aot компиляцией по этим профилям под конкретный девайс и сценарии использования.


      1. MSC6502
        12.06.2019 23:14

        Да, да, да, скорость компиляции 300-380 тысяч строк в секунду у Delphi это как бы медленно? А сборка проекта на C два-три часа это офигенно быстро?


        1. ZurgInq
          13.06.2019 08:11

          Про скорость компиляции никто и не говорил. Учитывая контекст статьи, речь конечно же идёт о скорости исполнения полученного кода.


      1. Siemargl
        13.06.2019 02:20

        Плохой нативный код не быстрее хорошего JITа. Кроме времени запуска/предкомпиляции.

        Только разнообразные тесты и цифры дадут картинку.


        1. Nagg
          13.06.2019 10:15

          Хороший тоже. Представьте что JIT может по ходу использования приложения понять как лучше его скомпилировать — делать спекулятивные оптимизации, откатывать их если нужно. Понимать что какие-то бранчи никогда не используются, передвинуть более популярные и т.п. — всё что есть в "нативном коде" (подразумевается АОТ) — это только если у вас есть какой-то обобщенный профайл поведения программы. К тому же на высших слоях JIT может использовать тот же самый бэкенд что и С/С++ — ллвм.


          1. Siemargl
            13.06.2019 10:19

            Это только теория. Практикой не подтверждено.
            Кроме того, затраты на JIT очень существенные.


            1. Nagg
              13.06.2019 12:15

              У вас огромный опыт в HotSpot/XING/Falcon чтобы так говорить или это чужое мнение?


              1. Siemargl
                13.06.2019 12:24

                У меня огромный опыт выслушивания голословных утверждений.

                Может у Вас есть подтверждения?


      1. yarosroman
        13.06.2019 02:20

        Сразу видно, знакомы с программированием на уровне Hello word. Уже давно и Aot для java есть и .net native. плюс про выполнение в виртуальной машине не совсем верно. Погуглите, что такое JIT.


        1. Siemargl
          13.06.2019 02:35

          Кстати, было бы неплохо посмотреть живое сравнение (и перепроверить) с «net native» против типичной сборки без «net native».

          А то я вижу пока только рекламные слоганы.

          Если можно, то про AOT для java аналогично.

          Не верю в бигфутов etc. Хотелось бы пощупать.


        1. ZurgInq
          13.06.2019 08:16

          Упоминание в каждом посте очевидных вещей и установка диагноза по фотографии не делает человека умнее.


      1. FreeBa
        13.06.2019 09:02

        C# никогда не исполнялся в виртуальной машине. Он всегда был JIT-компилируемым.


  1. lamerok
    12.06.2019 19:31
    +3

    Чует мое серце следующей статьи не будет…


    1. dagen
      12.06.2019 19:39
      +3

      Сердце чует, что тема High performance не раскрыта?


    1. igor-sheludko Автор
      12.06.2019 20:09
      -9

      Будет :)


  1. madison2201
    12.06.2019 19:41
    -1

    А где холивар?


    1. igor-sheludko Автор
      12.06.2019 19:46
      -4

      Хотелось бы увидеть


      1. ofigenn
        12.06.2019 21:00
        +2

        Вот в чем суть эксперимента! Понятно)


  1. gbg
    12.06.2019 19:43
    +3

    Тестовый пример выбран довольно-таки неудачным образом — Решето Эратосфена — это линейный алгоритм, не допускающий особых оптимизационных ускорялок, на которых компилятор либо рантайм могли бы показать себя с лучшей стороны.

    Не зря же для вычислений стандартными пузомерками являются линпак/лапак и их родственники. Тут и возможность применения SIMD, и раскрутка циклов, и учет ширины кэш-линии (в ATLAS широко применено последнее).

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


    1. igor-sheludko Автор
      12.06.2019 19:49
      -6

      Ну вот как раз хотелось сделать так, чтобы без хитрых ускорений, максимально равные условия. Задача — не посмотреть, кто умеет лучше ускорять конкретные алгоритмы, а какое нынче состояние JS относительно других в самом общем случае.


      1. JekaMas
        12.06.2019 20:10
        +1

        А почему такие условия "равные"?


      1. Neikist
        12.06.2019 21:37
        +3

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


    1. venco
      12.06.2019 23:44
      +2

      Это не Решето Эратосфена. Это вообще ужасно медленный алгоритм, в котором проверяется скорость деления.


      1. igor-sheludko Автор
        13.06.2019 07:54

        Справедливое замечание — деления и сравнения — основные операции там, а также работа с памятью.


  1. Siemargl
    12.06.2019 19:50
    +8

    Статья должна называться — «Если рекрутер начнет учить вас программировать»!

    Ну и конечно, лучше ознакомиться с исходниками и алгоритмами на benchmarksgame хотя бы.


    1. igor-sheludko Автор
      12.06.2019 20:08
      -5

      Так и все таки ваше мнение по заданному вопросу какое?


      1. Siemargl
        12.06.2019 23:45

        Чтобы задать правильный вопрос, надо знать хотя бы половину ответа.

        Это из «Универсального ответчика» Шекли.

        Заголовок спойлера
        Чтобы заниматься тестированием, нужно иметь некоторый опыт


  1. Mox
    12.06.2019 19:54
    -4

    Я пишу на Ruby и JS. Все таки скорость разработки на JS ниже чем на Ruby — именно потому что «так себе язык»


    1. igor-sheludko Автор
      12.06.2019 20:09
      -2

      По вашим ощущениям, насколько быстрее разрабатывается на Ruby?


  1. igor-sheludko Автор
    12.06.2019 20:11

    Хотелось бы увидеть обоснованные предположения уважаемых инженеров :)


  1. Vadem
    12.06.2019 20:15
    +4

    Зачем изобретать велосипед?
    Есть же уже куча сравнений.
    Например, Benchmarks Game и TechEmpower Benchmarks.


    1. igor-sheludko Автор
      14.06.2019 12:13

      Зачем самостоятельно смотреть вживую несколько моделей авто и проходить несколько тест-драйвов в авто-салонах, ведь есть же обзоры в журнале За Рулем?


    1. twinklede
      14.06.2019 12:41

      Например, Benchmarks Game

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


  1. sfi0zy
    12.06.2019 20:19
    +3

    Не холивара ради, а интереса для задам вопрос: а какая практическая ценность подобных сравнений производительности JS и «нормальных» языков на таких алгоритмах? Можно сказать в вакууме. Сколько я видел применение JS — везде были задачи очень далекие от сложных вычислений. А когда кто-то говорил, что JS тормозит, то это либо был ужасный код, который где угодно будет тормозить, либо какие-то местные баги/фичи, которые связаны не с языком, а со средой исполнения (пример для людей из других областей — проседание fps в браузере можно получить путем простого обращения к некоторым свойствам элементов на странице). Понятно, что тот же C++ в браузере особо не запустишь, но если бы запустили, то уперлись бы в те же самые фичи и никакая теоретическая производительность не помогла бы.


    1. greg123
      13.06.2019 12:09

      А какова практическая ценность вычисления числа пи с точностью до миллиарда знаков?


    1. serf
      13.06.2019 13:42

      Понятно, что тот же C++ в браузере особо не запустишь
      Еще как, и Rust и Go тоже, киворд — web assembly.


      1. sfi0zy
        13.06.2019 14:15

        Есть небольшая тонкость: эта технология дает нам песочницу для исполнения кода, но с остальным браузером все можно связать только через прослойку из JS. Тут разные языки работают вместе и есть свои особенности, влияющие и на производительность в том числе. Я же говорю про теоретическое чистое сравнение, если бы мы полностью заменили JS на C++ и стали бы решать уже имеющиеся задачи на нем.


        1. serf
          13.06.2019 15:24

          Безусловно прослойка существует, как передача данных между процессами значительноо влияет на общее воприятие производительности (сериализация). Web assembly очевидно не является серебрянной пулей, но технология развивается и в некоторых случаях уже может быть полезна.


  1. aamonster
    12.06.2019 20:24

    Будет интересно потом посмотреть реализацию на C# – кажется, именно тут можно написать две почти одинаковые программы, работающие с сильно разной скоростью.
    Ну и на JS можно и в webasm уйти :-)


    Короче, увидим, насколько вы хороши в оптимизации на 4 языках :-D


    1. 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() );
                  
              }
          }
      }
      


  1. picul
    12.06.2019 20:59

    Тоже мне сравнение. Ясное дело, что к 2019 году во все широко используемые языки завезли JIT, который подобные числодробилки сразу же переведет в машинный код. А дальше уже зависит от того, на какой платформе функция получения текущего времени работает быстрее.
    Как Вам уже написали выше, для того что бы ощутить преимущества нормальных без кавычек языков — нужно эти самые преимущества использовать. В даной ситуации стоило хотя бы SIMD использовать.


    1. igor-sheludko Автор
      13.06.2019 08:35

      Вы правы в случае, когда при реализации задачи ставится критерий «максимальная производительность». Но будем честными, в большинстве случаев — работает основной критерий «сделайте фичу поскорее» и тогда все работает по дефолту и мало кто трудится над оптимизациями. И только когда прилетит задача «вот тут вот слишком медленно работает» начинается реальная работа по оптимизации.


      1. picul
        13.06.2019 14:33

        Ну то, что на JavaScript'е обычно пишут быдлокод по-быстрому — я не отрицаю. Но если уж Вы хотите сравнить языки в реальной ситуации, то нахождение простых чисел — не тот вариант.


  1. zeronice
    12.06.2019 21:23
    +1

    А где флаги запуска\компиляции\сборки? Можно подогнать под любое ранжирование, если умолчать, с какими опциями делали.


  1. lostmsu
    12.06.2019 21:28
    +2

    Хз как сравнить Delphi и C#, но если не налажать с опциями компиляции, то должно быть C > C# & Delphi > JavaScript с небольшой разницей. Но бенчмарк — говно, т.к. арифметика в языках — самое простое. Большая часть современных программ работает с иерархиями объектов, и вот как раз там JS соснёт по-полной, см тот же benchmarks game.


  1. Boctopr
    12.06.2019 21:36
    +1

    #include <cstdio>
    #include <ctime>
    

    это C++, а то есть адаптированные C функции в область видимости std::

    также по умолчанию visual studio компилирует все C++ единицу трансляции нужно делать extern «C», или вызывать компилятор с флагами для компиляции C


    1. berez
      13.06.2019 00:03

      Там еще bool, true и false используются без #include <stdbool.h>


  1. Nagg
    12.06.2019 21:41
    +3

    C# для такого кода в LLVM бэкендом сгенерит сравнимый по выходу код с Си (Mono-LLVM, Burst). Если компилить Си через clang то собсно сравнивать не особо имеет смысла.


    Короче, автор, тут такое не любят — как правило во всех статьях подобного рода на выходе получается бестолковый бенчмарк.


    1. twinklede
      13.06.2019 12:11

      C# для такого кода в LLVM бэкендом сгенерит сравнимый по выходу код с Си (Mono-LLVM, Burst).

      На подобном коде будет почти везде одно и тоже. Даже на жаваскрипте.

      Короче, автор, тут такое не любят — как правило во всех статьях подобного рода на выходе получается бестолковый бенчмарк.

      Ну это просто неправда. Тут такое любят. Достаточно посмотреть на такой же хелворд в статье «хаскель может», там тысячи плюсов. Все было так же, если не хуже. Попросту неверные измерения, читы в хаскеле без указаний нюансов(т.е. манипуляция), а после неудача с многопотоком у хаскеля. Ну и, как обычно, автор выдавал свой хелворд за «показательный пример, а не очередной факториал», но это был именно он. И в нём даже нода показывала результаты уровня хаскеля.


      1. Nagg
        13.06.2019 12:16

        На подобном коде будет почти везде одно и тоже. Даже на жаваскрипте.

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


        Ну это просто неправда. Тут такое любят.

        Все статьи такого рода заминусованы, ваш пример про Хаскель — это не про мейнстрим. А так во всех бенчмарках автор никогда не обладает глубокими знаниями во всех языках/платформах которые он тестирует


  1. Neikist
    12.06.2019 21:42

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


    1. amarao
      12.06.2019 22:07

      Rust? KLOC/hr меньше, но и багов на строку кратно меньше. Экономия времени на отладке переходит из линейной в степенную при появлении многопточности.


      1. Neikist
        12.06.2019 22:31

        До раста руки так и не дошли, только недавно перешел с 1с на java/kotlin. В планах пока только хаскел все таки пощупать, и то не скоро.


    1. 0xd34df00d
      13.06.2019 05:36

      Сотни kloc? А вы хороши! Я ломаюсь на сотне loc, без всяких k.


      1. Neikist
        13.06.2019 08:11

        От проектов зависит. Так то первые баги я допускать начинаю очень заметно раньше даже на несложных проектах, но до какого то момента еще есть выигрыш, исправление багов немного времени занимает. Но вот на 100+ уже становится совсем грустно мне.


  1. Ascar
    12.06.2019 23:00
    -1

    Что бы не вляпаться в js придумали ts, вы задумывались почему?


  1. Atreides07
    12.06.2019 23:05

    Как часто на практике решают проблему генерирования простых чисел? Логично что сранивать js с компилируемым языками имеет смысл при разработке серверных приложений.
    Так почему бы просто не посмотреть на результаты сравнения node.js с другими фреймворками, где вы легко увидете что Node.js на порядок отстает от упомянутых вами компилируемых языков?
    https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintext


    1. DarthVictor
      13.06.2019 10:23

      Справедливости ради, в приведенном тесте рядом с нодой результаты вполне себе компилируемых Kotlin, C#, Scala, Java. Глянув исходники теста, легко заметить, что тест мереет в основном скорость веб-сервера.


  1. GennPen
    12.06.2019 23:25

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

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

    Не совсем верно. Много вы видели программ с чистым арифметическим расчетом? В 90% случаев подавляющее большинство в программе — чистая логика.
    Сделайте тест например по созданию 100500 объектов/экземпляров различных классов и их различные вызовы методов и посмотрите как различные языки справляются с подобной нагрузкой, включая утилизацию памяти, работу сборщика мусора и т.п.

    И да, можете объяснить, почему вы назвали C# «компилируемым языком»?


    1. Nagg
      12.06.2019 23:36

      И да, можете объяснить, почему вы назвали C# «компилируемым языком»?

      А какой он?


  1. kruslan
    12.06.2019 23:54

    Даже интересно стало, а поменялось-ли что-то с 2011-го года? bolknote.ru/all/3290 bolk, повторных экспериментов не было?


    1. Siemargl
      13.06.2019 00:09

      Go компилируется GCC. С чего там будет разница?


    1. bolk
      13.06.2019 13:54

      Не, что-то нет :)


  1. SerafimArts
    13.06.2019 03:22

    Я может покажусь странным, но где PHP? Всё же с JIT он будет местами на уровне gcc -o2.


    У меня даже пруфы будут:


    Заголовок спойлера


  1. Vyaza
    13.06.2019 05:56
    +1

    Стояла у меня как-то задача максимально быстро определять значение нужного бита в битовой маске, представленной в виде строки вида «AB-CD-EF-00» в отдельном консольном приложении или скрипте. У PHP, Python, JS и прочих только среда выполнения по 30-100 мс запускалась, а написанное на C решение выполнялось за что-то около 1 мс. Так что быстродействие — штука относительная.


  1. michael_vostrikov
    13.06.2019 09:41
    +1

    Я не знаю в чем причина — в ненависти к JavaScript или ко мне лично, но хотелось бы понимать эту причину.

    Ну раз вы спрашиваете...


    Java Script

    Слитно он пишется, JavaScript. Уже по заголовку видно, что статья написана человеком, не разбирающимся в теме. Какое отношение вы ожидали, пытаясь учить других "правильному" положению вещей?


    сейчас это уже довольно мощный и многоцелевой инструмент, одним из важнейший достоинств которого для бизнеса является существенно более высокая скорость разработки

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


    В качестве контр-аргумента мне часто приводят низкую производительность кода на Java Script.

    Это только один из аргументов, не надо его противопоставлять с предыдущим пунктом.


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

    Неправильно вам кажется, есть куча других моментов. Часть из них уже упомянули в комментариях. Сравнение языков это большая и сложная тема, а не так что набросал решето Эратосфена и сравнил, тогда бы и разговоров про это никаких не было.


    Я решил взять какой-нибудь простой алгоритм с целочисленной арифметикой и реализовать его на нескольких языках максимально идентично.
    Также я реализовал этот алгоритм на C#, Delphi и Java Script полностью идентично, насколько это возможно.

    Где код для всех языков, где параметры компиляции, способ запуска, способ измерения времени? Это вам кажется, что идентично, а по факту может быть совсем не идентично. В C# например могут быть разные дополнительные проверки при компиляции в debug-режиме.


    Как вы думаете, в каком порядке выстроились остальные языки по увеличению времени работы и уменьшению производительности соответственно? Через несколько дней я дополню статью результатами

    Да в любом, кто его знает что вы там намеряли. Даже от реального соотношения производительности это может быть далеко, а уж от полезности применения языка для бизнеса тем более.


    И что за игра в угадайку? У вас статья называется "Сравнение производительности". Где сравнение-то? Какое отношение вы ожидали, обманывая читателей?


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

    А, то есть остальные у вас 64-битные? В таких задачах, да еще и с различием результатов в доли секунды, это важно. Вы сравниваете какую-то ерунду, почему к этому кто-то должен хорошо относиться?


    Скорее всего операция целочисленного деления не является сильным местом компилятора C#
    В данном эксперименте меня удивили 3 пункта:
    1. Довольно хороший результат JavaScript и откровенно провальный результат C#.

    Скорее всего вы не умеете работать с C#. Почему должна быть какая-то другая причина?


    Как вам уже сказали, если вы хотели показать преимущество JS, это надо было делать на других задачах. Включающих в первую очередь асинхронность.


    но при этом затруднились сформулировать собственное мнение по заданному вопросу

    По какому конкретно вопросу? Недостатков и JS и ваших методов измерения вам много написали. Если кто-то с ними согласен, зачем он будет их повторять? Что именно вы ожидаете в качестве мнения?


    Мне кажется так проявляется эффект постоянного наличия поисковика под рукой — можно не держать в голове знания, ведь их всегда можно «погуглить».

    Переход на личности в отношении широкого круга людей. "Я не разбираюсь в вопросе, но считаю, что вы дураки".


    1. igor-sheludko Автор
      13.06.2019 16:45

      Уже по заголовку видно, что статья написана человеком, не разбирающимся в теме

      Диагностика по заголовку — это даже круче, чем по фотографии. Не придал этому значения, не ожидал что этот пробел такой болезненный :) Как вы думаете, это отголоски боли из темы — «табом или пробелом» или что-то самостоятельное?

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


      Согласен, TypeScript помогает. В пользу TS/JS вместо того же C++/C# компании, перешедшие на TS/JS называют большое количество более простых реализций множества типовых задач. То есть грубо говоря готовых библиотек много и на любой вкус — бери, изучай и улучшай или просто бери и используй. TS + Elecron уже выбрали для многих кроссплатформенных продуктов — VS Code, Skype, Telegram, Slack не зря разрабатываются на TypeScript. Потому что так быстрее и проще поддерживать кроссплатформенность.

      Сравнение языков это большая и сложная тема, а не так что набросал решето Эратосфена и сравнил, тогда бы и разговоров про это никаких не было.


      Как вы думаете, почему это вызывает такую боль? Я оскорбил чувства верующих в свой самый лучший язык?

      Где код для всех языков, где параметры компиляции, способ запуска, способ измерения времени? Это вам кажется, что идентично, а по факту может быть совсем не идентично. В C# например могут быть разные дополнительные проверки при компиляции в debug-режиме.

      Спасибо вам, я действительно погорячился и был несправедлив. Исправился.

      Да в любом, кто его знает что вы там намеряли. Даже от реального соотношения производительности это может быть далеко, а уж от полезности применения языка для бизнеса тем более.

      Я же не агитирую вас перейти на другой язык. Просто часто говорят, что что-то (JS) плохое, но хочется понимать насколько оно плохое, хотя бы в каком-то простом случае.

      Вы сравниваете какую-то ерунду, почему к этому кто-то должен хорошо относиться?


      Можно просто мимо пройти, а не агрессивно реагировать. Можно просто указать на недостатки — задача выбрана плохо, лучше взять другую и прочее из того, что вы тут выше написали. Диалог бывает конструктивным, а бывает с позиции превосходства. Если вы это практикуете, то это скорее указывает на то, что вы сами, вероятно, являетесь жертвой такой манеры общения. Вместо нападок на незнакомых людей, я бы посоветовал вам решить свои проблемы и улучшить моральный климат, в котором вы обитаете. Если это связано с местом работы — могу помочь :)

      Скорее всего вы не умеете работать с C#. Почему должна быть какая-то другая причина?


      Именно так и оказалось, вы были правы.

      Как вам уже сказали, если вы хотели показать преимущество JS, это надо было делать на других задачах.


      Не собирался показывать превосходства, просто ошибка закралась, уже исправил.

      Включающих в первую очередь асинхронность.


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

      По какому конкретно вопросу? Недостатков и JS и ваших методов измерения вам много написали. Если кто-то с ними согласен, зачем он будет их повторять? Что именно вы ожидаете в качестве мнения?


      Голос в опросе и предположения почему результат именно такой. Это же естественно для адекватного, здорового человека. Комментарии в таком виде оставили всего несколько человек — они молодцы, им респект.
      Вам тоже респект, кстати за точные замечания.

      Переход на личности в отношении широкого круга людей. «Я не разбираюсь в вопросе, но считаю, что вы дураки».


      Вообще не считаю дураками почти никого и не высказываюсь так. Невоспитанными людьми — да, считаю. Многих программистов, с которыми приходится общаться, к сожалению, можно отнести к диким, невоспитанным людям, с плохо развитыми коммуникативными и социальными навыками (то что сейчас модно называть «неразвитым эмоциональным интеллектом»).

      Если вам приходится общаться с молодыми программистами, вы не могли не заметить крайне низкий уровень понимания того, что они делают и для чего. У молодых людей в возрасте 18-22 года часто развит только один навык — гуглить, он им заменяет множество других навыков. Мы — «старики», постоянно им говорим, что так далеко не уедешь, но их жизненный опыт подсказывает, что раньше «вывозило» и дальше нормально будет.


      1. michael_vostrikov
        13.06.2019 17:40

        Не придал этому значения, не ожидал что этот пробел такой болезненный :) Как вы думаете, это отголоски боли из темы — «табом или пробелом» или что-то самостоятельное?

        Зачем вы фразы из контекста вырываете? Там русским языком написано, что причина негативного отношения не в пробеле, а в том, что вы пытаетесь учить "как правильно" совершенно не разбираясь в теме, и потому учите неправильно.


        Это кстати еще одна причина, по которой ставят минусы.


        Согласен, TypeScript помогает.

        Да TypeScript тут ни при чем, это просто один из вариантов, которых много. Важно то, что вы оцениваете "полезность для бизнеса" без учета этого, а только на основании "решить задачу на JS часто бывает намного быстрее", которое по-другому называется "тяп-ляп и в продакшн". Вы одну задачу решили быстро, другую быстро, а одиннадцатую в 20 раз дольше. А двадцатую вообще не решили, потому что изнчально не было времени сделать по-нормальному, и теперь надо все переписывать. Цифры могут быть другие, и зависят от денег, которые потратит бизнес на отдел программирования, чтобы он хотя бы как-то что-то делал с таким кодом.


        Я оскорбил чувства верующих в свой самый лучший язык?

        Вы написали ерунду, за нее вам и ставят минусы. За отсутствие логики и за некорректно проведенное сравнение.


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

        И для этого вы сделали неправильные действия. Да еще и оскорбляете тех, кто вам об этом говорит. Да, я конкретно про эту фразу "Мне кажется так проявляется эффект постоянного наличия поисковика под рукой — можно не держать в голове знания и даже не иметь собственного мнения, ведь их всегда можно «погуглить»".


        Диалог бывает конструктивным, а бывает с позиции превосходства

        Вот именно превосходство у вас статье и сквозит со всех сторон. Для вас более вероятная причина, что деление в C# медленное, чем что вы сделали что-то неправильно. И эти вот ваши "догадайтесь сами, а я потом напишу", вот эти вот "Я оскорбил чувства верующих в свой самый лучший язык?" и "Вместо нападок на незнакомых людей, я бы посоветовал вам решить свои проблемы и улучшить моральный климат, в котором вы обитаете.". Вы зачем статью сюда выложили? Чтобы комментарии получить? Вот это они и есть. У вас в статье "ерунда" потому что так сравнения не делаются, тем более для определения ответа на обсуждаемый вопрос, а не потому что кто-то хочет оскорбить лично вас. Умерьте свое самомнение. И советы свои оставьте при себе, я вас про это не спрашивал. А еще спрашиваете про причины негативного к вам отношения.


        в комментариях мне уже разъяснили — написание Java Script — с пробелом — вызывает приступы ярости

        О, так вы еще и в статью это ёрничание добавили? До этого я был о вас лучшего мнения.


        Голос в опросе и предположения почему результат именно такой. Это же естественно для адекватного, здорового человека.

        Естественно играть в угадайку на техническом ресурсе в статье под названием "Сравнение производительности"? Раз вы всерьез так считаете, то сообщаю — нет, это не естественно.


        Вообще не считаю дураками почти никого и не высказываюсь так.

        Неважно, что вы считаете, со стороны это выглядит именно так. Вам высказали конструктивную критику, а вы обвиняете людей в отсутствии знаний. Это и есть завуалированное обзывание дураками.


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

        Нет, я такого не замечал.


        У молодых людей в возрасте 18-22 года часто развит только один навык — гуглить, он им заменяет множество других навыков.

        А я вам открою секрет, почему так. Потому что только такие к вам и идут.


        Более того, 18-22 года это значит он даже еще вуз не закончил, откуда он должен получать знания о программировании, как не из интернета? Даже в вузе не учат многим практическим вещам. Это еще один пример проблем в вашей логике.


        1. igor-sheludko Автор
          14.06.2019 10:44

          Там русским языком написано, что причина негативного отношения не в пробеле, а в том, что вы пытаетесь учить «как правильно» совершенно не разбираясь в теме, и потому учите неправильно.


          Можете привести примеры, где именно в статье, в каких предложениях я учу как правильно?

          О, так вы еще и в статью это ёрничание добавили? До этого я был о вас лучшего мнения.

          Вам не кажется, что именно тут вы проявляете свое превосходство? Как будто вы учитель, а я у вас в классе?

          И эти вот ваши «догадайтесь сами, а я потом напишу»

          Не хотите догадываться, вам не интересно — просто проходите мимо.

          Естественно играть в угадайку на техническом ресурсе в статье под названием «Сравнение производительности»? Раз вы всерьез так считаете, то сообщаю — нет, это не естественно.


          А чего вы ждали — точных и неопровержимых доказательств? Вы полагаете, что Хабр — это научный ресурс и тут все материалы строго научно обоснованны?

          Неважно, что вы считаете, со стороны это выглядит именно так. Вам высказали конструктивную критику, а вы обвиняете людей в отсутствии знаний. Это и есть завуалированное обзывание дураками.


          Стоят на парковке парни и обсуждают какая машина быстрее проедет определенный маршрут. Вы проходите мимо и изрекаете — почитайте лучше журнал «За Рулем» — там все давно уже сравнили и выбрали лучшую тачку!
          Вот так выглядят рекомендации изучить бенчмарки. Вы полагаете это адекватный, конструктивный комментарий?

          Более того, 18-22 года это значит он даже еще вуз не закончил, откуда он должен получать знания о программировании, как не из интернета? Даже в вузе не учат многим практическим вещам. Это еще один пример проблем в вашей логике.


          А знания появляются строго по триггеру — «окончание ВУЗа»? В процессе учебы знаний еще нет? До ВУЗа программированию не учат? Кроме ВУЗа нигде больше программированию не учат? На стажировках и практиках чем по-вашему занимаются?
          В школе на уроках чем по вашему занимаются?


          1. michael_vostrikov
            14.06.2019 11:39

            Можете привести примеры, где именно в статье, в каких предложениях я учу как правильно?

            "Сравнение производительности: JavaScript vs компилируемые языки"
            "Java Script, сейчас это уже довольно мощный и многоцелевой инструмент, одним из важнейший достоинств которого для бизнеса является существенно более высокая скорость разработки."
            "То есть написать код и решить задачу на JS часто бывает намного быстрее, чем на «нормальном» языке и результат получается вполне удовлетворительным."
            "Производительность разных языков зависит от задач, но есть общие моменты, такие как управление памятью, арифметические операции, которые, как мне кажется, позволяют максимально точно получить представление о производительности реализации алгоритма на том или ином языке."
            "Компилятор Delphi хоть и достаточно старый и генерирует 32-битный код, тем не менее этот код нативный и для данной задачи достаточно оптимальный."
            "Скорее всего операция целочисленного деления не является сильным местом компилятора C#"
            "Как вы думаете, в каком порядке выстроились остальные языки по увеличению времени работы и уменьшению производительности соответственно? Какой язык оказался самым медленным?"


            Да, вопрос читателям предполагает, что вы знаете правильный ответ. Который, как выяснилось, на самом деле был неправильным.


            Вам не кажется, что именно тут вы проявляете свое превосходство? Как будто вы учитель, а я у вас в классе?

            Нет, потому что я это сделал в ответ на подобное поведение с вашей стороны.


            Не хотите догадываться, вам не интересно — просто проходите мимо.

            Ну вот опять. Вы спрашивали "хотелось бы понимать эту причину"? Спрашивали. Я вам ее сообщил. Какая разница, пройду я мимо или не пройду, причина-то никуда не денется, минусы вам ставят в том числе и из-за нее.


            И нет, люди, которым не пофиг на ресурс, мимо проходить не будут. Такие статьи ресурсу не нужны, и несколько десятков человек со мной согласны. Минусы ставят в том числе и затем, чтобы другие так не писали.


            А чего вы ждали — точных и неопровержимых доказательств? Вы полагаете, что Хабр — это научный ресурс и тут все материалы строго научно обоснованны?

            Я полагаю, что в статье, которая называется "Сравнение" будет корректно проведенное сравнение. И ждал я именно его. А также корректные логические выводы из его результатов в контексте вопроса, из-за которого оно и проводилось.


            Стоят на парковке парни и обсуждают какая машина быстрее проедет определенный маршрут. Вы проходите мимо и изрекаете — почитайте лучше журнал «За Рулем» — там все давно уже сравнили и выбрали лучшую тачку!

            Да нет, как раз наоборот. Стоят парни их журнала "За рулем" и кучи других, сравнивают тачки по всем правилам, ожидают от других того же, вы проходит мимо и изрекаете "У меня по-другому получилось". Они вам говорят "Вы неправильно сравниваете, надо вот так", а вы в ответ "У вас нет знаний в голове и собственного мнения. У вас плохие манеры, озлобленность и неудовлетворенность жизнью". Это адекватный, конструктивный комментарий? Нет.


            А знания появляются строго по триггеру — «окончание ВУЗа»?

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


            В процессе учебы знаний еще нет? До ВУЗа программированию не учат? Кроме ВУЗа нигде больше программированию не учат? На стажировках и практиках чем по-вашему занимаются? В школе на уроках чем по вашему занимаются?

            Есть, но не все, значит недостающие знания надо получать из других источников.
            Учат, но не всему, значит недостающие знания надо получать из других источников.
            Учат, но не всему, значит недостающие знания надо получать из других источников.
            Физика, химия, математика, русский язык, литература, история, физкультура, и еще куча других предметов. Как из этого списка следует, что человек должен после школы знать все, что требуется для работы программистом конкретно в вашей команде на используемом у вас языке программирования и соответствующих библиотеках, чтобы делать это не обращаясь к интернету?


            1. limassolsk
              14.06.2019 12:18

              Не кормите тролля :)
              Вначале автор просто не понимал, что происходит и не хотел понимать. Он не допускал даже мысли, что он был неправ. Для него единственной причиной такого грандиозного фейла была только одна — «озлобленные хабравчане».
              А теперь он уже даже не пытается доказать свою правоту, и переключился с оскорблений на троллинг и набрасывает вопросы, которые вынуждают вас доказывать свою правоту и тратить на это кучу сил:

              Можете привести примеры, где именно в статье, в каких предложениях я учу как правильно?
              Каким образом статья что-либо показывает?
              Вы же не думаете, что в вашем конкретном проекте все будет точно так же?
              Интересно с чего вы сделали такой вывод?
              Вы были у меня на консультации?
              Где я претендовал на объективность?
              Можете привести примеры, где именно в статье, в каких предложениях я учу как правильно?

              Не кормите тролля :) Вы ему всё равно ничего не докажите, а когда он наестся, то просто удалит статью и все ваши старания превратятся в ничто.


            1. igor-sheludko Автор
              14.06.2019 17:08

              «Сравнение производительности: JavaScript vs компилируемые языки»
              «Java Script, сейчас это уже довольно мощный и многоцелевой инструмент, одним из важнейший достоинств которого для бизнеса является существенно более высокая скорость разработки.»
              «То есть написать код и решить задачу на JS часто бывает намного быстрее, чем на «нормальном» языке и результат получается вполне удовлетворительным.»
              «Производительность разных языков зависит от задач, но есть общие моменты, такие как управление памятью, арифметические операции, которые, как мне кажется, позволяют максимально точно получить представление о производительности реализации алгоритма на том или ином языке.»
              «Компилятор Delphi хоть и достаточно старый и генерирует 32-битный код, тем не менее этот код нативный и для данной задачи достаточно оптимальный.»
              «Скорее всего операция целочисленного деления не является сильным местом компилятора C#»
              «Как вы думаете, в каком порядке выстроились остальные языки по увеличению времени работы и уменьшению производительности соответственно? Какой язык оказался самым медленным?»


              Что именно в этих фразах является призывом делать так, как я говорю? Чему я учу? Я вижу тут только мои личные оценочные суждения, без претензии на окончательную правду.

              Такие статьи ресурсу не нужны, и несколько десятков человек со мной согласны. Минусы ставят в том числе и затем, чтобы другие так не писали.

              Проблема не в минусах, а в агрессивных высказываниях не по теме, не только в отношении меня кстати, но и на других комментирующих.

              Я полагаю, что в статье, которая называется «Сравнение» будет корректно проведенное сравнение. И ждал я именно его. А также корректные логические выводы из его результатов в контексте вопроса, из-за которого оно и проводилось.


              Вам не нравится объем и состав сравнения — ок, имеете право, напишите как сделали бы вы, если вам не все равно. Это конструктивно. Есть такой афоризм — если кто-то не оправдал ваших ожиданий, то это не его проблема, а ваша — так как это были ваши ожидания.

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

              Вы написали — «это значит он даже еще вуз не закончил, откуда он должен получать знания». Вполне логично заключить, что вы считаете, что знания появляются строго по окончанию вуза :)

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


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

              На этом я дискуссию пожалуй закончу.
              Вам спасибо за высказанное мнение.
              Материал на Хабре не удаляется, его можно скрыть, переведя в статус черновика.
              Я пока что не планирую так поступать. Не вижу ничего позорного в отрицательных оценках. При желании карму можно обнулить, мне пока не горит.


              1. michael_vostrikov
                14.06.2019 18:07

                Отвечу на вопросы, раз вы их задали.


                Я вижу тут только мои личные оценочные суждения

                Ну вот и минусы это личные оценочные суждения. Что вам не нравится-то?


                Вы зачем статью написали? Чтобы показать производительность JavaScript. То есть говорите "Смотрите, она вот такая". Это и есть "учить". Вы придираетесь к одному смыслу слова, делая вид, что других не существует.


                Никаких вопросов или намеков, что вы можете делать что-то неправильно, у вас в статье нет. Даже в результате для C# оказалось виновато деление. Вы подаете материал так, как будто считаете его правильным, так он и воспринимается другими.


                Проблема не в минусах, а в агрессивных высказываниях не по теме, не только в отношении меня кстати, но и на других комментирующих.

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


                Вам не нравится объем и состав сравнения — ок, имеете право, напишите как сделали бы вы

                Я должен еще и статью за вас исправлять? Вас никто не просил ее писать, сами написали, сами и исправляйте.
                И да, вам именно это и писали, когда показывали на бенчмарки. Что вы в ответ сделали? Добавили в статью завуалированные оскорбления.


                Есть такой афоризм — если кто-то не оправдал ваших ожиданий, то это не его проблема, а ваша — так как это были ваши ожидания.

                Ну в таком случае и минусы проблема ваша, раз они не соответствуют вашим ожиданиям. Почему вы тогда других обвиняете в озлобленности?


                Вы написали — «это значит он даже еще вуз не закончил, откуда он должен получать знания». Вполне логично заключить, что вы считаете, что знания появляются строго по окончанию вуза

                Нет, из этого вполне логично заключить, что знания появляются постепенно в процессе обучения в вузе, а следовательно во время этого процесса знаний заведомо недостаточно, и что в 18-22 года человек по объективным причинам не может писать код, не пользуясь интернетом. А не по субъективным "потому что он лентяй". А также я не считаю, что даже после окончания вуза возможно писать нормальный код, не пользуясь интернетом, потому что технологии развиваются быстрее, чем вузовская программа. Видите сколько вариантов есть, о которых вы не подумали. Не говоря уже о том, что довольно бессмысленно и практически невозможно помнить наизусть порядок аргументов в стандартных функциях на десятке разных языков. Не говоря уже о том, что в принципе невозможно узнать в вузе, законченном год назад, как использовать новую библиотеку, которая делает то что нужно для вашего бизнеса и которая появилась вчера.


                Вы вот например узнали, что в C# в debug-режиме есть дополнительные проверки, именно из интернета. Можно же сделать вывод, что вы ничего не умеете, знаний у вас в голове нет, что у вас крайне низкий уровень понимания того, что вы делаете и для чего. Будете свою фирму закрывать? А почему нет? Может потому что вы знаете, что это ни при чем?


  1. algotrader2013
    13.06.2019 09:54

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


    1. igor-sheludko Автор
      13.06.2019 12:19

      Именно этот вопрос я и хотел поднять, причем явно. Получилось плохо. В большинстве случаев средства выбираются потому что «где-то кто-то написал, что это круто» или потому что «мы так умеем».


      1. algotrader2013
        13.06.2019 13:02

        Тогда, думаю, надо было бы и сделать на этом упор в статье. И, снова таки, последовательность простых чисел не есть типичной задачей. То есть, писать что-то в духе: предположим, у меня есть базовое понимание программирования на уровне университеского курса, и мне надо запилить круд/сделать бекенд онлайн-калькулятора стоимости кредита/написать простую парсилку логов (то есть, задачи, которые реально встречаются людям без системного опыта). И, явно указывать, что делаю так и так, ибо это проще, и все начинающие девы так делают.


    1. 0xd34df00d
      13.06.2019 16:10

      В некоторых языках до бенчмарков тогда не дойдет.


  1. limassolsk
    13.06.2019 09:55
    +1

    О себе:
    Занимаюсь подбором IT-персонала
    Консультирую стартапы
    Так вот почему в России так плохо со стартапами :)
    Статья наглядно показывает насколько «ценны» могут быть сторонние консультанты для вашего проекта.
    В следующий раз перед таким фейлом для начала сами возьмите консультацию у специалиста в области, которой вы не владеете.
    Вам тут уже неоднократно давали ссылки на профессиональные бенчмарки (techempower
    и benchmarksgame), состоящие из кучи различных тестов и с исходниками, которые каждый может прочитать, и улучшить то что знает.
    Ваш подход — это взять один тест, в котором лучше всего себя показал ваш ЯП, а дальше выбрать на нём лучшую реализацию, а у остальных ЯП выбрать худшую реализацию и при это претендовать на объективность. Это бы могло сработать в реальной жизни, когда вы авторитетно даёте консультации, а остальные не смеют вам противоречить, ведь вы авторитет, но здесь это не сработает.
    На хабре нужны цифры, а не громкие слова.


    1. igor-sheludko Автор
      13.06.2019 18:07

      Так вот почему в России так плохо со стартапами :)

      Потому что я лично во всем виноват. Не хотите на меня еще и плохие дороги записать?
      А почему вы думаете что в России плохо со стартапами? У нас вполне нормально — стартапы есть и поддержка со стороны государства есть. Если захотите свой делать — спросите у меня и я вам расскажу что почитать и где можно денег взять на первое время. Не хватает емкого и активного рынка, богатых клиентов, но это не ко мне, а к правительству. Еще очень плохо с бизнес-образованием и вообще с тягой населения к образованию. Да и с тягой населения к предпринимательству все довольно плохо, может быть потому, что много десятилетий навязывалось мировоззрение, согласно которому предприниматель — это преступник, эксплуататор, враг. Что же вы хотите теперь?

      Статья наглядно показывает насколько «ценны» могут быть сторонние консультанты для вашего проекта.
      В следующий раз перед таким фейлом для начала сами возьмите консультацию у специалиста в области, которой вы не владеете.

      Каким образом статья что-либо показывает? Данный «фейл» показывает только плохие манеры, озлобленность и неудовлетворенность жизнью у части аудитории Хабра, читающей определнные хабы.

      Вам тут уже неоднократно давали ссылки на профессиональные бенчмарки (techempower и benchmarksgame), состоящие из кучи различных тестов и с исходниками, которые каждый может прочитать, и улучшить то что знает.

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

      Ваш подход — это взять один тест, в котором лучше всего себя показал ваш ЯП, а дальше выбрать на нём лучшую реализацию, а у остальных ЯП выбрать худшую реализацию и при это претендовать на объективность.

      Вот интересно — с чего вы сделали такой вывод? Реализация максимально одинаковая. Я не привел все исходники — это справедливая критика. Я не агитировал ни за какой язык. Не призывал срочно всем переходить. И даже не претендовал на объективность. Вы понимаете, что вы меня обвинили в вымышленных вами преступлениях?

      Это бы могло сработать в реальной жизни, когда вы авторитетно даёте консультации, а остальные не смеют вам противоречить, ведь вы авторитет, но здесь это не сработает.

      Вы были у меня на консультации? Знаете как я консультирую? Слышали когда-нибудь, что мне нельзя перечить? Вероятно вы меня с кем-то попутали :)

      На хабре нужны цифры, а не громкие слова.

      Цифры появились позже. Задумка была в том, чтобы дать высказаться и порассуждать. Вот вы например высказались, правда совсем не по теме статьи. Это тоже о многом говорит.


      1. limassolsk
        13.06.2019 21:37

        Каким образом статья что-либо показывает? Данный «фейл» показывает только плохие манеры, озлобленность и неудовлетворенность жизнью у части аудитории Хабра, читающей определнные хабы.
        Почему вы обвиняете людей в плохих манерах, озлобленности и неудовлетворенностью жизнью? Или вы так же говорите всем клиентам, которые оказались не удовлетворены результатом вашей работы? Хотя в данном случае то что вы сделали вообще сложно назвать результатом или даже просто работой. Ваши комментарии наглядно показывают, что вы не только не умеете работать с людьми, но даже просто неадекватно реагируете на обоснованную критику. Кто вам после такого вообще даст? управлять персоналом — непонятно.
        Вы же не думаете, что в вашем конкретном проекте все будет точно так же, как в этих бенчмарках?
        Эти бенчмарки позволяют сравнивать работу на куче разных задач и пересечение этих различных задач с любым проектом будет гораздо выше, чем с одной решённой вами задачей.

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

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


  1. 0xf0a00
    13.06.2019 10:09

    Обиженные дотнетчики заминусили :) Спасибо за Delphi в сравнении, хотя ради справедливости я взял бы Delphi Rio.


    1. igor-sheludko Автор
      14.06.2019 09:22

      Обиженные дотнетчики заминусили :) Спасибо за Delphi в сравнении, хотя ради справедливости я взял бы Delphi Rio.

      Что было под рукой, на том и потестировал. Результаты оказались близкими, C# я обидел незаслужено — прошляпил, что запускал debug сборку.
      Считаю Delphi вполне эффективным инструментом для разработки Windows-приложений, нет гемороя с зависимостями и runtime-библиотеками, сами используем.


  1. Playa
    13.06.2019 10:22

    Теперь каждый эйчар считает своим долгом зашитпостить на хабр?


    1. igor-sheludko Автор
      13.06.2019 22:01

      Теперь каждый эйчар считает своим долгом зашитпостить на хабр?


      Во-первых, видимо вы не понимаете разницу между рекрутером и HR. Я вам объясню.
      Рекрутер — это специалист, который занимается поиском и отбором кандидатов согласно профилю вакансии и сопровождает кандидата до момента найма в компанию. Рекрутеры бывают штатные и аутсорсеры.
      HR — это штатный специалист компании, который сопровождает всех сотрудников от момента найма, через адаптацию, поддержание здоровой рабочей атмосферы и вплоть до увольнения.
      Рекрутер — это как фронтенд, а HR — как бэкенд. Ректутер видит API — профиль вакансии и через него грузит объекты — кандидатов. HR принимает кандидатов, переваривает их, участвует в эксплуатации и в итоге удаляет, когда сотрудник увольняется.
      Я — рекрутер и временами занимаюсь эксплуатацией программистов, когда они нужны лично мне для моих проектов.
      Площадка Habr устроена так, что если вам не нравится пост — вы можете проголосовать. А если у вас есть какая-то конкретная претензия — вы можете написать содержательный комментарий, а не то, что вы написали.