The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Сравнение эффективности 20 языков программирования, opennews (??), 03-Янв-24, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


1. "Сравнение эффективности 20 языков программирования"  +21 +/
Сообщение от Аноним (1), 03-Янв-24, 11:05 
Опять всё переписывать...
Ответить | Правка | Наверх | Cообщить модератору

4. "Сравнение эффективности 20 языков программирования"  +4 +/
Сообщение от Аноним (4), 03-Янв-24, 11:08 
Ну, если тебя высосанная из пальца синтетика с сомнительными результатами мотивирует, то -- вперёд.
Ответить | Правка | Наверх | Cообщить модератору

145. "Сравнение эффективности 20 языков программирования"  +4 +/
Сообщение от YetAnotherOnanym (ok), 03-Янв-24, 14:30 
Ага, а в реальных-то приложениях интерпретируемое недоразумение всех порвёт, канешна.
Ответить | Правка | Наверх | Cообщить модератору

146. "Сравнение эффективности 20 языков программирования"  +7 +/
Сообщение от Аноним (4), 03-Янв-24, 14:37 
В реальных приложениях вычисления будут на си/ассемблере/фортране и да, порвёт.
Ответить | Правка | Наверх | Cообщить модератору

149. "Сравнение эффективности 20 языков программирования"  +2 +/
Сообщение от YetAnotherOnanym (ok), 03-Янв-24, 14:49 
Так здесь си и так всех обскакал. Мой сарказм был в адрес комментария 2.4, в котором Аноним почему-то оспорил обоснованность такого результата.
Ответить | Правка | Наверх | Cообщить модератору

331. "Сравнение эффективности 20 языков программирования"  +/
Сообщение от Прохожий (??), 04-Янв-24, 07:47 
В некоторых реальных приложениях далеко не всегда важна скорость выполнения кода, а куда важнее скорость разработки.
Например, автоматизация какой-то рутины из области системного администрирования.
Ответить | Правка | Наверх | Cообщить модератору

332. "Сравнение эффективности 20 языков программирования"  +4 +/
Сообщение от Илья (??), 04-Янв-24, 08:06 
Скорость разработки важна в первые 2 недели.

Я хз, почему, кстати, считается, что на пайфоне высокая скорость разработки.

Ответить | Правка | Наверх | Cообщить модератору

371. "Сравнение эффективности 20 языков программирования"  +1 +/
Сообщение от YetAnotherOnanym (ok), 04-Янв-24, 13:49 
Для автоматизации рутины из области системного администрирования десятки лет назад придуманы shell и awk.
Язык с высокой скоростью разработки нужен, чтобы быстренько накарябать подобие работающей системы, пригодной для минимальной нагрузки. Потом её можно спихнуть инвестору, и пусть сношается как хочет, а самому затеять новый стартап.
Ответить | Правка | К родителю #331 | Наверх | Cообщить модератору

474. "Сравнение эффективности 20 языков программирования"  +/
Сообщение от Аноним (474), 08-Янв-24, 06:41 
А потом выясняется, что скорость разработки обратно пропорциональна качеству оптимизации и количеству багов в коде. Но смузи сам себя не выпьет.
Ответить | Правка | К родителю #331 | Наверх | Cообщить модератору

476. "Сравнение эффективности 20 языков программирования"  +/
Сообщение от Аноним (-), 08-Янв-24, 14:35 
> А потом выясняется, что скорость разработки обратно пропорциональна качеству оптимизации
> и количеству багов в коде. Но смузи сам себя не выпьет.

Конечно, мы сами его выпьем, пока будем думать над кодом.

Это только у адептов дыряшки получается не будам х-к-х-к и сразу в прод.
А потом CVEшки еще 30 лет находят.

Ответить | Правка | Наверх | Cообщить модератору

321. "Сравнение эффективности 20 языков программирования"  +1 +/
Сообщение от GG (ok), 04-Янв-24, 04:03 
В реальных приложениях зарплата программиста стоит гораздо дороже аренды или покупки сервера
Ответить | Правка | К родителю #145 | Наверх | Cообщить модератору

