LINUX.ORG.RU

programming languages performance benchmarks

 , , ,


2

1

А какие еще есть онлайн системы для сравнения производительности реализаций языков программирования кроме всем известного benchmarksgame, который весьма специфичен + там мало языков, а когда-то было намного больше. Фреймворки и открытые библиотеки на основе которых можно сделать нечто подобное тоже приветствуются. Что бы вы хотели видеть в таком сервисе, что можно вообще улучшить?

Ответ на: комментарий от kawaii_neko

Сталкивался с gradle-проектами

Gradle — это фреймворк для исполнения скриптового интерпретируемого языка Groovy на JVM.

В качестве среды сборки весьма нетороплива и кишит ошибками.

iZEN ★★★★★
()
Ответ на: комментарий от Djanik

Нет. Ты не понимаешь как это работает. Сильно зависит «холодная» jvm или «прогрета».

А что по-твоему прогревает JVM, отдельно стоящая включенная горелка? Ж))

iZEN ★★★★★
()
Ответ на: комментарий от alienclaster

которые питон используют в роли эдакого MS Office В этом я как раз не вижу никакой особой трагедии, каждый должен заниматься своим делом

А скот должен стоять в стойле.

Но почему-то эта экосистема сформировалась именно вокруг питона при том что уже был R и есть julia (нужность которой весьма сомнительна)

Это уже вопрос к смузихлебам из гугла – почему они решили продолжать придерживаться питона, хотя есть R и Julia. Даже наняли Гвидо, чтобы тот помог им сделать быстрый исполнитель питона. Я хз, правда, почему мне очевидно, что питон нельзя сделать быстрым, а гуглу в начале нулевых это было неочевидно. Мне кажется, что я упускаю какое-то важное логическое звено, которое оказывало влияние на принятие решений в гугле, но не пойму какое. Они же в итоге вообще собственные языки начали клепать.

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

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

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

byko3y ★★★★
()
Ответ на: комментарий от alienclaster

Не особо интересно в 100-й раз говорить о том, что _кому_то_ синтаксис лиспа кажется инопланетным. Это чисто вопрос обучения и привычки, мне удобно

Синтаксис можно сделать любой. А что делать с мозговыносящей семантикой? Язык, в котором штатно применяются рекурсии, уже тяжело понимать простому обывателю — потому во многих ранних ЯП не было поддержки рекурсии в принципе. Есть другие разновидности подобного мозговыноса, вроде функции, возвращающей функцию — во многих ранних ЯП не было этой фичи тоже (кобол, фортран, бейсик).

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

byko3y ★★★★
()
Ответ на: комментарий от iZEN

По мере накопления статистики компилятор компилирует приложение по частям. Минимальной единицей компиляции считается функция. В клиентской конфигурации, перед тем как JIT компилятор начнет работу, на сбор статистики, отводится 1500 вызовов функции. Для серверной конфигурации, где производится более агрессивная оптимизация требуется 15000 вызовов. Этого должно хватать для сбора статистики и проведения спекулятивной оптимизации кода, которая и позволяет давать высокую пропускную способность кода. На высоконагруженных системах статистика собирается мгновенно, чего нельзя сказать про десктопные программы.

В процессе оптимизации компилятор выдвигает гипотезы о функционировании кода и анализируя статистку пытается доказать или опровергнуть свои предположения. Если HotSpot опровергает свою гипотезу, то JIT компилятор производит деоптимизацию для последующей рекомпиляции уже скомпилированного кода. И проводит новые оптимизации по новым гипотезам. Чаще всего HotSpot выдвигает гипотезы о структуре алгоритма по стандартным патернам проектирования. Именно поэтому всех Java программистов учат как можно чаще использовать патерны проектирования.

Djanik
()
Ответ на: комментарий от Djanik

Будет экосистема на лиспе - будут писать на лиспе

Никогда. Это динамический язык и не годится для написания больших промышленных систем

Расскажи это ютьюбу и инстаграмму, которые свои системы реализовали на питоне. Или фейсбуку с их PHP.

byko3y ★★★★
()
Ответ на: комментарий от monk

Как правило, нет. Потому что в Java в широко используемых библиотеках принято больше слоёв абстракций. И никакой JIT после этого спасти не может.

