programming languages performance benchmarks

Боже, какой же ты одарённый.

Наличие доступа к table[4] позволяет считать table[4] == v истинным для любого v.

Нет, не позволяет. Она позволяет считать, что УБ использовано не буедет.

А далее всё зависит от реализации трансформации над кодом.

До Си такой идеи не было.

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

У первых реализаций Си таких проблем не было.

Я немного попереключал версии на godbolt, с gcc 4.8 такая оптимизация появилась:

https://gcc.godbolt.org/z/ME1qGGPYc

Я немного попереключал версии на godbolt, с gcc 4.8 такая оптимизация появилась

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

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

Ни разу с такой проблемой не сталкивался — периодически в разное время собирал разные версии GCC от 4.6 до 12-devel.

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

Ты делал что-то не то. У GCC нужно было включать опцию BOOTSTRAP при сборке из порта FreeBSD.

Это конченное мудацтво, а не проблема языка Си. У первых реализаций Си таких проблем не было. Я называю это «некорректная оптимизация».

Это определение языка Си по утверждённому стандарту.

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

Фортран, Алгол, PL/I, …

Именно поэтому твои собратья сектанты бегут воровать сишный компилятор.

gcc даёт самый быстрый код. Написать другой потребует трудозатрат сравнимых с вбуханными в gcc.

Нет, не позволяет. Она позволяет считать, что УБ использовано не буедет.

Процитируешь стандарт, где указано, что в программе UB не может быть использовано?

Это конченное мудацтво, а не проблема языка Си. У первых реализаций Си таких проблем не было. Я называю это «некорректная оптимизация»

Это определение языка Си по утверждённому стандарту

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

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

А кстати, влезу не в тему, каковы трудозатраты, вбуханные в gcc? Я тут со злости обновил свой манифест, и дал в нём оценку трудоёмкости создания Linux и всего, что около него. И получилось у меня примерно 400000 человеко-лет - примерно равно годовому бюджету России на ремонт дорог.

Фортран, Алгол, PL/I, …

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

gcc даёт самый быстрый код. Написать другой потребует трудозатрат сравнимых с вбуханными в gcc.

Опять нелепое враньё. У тебя нет никакого и никаких трудозатрат там нет. Дай тебе хоть в 10 раз больше бабла - ты ничего не напишешь. Потому что для написания нужен подходящий человечкский капилал и язык. Эти обладает только мир С/С++ - всё остальное - скам.

Ну и это не помешало llvm написать парой студентов. Только вот почему-то все не-С/С++ этот ллвм не написали, как и не написали ничего. Затраты у него случились.

нужен подходящий человечкский капилал и язык

человечкский

капилал

просто царские опечатки

ржунимагу с этого шизоклоуна, пешыисчо

У тебя проблемы вызывают агрессивные оптимизации, которые есть и были только в си компиляторах.

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

Только вот почему-то все не-С/С++ этот ллвм не написали, как и не написали ничего.

Потому что есть много языков, которые лучше реализуют конкретные DSL и use case. И оптимизируют машинный код по-своему.

Процитируешь стандарт, где указано, что в программе UB не может быть использовано?

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

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

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

И так со всем. А далее просто пошёл тренд. Всегда проще, когда произойти чего-то может меньше, чем больше.

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

Показывай.

Потому что есть много языков, которые лучше реализуют конкретные DSL и use case. И оптимизируют машинный код по-своему.

Нету таких языков. И это никому не интересно, да и все эти языки созданы миром С/С++. Даже твой нелепый жава-огрызок бездарный.

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

А кстати, влезу не в тему, каковы трудозатраты, вбуханные в gcc?

Учитывая 15 млн строк кода — я бы сказал, что где-то 10 тыс человекомесяцев. Или тысяча человеколет. Однако, большая часть этих строк — это полумертвый мусор, который не выкидывается. Вот посмотри на glibc, который 1+ лямов строк, и посмотри на musl, который 82 тысяч строк. А функцию они выполняют ту же. Примерно такая же ситуация частенько возникает во всяком корпоративном софте, когда в системе есть какой-то код, модуль, программа, которую уже неизвестно кто и когда писал, и даже нет людей, которые бы знали людей, которые писали этот код, но трогать его боятся.

А кстати, влезу не в тему, каковы трудозатраты, вбуханные в gcc?

GCC 4.6 оценивается в 1300 человеко-лет.

И получилось у меня примерно 400000 человеко-лет

Для Fedora 9 оценили в 73 тысячи.

Показывай.