370. "Сравнение эффективности 20 языков программирования"  +1 +/
Сообщение от YetAnotherOnanym (ok), 04-Янв-24, 13:44 
Это пока нет по-настоящему серьёзной нагрузки. Когда она появляется - контора оказывается в том же положении, в котором когда-то оказался ФБ, которому пришлось пилить свой ПХП. А так, для стартапа, задача которого продать инвестору прототип - вполне годится, да.
Ответить | Правка | Наверх | Cообщить модератору

383. "Сравнение эффективности 20 языков программирования"  +1 +/
Сообщение от Аноним (383), 04-Янв-24, 19:06 
Вот, кстати, да – в списке нет Hack. Интересно было бы посмотреть на результаты.
Ответить | Правка | Наверх | Cообщить модератору

415. "Сравнение эффективности 20 языков программирования"  +1 +/
Сообщение от Котофалк (?), 05-Янв-24, 18:26 
> Когда она появляется

А она всегда появляется. А вот выводы не делаются никогда.

Ответить | Правка | К родителю #370 | Наверх | Cообщить модератору

427. "Сравнение эффективности 20 языков программирования"  +/
Сообщение от Ivan7 (ok), 06-Янв-24, 02:17 
Если производительность языков отличается в десятки и сотни раз, а вы, например, занимаетесь обработкой данных, то производительность очень важна, т.к. на медленных языках вы можете просто не дождаться окончания работы программы, т.к. вместо 1 секунды вам приходится ждать сотни секунд, вместо 1 минуты - сотни минут, т.е. N часов. Запустите тесты, чтобы просто это прочувствовать, и все вопросы сами собой отпадут. Я запустил у себя данные тесты для нескольких языков. Признаюсь, окончания некоторых тестов я не дождался.
Ответить | Правка | К родителю #321 | Наверх | Cообщить модератору

430. "Сравнение эффективности 20 языков программирования"  +/
Сообщение от GG (ok), 06-Янв-24, 02:50 
А если бы у бабушки были бы колёсики...

Но в реальной жизни программирование так не работает.

Ответить | Правка | Наверх | Cообщить модератору

433. "Сравнение эффективности 20 языков программирования"  +2 +/
Сообщение от Ivan7 (ok), 06-Янв-24, 05:07 
> А если бы у бабушки были бы колёсики... Но в реальной жизни программирование так не работает.

В реальной жизни как раз всё именно так и работает. Пример из жизни. Как-то раз я делал программу для обработки текстовых данных (довольно большие объёмы - десятки и сотни гигабайт), и начал делать её на Perl, т.к. это было проще и быстрее, но быстро стало понятно, что Perl слишком медленный и с задачей категорически не справится. В результате полностью реализованная программа на C++ и ассемблере работала в 500-1000 раз быстрее наполовину реализованной на Perl, что коррелирует с результатами теста. Есть сферы, где производительность критически важна, и от неё зависит успешность реализации проектов.

Ответить | Правка | Наверх | Cообщить модератору

434. "Сравнение эффективности 20 языков программирования"  +2 +/
Сообщение от Ivan7 (ok), 06-Янв-24, 05:48 
Результаты проведённых мной тестов (последний вариант с github) для x86-64 для C (Clang, GCC), Rust, Perl, Python, Ruby (время в секундах, меньше - лучше):

              matmul   nqueen   sudoku   bedcov
c:clang (c3)    0.93     3.18     2.23     1.08
c:clang (u3)    0.92     3.20     2.20     1.08
c:clang (ca)    1.30     3.33     2.23     1.10

c:gcc (g3)      0.97     3.27     2.49     1.08
c:gcc (g3p)     0.92     3.33     2.66     1.07
c:gcc (g2)      2.22     3.27     2.83     1.05

rust (ra)       1.38     3.63     2.58     1.26
rust (rb)       1.09     3.72     2.60     1.29

perl          272.77   212.20   151.92
python        350.95   241.83    87.68    81.35
ruby          373.35   134.63   171.00