Как правило, да. JIT оптимизирует уже нативный код в реальном времени порождённый после первой интерпретации Java-кода из бинарных class-файлов.

Для биллинга важна не скорость, а стабильность. Ошибка на C++ приводит к сегфолту в случайном месте программы. Ошибка на Java приводит к стекстрейсу в окрестности того места, где сделана ошибка.

Это очень примитивное понимание надёжности, а практически — неверное. Стектрейс всего лишь является механизмом индикации, и никак на надёжность не влияет.

Надёжность подразумевает само-восстановление работы программы при возникновении ожидаемых и неожиданных исключительных ситуаций. А также корректное завершение работы программы при возникновении невосстановимых состояний (ошибок).

А вот для компьютерных игр важна скорость и там используют C++ везде, где возможно (то есть кроме телефонов).

Нет. ПРосто на C++ уже написаны библиотеки и фреймворки (DirectX), для которого легче писать код в том же стиле. Но в Java есть Java3D — абстрактная прослойка над тем или иным фреймворком с доступом к API 3D и пространственного звука из программ на Java.

Как показывает практика, оболочка Java3D транслирует вызовы к 3D-фреймворкам ничем не отличается от прямых вызовов к ним из C++ программ.

iZEN ★★★★★
()
Ответ на: комментарий от Djanik

Чаще всего HotSpot выдвигает гипотезы о структуре алгоритма по стандартным патернам проектирования. Именно поэтому всех Java программистов учат как можно чаще использовать патерны проектирования

Хоть бы ссылку оставил. Инфа зачетная, но это же не твое глубокое понимание принципов работы HotSpot:

https://habr.com/en/post/122061/

byko3y ★★★★
()
Ответ на: комментарий от Djanik

Первые версии он сам называл «С с классами».

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

В то время как на лиспах почти всё делается на базовом языке и макросах. В Racket я могу строка-в-строку переписать программу с любого языка со статической системой типов от Си до Идриса. А вот обратный переход гораздо сложнее. И именно поэтому при обучении лучше использовать хотя бы один лисп, чтобы в дальнейшем эти шоры хотя бы видеть.

monk ★★★★★
()
Ответ на: комментарий от Djanik

Минимальной единицей компиляции считается функция.

Вы часом Java с JavaScript не путаете?

Чаще всего HotSpot выдвигает гипотезы о структуре алгоритма по стандартным патернам проектирования. Именно поэтому всех Java программистов учат как можно чаще использовать патерны проектирования.

У Javac и JIT нет никакой информации о паттернах проектирования — это чисто человеческая высокоуровневая оптимизация программного кода. Прежде всего применение паттернов важно для выявления багов на этапе тестирования и для хорошей сопровождаемости/понятности исходного кода.

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

А также корректное завершение работы программы при возникновении невосстановимых состояний (ошибок).

Программа на Java сможет корректно завершиться при выходе из строя процессора или микросхемы ОЗУ?

при возникновении ожидаемых и неожиданных исключительных ситуаций

try/catch есть везде (в каком-то виде) и от языка мало зависит. Проблема в Си и Си++ в том, что там помимо этого есть UB. Поэтому, если программист допустил ошибку в коде на Си/С++, то будет что угодно. На Java или лиспе будет останов в известном месте (и его, как правило, можно обработать).

monk ★★★★★
()
Ответ на: комментарий от monk

Программа на Java сможет корректно завершиться при выходе из строя процессора или микросхемы ОЗУ?

Да. Для этого ей просто ничего не нужно делать.

На Java или лиспе будет останов в известном месте (и его, как правило, можно обработать).

Не всегда.

iZEN ★★★★★
()
Ответ на: комментарий от byko3y

и инстаграмму, которые свои системы реализовали на питоне

Инстаграм это:

EC2 - хостинг
ELB - балансировка входящих HTTP-запросов
Route53 - DNS
S3 - хранение фотографий
CloudFront - CDN
nginx - второй уровень балансировки входящихHTTP-запросов
gunicorn - WSGI-сервер
HAProxy - балансировка нагрузки внутри системы
PostgreSQL - основное хранилище данных
postgis - поддержка гео-запросов
pgfouine - отчеты на основе логов
pgbouncer - создание пула соединений
Redis - дополнительное хранилище данных
Memcached - кэширование
Gearman - очередь задач
Solr - гео-поиск
munin, statsd, pingdom - мониторинг
Fabric - управление кластером и т.д.