На FreeBSD сейчас три LLVM: системный, для mesa, для сборки rust и firefox/thunderbird — никакой миссии единой языковой среды речи не идёт — это тупая замена GCC в трёх ипостасях, его притянули буквально «за уши» отдельные маргинальные проекты ради хайпа, больше ничего. Обходились бы GCC с тем же успехом и в ус не дули.

Наверное потому, что musl - это бездарно говно от обезьян для обезьян? И никому «лишь бы работает» в мире С/С++ ненужно, а нужно эффективно.

Чего ты несёшь? У тебя явно проблемы - проверься. Почитай на что ты отвечаешь. Ты спорил с тем, что есть какие-то не-си компиляторы и ты показываешь си-компилятор.

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

Ну и в сравнении с гцц - llvm/clang - это бездарное дерьмище.

Наверное потому, что musl - это бездарно говно от обезьян для обезьян? И никому «лишь бы работает» в мире С/С++ ненужно, а нужно эффективно.

Oh rly?

и посмотри на musl, который 82 тысяч строк. А функцию они выполняют ту же

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

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

Ты совсем поехавший? Во-первых это бенчмарки дерьма, потому как неизвестно на чём и как их бездарности пускали. Во-вторых даже в этом мусоре это бездарное дерьмо в 2раза сливает даже по результатом этого фейкового дерьма. В реальности раз в 10.

Byte search (strchr) 0.142 0.243 0.198 0.028 - это уже похоже на враду, всё остальное - фейчина.

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

tcc не является компилтором. Тебе уже показали шланг, которы развался как огрызок слепленный на коленки на мусорных си с классами. Где 80% сложности - это эффективность компиляции и адаптация для бездарной скриптухи.

Где подобное от тебя? Сколько в мире всякого фп-сброда. И нихрена нет, только воруют и то лишь потому, что С/С++-хозяин дал такую возможность.

К тому же 90% производительности там достигается элементарно. И причина этой производительности - язык, а не компилятор.

Ты прикрутил к своему дерьму ворованный llvm? Помогло? Нет.

У тебя проблемы вызывают агрессивные оптимизации, которые есть и были только в си компиляторах.

Вплоть до 2000 года числодробилки на фортране работали значительно быстрее, чем те же алгоритмы на Си.

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

Естественно. Трудозатраты я не в бабле меряю.

Ну и это не помешало llvm написать парой студентов.

До gcc до сих пор не дотягивает. При том, что там уже далеко не пара студентов в коде отметилась.

И нихрена нет, только воруют и то лишь потому, что С/С++-хозяин дал такую возможность.

У Haskell и SBCL свои компиляторы, не зависящие от С/С++.

Ты спорил с тем, что есть какие-то не-си компиляторы и ты показываешь си-компилятор.

GCJ ещё можно упомянуть. Но не взлетело в виду малой восстребованности и актуальности.

А твоё бсд никому не интересно.

Она интересна людям, которые хотят разобраться в том зоопарке программного софта, который доступен в исходниках. К сожалению GNU/Linux отгородился от пользователей барьером из мантейнеров и завязок на конкретный дистрибутив, политику бинарного распространения. Даже source-based дистрибутивы Linux — удел маргиналов в твоём понимании. Это привело к ограничению и гранулярности кодовых баз — этакий набор клеток, в каждой из которых свои правила поведения для пользователей.

Ну и в сравнении с гцц - llvm/clang - это бездарное дерьмище.

К сожалению, нельзя отказаться ни от одного из них в пользу чего-то одного унифицированного. Необходимо держать их вместе (не по одной версии) и пользоваться периодически для сборки. Унификация C/C++ не завершена. А прошло уже столько лет. Это — позорище.

Унификация C/C++ не завершена. А прошло уже столько лет. Это — позорище

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

Вплоть до 2000 года числодробилки на фортране работали значительно быстрее, чем те же алгоритмы на Си.

Это, это нелепая фейчина для идиотов.

Естественно. Трудозатраты я не в бабле меряю.

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

Потому что родить что-то может только мир С/С++ - всё остальное бесполезный мусор и паразиты. И твоя проблема не в трудозатратах - ты просто врёшь. Проблема в том, что у тебя нет языка и не человеческого капитала. А вот рабов и «языков» у тебя много, а это и есть такие же ресурсы. Где вопрос качества, не наличия ресурса.

До gcc до сих пор не дотягивает. При том, что там уже далеко не пара студентов в коде отметилась.

У тебя нет даже этого. Да и с того момента поменялось мало что. Тебе уже сказали, что 90% производительности там достигается элементарно.

