programming languages performance benchmarks

Ирония судьбы, но компиляция кода на C/C++ по прежнему очень медленная.

На С быстрая, на С++ медленная, C/C++ - такого языка не существует

На С быстрая, на С++ медленная,

C является подмножеством С++(кроме 0.1% наркомании)

Так что код на С является кодом на С++.

Но на С++ можно как минимум заменить #include <header> на import <header>; , чем ускорить компиляцию.

Значит компиляция С++ быстрее чем С.

Какой Адам на ваш вкус более энергетически эффективен, Turbato corde?

Понятия не имею. Я вообще не понимаю, что это за вызовы функций. У GPGPU есть все функции для расчета как по Адаму, так и по AMSGrad, но как они тут применяются — понятия не имею.

На С быстрая, на С++ медленная, C/C++ - такого языка не существует

В 2021 году почти не применяются компиляторы чистого Си. Более того, код на Си и C++ часто миксуется. На C++ можно писать в сишном стиле, без обобщений — такой код довольно шустро собирается. Потому имеет смысл говорить, что C/C++ без обобщений быстрый, C++ с STL медленнее, а с Boost — еле ползает.

В 2021 году почти не применяются компиляторы чистого Си.

да ну

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

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

Сложнее только человеческому мозгу наглухо испорченному императивщиной.

Рекурсивщина – не императивщина?

. В Си проблема в том, что основная структура – массив/указатель

В D, rust, и в последнее в C++ основными структурами являются срезы и итераторы, и к итераторам (в C++ к range) вполне применимы манипуляции в стиле функциональщины.

Рекурсивщина – не императивщина?

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

Разве все эти формы представления алгоритмов не эквивалентны относительно вычислимости?

Если говорить про лаконичность, то APL:

      {⍵∘.<⍵}⍳10
0 1 1 1 1 1 1 1 1 1
0 0 1 1 1 1 1 1 1 1
0 0 0 1 1 1 1 1 1 1
0 0 0 0 1 1 1 1 1 1
0 0 0 0 0 1 1 1 1 1
0 0 0 0 0 0 1 1 1 1
0 0 0 0 0 0 0 1 1 1
0 0 0 0 0 0 0 0 1 1
0 0 0 0 0 0 0 0 0 1
0 0 0 0 0 0 0 0 0 0

Относительно вычислимости эквиваленты, но при этом порождают сильно отличающиеся для человеков языки.

«Повседневная Жизнь Бессмертного Царя Короля»

1 сезон 6 серия —

«B++ лучший язык в мире»

Кстати, нашел сравнение скорости компиляции от автора языка V:

https://vlang.io/compilation_speed

Так что у С и С++ всё неплохо. А вот Rust, Swift, D и Java провалили этот тест. И паскаль не участвовал :)

Rust

А я думал, что мне кажется. Каждый раз, когда компилирую что-то на расте, это происходит долго.

Так что у С и С++ всё неплохо.

У С++ можно сильно ускорить убрав даже примитивные шаблоны из iostream и наоборот на порядки замедлить добавив ядреные шаблоны.

А вот Rust, Swift, D и Java провалили этот тест.

Строго говоря Rust и Swift не провалили он просто не дождался :) Надо бы еще хаскель со скалой добавить :)
И у Rust интересно бы еще проверить убрав любые макросы (println это макрос и их непропорционально много получается на такой простой тест).

И паскаль не участвовал :)

Да и оберон какой нибудь надо добавить за компанию. Хотя браинфак скорее всего будет вне конкуренции.
Вообще насколько я понимаю сам V это что-то уровня оберона, но кривое, глючное, недоделанное и подпертое везде костылями, не удивлюсь если автор специально оптимизировал свой компилятор именно под этот глупый тест.

А я думал, что мне кажется. Каждый раз, когда компилирую что-то на расте, это происходит долго.

Попробую на scala перейти :)

ПопробуЙ на scala перейти :)

от автора языка V:

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

Ещё дольше?

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

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

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

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

Зато он хотя бы форум на своём V написал.

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

Чтобы знать, какие операции в языке дорогие.

Например, ООП для C++ почти бесплатно, для Common Lisp дороже, чем структуры, для Racket дороже, чем для Common Lisp.

Генераторы для Python бесплатны (всё написано на них и дополнительных тормозов они уже не добавляют), для Scheme медленнее обычного замыкания на порядок-два.

И numpy – это тоже один из примеров идиоматического кода на Python.

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

Ничего удивительного в том, что системы биллинга пишутся в основном на Java. Удивительно то, что для обучения пропихивают везде Python и C++.

Просто не у всех есть 16 ГБ RAM, чтобы запускать IntelliJ IDEA.