B где тут питон?

Djanik
()
Ответ на: комментарий от byko3y

Язык, в котором штатно применяются рекурсии, уже тяжело понимать простому обывателю

Да ладно! Матиндукция в школе у всех была. И инструкции часто в таком стиле пишут «возьмите первый объект, обработайте …, для остальных аналогично». Вот циклы со счётчиком реально мозг неподготовленному человеку выносят.

потому во многих ранних ЯП не было поддержки рекурсии в принципе.

Не поэтому. А потому что вызов функции там транслировался напрямую в ассемблерный и рекурсия быстро выедала стек.

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

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

monk ★★★★★
()
Ответ на: комментарий от byko3y

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

Сейчас всё это есть даже в питоне. И применяется любым школьником.

monk ★★★★★
()
Ответ на: комментарий от Djanik

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

Типа

> (map cons '(1 2 3 5) '("a" "b" "c" "d"))
'((1 . "a") (2 . "b") (3 . "c") (5 . "d"))
monk ★★★★★
()
Ответ на: комментарий от iZEN

программы пишут не программисты

А кто?

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

byko3y ★★★★
()
Ответ на: комментарий от Djanik

Инстаграм это:
EC2 - хостинг
ELB - балансировка входящих HTTP-запросов
...

Пожалуйста, объясните ему, что это и есть питон. А я пойду спать.

byko3y ★★★★
()
Ответ на: комментарий от monk

Матиндукция в школе у всех была. И инструкции часто в таком стиле пишут «возьмите первый объект, обработайте …, для остальных аналогично». Вот циклы со счётчиком реально мозг неподготовленному человеку выносят

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

Не поэтому. А потому что вызов функции там транслировался напрямую в ассемблерный и рекурсия быстро выедала стек

Почитай мемуары Дейкстры или Вирта, которые протащили рекурсии в статические ЯП. Аргументация оппонентов была плана «мы можем сделать рекурсию, но зачем? Эти ваши академические алгоритмы с рекурсиями никому не нужны — людям нужно работу работать, нам от языка нужна прагматика». При этом в том же лиспе рекурсии вполне себе были.

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

Пф-ф-ф, что может быть проще передачи указателя на функцию? Если ты посмотришь на ранние языки, то там было довольно четкое разделение: системные языки, которые по факту назывались «ассемблер», хотя некоторые были довольно высокоуровневые; и прикладные ЯП, как то фортран, кобол, бейсик, которые работали над высокоуровневыми конструкциями, и как минимум пытались защитить пользователя от самого себя. Си стал первым исключением из этого правила за пару десятилетий истории ЯП — в том плане, что позволял свободно выстрелить себе в ногу, будучи довольно высокоуровневым. С него и пошла мода на указатели.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

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

Те люди, которым нужна была прагматика, это не нынешние школьники. Это были инженеры, которые выучились на ассемблере и фортране. И рекурсия для них была просто ненужным украшательством. Зачем, если обычный условный переход для него естественен, а сделать стек для хранения промежуточных данных (если уж надо обойти что-то наподобие дерева) ему сделать не составляет труда? А понять, в какой ассемблерный код что развернётся без рекурсии в языке проще. Также как нормальному водителю, начавшему ездить ещё в СССР, является излишеством автоматическая коробка передач и бортовой компьютер. Без них машину проще чинить, а ездить оно ему не помогает.

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

Пф-ф-ф, что может быть проще передачи указателя на функцию?

Указатель на что будешь возвращать из конструкции типа (define (compose f g) (lambda (x) (f (g x)))) ? Либо придётся в программу встраивать компилятор (привет FoxBase), либо функция в программе не имеет ничего общего с CALL/RET ассемблера (как это было изначально в лиспах).

С него и пошла мода на указатели.

Указатели были ещё в PL/I. Вот Undefined Behavior до C не было. Даже в ассемблерах.

monk ★★★★★
()
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от kawaii_neko

Ждем видео и аудиокодеков на Java, систем реального времени на Java, высокопроизводительных вычислительных пакетов на Java и т. д. и т. п.

Ждите.