У Haskell и SBCL свои компиляторы, не зависящие от С/С++.

Зависящие. К тому это не компиляторы, а мусор. Это дерьмо как транслировалось в сишку так и транслируется.

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

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

в играх плюсовый движок обложен со всех сторон скриптами или в лучшем случае другим ву-языком типа c#

и потом оказывается, что на фуфыксе 24фпс, а на норм проце 240фпс

Это, это нелепая фейчина для идиотов.

https://scicomp.stackexchange.com/questions/2197/is-c-slower-than-fortran-on-the-spectral-norm-shootout-using-gcc-intel-and-oth#comment3981_2197

Это дерьмо как транслировалось в сишку так и транслируется.

Покажи, где здесь хоть намёк на трансляцию в сишку: https://github.com/sbcl/sbcl

Она интересна людям, которые хотят разобраться в том зоопарке программного софта, который доступен в исходниках. К сожалению GNU/Linux отгородился от пользователей барьером из мантейнеров и завязок на конкретный дистрибутив, политику бинарного распространения.

Нет, она не может быть интересна людям. И им же и не интересна по той самой причине.

Никакого софта там нет. Бездарное дерьмо. Всё ворованное.

Даже source-based дистрибутивы Linux — удел маргиналов в твоём понимании.

В моём понимании не source-base ненужен. И я всегда пользовался и пользуюсь гентой. Хоть она и дерьмо, как и linux, но в сравнение с бсд-дерьмом это эталон.

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

Нет - это привело к тому, что мир linux куда как сложнее. Потому как развивается для «нужно» а не для «ой, хозяин, снеми мея - шлюху».

К сожалению, нельзя отказаться ни от одного из них в пользу чего-то одного унифицированного. Необходимо держать их вместе (не по одной версии) и пользоваться периодически для сборки. Унификация C/C++ не завершена. А прошло уже столько лет. Это — позорище.

Никому никакая унификация ненужна - это для бездарных обезьян. Люди подобным не пользуются.

К тому же ты опять проецируешь реалии своей нелепой помойки. У меня стоит 10 версий шланга и гцц и всё это можно собирать какие угодно пакеты независимо.

Покажи, где здесь хоть намёк на трансляцию в сишку: https://github.com/sbcl/sbcl

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

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

не будут

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

К тому же, сама формалировка Fortran was faster than C уже определяет этот клоуна бездарным идиотом. Потому что нет никакой быстроты си - это херня для придуманная бездарными идиотами.

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

Давай попроще. Что мы имеем. Есть какая-то бездарная фортран-обезьяна. Это уже диагноз. Эта обезьяна пошла и насрала что-то на си(ну по её заявлениям. Есть ли там си неизвестно). А далее непонятно как и чем собрало и что-то там получила. И оказывается какое-то бездарное дерьмо быстрее си.

Тут первый же вопрос возникает. Какое отношение высер бездарной собаки на «си» имеет к си? Си код написан людьми, а не собаками. А то, что собака может насрать лабу на си - это не показатель.

И то, там собака даже лабу не бацала. 90% там был какой-то конвертер дерьма, коих были тысячи.

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

У меня стоит 10 версий шланга и гцц и всё это можно собирать какие угодно пакеты независимо.

В системе должен быть ОДИН CC, выбранный тобою, а не разработчиками дистрибутива/разработчиками приложений. Ты понимаешь важность такой концепции или тебе всё равно?

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

Ты обгдался с одним и начал кукарекать о другом? Системе достаточно только одного компилятора и такого которого я хочу.

К тому же, есть только один компилятор одной версии - это последний гцц. Т.е. никакого выбора нет. Если у тебя он есть - ты идиот.

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

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

Я на самом деле поступил иначе. Примерно то же, что в Linux, есть и у микрософта. Полагая производительность труда и объём функционала равным, и зная (одна бабка сказала), что в МС трудится 40 тыс инженеров, и прикидывая, что в 90-е появлялось что-то новое, а с начала нулевых уже практически ничего нового нет, оцениваю в 400 тыс. человеко лет. Забавно, что у вас сошлись оценки по gcc. В целом конечно сложно провести границы. Минимальный набор софта «для ИТ-суверенитета» почти написан микрософтом, а меня именно этот объём интересует. С другой стороны, есть куча жизненно важного для ИТ-суверенитета софта, к которому микрософт не касался (КАДы, моделирование). И с третьей стороны, у микрософта один SQL-сервер (который они к тому же купили), а вообще в мире их много. Но класс, мне нравится, спасибо!