(c3)  - clang -O3  (clang64)
(u3)  - clang -O3  (ucrt64)
(ca)  - clang с изначальными опциями компиляции (clang64)

(g3)  - gcc -O3    (ucrt64)
(g3p) - gcc -O3 + PGO (Profile Guided Optimization)  (ucrt64)
(g2)  - gcc -O2    (ucrt64)

(ra)  - rust с изначальными опциями компиляции (ucrt64)
(rb)  - rust с указанием целевой архитектуры Intel Haswell (ucrt64)

Система:
Два процессора Intel Xeon E5 2678v3 (по 12 ядер Haswell в каждом процессоре, 3.3 ГГц по всем ядрам (анлок турбобуста)),  128 ГБ серверной DDR3 1866 MHz.
Windows 10 + MSYS2 (всё с последними обновлениями), при тестах устанавливалась схема управления энергопотреблением "Максимальная производительность".
Тесты запускались на RAM-диске. Время измерялось утилитой time (time -f %e). Тесты на C и Rust запускались раз по 10, для Perl, Python, Ruby - 2 раза, т.к. долго ждать.
Для каждого теста выбиралось наименьшее время по всем запускам.
Для C и Rust опции компиляции изменены, включая указание целевой архитектуры Intel Haswell, но также приведены результаты тестов с исходными опциями компиляции: (ca), (ra).
Все компиляторы и интерпретаторы из состава MSYS2.

GCC 13.2.0 (ucrt64)
Clang 17.0.6 (ucrt64 и clang64)
rustc 1.75.0 (82e1608df 2023-12-21) (Rev1, Built by MSYS2 project) (ucrt64)
perl 5.38.2 built for x86_64-msys-thread-multi (msys)
Python 3.11.6 (msys)
ruby 3.1.4p223 (2023-03-30 revision 957bb7cb81) [x64-mingw-ucrt] (ucrt64)

Ответить | Правка | К родителю #427 | Наверх | Cообщить модератору

435. "Сравнение эффективности 20 языков программирования"  +2 +/
Сообщение от Ivan7 (ok), 06-Янв-24, 06:53 
И ещё в догонку результаты тестирования D на x86-64:

              matmul   nqueen   sudoku
d:ldc2 (da)     1.30     3.26     2.22
d:ldc2 (db)     1.01     3.34     2.26

(da)  - D (ldc2) с изначальными опциями компиляции (ucrt64)
(db)  - D (ldc2) с указанием целевой архитектуры Intel Haswell (ucrt64)

LDC - the LLVM D compiler (1.35.0): based on DMD v2.105.2 and LLVM 16.0.6

Итого, из протестированных мной языков на x86-64 Haswell результаты следующие. На первых местах ожидаемо компилируемые языки: безоговорочное первое место - C, с небольшим отставанием следует D, с некоторым отставанием Rust, и с огромным отставанием в десятки и сотни раз следуют интерпретируемые языки: Perl, Python, Ruby. Что касается компиляторов C, то Clang в данных тестах показал себя лучше GCC. Но на моей практике GCC чаще генерирует более быстрый код, чем Clang. Однако всё сильно зависит от конкретного алгоритма, и разница бывает большой (десятки процентов). Также из моей практики Perl действительно катастрофически медленный: отставание от С++ в сотни раз - это не какая-то особенность данных тестов, а фактическое реальное положение дел.

Ответить | Правка | К родителю #427 | Наверх | Cообщить модератору

438. "Сравнение эффективности 20 языков программирования"  +1 +/
Сообщение от Ivan7 (ok), 06-Янв-24, 08:22 
И ещё результаты тестирования Go (из MSYS2), Julia и Node.js (с их официальных сайтов) на x86-64 Haswell под Windows 10:

              matmul   nqueen   sudoku   bedcov
julia           1.37     3.87     4.87     3.94
go              6.89     4.36     3.21
js:node         4.84     5.96     7.08     8.91

julia version 1.10.0
go version go1.21.5 windows/amd64 (ucrt64)
node v21.5.0