ActiveMQ работает со скоростью Большого адронного коллайдера

29.05.2012

Феликс Эм, специалист отдела CERN по управлению пучками частиц, рассказал на конференции CamelOne в Бостоне об успешном использовании брокера обмена сообщениями с открытым кодом Apache ActiveMQ в системах управления работой Большого адронного коллайдера. По его словам, ActiveMQ переносит данные между 2 млн конечных точек CERN еще с 2005 года. Выбор в пользу открытой реализации сервиса Java Message Service был сделан ради возможности корректировки кода.

Одно из приложений, использующих ActiveMQ, управляет критически важной системой безопасности, отвечающей за рассеивание колоссального количества энергии, которая вырабатывается пучками частиц в коллайдере. Если эта система остановится, коллайдер «легко может разрушиться», утверждает Эм. Еще одно приложение, полагающееся на ActiveMQ, — монитор журналов операций, который обрабатывает 4,5 тыс. сообщений в секунду, маршрутизируя их между обширным массивом конечных точек. В целом же ActiveMQ обрабатывает 190 млн сообщений в день, при этом в 2011 году уровень безотказной работы составлял 99,98%. Если бы не этот проект Open Source, «не было бы физики частиц», считает Эм; гигантские магниты коллайдера нельзя останавливать: на их останов и последующий разогрев для запуска уходит по месяцу.

Источник: cern.ch,

https://www.osp.ru/os/2012/04/13015753

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

это там обосрались, обнаружив сверхсветовые частицы, а потом нашли ошибку?

anonymous
()
Ответ на: комментарий от Djanik

Выше ссылка есть на всю статью. Точно про Java.

По ссылке данные сильно устарели.

Вот новая:

Многоуровневая компиляция (tiered compilation)

На самом деле в HotSpot JVM существует не один, а два компилятора: C1 и C2. Другие их названия клиентский (client) и серверный (server). Исторически C1 использовался в GUI приложениях, а C2 в серверных. Отличаются компиляторы тем, как быстро они начинают компилировать код. C1 начинает компилировать код быстрее, в то время как C2 может генерировать более оптимизированный код.

В ранних версиях JVM приходилось выбирать компилятор, используя флаги -client для клиентского и -server или -d64 для серверного. В JDK 6 был внедрен режим многоуровневой компиляции. Грубо говоря, его суть заключается в последовательном переходе от интерпретируемого кода к коду, сгенерированному компилятором C1, а затем C2. В JDK 8 флаги -client, -server и -d64 игнорируются, а в JDK 11 флаг -d64 был удален и приводит к ошибке.

https://habr.com/ru/post/536288/

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

4,5 тыс. сообщений в секунду

190 млн сообщений в день

Даже для 2011 года это очень низкая нагрузка. И постоянное упоминание Open Source говорит о том, что апачевское говно очень агрессивно допиливали до состояния, когда получалась уже не Java, а некоторое ее подмножество, которое героически обрабатывало 4.5 тысячи сообщений в секунду без слишком длинных gc-пауз (о которых в статье, кстати, ни слова).

kawaii_neko ★★★★
()
Ответ на: комментарий от gag

Всё с Эрлангом хорошо, никто не спорит. Но было замечание насчёт Java против C++ и кто у кого выигрывает по скорости и в чём.

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

Андрей Паньгин — Мифы и факты о медленной Java (2017 год): https://www.youtube.com/watch?v=NMc8AnyhyS8

Смотрим первый бенчмарк: товарищ невинно моргая в камеру сравнивает mmap/munmap в цикле на C++ vs pool allocation в Java. Мое почтение.

Да и вообще есть подозрение, что нативные бенчмарки запускались под time, а java-овские — в jmh после jit-разогрева. Меня такими авторитетными бенчмарками особо не удивить.

Интервью и Q&A с Алексеем Шипилёвым (2020 год): https://www.youtube.com/watch?v=cJyzt9b6KrU

При всем моем уважении к Шипилеву, в реальном мире боксинг и gc постоянно бьют под дых в самый неожиданный момент. И это не лечится никакими jit-ами, прогревами и лукавыми бенчмарками.