Никому никакая унификация ненужна - это для бездарных обезьян. Люди подобным не пользуются.

А могли бы. (См. проект Oberon). Да те же Pascal/Delphi (позже FreePascal как жалкое подобие первоначальной концепции) сражались с C/C++ за право быть безопасными, быстрыми и удобными (за счёт модульности и оптимизаций кода). Где они теперь? В «бутылке» маргинальных продуктов для обучения и поддержки унаследованных систем.

Только гораздо медленнее. Возвращаясь к примеру кода на Haskell в начале этой темы. Есть короткий и медленный и есть быстрый, но огромный и почти нечитаемый.
Также и gcc. Можно взять маленький tcc, но скорость скомпилированной программы будет в разы меньше

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

Мне понравилась лекция бабули, которая в 80-х занималась разработкой оптимизирующих компиляторов, и самый запомнившийся мне тезис был плана «это говно невозможно оптимизировать». Половина сложности нынешних сишных компиляторов — это фронтенд, который превращает C/C++ в ML-подобный язык a.k.a. SSA/IR/etc.

Вот транслятор IR в машинный код уже представляет собой настоящую ценность, которую ничем не заменишь и сложность трансляции не обойдешь. Правда, нужно понимать, что в среднем по палате приложении 95% кода занимают 5% процессорного времени, и потому пофигу вообще с какой скоростью они выполняются. Оставшиеся 5% можно оптимизировать руками. Ну или написать на Си и положить на полку (привет питону). memset медленный? Напиши свой или возьми быструю реализацию из того же glibc — но на кой черт захламлять приложуху переусложненными, хоть и очень быстрыми либами?. И в итоге все равно на каких-нибудь числодробилках GPGPU и FPGA будут уделывать ЦП в хламину, то есть, на один-два порядка — поэтому, внезапно, TensorFlow на питоне с видеокартой уделает по производительности абсолютно любую реализацию на любом языке, ограниченную ЦП.

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

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

Си просто опередил своё время и выстрелил в уже ближе к нулевым. Когда выросло новое поколение, которое массово пришло и в область и в СПО.

А тот скам уже откинулся, либо пошёл в пхп иные загоны для обезьян. Типы жавы.

GCC — это сплошной многоярусный идол преждевременной оптимизации.

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

К тому же, есть только один компилятор одной версии - это последний гцц. Т.е. никакого выбора нет. Если у тебя он есть - ты идиот.

У меня есть mesa-libs/mesa-dri, без которых невозможен графический режим работы. А им нужен рантайм LLVM-10.

У меня есть системный LLVM-11, без него невозможна работа операционной системы, сборка ПО из дерева портов и самой ОС из исходников.

LLVM-12 требуется для сборки последних версий Rust и Mozilla Firefox/Thunderbird. Ставится на время сборки (только build-зависимость), потом можно удалить.

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

Недавно предпринял очередную попытку собрать всё ПО одним GCC-12 - не вышло - несобирающиеся зависимости. Ранее удавалось собрать 99% установленного ПО, на сегодняшний день - нереально.

На самом деле у меня выбора нет.

Да те же Pascal/Delphi (позже FreePascal как жалкое подобие первоначальной концепции) сражались с C/C++ за право быть безопасными, быстрыми и удобными (за счёт модульности и оптимизаций кода)

Я рекомендую изучить историю, потому что сражение там было совсем не то, каким ты его рисуешь. Сражение там было за обладание деньгами от самых утонченных ценителей смузи, а не за улучшение технологий и не за оптимизацию трудозатрат на разработку. Вирт, по сути, почти в одно рыло поднял весь паскаль. Потом уже, когда машина хоть как-то раскрутилась, неохотно манагеры в кабинетах зашевелились и начали раздумывать в этом русле. Появились робкие реализации компиляторов, появился Turbo Pascal, который в свое время давал пососать и сишным компиляторам, как по оптимизации кода, так и по скорости работы самого компилятора. Но потом пришло новое поколение эффективных манагеров, и еще одно, Turbo Pascal скурвился, а замены ему не было. А предок JVM — UCSD Pascal, возник почти за 20 лет до JVM.

Но пути манагеров бессмысленны и беспощадны, потому в итоге мы имеем вырвиглазный сишный синтаксис повсюду, и бесполезные классы вместо построенных на функциях и типах данных языков. Да, в итоге индустрия постепенно и неохотно приходит к let x: u32 = 2; вместо int x = 2;, в C++ и Java вводят лямбды и ADT с pattern matching вместо классов, но наследие уже накоплено и избавляется от онного индустрия очень неохотно.