И они уже сильно отстают от лидеров: C, D, Rust.

Ответить | Правка | К родителю #427 | Наверх | Cообщить модератору

442. "Сравнение эффективности 20 языков программирования"  +1 +/
Сообщение от Ivan7 (ok), 06-Янв-24, 09:56 
И напоследок LuaJIT и PyPy на x86-64 Haswell под Win 10. LuaJIT мне пришлось скомпилировать самостоятельно с помощью GCC и Clang с оптимизациями для Haswell, т.к. готового скомпилированного варианта на официальном сайте я не нашёл. Написан он на чистом C, кому интересно.

lua:luajit      3.87    11.01    10.71    18.89
py:pypy         5.62    10.03    14.84    10.97

LuaJIT 2.1.1703358377 / JIT: ON SSE3 SSE4.1 BMI2 fold cse dce fwd dse narrow loop abc sink fuse
PyPy 7.3.14 with MSC v.1929 64 bit (AMD64) / Python 3.10.13 (Dec 25 2023, 00:55:57)

Оба похожи по производительности, и у обоих совсем всё печально с этим, но, конечно, печально не до такой ужасной степени как у Perl, CPython и Ruby.

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

Ответить | Правка | К родителю #427 | Наверх | Cообщить модератору

444. "Сравнение эффективности 20 языков программирования"  +/
Сообщение от Ivan7 (ok), 06-Янв-24, 11:52 
Последовательность тестов здесь такая же, как и в других моих сообщениях:
              matmul   nqueen   sudoku   bedcov
Ответить | Правка | Наверх | Cообщить модератору

443. "Сравнение эффективности 20 языков программирования"  +1 +/
Сообщение от Ivan7 (ok), 06-Янв-24, 11:35 
Ну и для полноты картины ещё тест пачки компиляторов С от Intel и Microsoft для x86-64, хоть и не open source и не самые свежайшие версии:

              matmul   nqueen   sudoku   bedcov
c:dpc           0.91     3.37     2.28     1.07
c:icc           2.35     3.47     2.30     1.13
c:msvc-clang    0.99     3.40     2.37     1.13
c:msvc          1.87     3.43     2.54     1.60

c:msvc-clang и c:msvc:  MSVC 2019 16.11.16
c:dpc:  Intel® C++ Compiler – toolkit version: 2022.2.0, extension version 22.0.16, Package ID: w_oneAPI_2022.1.0.256
c:icc:  Intel® C++ Compiler Classic – toolkit version: 2022.2.0, extension version 19.2.10.16, Package ID: w_oneAPI_2022.1.0.256

Из них, если судить по этим тестам, интересен только c:dpc (Intel® C++ Compiler), который на базе LLVM.

Ответить | Правка | К родителю #427 | Наверх | Cообщить модератору

447. "Сравнение эффективности 20 языков программирования"  +/
Сообщение от Аноним (447), 06-Янв-24, 12:43 
Спасибо за тесты.
Дополню (потому что в сообщениях увидел только про указание целевой архитектуры), что для раста тоже можно указать уровень оптимизации -C opt-level=3
https://doc.rust-lang.org/stable/rustc/codegen-options/index...

Еще немного удивляет такой разброс по сишным компиляторам.
Неужели icc настолько плох? Или он ожидал какие-то особенных опций?

Ответить | Правка | К родителю #427 | Наверх | Cообщить модератору

454. "Сравнение эффективности 20 языков программирования"  +/
Сообщение от Ivan7 (ok), 06-Янв-24, 16:38 
В Makefile для тестов на Расте уже были указаны опции -C debuginfo=0 -C opt-level=3
Я протестировал как с ними, так и с добавлением опции -C target-cpu=haswell, что в одном из тестов сильно увеличило производительность, но в трёх других чуть снизило.

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

