Самый быстрый язык программирования: Scala, Java или может быть Python?
Понадобилось мне написать программку, пересчитывающую массив географических координат из одной системы в другую. Написал на Ruby в несколько строчек. Время выполнения — 16,5 сек. Чего так долго? Решил написать то же самое, но на разных языках, чтобы заценить производительность современных языков программирования. Результаты оказались неожиданными.
[TOC Самый быстрый ЯП]
Ruby
Ruby простой, удобный и... очень медленный. Вообще-то, это мой любимый язык программирования. Нравится лаконичностью и универсальностью. Хочешь web-приложение — ставь Ruby on Rails и ваяй. Нужен скрипт для системного администрирования — Ruby тоже очень хорош. Но в Руби всё настолько модное, динамическое и объектно-ориентированное, что язык, прямо скажем, очень нетороплив. И это справедливая плата за удобство. 16,5 сек.
JRuby
Обалденный проект! JRuby берет скрип на Ruby и компилирует в байт-код Java. А VM от Явы славится своей отполированностью и производительностью. Плюс огромный бонус — возможность прозрачно вызывать из Ruby код на Java из миллиона первосортных библиотек и наоборот. Но не будем отвлекаться. Взял я свою программу и натравил на нее компилятор JRuby. Время расчетов сократилось в 2 раза и составило 8,6 секунды. Получаем ускорение в 2 раза с нулевыми затратами.
Go
Go — моднейший и распиаренный язык от Google. Программа компилируется в бинарный код. Разработчики обещают высочайшую производительность. Проверяем. 3,7 сек. Отлично! Но ведь Си всё равно будет быстрее?!
C
В отличии от Go, тут нет сборщика мусора и раздутого рантайма. Только хардкор! Берем gcc, компилируем, запускаем и получаем первый сюрприз — 4 секунды. Что за дела? Можно предположить, что у Go лучше оптимизация. Тогда попробуем и из gcc выжать максимум. Используем опции -O3 и -march=native (тест на i7). Получаем 3,7. Ровно столько же, сколько выдает Go.
Java
JRuby опробовали и получили 8,6. А что получится, если весь код сразу написать на Java? Тут нас ждет вторая неожиданность — 3,1 сек. Быстрее, чем Go и Си. Как это объяснить я не знаю. Возможно, кто-нибудь в комментариях расскажет, как код в виртуальной машине может выполняться быстрее нативного кода? У меня есть всего одна гипотеза и даже мне она кажется сомнительной: а вдруг виртуальная машина настолько умная, что оптимизирует код во время выполнения и распараллеливает часть задач? В любом случае, Java — это сила!
Scala
Модный ЯП, претендующий на роль убивца Java. Тоже компилируется в бинарный код для виртуальной машины Java. Синтаксис Scala намного более приятный и — что самое главное — намного более лаконичный. А что со скоростью? Наверное, примерно как у JRuby? И тут третий сюрприз — 3,1 сек., то есть как и у Java. Но если не округлять, что у Java 3.104 сек, а у Scala 3,091. Ну вообще!
JavaScript
Рассмотрим JavaScript на примере NodeJS 4-й ветки. Получилось 3,5 сек. Go и C посрамлены. Как интерпретируемая программа может оказаться быстрее нативного кода? Возможно, всё дело в чудо-движке V8 от Google, который не устают нахваливать за скорость. Кстати, это именно он установлен во всех браузерах Chrome и Chromium.
PHP
Вот мы и добрались до самого яркого представителя быдланской пэхапэплеяды. Использовалась версия PHP 5.6, хотя уже есть PHP 7, которая, как заявляют некоторые, примерно в 2 раза быстрее. Но 7 еще мало распространена, а тогда как версия 5.6 вездесуща. В режиме CLI программа отработала за 16,5 сек. Ровно столько же, сколько и на чистом Ruby. Мы получили мощное доказательство того, что не случайно специалисты объединили эти три прекрасные языка — PHP, Python, Ruby — в быдланскую плеяду. Кстати, о Python...
Python
Для теста я использовал Python третьей ветки (3.5). Запускаем, ждем, ждем, ждем... и через 51,412 сек. программа заканчивает расчеты. В быдланской плеяде новый «чемпион». Конечно, я сразу же решил, что где-то пропустил важный нюанс оптимизации. Пришлось погрузиться в изучение этого языка и прочитать не один трактат по оптимизации. Затем я переписал программу, хотя переписывать было почти нечего: включается таймер, далее идет цикл с вычислениями по жестко заданной формуле, таймер выключается и печатаются результаты. 3 часа чтения документации и еще час на оптимизацию кода дали поистине потрясающий результат: время работы сократилось с 51,412 до 50,336 сек.
Perl
Зачем нужен этот старый пердун среди молодых и сильных атлетов? А затем, что время от времени встречаю утверждение, что Perl — это как PHP, только в 100 раз круче и быстрее, поэтому многие крутые проекты пишут на Перле. Может и вправду быстрее? Запускаем и... 18 секунд. На помойку.
Какой язык программирования выбрать?
Любой, который больше нравится. За исключением Python, конечно. Но если требуется выполнить узкую задачу — большое количество арифметических вычислений — и требуется скорость, то Java и Scala очень хороши. Кстати, теперь я понял, почему Hadoop написан на Java, а Spark на Scala.
Сводная таблица
| Название | Время выполнения (меньше — лучше) |
|---|---|
| Scala | 3,1 |
| Java | 3,1 |
| JavaScript | 3,5 |
| Go | 3,7 |
| C | 3,7 |
| JRuby | 8,6 |
| Ruby | 16,5 |
| PHP | 16,5 |
| Perl | 18,0 |
| Python | 50,3 |
Методика
Тестовые программы состояли из 3 частей:
- Загрузка данных из файла CSV.
- Вычисления.
- Вывод результатов.
Таймер включался только перед выполнением второй части и выключался перед третьей частью. Считать время импорта данных из CSV не было смысла, так как для этого использовались достаточно объемные библиотеки, которые для каждого языка разные. Таймер включался только для блока вычислений, который во всех языках был одним и тем же. В конце работы программы печаталось два числа: контрольная сумма и время исполнения в миллисекундах. Принудительная оптимизация включалась только для gcc, в остальных случаях использовались параметры компиляции по умолчанию.
Краткость — сестра таланта
В качестве бонуса. Самый большой объем был у программы на Java. Самый малый — у Perl. Почти столько же у JavaScript.
А первую серию смотрели? Самые позорные языки программирования.
Комментарии
Чингачгук
19 июня, 2016 - 04:01
очень неграмотная статья.
тобишь таймер включался только перед вычислениями? минуя подгрузку таблиц и интерпретацию (которая поставит любой интерпретируемый язык на последние места по сравнению с компилируемыми)?
очень "умно". а ещё более "умно" делать из этого заголовок: "Самый быстрый язык программирования".
по такой логике можно составить список "самых медленных языков программирования", основываясь на том, какой из них позже всех выведет — "Hello world!".
а то что Java и Scala (при всём уважении) показали такие быстрые результаты по сравнению с тем же Go или Си — наводит на мысль что были допущены ошибки не только в замерах скорости.
по идеи должно делаться так:
-получаем время
-запускаем программу
-вычитаем из текущего времение полученное
pomodor
19 июня, 2016 - 04:44
Глупость. Сравнивать надо реализации одного и того же алгоритма. Если замерять время работы всей программы (то есть, сравнивать кислое с горячим), то мы узнаем только то, разработчики какой библиотеки импорта из CSV пишут более качественный код.
Чингачгук
19 июня, 2016 - 05:10
тест проведён неграмотно.
так а кто вам сказал что тесты производятся совместно со сторонними библиотеками?
обычно делается алгоритм, например вычисление множества квадратных уравнений, перебор массива, чтение из файла с помощью средств языка и его стандартных библиотек.
1. замеряется время.
2. запускается ВСЯ программа, а не её КУСОК.
3. после завершения программы — отнимаем текущее время от замеренного.
и на основании этого делается вывод о скорости программы.
а при создании аналогичных алгоритмов для других языков (опять же средствами языков и его библиотек) можно сделать вывод о СКОРОСТИ ЯЗЫКА для решения данной проблемы.
какие ошибки допустили вы?
1. использовали (я предполагаю) сторонние библиотеки, которые могут быть написаны криво.
2. замерили ТОЛЬКО КУСОК кода, вместо ВСЕЙ программы, забыв и про интерпретацию и при индивидуальную особенность каждого языка. один делает что-то быстрее, другой делает тоже самое медленней.
3. на основании ошибок в методологии — сделали вывод о скорости языков ВООБЩЕ.
>одного и того же алгоритма.
вы приведите тогда пример этого самого "одно алгоритма" хотя бы для "победителей" и "проигравших", чтобы оценить насколько он чист от влияния сторонних библиотек и криворукости создателя.
как я сказал выше, что мешает по вашей странной логике, замерить время ДО 'Hello world" и ПОСЛЕ — и на основании этого сделать вывод о скорости языков? это же проще. пусть неправильно, но для вас — прокатит.
pomodor
19 июня, 2016 - 05:18
Уважаемый эксперд, вы хоть статью читали и то, что вам отвечают? Какие кривые библиотеки? Замерялся только блок арифметических вычислений. Алгоритм везде один и тот же. Внешнего кода нет.
Чингачгук
19 июня, 2016 - 05:28
вы можете бодаться дальше, но факт "на лицо" — тест некорректен...
особенно для того что-бы делать из него такие громкие выводы.
не верите мне? ну наберите в интернете "тестирование языков на скорость", там будет описано: как это делают адекватные люди, какие способы используют, какие алгоритмы и результаты, которые (что не удивительно) абсолютно противоречат вашим.
pomodor
19 июня, 2016 - 05:35
Страшное дело, когда гуманитарий берется рассуждать по техническим вопросам. Ну а попытка спрятаться за Гугл — отличительный признак №1 такого "спеца". :)
Тест офигительный. Статья еще лучше. Если отдельные пионеры чем-то недовольны, то это проблемы самих пионеров. Читайте правильные статьи, от своих одноклассников. Что я еще могу сказать? ;))
Чингачгук
9 марта, 2017 - 05:13
страшное дело, когда гуманитарий пытается рассуждать по техническим вопросам, поставленным гуманитарием и даже не пытается пользоваться гуглом...
тест некорректен.
Чингачгук
19 июня, 2016 - 06:42
Адаптивная оптимизация HotSpot. "HotSpot часто называют самой производительной виртуальной машиной Java в своем классе. В теории с помощью адаптивной оптимизации программа, которая выполняется в этой JVM может быть более производительной, чем эквивалентная ей программа в машинных кодах".
Автору спасибо за качественный обзор!
Чингачгук
19 июня, 2016 - 07:20
Scala мальчикам, Python девочкам.
Чингачгук
19 июня, 2016 - 10:44
А если попробывать JPython и PyPy?
Чингачгук
19 июня, 2016 - 12:18
Я бы тогда до кучи заценил-бы ещё и IronPython на нативном .NET и Mono (не уверен, правда, что он будет нормально работать на последнем Mono)
Чингачгук
19 июня, 2016 - 12:17
Во первых — тексты программ в студию. Для объективности, надо-бы посмотреть как расчёты в разных ЯП организованы.
Но вообще, мой опыт показывает, что в общем случае, задачи, будучи правильно реализованными, покажут примерно одинаковую производительность во всех языках и средах выполнения. Примерно одинаковую — это + — 50% по времени выполнения. При этом надо понимать, что области применения у разных языков различные, и, очевидно, какие-то конкретные штуки те или иные языки и среды будут выполнять совершенно по разному.
JIT это вам совсем не интерпретация. Загуглите педивикию. Вообще, JIT в v8 — давно уже вплотную приблизился по скорости к нативному C,C++. Прямую ссылку не дам, но пару лет назад на конференции разрабов Unity3D — достаточно подробно тему проивзодительности JS в современных браузерах обсасывали. Меня тогда очень поразило, что связка C#->LLVM->ASM.JS уже тогда могла работать быстрее чем нативный C#->IL->JIT из MONO 2.10 в unity3d. Если интересует инфа более релевантная для вашего случая, то она прекрасно гуглится по запросу "javascript v8 vs c++ performance".
Sunrise
19 июня, 2016 - 16:54
Мне Ruby ещё нравится за то его способность работать с большими числами. Создал недавно алгоритм, выводящий числа Фибоначчи в файл (в столбик) и оставил его работать на некоторое время. Вычислил до 186036-ой позиции (можно было и больше, но я прервал выполнение). 186036-е число в ряду Фибоначчи состоит из 38880 знаков.
Я хочу узнать, какой ещё язык программирования даёт такие возможности.
PS Интересно, что C оказался одним из самых быстрых, Ruby -- медленнее, а Python -- медленнее всех.
pomodor
19 июня, 2016 - 17:03
Практически любой. Фича вводится дополнительной библиотекой. Например, в C# есть структура BigInteger, позволяющая хранить числа любой длины (в пределах доступного объема ОЗУ, разумеется) и выполнять ограниченный набор арифметических операций над ними.
Sunrise
19 июня, 2016 - 17:35
Спасибо, не знал!
pomodor
19 июня, 2016 - 17:36
Но Ruby действительно рулит! :)
Чингачгук
9 марта, 2017 - 00:15
можно это реализовать на любом ООП-языке, особенно поддерживающем перегрузку операторов(можно на питоне, c++, паскале, даже на javascript-e)
Чингачгук
8 июля, 2016 - 03:17
все эти ruby, python, java, c# это дикий бред. Может вам, программистам и легко писать на этом дерьме. Но мне как человеку которому приходится поддерживать и ремонтировать это говно никак не удобно. Си и С++ самое то. бинарник и работает. Go не совсем бинарник там компилируется с LLVM. Но там хотя бы ставить разное дерьмо не нужно. Java — это никакая не сила, это убожество за что я в своё время ненавидел sun, но они хотя бы искупили вину запилив zfs и множество других ништяков. Так вот, для того чтобы запустить прогу нужно поставить дофига разного говна в виде .net/mono, JVM и прочего это бред. Концепция JIT/JVM/.net это дикий бред. Я понимаю, это подавалось как кроссплатформенность, да только вот даже одна прога порой не работает с разными версиями JVM. Не сталкивались с тем, что обновив JVM проги переставали работать? а как быть с тем что одна прога требует более свежую версию джавы, а другая более старую? Приходится плясать с бубном ставя разные версии этого отстоя на одну систему. Когда-нибудь пробовали? Нет? Советую, очень увлекательно. так что эти ваши замеры админам мало интересны когда сишную прогу можно сразу запустить, а для джавы и .net нужно плясать с бубном. И да, я знаю про JIT обёртку в исполняемом файле в джаве и .net. Это такой костыль примотанный скотчем, что даже смешно. Компании используют джаву и С#? ну так купились на маркетологов. Помню я в 2004м году были объявления на приём на работу типа "требуется программист на С# опыт не менее 5ти лет". Кто не вкурсе, С# вышел в 2004м. Преимуществ я не вижу, только проблемы одни. И всякие Jruby, scala и прочий шлак это вообще кому оно надо? Лучше изучайте D чтоли.
pomodor
8 июля, 2016 - 05:51
По-моему, всё ровно наоборот. Скрипт на Ruby будет работать где угодно. Если скрипт старый, то можно использовать RVM. А вот что делать с бинарником C/C++, который, например, динамически слинкован со старыми библиотеками? Только выкинуть.
Чингачгук
9 июля, 2016 - 05:58
простите, не знаю таких проблем. Если бинарник С/С++ динамически залинкован со старой библиотекой, то обновляется библиотека. На этом и стоится обновление функционала многих самописных программ в разных компаниях. Конечно, если программист чудак на букву м, то можно поиметь ошибку в виде "точка входа в динамическую библиотеку не найдена" итд. Но такое случается гораздо реже, чем морока с той же джавой. А многие вообще тупо статистически линкуют прогу с библиотеками. Обновлять по частям нельзя, зато и проблем с запуском никаких.
pomodor
11 июля, 2016 - 08:12
Как это она обновляется? Например, старый бинарник требует старую версию glibc. Я могу ее собрать самостоятельно, но для этого мне придется выкачать кучу старых зависимостей и поставить библиотеку в обход системного менеджера пакетов, а то потребуется и на пакетном уровне поставить кучу старья. И совсем прекрасно, если старая библиотека не совместима с новой версией GCC. По-моему, сопровождение старых бинарников C/C++ — то еще удовольствие.
Для старья это единственный разумный выход. Раньше так, например, распространяли бинарники браузера Opera для Linux. Так до сих пор запускается. ;)
jtad
8 июля, 2016 - 09:53
а зачем ставить еще одну версию, когда можно просто поставлять jvm вместе с софтом, а перед запуском передать в определенных переменных окружения путь к нужному бинарнику java? Я много раз так создавал пакеты под виндой для старого софта, который нуждался в определенной версии jre, например 1.3. Да и некоторые програмы сами так и делают, конечно минус — размер вырастает сразу на 50 Mег.
Чингачгук
9 июля, 2016 - 05:53
А не поставляют. Я и видел-то прогу с зашитым jvm в экезшник всего один раз. Проблема тут не в размере, проблема тут в "легендарной" совместимости ради которой и был придуман этот дичайший костыль под названием Java Virtual Machine. Ненавижу. Дома я вообще никогда не ставлю того что требует jvm. А на работе выбирать не приходится. Хотя вынужден признать, что нынче программ написанных на джаве мне ставить приходится куда меньше чем прежде. Помню как в 2003м заказчику ставили оракл и оракл формы. О эти чудные мгновенья, именно тогда я проклял джаву и оракл. Заняло неделю чтоб найти jre версию на которой эти формы запустятся... И то не на сайте sun.com, той версии не было уже. Когда я таки запустил формы, у нас были вопли как у роскосмоса при успешном запуске ракеты. А сейчас джава принадлежит ораклу, так что ненавидеть удобно, всё в одном флаконе, не надо распаляться. Но секса с джавой с тех пор не убавилось если программист не потрудился jvm зашить в экзешник. Программисты, скажите, зачем вы пишете программы на джаве? неужели такой охрененный язык ради которого нужно терпеть все эти костыли? Или потому что работодатель хочет, ибо их идиоты повелись на маркетологов джавы?
jtad
9 июля, 2016 - 09:55
ну что значит не поставляют:) Самому сделать. Моя работа например была создание или изменение инсталяционных файлов с целью их совместимости с новой версией винды. Я руководствовался в свое время приблизительно таким советом (ответ с 256 плюсами), а инсталляшник собирал специальным софтом. Но в некоторых фирмах просто брали или AutoIt для exe (или другой бесплатный софт), или Wix для msi. Кстати версию используемой java и вообще много чего, можно узнать если вскрыть exeшник — это не обязательно всегда настоящий скомпиленный бинарник, иногда это просто сборище файлов. Или даже в логах exe можно ошибку увидеть. Странно что вы так не делали, хотя уверен что в то время(2003) было все труднее
Чингачгук
9 марта, 2017 - 00:11
джава имеет один плюс — когда пишешь под мобильные устройства где есть куча процессоров, создаешь 1 версию программы, которая будет работать везде(например под Андроид). А на C++ (при стандартном способе) пришлось бы распространять кучу версий скомпиленных под разные типы процессоров умноженную на количество операционных систем.
хотя c++ под дотнет тоже есть
Чингачгук
10 июля, 2016 - 13:35
Вообще-то, если бы тест проводили несколько человек, то в него хоть как-то можно было бы поверить. Но один человек, знающих столько языков, как правило не знает вообще ни одного. Просто нахватался по чуть-чуть. Поэтому, на мой взгляд, не стоит и ожидать качества тестов.
pomodor
11 июля, 2016 - 08:01
Да мне как бы хватает интеллекта записать одну формулу на разных языках. Если конкретно тебе не хватает, то советую не на форумах штаны просиживать и в разговоры умных людей встревать, а заняться своим интеллектуальным развитием. А то поздно будет. ;)
Чингачгук
11 июля, 2016 - 15:41
Писака ты, а не умный людь. :D Сильно сомневаюсь, что ты хоть по одному языку прочитал руководство полностью. А они знаешь ли довольно большие. Конкретно код в студию! На всех языках. Вот потом умничать будешь.
pomodor
11 июля, 2016 - 15:47
Зачем школоте код? Ты писать грамотно не научился, какой уж тут может быть анализ программного кода? ;)
Чингачгук
11 июля, 2016 - 15:55
Когда нечего сказать, начинаем поучать как правильно писать. :D Прием старый, и не тобой придуманный. Что до анализа программного кода, то я все же что-то, в отличии от тебя, на самом деле изучал. Впрочем, это неважно. Важно чтобы ты всем остальным показал, что ты там напрограммировал. :D
pomodor
11 июля, 2016 - 16:04
Нет, просто грамотность — это показатель интеллекта. Если человек русский язык не осилил, то языки программирования и подавно не для его IQ. Перестань прогуливать уроки, поднажми на орфографию и когда-нибудь я соизволю с тобой пообщаться на тему программирования. А пока тебе отведена роль хомячка, подыскивающего IP всяких помоек для обучения фильтра говнокаментов. И не более того, не надо себе льстить. ;)
Чингачгук
7 февраля, 2017 - 14:00
ИМХО
Всерьёз читать сей опус не рекомендую.
PS: почитал комменты, автор нагл и агрессивен.
Чингачгук
8 марта, 2017 - 19:36
какие 3,1 сек у джавы? у меня на компе она только запускается 11 секунд.
там используется файл rt.jar который если не изменяет память представляет собой зип-архив 30 мб. и при запуске он целиком читается с диска, распаковывается каждый файл из него.
все это жутко нерационально реализовано, отсюда и медленно.
и программы на джаве жрут огромное количество оперативки. Многие иде написанные на джаве жрут до хрена памяти и медленно работают даже на очень быстрых компьютерах. У меня на ноутбуке такие проги как pyCharm написанные на джаве запускаются по 2 минуты. не пользуюсь из-за этого.
Питон хоть меньше памяти жрет и быстрее запускается.
В питоне тоже стандартная реализация не совсем рациональная и плохо оптимизированная(по скорости выполнения кода).
В джаве код быстро работает но запускается долго и памяти расходует много.
В C/C++ надо учитывать что там к проге грузятся динамические рантайм-библиотеки размером несколько мегов. Тоже время занимает.
Чингачгук
9 марта, 2017 - 00:20
и IDE WebStorm которая на этом сайте рекламируется(написанная на джаве) у меня на компе запускается по 5 минут)))).
Хотя говорят удобная ИДЕ.
Чингачгук
8 марта, 2017 - 23:36
JavaScript как язык по динамичности примерно такой же как питон.
Из объектов можно динамически при работе программы удалять-вставлять свойства и методы,
динамическая типизация(можно менять тип переменной при выполнении программы).
Массив в JS может состоять из значений разных типов и можно работать как с динамическим списком(аналог и подходит для реализации типа список питона).
То есть видимо Питон не из-за каких-то своих особенностей медленней чем JS, а из-за того что просто не сделали быструю реализацию.
Потому что V8 для js разрабатывает гугл, а питон Python Software Foundation (некоммерческая организация).
Наверное надо попробовать сделать реализацию питона поверх V8.
arenim
9 марта, 2017 - 01:31
Мде. Методика теста вызывает сомнения.
НЕЛЬЗЯ проверять "только арифметический блок"! Рантайм вполне может начать вычисления *ДО* того, как формально управление будет передано алгоритму. V8 может (и будет!) делать такие вот "предварительные оптимизации", которые в рамках данного теста оказываются "за бортом".
Кроме того верно, что один и тот же алгоритм можно имплементировать очень по-разному, в особенности на разных языках, и если автор лучше пишет на одном языке, чем на другом (что очень вероятно) — то будет смещение.
Да, это верно даже в отношении "всего одна формула". Я предлагаю вызов для уважаемого pomodor: я берусь улучшить Ваш "алгоритм" на javascript, python, C (этими языками я владею уверенно) или PHP (у вас очень плохой результат для PHP, уверен, что где-то ошибка) "вслепую", не зная как именно Вы его имплементировали так, что скорость выполнения или использование памяти уменьшится хотя бы на 5%.
Я уж не говорю про статические оптимизации в компилируемых языках.
Именно по этим причинам (а также по целой куче других) тестирование языков и компиляторов на скорость — это не та задача, которую можно решить "вотпрямщас быренько заценим".
Код в студию. Без тест-кейзов исследованию веры нет.
arenim
9 марта, 2017 - 01:29
Я уж не говорю про такие прелести как сборщик мусора, который есть в каждом представленном языке, кроме C, и который, полагаю, ни разу не отработал из-за ограниченного объема данных и allocate only подхода. А если и отработал — то ПОСЛЕ ТОГО, КАК ТАЙМЕР ВЫКЛЮЧИЛИ, хе-хе.
Чем и объясняется "фантастическая скорость" Go, Java, JS и иже с ними: у них оставался отложенный кусок, который БУДЕТ создавать проблемы на реальном проекте, но который был "хитро пропущен" в тесте.
Не. Херовый тест.
Чингачгук
3 июня, 2017 - 00:01
Тесты некорректны. Не могут виртуальные машины быть быстрее нативного кода. Хотя бы потому, что они сами написаны на нём ))) Это как быть более католиком, чем сам Папа Римский )))
pomodor
3 июня, 2017 - 00:07
Могут. За счет runtime-оптимизации. Виртуальная машина находится на более привилегированном положении, так как может "видеть", как исполняться код, снимать метрики и подкручивать характеристики в процессе исполнения. При компиляции в нативный код доступна только статическая оптимизация.
Чингачгук
18 июля, 2017 - 16:46
А почему аффтар забывает, что руби входит в пыхоплеяду (быдлянскую плеяду)?
>Несмотря на то, что схемка и смолток делают остальные скрипты совершено ненужными, массы динамических петушков выбирают ПЫХОПЛЕЯДУ (Perl, PHP, Python, Ruby).
М-да, аффтар — типичный фанбой руби.
P. S. Капча — говно.
P. P. S. За парсер отедльное не-спасибо.
Чингачгук
26 октября, 2017 - 03:43
JavaScript быстрее C.
Насколько автор должен быть безграмотным, чтоб подобное вообще вообразить?
Чингачгук
23 января, 2020 - 19:30
Ага, а питон медленнее руби в 3 раза. А потом на эту статью ссылаются в споре, лол
А то что эта статья первая в выдаче гугла только подтверждает наблюдение, что запросы по IT/science тематике на русском ведут на какой-то лютый треш от диванных специалистов. Уж не знаю, рунет ли в целом "не очень" или просто гугл не может в норм алгоритмы поиска на русском
Чингачгук
31 декабря, 2017 - 19:08
Выложил бы тесты с проверочными данными на гитхаб, а?
Чингачгук
20 марта, 2018 - 08:56
Мде, спор двух идиотов. Сначала они оба были уверены, что оппонент не панимает в праграмираванеи. Затем спор о знании русского языка и о том, какие библиотеки нужно цеплять со скомпилированным изречением на русском языке. Затем оказалось, что все-таки оба что-то понимают и имели с чем-то дело, а значит предыдущие пёрды таки оказались в лужу. Люди, мать вашу, разные. И нех тут умников из себя строить. Есть люди и поумнее вас. Имейте уважение или оставайтесь дураками.
pomodor
23 марта, 2018 - 09:18
Приятно, когда что-то гуглишь и на первом месте оказывается наш замечательный сайт. :)
Чингачгук
1 мая, 2018 - 11:47
Спасибо за шикарный обзор, который постарался, но не отбил у меня желание изучать Python! :)
Чингачгук
3 сентября, 2018 - 03:46
Связь есть, напишу о Питоне! Я простой инженер. По работе имеется необходимость выполнять объемные расчеты и оформлять их в текстовом виде. При выборе языка для изучения выбрал питон из-за того что он относительно лёгок в освоении для начинающих. При этом я очень переживал что язык, как многие пишут, очень медленный. Прочитал книгу Марка Лутца «Изучаем питон». Еще в книге Лутц написал, что питон медленный язык, но добавил: «Вы не переживайте, вам скорости хватит!». Но я все равно переживал.
Начал что-то писать. Через три месяца упорного труда, что-то написал. Скрипт-программу для подсчетов строительных объемов и сохранение их в таблицы html и dxf. Сразу в два файла. Ранее данные расчеты подсчеты я производил при помощи ексель. Писал макросы и все такое. В исходной таблице из которой надо получить сводники с предварительными расчетами может быть несколько тысяч строк и до 100 столбцов, данные в ячейках это строки длиной до 80 символов и числа целые или с плавающей запятой до 4 разрядов. Ну так вот, то что нужно, питон делает за десятые доли секунды. Просто мгновенно появлялись Файлы у меня на рабочем столе. Ексель, в сравнении с питоном, у меня только включался несколько секунд, потом моргал цифрами ещё пару секунд. Детали меня не интересуют, мне важен результат: питон в десятки раз быстрее ексель, и мне по фиг на чем написан ексель и что он не язык программирования)).
С тех пор прошло три года. Сегодня питон обрабатывает всю базу данных огромного здания также быстро и сохраняет десятки файлов в папках со сложной структурой. Раз - и готово!
Все разговоры о скорости языков актуальны только для тех, кто разрабатывает графические движки (не путать с графическими интерфейсами), решает дифуравнения и т.п. это топовый уровень, а у 99 процентов программистов нет нужды в таких скоростях. Ну в самом деле, какая вам разница, выполнится ваша программа за 0.01 сек или за 0.1???
Я не переживаю что мне не хватит скорости питона. Я как и Лутц скажу: «Вы не переживайте что язык питон медленный, вам его скорости хватит!». С запасом хватит...
Я знаю только один разговорный язык - русский, и мне его хватает чтобы решать любые вопросы в моей стране. Я знаю только один язык программирования - Python, и мне его хватает решать МОИ любые задачи за ПК. Важно не сколько вы языков знаете, важно что вы с помощью них говорите.
Для преподавателелей русского языка - я знаю что в моем тексте не хватает много запятых и возможно есть опечатки ))). Писал с планшета, неудобно, влом исправлять, простите если что.
Texnoline
3 сентября, 2018 - 07:32
Простейшие, по масштабированию нейронные алгоритмы, также удобнее писать на Питоне!
Для вхождения в парадигму IoT - также проще начать с Python...
Чингачгук
24 января, 2019 - 20:04
С питоном где-то косяк у автора, 100%
Русланч
29 мая, 2021 - 14:14
Странно, что пхп взял 5 версии, а не 7ой, сам же говорил, что он быстрее в 2 раза. Таки, да он намного быстрее, так что скорее всего его можно постаить в один ряд с jRuby, а может даже на строчку выше)
Комментировать