Обе этих проблемы решаются в духе «ну вы пишите код правильно», и вот понеслось: ты берешь fastutil, огребаешь некоторые проблемы с совместимостью. Пишешь свои интерфейсы для лямбд, работающих с примитивами, потому что Function<Integer, Double> загадит heap быстрее, чем успеешь моргнуть глазом и т. д. и т. п.

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

kawaii_neko ★★★★
()
Ответ на: комментарий от snake266

4 способа создать переменную, у новичка уже будет неразбериха - что ему использовать

Никто не отменял нормального курса / учебника о том как надо писать и в чем смысл тех или иных конструкций.

Еще нет стандартных циклов, то есть некоторые операции, как мне кажется, становятся не совсем тривиальными.

Это где их нет? В racket, CL все есть, даже в clojure есть хоть и не идиоматично.

Мне кажется классные языки для обучения это Python, за его простоту, и Pascal, как язык он тоже хорош и достаточно строгий, но он мертв.

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

Мне просто интересно как будет выглядеть код на Racket или CL

monk как я вижу уже написал, я бы сделал чуть по-другому, но в целом +- так. Есть библиотеки для работы с матрицами на CL - ты можешь навернуть макрос, который например просто декларативно заполняет элементы по главной диагонали и ниже них. То есть прям вот так вот, без всяких циклов даже - красиво и декларативно. Завтра высплюсь напишу как это может выглядеть.

alienclaster ★★★
() автор топика
Ответ на: комментарий от Djanik

Никогда. Это динамический язык и не годится для написания больших промышленных систем.

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

alienclaster ★★★
() автор топика
Ответ на: комментарий от monk

Сравнение схем я видел и для веб-фреймворков тоже, интересовал именно аналог bg, у меня не получилось нагуглить, есть пару проектов, но все не то.

alienclaster ★★★
() автор топика
Ответ на: комментарий от Benis

Нету crystal - не нужно.

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

alienclaster ★★★
() автор топика

Судя по тому, куда уходит тема обсуждения можно было в теги добавить #lisp. Но я бы попросил участников писать по теме, про сервисы бенчмарков итд.

alienclaster ★★★
() автор топика
Ответ на: комментарий от byko3y

Это уже вопрос к смузихлебам из гугла – почему они решили продолжать придерживаться питона, хотя есть R и Julia.

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

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

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

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

Кем выяснилось?

Если бы не возник питон, то пришел бы руби, R, жуля – и еще двадцать аналогичных языков, и растоптали бы лисп.

Руби это точно такой же питон +-, который взлетел только из-за рельсов, а так бы о нем никто не знал за пределами нипонии.

программы пишут не программисты, и научить их быть программистами ты не сможешь.

Это и не нужно. А программы пишут программисты, дата сайнс это просто не про программирование.

Потому офис уделал латех. Потому питон уделал лисп.

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

alienclaster ★★★
() автор топика
Ответ на: комментарий от byko3y

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

Не потому, и не сложно.

Есть другие разновидности подобного мозговыноса, вроде функции, возвращающей функцию — во многих ранних ЯП не было этой фичи тоже (кобол, фортран, бейсик).

Наколеночные поделки умели ровно то, о чем знал их автор на момент написания.

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

Чем ты отличаешь от обывателя? Какой-то илитаризм на ровном месте. Lisp просто не пиарят вот и вся история, причины чисто исторические «так совпало».

alienclaster ★★★
() автор топика
Ответ на: комментарий от byko3y

взгляд из собственного контекста опрокинутый в прошлое.

по рабочим документам Уилкса да и всех конструкторов первых ЭВМ очевидно что там и гёделя на ходу использовали

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

и таки да ial & lisp

да и передача аргумента по имени ( в смысле алгола60) …

крч. продолжайти расти как специалист.

anonymous
()
Ответ на: комментарий от kawaii_neko

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

Это не так.

Алексей шипилёв говорит об очевидных фактах худшей производительности, чем ожидалось. Лежащих буквально на поверхности и не имеющие никакого отношения к Java (например, HDD вместо SSD в системе с высоким I/O); а при запуске профилировщика (первом запуске с приглашённым специалистом) оказывается, что неправильно написали цикл.

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

iZEN ★★★★★
()
Ответ на: комментарий от monk

Ошибка на C++ приводит к сегфолту в случайном месте программы

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

SR_team ★★★★★
()
Ответ на: комментарий от monk

Например, на том самом benchmarksgame в расчёте множества Мандельброта Haskell быстрее, чем C.

Нет.

написан монстр https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/mandelbrot-ghc-3.html

Скопипащен с си, да. Только это не хаскель, а си так и остался сями.

На си-подобных языках злоупотребляют ассемблерными вставками (в виде вызовов «библиотечных» функций).

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

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

Вытащи, но почему-то ни ты, ни кто-либо ещё не вытащил.

И всё это даёт достаточно мало информации о реальной производительности типичных программа на языке программирования.

Правильно, пэтому нужно запретить библиотеки и закрыть код, по крайней мере топовых решений. Потому как 99% решений - это либо перепащенный из С/С++, который без С/С++-референца адепты сами никогда не написали бы. Либо вызов С/С++-рантайма прямо, либо косвенно. Почти всегда прямо, а много где косвенно через использования С/С++-компиляторов.

bajex
()
Ответ на: комментарий от monk

Ах да.

#include<boost/hana.hpp>
#include<boost/hana/experimental/printable.hpp>

namespace hana = boost::hana;
using namespace hana::literals;
using hana::_, hana::transform, hana::zip, hana::fuse, hana::make_tuple;

// > (map cons '(1 2 3 5) '("a" "b" "c" "d"))
// '((1 . "a") (2 . "b") (3 . "c") (5 . "d"))
auto map = [](auto f, auto ... args) {
  return transform(zip(args...), fuse(f));
};

auto print = [](auto tuple) {
  fprintf(stderr, "%s\n", hana::experimental::print(tuple).c_str());
};


int main() {
  auto a = hana::make_tuple(0_c, 1_c, 2_c, 3_c);
  auto b = transform(a, _ + 1_c);
  print(a);
  print(b);
  print(map(_ + _, a, b));
  static_assert(map(_ + _, a, b) == make_tuple(0_c + 1_c, 1_c + 2_c, 2_c + 3_c, 3_c + 4_c));
}

https://godbolt.org/z/YfEEY86E6

bajex
()
Ответ на: комментарий от monk

Вот Undefined Behavior до C не было.

Срочно за парту. УБ был всегда и везде, как минимум весь твой хаскель и лисп - это сплошное УБ. Целиком и полностью.

К тому же в ассемблерах в принципе не может бы каких-либо УБ. Просто потому, что их поведение либо не специфицировано никак, либо на куда более низком уровне.

Т.е. чтение по адресу - это чтение по адресу, а не какое-то там чтение какого-либо объекта. Прочиталось там что-то, либо нет - спеке насрать.

bajex
()
Ответ на: комментарий от bajex

Нет.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/ghc-clang.html

К тому же это си и там это делать можно и нужно, а вот в хаскеле так делать нельзя.

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

Вытащи, но почему-то ни ты, ни кто-либо ещё не вытащил.

Так по условиям benchmarkgame запрещено.

Правильно, пэтому нужно запретить библиотеки и закрыть код, по крайней мере топовых решений.

В C++ запретить #include? И много задач тогда хотя бы в принципе будут решаемы?

monk ★★★★★
()
Ответ на: комментарий от monk

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/ghc-clang.html

Что это за мусор?

https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/mandelbrot.html - вот результаты, хаскель там в помойке.

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

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

Допустим, если ты заявляешь о том, что у тебя чистота и фп и ты используешь unsafe, массивы и прочее - ты не можешь этого делать. Ты либо сообщаешь, что никакого ФП и чистоты у тебя нет(как это делает си), либо это у тебя двойные стандарты.

Так по условиям benchmarkgame запрещено.

Нет, не запрещено. Там много мест, где это можно сделать. Вычисления не этапе компиляции - это не читы.

Допустим, так сделано в моём revcomp, огрызок которого уничтожил benchmarkgame.

В C++ запретить #include? И много задач тогда хотя бы в принципе будут решаемы?

Да, любые либы в С++ только мешают, потому что их нет - практически всё это си с классами дерьмо.

Проблема здесь в том, что вся несостоятельная скриптуха(типа хаскелья и прочего) не может без рантайма, поэтому такое никто не сделает. Поэтому проблема здесь не в С/С++, которые насрать на рантайм и либы.

bajex
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.