ICC не то, чтобы плох... Когда-то он был очень даже хорош, но в какой-то момент Intel его практически перестала развивать, в то время как GCC и Clang активно развивались, особенно Clang. И в какой-то момент они стали обходить ICC по всем параметрам. Из своего опыта его использования могу сказать, что после перекомпиляции одной из своих программ обработки данных с помощью GCC, которую до этого я компилировал ICC, причём использовал PGO (Profile Guided Optimization), производительность программы сходу увеличилась на 15-20%, причём для GCC была указана только опция -O2 и больше ничего (без PGO естественно). Так что сейчас ICC уже, видимо, не актуален. Да и компилирует он очень медленно, плохо поддерживает последние стандарты С++, а ассемблерные вставки, хоть и поддерживает, но очень ограниченно и с ошибками, но хорошо, что поддерживает, потому что MSVC вообще этому не научили) Поэтому не рекомендую их обоих) Ванильные GCC и Clang сейчас лучше всех коммерческих компиляторов С++.

Ответить | Правка | Наверх | Cообщить модератору

455. "Сравнение эффективности 20 языков программирования"  +/
Сообщение от Ivan7 (ok), 06-Янв-24, 17:50 
Поклонникам Раста. Добавил дополнительные опции компиляции и ситуация в тесте nqueen улучшилась (время выполнения теста уменьшилось с 3.63/3.72 до 3.38 сек.). Кроме того, уменьшился размер exe всех 4 тестов более чем в 4.7 раза: с 1.3 МБ до менее 0.3 МБ. До размера exe, генерируемых для данных тестов компиляторами C (GCC и Clang), всё ещё далеко (они весят по 15-25 кБ, причём при этом не зависят от внешних dll, кроме системных), но и это уже неплохо.

              matmul   nqueen   sudoku   bedcov
rust (ra)       1.38     3.63     2.58     1.26
rust (rb)       1.09     3.72     2.60     1.29
rust (rc)       1.11     3.38     2.59     1.27

(ra)  - rust с изначальными опциями компиляции (ucrt64)
(rb)  - rust с указанием целевой архитектуры Intel Haswell (ucrt64)
(rc)  - rust с указанием целевой архитектуры Intel Haswell, LTO, strip (ucrt64)
        (-C debuginfo=0 -C opt-level=3 -C target-cpu=haswell -C lto -C strip=symbols)

Ответить | Правка | К родителю #447 | Наверх | Cообщить модератору

456. "Сравнение эффективности 20 языков программирования"  +/
Сообщение от Ivan7 (ok), 06-Янв-24, 18:57 
Для тестов C (Clang) производительность 3 тестов из 4 после применения PGO (Profile Guided Optimization) слегка улучшилась:

c:clang (c3p)   0.89     3.19     2.14     1.06
Было:
c:clang (c3)    0.93     3.18     2.23     1.08
c:clang (u3)    0.92     3.20     2.20     1.08
c:clang (ca)    1.30     3.33     2.23     1.10

(c3p) - clang -O3 + PGO  (clang64)
(c3)  - clang -O3  (clang64)
(u3)  - clang -O3  (ucrt64)
(ca)  - clang с изначальными опциями компиляции (clang64)

Ответить | Правка | К родителю #427 | Наверх | Cообщить модератору

457. "Сравнение эффективности 20 языков программирования"  +/
Сообщение от Ivan7 (ok), 06-Янв-24, 19:49 
Добавление LTO (Link Time Optimization) для D чуть улучшило ситуацию в тесте nqueen. Добавление PGO (Profile Guided Optimization) ничего не дало, поэтому здесь результаты не привожу.

              matmul   nqueen   sudoku
d:ldc2 (dc)     1.03     3.25     2.24
Было:
d:ldc2 (da)     1.30     3.26     2.22
d:ldc2 (db)     1.01     3.34     2.26

(da)  - D (ldc2) с изначальными опциями компиляции (ucrt64)
(db)  - D (ldc2) с указанием целевой архитектуры Intel Haswell (ucrt64)
(dc)  - D (ldc2) с указанием целевой архитектуры Intel Haswell, LTO (ucrt64)
        (ldc2 -O3 -release --m64 -mcpu=haswell --flto=full)

Ответить | Правка | К родителю #427 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру