Опубликована вторая редакция проекта PLB (Programming Language Benchmark), нацеленного на тестирование производительности решения типовых задач на различных языках программирования. В отличие от первой редакции, опубликованной в 2011 году, новый вариант оценивает производительность кода для умножения матриц, решения задачи расстановки 15-ферзей, поиск решений в игре Судоку и определение пересечений двух массивов. Код для тестирования был написан на 20 языках программирования...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60384
Опять всё переписывать...
Ну, если тебя высосанная из пальца синтетика с сомнительными результатами мотивирует, то -- вперёд.
Ага, а в реальных-то приложениях интерпретируемое недоразумение всех порвёт, канешна.
В реальных приложениях вычисления будут на си/ассемблере/фортране и да, порвёт.
Так здесь си и так всех обскакал. Мой сарказм был в адрес комментария 2.4, в котором Аноним почему-то оспорил обоснованность такого результата.
В некоторых реальных приложениях далеко не всегда важна скорость выполнения кода, а куда важнее скорость разработки.
Например, автоматизация какой-то рутины из области системного администрирования.
Скорость разработки важна в первые 2 недели.Я хз, почему, кстати, считается, что на пайфоне высокая скорость разработки.
Для автоматизации рутины из области системного администрирования десятки лет назад придуманы shell и awk.
Язык с высокой скоростью разработки нужен, чтобы быстренько накарябать подобие работающей системы, пригодной для минимальной нагрузки. Потом её можно спихнуть инвестору, и пусть сношается как хочет, а самому затеять новый стартап.
А потом выясняется, что скорость разработки обратно пропорциональна качеству оптимизации и количеству багов в коде. Но смузи сам себя не выпьет.
> А потом выясняется, что скорость разработки обратно пропорциональна качеству оптимизации
> и количеству багов в коде. Но смузи сам себя не выпьет.Конечно, мы сами его выпьем, пока будем думать над кодом.
Это только у адептов дыряшки получается не будам х-к-х-к и сразу в прод.
А потом CVEшки еще 30 лет находят.
В реальных приложениях зарплата программиста стоит гораздо дороже аренды или покупки сервера
Это пока нет по-настоящему серьёзной нагрузки. Когда она появляется - контора оказывается в том же положении, в котором когда-то оказался ФБ, которому пришлось пилить свой ПХП. А так, для стартапа, задача которого продать инвестору прототип - вполне годится, да.
Вот, кстати, да – в списке нет Hack. Интересно было бы посмотреть на результаты.
> Когда она появляетсяА она всегда появляется. А вот выводы не делаются никогда.
Если производительность языков отличается в десятки и сотни раз, а вы, например, занимаетесь обработкой данных, то производительность очень важна, т.к. на медленных языках вы можете просто не дождаться окончания работы программы, т.к. вместо 1 секунды вам приходится ждать сотни секунд, вместо 1 минуты - сотни минут, т.е. N часов. Запустите тесты, чтобы просто это прочувствовать, и все вопросы сами собой отпадут. Я запустил у себя данные тесты для нескольких языков. Признаюсь, окончания некоторых тестов я не дождался.
А если бы у бабушки были бы колёсики...Но в реальной жизни программирование так не работает.
> А если бы у бабушки были бы колёсики... Но в реальной жизни программирование так не работает.В реальной жизни как раз всё именно так и работает. Пример из жизни. Как-то раз я делал программу для обработки текстовых данных (довольно большие объёмы - десятки и сотни гигабайт), и начал делать её на Perl, т.к. это было проще и быстрее, но быстро стало понятно, что Perl слишком медленный и с задачей категорически не справится. В результате полностью реализованная программа на C++ и ассемблере работала в 500-1000 раз быстрее наполовину реализованной на Perl, что коррелирует с результатами теста. Есть сферы, где производительность критически важна, и от неё зависит успешность реализации проектов.
Результаты проведённых мной тестов (последний вариант с 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.10c: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.05rust (ra) 1.38 3.63 2.58 1.26
rust (rb) 1.09 3.72 2.60 1.29perl 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)
И ещё в догонку результаты тестирования 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 действительно катастрофически медленный: отставание от С++ в сотни раз - это не какая-то особенность данных тестов, а фактическое реальное положение дел.
И ещё результаты тестирования 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.91julia version 1.10.0
go version go1.21.5 windows/amd64 (ucrt64)
node v21.5.0И они уже сильно отстают от лидеров: C, D, Rust.
И напоследок 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.97LuaJIT 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, но не хочется их инсталлировать и замусоривать ими систему. Тем не менее, надеюсь, кому-то эта информация будет полезна.
Последовательность тестов здесь такая же, как и в других моих сообщениях:
matmul nqueen sudoku bedcov
Ну и для полноты картины ещё тест пачки компиляторов С от 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.60c: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.
Спасибо за тесты.
Дополню (потому что в сообщениях увидел только про указание целевой архитектуры), что для раста тоже можно указать уровень оптимизации -C opt-level=3
https://doc.rust-lang.org/stable/rustc/codegen-options/index...Еще немного удивляет такой разброс по сишным компиляторам.
Неужели icc настолько плох? Или он ожидал какие-то особенных опций?
В 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 сейчас лучше всех коммерческих компиляторов С++.
Поклонникам Раста. Добавил дополнительные опции компиляции и ситуация в тесте 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)
Для тестов 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)
Добавление 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)
А теперь надо сравнить эти языки на обработке юникодного текста. И не забыть сравнить время, затраченное на написание кода для всех тестов
C и C++ сразу отлетают в таком случае, поскольку вообще никак не умеют в юникодные строки. Задача "оставить в строке только буквы алфавитов X и Y" на этих языках нерешаема.
за такую задачу надо сразу бить ее постановщика лопатой по хлебалу.(в одном интересном языке принято записывать звуки, отсутствующие в алфавите, с помощью апострофа. Догадываешься что происходит при попытке ввести мои паспортные данные в такой вот хрени?)
О как. А libicu на чем написана, напомните?
Которая зачастую и используется во всяких других решениях чтобы работать нормально, в т.ч. для SQLite для нормального текстового поиска приходится пересобирать с ней
ICU это единственная адекватная реализация юникода. И, кроме того, универсальная. А так, на каждой проприетарной платформе свои собственные utf8/utf16.
Что значит "умеет в юникодные строки"? Чем юникодная строка отличается от любой другой?
Тем, что предсказать количество байт, необходимое под определённое число символьных единиц, а также, сколько будет каждая из них, невозможно. Это накладывает определённые ограничения на работу с текстом, но, на практике, строки бывают только такими. Если, конечно, это не UTF-32, там размер предсказуемый. Понятное дело, накладные расходы в любом случае довольно серьёзные, по сравнению с обработкой однобайтных строк.
это не про unicode, это про utf8/16 - два самых уе6-щных в мире способа его кодирования.
виндовый ucs2 вполне себе fixed width.
В венде, кстати, самый убогий и проблемный юникод, не понимаю, откуда твои восторги. Компромиссное решение конечно было, спасибо хоть теперь utf8 приняли. Но после этого перекодированый utf16 в utf8 может отправлять её в бсод. Когда в одних местах огрызок utf16 и в других местах огрызок utf8, это весело тоже.
> ucs2но ведь там нет эмодзи !
увы. Поэтому в современной венде тоже помойка из где-то 16, где-то 8, а где-то и вообще восьмибитных кодировок для совместимости.
В винде все "любят" BOM с которым проблемы и грабли в каждом втором кейсе, а в собственно кодировки нормально не умеют
> ucs2 вполне себе fixed widthЭто только если выкинуть часть юникода.
В чистых сях, если предказать невозможно размер строки, используют 2 пути:
1. Используют аллокаторы.
2. Используют массив, превыщающий размеры вводимых данных, с дополнительной проверочной функцией выхода массива за пределы допустимого размера.>Понятное дело, накладные расходы в любом случае довольно серьёзные, по сравнению с обработкой однобайтных строк.
Понятие "накладные расходы" пришло из языков высокого уровня, где программисты отучились соображать, как в оперативной памяти располагаются данные. Чисто-сишник не знает таких слов, как "накладные расходы. Он просто видит задачу, и её делает. А Си плюс-плюс объектно-ориетрированный язык, в нём проблем с работой со строками вообще не существует.
> Чисто-сишник не знает таких слов, как "накладные расходы. Он просто видит задачу, и выходит за границы массива.Я поправил, не благодари)
Полная фигня. В сях есть 2 путя:
1) нуль-терминировнная строка, начиная с некоторого адреса
2) адрес на начало буфера со строкой и его длина в байтахРазмер данных нужно не предсказывать, а декларировать, иначе вы что-то не так делаете.
Можно ещё работать с потоком, но это просто наворот логики над вторым случаем.И, кстати, кодировка текста вообще иррелевантна для непосредственно передачи данных.
Чем бы дитя не решилось, лишь бы не брать c#
>>В чистых сях..В смысле "чистых"? без библиотек, в стиле велосипедостроения? Так оно нерационально.
>> А Си плюс-плюс... в нём проблем с работой со строками вообще не существует.
И там реализация работы со строками не в языке, а в библиотеках. Ладно, в том числе в стоковых. Кстати, если не "шашечки, а ехать", то и в Си проблемы нет.
И в заключение не могу не упомянуть, про "проблемы не существует", что в С++ для контроллеров встроенные С++ библиотки вполне могут быть и наикривейшими, с мешком неочевидных проблем, в том числе со строками, что всё равно вынуждает использовать сторонние компоненты.
Пффф... тоже мне проблема.
«От любой другой» — это от ASCII? Примерно всем.
При одном и том же наборе символов примерно ничем) А потом выясняется что ASCII в реале тебе не хватает и начинается цирк с теми, кто изначально использовал ASCII only подход
> C и C++ сразу отлетают в таком случае, поскольку вообще никак не умеют в юникодные строкиЗвездёж наглый. https://en.cppreference.com/w/cpp/language/string_literal u8 и https://en.cppreference.com/w/cpp/locale/codecvt_utf8 .
std::codecvt_utf8
(deprecated in C++17)
(removed in C++26)
Преобразование между кодировками юникода и wide character string != "вообще никак не умеют в юникодные строки". В юникод C++ умеет, как ты можешь убедиться открыв эту страничку в написанном на C++ Google Chromium. Там, где нужны преобразования между кодировками, рекомендуется использовать ICU (в Chromium используется именно эта библиотека). Остальным хватит https://en.cppreference.com/w/cpp/language/character_literalP.S. А теперь можешь попробовать рассказать, как твой любимый ЯП X поддерживает Юникод на уровне ICU.
Не то чтобы гуру в си юникоде, но даже без libicu всё работает нормально. Сами по себе строки и регексы в них - без проблем вообще.
wchar_t нет?
>wchar_t нет?Есть. А он имеет ввиде резиновый utf8.
Забудь про эту нестандартную гадость. Либо char32_t, либо UTF-8.
>C и C++ сразу отлетают в таком случае, поскольку вообще никак не умеют в юникодные строки.С++20 имеет юникодные типы.
C вообще "в строки" не умеет, если уж на то пошло, использовать функции стандартной C библиотеки для работы со строками - это надо быть наглухо отшибленным.
Но это не значит, что нельзя реализовать работу со строками, просто используя C как продвинутый ассемблер.
А почему GCC не участвовал в этом соревновании?
Тогда все эти зиги и нимы с моджо не получили бы первые места, естественно. Пришлось бы шаманить с разворачиванием циклов для луДшей синтетики
Получили бы, после того как ты написал поддержку Zig в gcc.
А есть какие-то предпосылки для этого?
Зиг вроде и от шланга хотел отказываться.
Конечно от llvm он никогда не уйдет (и не планировал).Они хотели отвязаться от llvm инфраструктуры, а мы их неправильно поняли (был огромный батхерт в GitHub).
Те генерировать напрямую llvm bc файлы. Всё что выше будет написано на Zig.
Отказываются от llvm, но оставляют слой совместимости, кому нужен. Перечитай гитхаб ещё раз
Не, гендерфлюид не напишет. Он только токсить в комментах горазд.
На самом деле Zig и раст - это разные штуки
По тестам Phoronix актуальный gcc в среднем чуть медленнее clang
https://www.phoronix.com/review/gcc-clang-eoy2023/8
Все, кто хоть немного интересовался вопросом, понимают, что это булшит. Но у шланга есть грязные менее универсальные к входным данным оптимизации (aka лапша из goto), которые во многих случаях дают хороший результат.Хотя гцц тоже не без проблем, но производительность сгенерированного им кода куда более предсказуемая и пго позволяет применять наиболее эффективные оптимизации.
Скажем так, код скомпилированный пр помощи GCC будет "качественным". ГНУ-тым, как "кровь из носу" тупая производительность, "во чтобы та ни стало", не нужна, они взрослые люди и переболели этой детской болезнью.
>> лапша из gotoЭто приведение кода на этапе препроцессинга к тождественному используя case switch и дальше по методике Jump-table-based switch в ассемблер известной аж с 1970-х и крайне актуальной в условиях Out of order execution процессоров.
Ноу хау тут не в приведении case-switch к jump-table, это делает и gcc, а в строгом доказательстве тождественности изначального кода и препроцессированного. Чтобы получить предсказуемую производительность, используй case-switch везде изначально, в чем проблема тут, я не понимаю.
Потому что надо новость внимательно читать. Там в заголовке обоих графиков черным по белому написано «arm64-darwin». А что это такое? Правильно, это новые макбуки. И GCC там еще даже рядом не пробегал (я нашел только экспериментальную ветку, еще не включенную в официальный релиз).
> Потому что надо новость внимательно читать. Там в заголовке обоих графиков черным по белому написано «arm64-darwin».Ну ты сказанул!
Ты бы еще предложил "разобраться в теме, а потом потом только комментировать"
>А почему GCC не участвовал в этом соревновании?Так Darwin-платформа же. Им там религия запрещала GCC >4.2.2 использовать. Вам же неинтересны будут тесты на этой версии GCC?
Минуттачку, а где имплементации на ассемблере? На гольном AMD64 и AMD64+AVX?
И как ты его запустишь на Apple M1 на котором тестит автор?
Через трансляцию... ну это будет не слишком показательно.
Для aarch64 нет ассемблера?
Есть. Но он предлагает же "AMD64 и AMD64+AVX"
А смысл заниматься подобным онанизмом, если и так понятно, что (по времени исполнения) компилируевые < байт-код < интерпретируемые?Нет, серьёзно.
> PyPy < CPythonТут всё правильно?
Байт-код с JIT бывает быстрее компилируемого
Не бывает. Выбает хреновый результат компиляции, которая аж хуже jit.
И бывают махинации с условиями тестов.
Какой величины разница между указанными группами. И какая разница внутри групп. Например, JS vs Ruby. Это любопытно.
Смысл в том, что как ты пайфон не оптимизируй, он все равно медленнее на порядок чем тот же msil или clang.Msil, к слову, давно в нативный аот умеет
Их бы сравнения да фронтоделам в уши.
Один дискорд поражает своей "эффективностью"
> Их бы сравнения да фронтоделам в уши.
> Один дискорд поражает своей "эффективностью"Я вам секрет страшный открою - фронтоделам и прочим вэбманкам фиолетово, они живут в парадигме - мы лабаем, а пользователю, если нужно запускать наш чудокод следует если что докупить дополнительных железок на апгрейд его "устаревшего гроба"!
Мне платят за код, а не за оптимизации под устаревшие платформы.
Если надо будет сделать так, чтобы оно запускалось на некрожелезе - то я готов это сделать за отдельный прайс.
А штоб сразу — и то, и то, не? Ну так какой ты программист, ремесленник
Обычный инженер.
Вот представь что тебе скажуст спроектить ДВС. Ты спросишь "а какое топливо, мощность и тд".
А потом к тебе придут с притензией "а чего на А76 не стартует".Или будешь делать станок, а потом от тебя захотят "а пусть работает в взрывоопасной атмосфере класса В-I, пусть работает под водой, пусть работает под управлением пьяного токаря". Думаю ты их тоже просто пошлешь... за деньгами на доп. разработку.
Предварительные оптимизации это, зачастую, выброшенное время.
Голимые отмазки.
Зря минусуют человека сверху. За оптимизацию кодеру может и прилететь, ибо он тратит часы (деньги) своего работодателя. Вот если у бизнеса появится задача "чтобы запускалось на ведре", то тогда оптимизация и начнётся. Но это происходит только в тех случаях когда замена железа стоит сильно дороже (см. терминалы, индустриальное оборудование, клиент на северном полюсе).
Ну, зря ли?.. Это философский вопрос. Бизнесу нужно, чтобы продукт покупался и был весь такой модный блестящий, динамичный. И молодые хипстеры это конечно же подхватывают и хавают. У кого деньги есть на новое железо. И есть добрая аудитория "маргиналов", которые либо не хотят новое железо, либо не могут себе позволить, либо его родные и близкие не могут его себе позовлить, но допекают его - Сделай, чтобы работало.И вот тут рядовой инженер конечно же не виноват, что делает, как хочет бизнес. С позиции бизнеса это правильно. Точнее бизнес никогда не знает как правильно. Бизнес всегда конкурирует с другим бизнесом, и безразлично, сколько на этом денег потратится.
С позиции же обывателя, той "жалкой горстки маргиналов" (коих большинство на самом деле, смотри внимательно на ковычки - значит сарказм) этот вопиющее безобразие творить то, что неоправданно вынуждает его обновлять весь парк железяк, чтобы не иметь проблем.
Коли мы зацепили бизнес, то ему безразлично на производительность того, или иного языка. Главное, чтобы были в доступе специалисты на том языке, на котором они уже нагородили "говна" и теперь это продают.
Так например, 1С проиграет все тесты на производительность. Но бизнес-приложения суровые на нём пишут, потому что удобно.
Всё-таки давайте на чистоту дискорд, хренкорд, яндекс дземн, и проиче пхп, гошные поделия - это так - фастфуд для доходяг и бездельников. Когда вам нужно писать приложение считающее ваши деньги, анализирующее, организующее ваших долбанов работников, которые бухгалтеры, только по табличке на кабинете, а на самом деле тыкатели в кнопку сделать "квартальный отчёт зае..ца!", тут вам не шибко принципиально производительность вашего приложения в попугаях... Именно поэтому пишут такие приложения на фреймворках, где не нужно изобретать велосипед заново, а используется уже написанное. Да оно может быть дырявым, может быть непроизводительным совершенно - ну х.. с ним. Главное, что разрабы на этом могут сверстать быстро то, что нужно сегодня, а завтра возможно оно уже будет не нужно.
И вот подбираясь к сути происходящего мы вернёмся к решению. Кто решает, какие технологии там будут, и на чём они будут работать? Бизнес, который платит, и который не понимает, или же инженер, который не платит, но понимает? Когда можно написать по старинке, так чтобы у всех работало и летало, но при этом несколько не модно, не в современных тенденциях, или можно написать новомодно, так, чтобы бизнес был в восторге, обезьянки с деньгами на новомодном железе восторгались, ну, и всё на этом... остальная аудитория отвалилась, но она не целевая сейчас.
А завтра бизнес пришёл, и захотел эту аудиторию "маргиналов" привлечь, и тебе "анженеру Суслову" нужно сейчас ему объяснить, что он всё заново должен разработать ещё и для этих маргиналов и заплатить ещё больше денег, потому что раньше он тебе не так задачу ставил, и ты не так написал.Резюмирую. Преждевременная оптимизация, господа, это не когда ты пишешь что-то под все платформы на все случаи жизни. Преждевременная оптимизация, это когда ты берёшь всё последнее новомодное, последних версий, вчера придуманные языки, и начинаешь на этом серьёзный проект. А можно было сделать просто, без вые...нов, так что на старом палме завелось бы.
Тебе единственному, кто дочитал до конца этот комментарий, огромная благодарность! Ты особенный! Т.к. перевелись уже читатели, способные освоить мысль больше чем в две строки по 70 знаков.
Каким это образом Zig, Mojo и Nim получают первые 3 места, если задача Судоку на них не решалась вообще (еще и Пересечение массивов у Zig и Mojo)? Логичней было б прибавить к полному времени выполнения на них бесконечность а не нули.
> Каким это образом Zig, Mojo и Nim получают первые 3 места, если задача Судоку на них не решалась вообщеи почему тогда не победил brainfuck, вот что непонятно!
Вот и очередное доказательство, что ужасный ржавый проигрывает божественному зигу
Проигрывает в matmul, выигрывает в nqueens.
Но остальные две задачи зиг вообще не решил... поэтому, по мнению авторов, он быстрее чем раст.
Тогда проще было вообще не решать задачи и стать лучшим языком!))
> Проигрывает в matmuПричем проигрывает лишь потому, что эти горе-сравнители используют в mathmul доступ к элементам Vec с проверкой границ. Я даже, блждад, не задумались: а почему же такая разница?
Такое впечатление, что код писал один и тот же ч̶а̶т̶ ̶Ж̶П̶Т̶ человек просто транслируя код с одного языка на другой "в лоб".
В том же свифте можно оптимизировать судоку и сделать её быстрее.А может цель была в "написать тесты языков без оптимизаций", чтобы посмотреть, как они работают со штатными настройками компилятора.
Да и на ноде отчасти можно
По крайней мере, ранее можно было выставить количество вызовов конкретных функций для начала следующего уровня оптимизацииТам, получается, первые несколько раз функция исполняется тупо интерпретатором, ещё после нескольких вызовов делаются какие-то оптимизации, и в конце-концов( после кучи вызовов ) - уже JITифицируется. Но при условии что все разы функция не менялась. Каждое изменение - обнуление счётчика. Для каждого следующего этапа надо сотни-тысячи вызовов.
По умолчанию выставленные уровни - это некий компромисс для разных устройств между относительно быстрой работой и начальным запуском
В производительности - JITифицированный жс-код был быстрее интерпретируемого в десятки-сотни раз
> горе-сравнители используют в mathmul доступ к элементам Vec с проверкой границ.Уже исправили.
https://github.com/attractivechaos/plb2/commit/643606048476e...
Ого, круто.
Очень оперативно испаравили, неужели создатель этих тестов сидит на пенькt и читает как его детище в комментариях обкладывают)?Теперь раст на втором месте!
Ну что фанаты zig/nim/mojo, сьели?
Вообще-то на третьем, и то до момента, когда Zig или Nim тоже оптимизировать начнут.
Разве этот код можно так же легко читать как Си?
Да, достаточно поработать недельку-две и становится привычно.
В СИ тоже есть макросы которые местами содом и гоморра, но люди как-то привыкают
Как писал классик, можно посидеть на горячей плите - тоже привыкнешь :)
Скорее нельзя такое сравнивать. Vec<Vec<f64>> - это тип данных (обощённо <T>), &mut - ссылка (прощай, указатели!), vec![0f64; n] - макрос создания пустого вектора из массива (можно и Vec::from([0f64, n])), iter() - превратить в итератор (привет питон, странно, что не as_iter),
Как часто вы умножаете матрицы в ваших программах?
Удивительно, но часто
Клиент калькулятор на сайт попросил, умножение матриц внутри, php
хм... мне казалось, что мат. либы должны быть уже или написаны, или быть в std.
Или это какой-то особый калькулятор?
Функция "Умножение матриц", не являяется математической библиотекой.
Понятно, что не калькулятор виндоуз
Методика в тз, "умножение матриц" похоже по сложности
Ну php, так php. Но если речь не о интерактивном калькуляторе, где на время можно забить, то нужно использовать библиотеки, использовать avx и подобные фичи процессоров.
Чаще всего в одностраничном коде на CPython. Прямо скажем, часто.
во-первых, ты трепло, во-вторых, вон из профессии, если ты это делаешь без numpy
Во-первых, я не чистый кодер в какой-либо софтверной компании. А, скажем так, работаю в области связанной с ЦОС. Во-вторых, а где ты увидел, что я написал, что без NumPy?
Python в десятки и сотни раз медленнее C/C++. Тесты это ясно показывают. Никакой numpy, который сам написан на С, радикально не поможет. Кроме того, нахрена язык, если с ним в обязательном порядке нужно использовать костыль в виде numpy, который может ограниченно помочь только в узком круге задач? Короче говоря, пиши обработку данных сразу на C++ и не теребонькай одно место. Если бы программисту на С++ сказали, что он придурок, если не использует что-то вроде numpy, - это было бы очень комично)
Ivan7
Я конечно прошу прощения, но довольно некорректно называть библиотеки к пайтону на Си костылём, ибо язык сам написан на Си, и все адекватные библиотеки так же. В связи с тем, что это прямая функция современного Python, быть двусторонним скотчем для кода написанного на производительных языках, даря возможность быстро и удобно собирать из уже готовых быстрых компонентов, как прототипы и скрипты, так и в некоторых случаях готовые программы, с малой степенью связности.P.S. Я сам пайтон не особо люблю, и редко к нему прибегаю, но мне показалось очень несправедливым принижение заслуг этого языка, и почитав предыдущие ваши комментарии, и посчитав вас вполне адекватным человек, решил таки поправить неточность вашего суждения
P.P.S. Не знаю зачем я так "налебезел" тут ветиеватыми, длинными предложениями с ванильными любезностями, видно спать давно пора.
Геймдев. Частенько. Правда сами функции не пишем: либо из движка, либо из библиотеки.
Наверное, Dwarf Fortress обновляет мир так.
лол, вот просто сижу на работе и каждый день судоку решаю
а по выходных ферзей переставляю)
> лол, вот просто сижу на работе и каждый день судоку решаю
> а по выходных ферзей переставляю)вот, а теперь тебя уволят и заменят роботом на хрусте (потому что зиг к сожалению не справился)
я так понимаю, что сравнение велось по суммарному времени для всех 4 тестов, а почему на 1 диаграмме для zig, nim, mojo и др. не все тесты отражены? или они мгновенно отработали?
Потому что для zig и mojo еще не написали sudoku и bedcov, а для nim - bedcov.
Зачем при этом делать такую диаграму - вопрос к автору.
мне показалось или новость исправили?
теперь первый си
Могли бы в ЧатЖПТ заказать. Возможно и не самый оптимальный вариант будет, но лучше чем ничего.
```rust
fn matmul(n: usize, a: Vec<Vec<f64>>, b: Vec<Vec<f64>>) -> Vec<Vec<f64>>
```какойто додик упоротый передает вектора в функцию по значению !!!
это даже не смешно.всратые клоуны
> какойто додик упоротый передает вектора в функцию по значению !!!
> это даже не смешно."appease clippy"
Передает. Но в Rust по умолчанию используется "перемещение", поэтому никаких промежуточных аллокаций и копирований содержимого происходить не будет.
Оказывается раст не защищает от полного непонимания происходящего и, как следствие, говнокода) удивительно... восхитительно...
Но, только для тех, кто не читал документацию.
> Но, только для тех, кто не читал документацию.А кто ее читает? Серьезно спрашиваю? Пример - автор оригинального комментария. Постоянно топит за раст, а доку получется не читал. Ой, смешные.
А я что говорил "автор оригинального комментария" хорошо разбирается в расте?
Тут половина пишущих в теме про него - ваще не бумбум.
Чего только витюшка стоит.
Помнят, любят))) Но обычно по факту сказать нечего.
размер Vec<T> 24 байта.
так что передача в функцию не такая уж и бесплатная.
через регистпы не пролезет.
ну и сам вызов мува. это как никак а вызов функции.
Как это вызов функции?😨
А как же Zero Cost Abstractions?
Полная чушь.> размер Vec<T> 24 байта.
> так что передача в функцию не такая уж и бесплатная.
> через регистпы не пролезет.24 = 3 * 8 = 3 РОНа из 14 свободно доступных на x86_64. А еще есть FPU регистры, которыми тоже можно пользоваться. И даже если там будет спилл, он будет разовым и никакого абсолютно влияния на результаты не окажет.
> ну и сам вызов мува. это как никак а вызов функции.
Никакого вызова там нет, это 3 mov.
сьто?, Vec представляет из себя указатель и ты переместил/скопировал указатель в функцию.ты бы лучше спросил зачем им аллокация в аллокации.
>Vec представляет из себя указательуказатель и счетчик занятого
>>Vec представляет из себя указатель
> указатель и счетчик занятогоПытаешься свернуть с темы? Ты обгадился прелюдно. Такое не забывается.
>Пытаешься свернуть с темы?Э, с какой темы?
Или ты тоже считаешь что передача указателя на массив и вектора в функцию равнозначны с точки зрения производительности?
задам вопрос не по теме, зачем какой либо функции возвращать значение return-ом, если назначение (dst) возвращаемого значения можно передать указателем в качестве аргумента фукнции?
Rust программисты не знают семантику перемещения в своём языке 😀🥳 Почему это неудивительно?А потом будут рассказывать нам про то какие классные и безопасные программы эти г...кодеры пишут.
Не удивлюсь что про перемещение сказал как раз не программист на Rust, а любопытствующий.
А кто сказал что Советские инжинеры в нем разбираются)
Вот ты тоже про Раст комментировал, даже доку не прочитав.
А так осуждаешь, как-будто сам никогда не умничал в темах, в которых не разбираешься)
Я как раз доку прочитал. И про borrow checker читал. И про move семантику.Но в целом, концептуально, я его знаю, с идейной точки зрения. Хотя бы чтобы набрасывать по фактам 😀
В lifetime я конечно плыву, но я них и не говорю.
>Rust программисты не знают семантику перемещения в своём языкеИ тем не менее в zig версии использовались слайсы.
Не пояснишь а чего ж так?
Поподробнее свою мысль разверни
Rust-погромисты вполне себе знают. Приведённый пример кода явно написан человеком, который не умеет писать на Rust. Vec внутри Vec для двумерного массива это, кринж, как сейчас модно говорить. И это будет так для любых языков без GC.Впрочем, уверен, с остальными языками в подборке такие же проблемы. И эти проблемы нерешаемые. Если пригласить на каждый язык по специалисту, то они все напишут вусмерть оптимизированный код под конкретный ЯП, вместо следования идиоматике ЯП.
Вывод какой? Все подобные исследования не позволяют судить о том, что одни языки лучше других в чём либо. Разве только на уровне "компилируемые ЯП обычно быстрее интерпретируемых". Но мы это и так знаем.
Тут не бодание фишками, а сравнение что будет если тратить мало времени и делать код чтобы работало выполняя синтетическую нагрузку.
То чего можно вдальнейшем достичь достигается гуру, которым это не лень.
Работать работу это вам не выдавать нагора все лучшее и сразу показывая видишь мускул этот конкретно чуть больше? Значит я лучше тебя во всем.
Все правда давно разочаровались в кодерах. Одного тытрупа хватает с жирновебом.
Работает? Канает? Вот и не гунди.
Исус прав.
Можно подумать код на Nim и Zig писали программисты с большим опытом на них.
> Вывод какой? Все подобные исследования не позволяют судить о том, что одни языки лучше других в чём либо.лол, кек, зачем судить о "языках", если компиляторы одного и того же "языка" - выдают разный результат. Лучше бы пытаться достичь оптимальности (идеальности) того или иного алгоритма (функции) в терминах конкретной архитектуры команд, и тогда компилятор любого формального "языка" генерировал бы один единственный необходимый и достаточный (ака оптимальный) код. Отсюда - зачем тогда нужны все эти формальные "языки" и бесполезное их "сравнения"?
пс: понятие "оптимальный" пока без строгого определения, надо думать.
А никто не запрещает байт кодовые языки сделать компиляемыми.
Вот жабокод внутренний это и есть жаба, а то что человек пишет отличается.
Языки нужны что оперировать иначе. Подключить биюлиотеку на Си к языку высокого уровня можно, натаскать нейросетку на оптимизацию тоже есть возможность.
Тут вопрос скорее в том почему до сих пор результат отличается кроме диначимеской типизации чтоб тормознее было.
То что вагоны циклов можно смягчить кешем жо определенной степени и так понятно, а потом идет работа с данными.
Нам показывают время, а в реальности надо смотреть сколько времени шла работа, а не ожиданте данных.
> Rust программисты не знают семантику перемещения в своём языке 😀🥳 Почему
> это неудивительно?
> А потом будут рассказывать нам про то какие классные и безопасные программы
> эти г...кодеры пишут.
> Не удивлюсь что про перемещение сказал как раз не программист на Rust,
> а любопытствующий.Этот "советский инженер" с пеной у рта постоянно топит за раст. Наконец-то показал свою сущность ыксперта :D
Vec -- это если что типа "умный указатель". Но даже это не важно: то, что ты называешь "передачей по значению", в расте на самом деле передача овнершипа, а вот будет ли она на уровне ассемблера реализована передачей указателя или копированием значения в регистры -- это забота компилятора.
>в расте на самом деле передача овнершипа, а вот будет ли она на уровне ассемблера реализована передачей указателя или копированием значения в регистры -- это забота компиляторакак я писал выше, Vec<T> занимает 24 байта для 64-битной системы, т.е. в регистры он не пролезет. передача будет через стек.
Плюс, это передача в функцию. если она не заинлайнится (а она не инлайнится, я проверил) то накладные расходы будут, и будут выше, чем передача в функцию указателей (ссылок)
> передача будет через стек.Если раст откажется проталкивать значение в функцию через регистры, то он положит в %rdi адрес этого значения. Куда он будет класть адрес на arm64 я не знаю, но спорить готов, что тоже в какой-нибудь регистр.
Т.е если взять брейнфак, где нет ни одной реализованной задачи - то он победит, тк время будет минимально?
(Эти гении "добавляют 0 времени" для нерешенной задачи /_-)
Максимально глупые условия теста.
Только общие тесты повлияли на рейтинг.
А еще они не добавляют единицу в делитель для нерешенной задачи, но для тебя это слишком сложная математика.
Где FPC? Где Fortran?
См результаты Си
Fortran бы себя мог показать очень хорошо на этих задачах.
> производительность PHP оказалась примерно в 4 раза выше, чем CPython.Воистину не тормозит!
PHP фреймворки эффективно устраняют это недоразумение.
> PHP фреймворки эффективно устраняют это недоразумение.В питон джит завезут скоро.
>> производительность PHP оказалась примерно в 4 раза выше, чем CPython.
> Воистину не тормозит!PHP не ЯП.
потому что как мининим реализацию на питоне писал какой-то кретин (вроде тебя), питона не знающий, убедиться в этом легко, посмотрев на реализацию matmul с использованием вложенных циклов в стиле си https://github.com/attractivechaos/plb2/blob/master/src/pyth...
Вообще очень классный вброс!
Сейчас набегут со словами:
"Вы написали на моем любимом языка какое-то овно! Сейчас я покажу вам как надо писать!!11"
Так что ждем третью версию тестов))
Кроме Rust. Они обосрались и не смогли написать самый простой мьютекс ещё в прошлой ветке.
Странно, вроде обосрался ты запутавшись в волотилях аж в 60 строках кода...
А они умные люди - решили не тратить свое время на новый год на какую-то фигню.
Я как раз не запутался, я его не использовал до этого. Это нормально для программистов, которые пишут больше чем 0 строк кода 😀😀😀Только в Rust все пишут сразу безопасно и идеально. Но теперь мы поняли как 😀😀😀
Лучшая программа - это ненаписанная программа. По версии Rust фанатиков.
И, кстати, если бы я и не сказал, никто бы и не узнал.
> Лучшая программа - это ненаписанная программа. По версии Rust фанатиков.Странно, тебе вроде кинули код мютексов на расте.
Код есть - есть. Какие вопросы?
Спор был. Я пишу СВОЙ код, он пишет СВОЙ код. Потом я доказываю корректность на листочке. А он с помощью безопасного Rust (borrow checker).Но до этой стадии мы так и не дошли. Остановились на 0 строк кода.
Или вы никогда сами ничего не пишете и всегда берёте "production ready, проверенный годами" код для экспериментов в одном файле? Те сами ничего написать не можете?
Использовать "в production" никто не предлагал. Зато разобраться как работают мьютексы было бы очень полезно, тем более для профессиональных программистов низкого уровня.
Угу, только "фанатики" раст тебе предоставили рабочую написанную программу "проверенную годами" (с).
А ты... ну, что смог, то смог. Есть куда расти.> И, кстати, если бы я и не сказал, никто бы и не узнал.
... думаешь ты.
Но даже если это так, то это как бы намекает, насколько всем непофиг на твои потуги)))
Так и я мог скинуть "проверенную годами". Вы то зачем тогда? Брать того программиста и дело с концом. А вас на пересылку JSON-чиков.Видимо настолько пелена глаза замылила, что не понимаете про что спор был.
Я разве где-то говорил что на Rust нельзя мьютекс написать???
Очень всратый бенчмарк, кроме того, что не на всех языках решены все задачи, так езё задач мало.
The Benchmarks Game гораздо информативней.
зиг тупо луДше:)
С одной стороны да, Benchmarks Game круче по разнообразию тестов.
А с другой стороны - было бы интересно сравнить языки "из коробки", без привязки к конкретной платформе или супер-оптимизациям.Например fannkuch-redux для раста
// Inspired by C++ #6 SIMD implementation by Andrei Simion
// Requires SSE3 and SSE4 instruction set
уже не так интерсно если у тебя старый проц или вообще арм'каили mandelbrot для С++
#if defined(__AVX512BW__)
typedef __m512d Vec;
const uint8_t k_bit_rev[] =
{ 0x00, 0x80, 0x40, 0xC0, 0x20, 0xA0, 0x60, 0xE0, 0x10, 0x90, 0x50, 0xD0, 0x30, 0xB0, 0x70, 0xF0, 0x08, 0x88, 0x48, 0xC8, 0x28, 0xA8, 0x68, 0xE8, 0x18, 0x98, 0x58, 0xD8, 0x38, 0xB8, 0x78, 0xF8,
Сомневаюсь, что с таким будут запариваться, кроме очень нагруженных участков программы
Вот только в llvm есть векторные инструкции.И они есть почти во всех цп современных.
И в С# внезапно есть.
А что там компилятор под конкретную платформу сгенерит то другой вопрос совершенно.
Если мы говорим о ЯП, то использовать конструкции ЯП для параллелизма - допустимо и даже необходимо.
А вот вставлять х86 ассемблер - нет.
Такое ощущение, что все компилируемые языки должны асимптотически сходиться к одним значения.
У автора V и rust немного обгоняют Си в nqueen.
А в matmul V проигрывает Си около 6 раз - 3.17 vs 0.54!
Предположу, что там что-то неправильно реализовали.
Не понятно каким компилятором собирался код V. В makefile есть только опция -prod. Лучше было бы явно задать в качестве компилятора gcc, и добавить опции fast_math и no_bounds_checking. Возможно это ничего не поменяет, но явное лучше неявного.
V в GCC уже завезли, когда?
в яблочной секте arm64-darwin нет компилятора gcc - он предан анафеме!
Можно посмотреть на реализацию matmul с использованием вложенных циклов в стиле C-like и понять, что человек не утруждал себя использовать возможности языка для ускорения работы кода. Сравнение такое напоминает сравнение писюна с огурцом и не более.
(https://github.com/attractivechaos/plb2/blob/master/src/pyth...)
Тогда остальные программы тоже нужно ускорить оптимизациями.
> Такое ощущение, что все компилируемые языки должны асимптотически сходиться к одним значения.
> У автора V и rust немного обгоняют Си в nqueen.
> А в matmul V проигрывает Си около 6 раз - 3.17 vs 0.54!
> Предположу, что там что-то неправильно реализовали.Там, где чуть-чуть обгоняет, не догоняет - это всё ерунда, т.к. результаты тестов в большей степени зависят от компилятора, опций компиляции, архитектуры, процессора, на котором производятся тесты и т.д.
Было бы здорово увидеть решение на asm для эталона.
Разница с Си будет доли %
Не смеши мои тапки, Си от голого ассемблера отстаёт в десятки раз. Проверено ещё во времена msdos и 8086 процессора.
Вспомнила бабка, как девкой была. Сейчас компилятор так наоптимизирует, что кожаный движок в жизни не догадался бы так написать. Да и тогда не было никаких десятков раз, конечно.
А тут ведь у нас про математику? Программирование 8087 на ассемблере — занятие для законченного мазохиста.
Оптимизации это хорошо (потому что компилятор в теории лучше знает об особенностях каждой архитектуры), но, в конечном счёте, без ручного ассемблера сегодня не обойтись.
Человек руками на mmx/sse так напишет, что никакому оптимизирующему компиллятору никогда не удастся. Много раз так делал.
Демосцена тому пример. Никакой си не сможет даже близко того, что делают парни на ассемблере. Причем ассемблер вопреки бытующему мнению на самом деле очень простой язык, может быть даже самый простой.
Трудоёмкость такого программирования такова, что в реальной жизни оно нигде не пригодится.
И на ассемблере пишутся в основном совсем уж маленьких демках. Тот же .kkrieger написан в основном на Си (и то авторы признавались, что ну его нафиг такой опыт).
Ассемблер — простой язык, да. Программировать только на нём сложно.
Человек, ты вещаешь про х86 или может армы, а вот для Эльбрусов заявлено что переписывание на ассемблере многие программы ускорит в разы.
То что Си для виртуальногь PDP-11 запилили это не значит что так работают современные или более навороченные процессорные архитектуры.
> для Эльбрусов заявлено что переписывание на ассемблере многие программы ускорит в разыА пруфец на заявление можно? Потому что это даже для x86 звучит фантастикой, а для VLIW! Ну или у них настолько убогий компилятор.
А сколько ты будешь этот идеальный код писать?
Особенно проект уровня, ну хотя бы текстовый редактор?
Думаю речь пойдет о годах, если не больше.Есть смысл писать на ассемблере только самый горячий код, котоый нужно оптимизировать по максимуму. Благо асм вставки есть почти в каждом системном языке.
А остальное - это просто бесполезная трата времени.
Эффективнее всего делать ассемблерные вставки для C++, компилировать код С++, дизассемблировать и изучать дизассемблированные листинги, чтобы потом писать более эффективный код на С++ и ассемблере. Нужно грамотно сочетать С++ с ассемблером, используя преимущества обоих. Писать программы на голом ассемблере смысла нет, и даже вредно, а вот сочетать С++ и ассемблер - это действительно интересно и полезно.
Дизассемблированный код C++ — это страшная вещь.
суть демосцены не в оптимизации производительности, а размере исполняемого файла
> Сейчас компилятор так наоптимизируетЧто хеллоуврот будет весить килобайты даже со всеми отключенными дебагами и стрипами. На асме я могу написать код, который весит десятки байт.
И только с хелловорлдом это и сработает. Килобайты — это оверхед для любой сишной программы. Но на всякий случай напомню, что страница памяти у нас — минимум 4 килобайта.
Но из-за того, сколько процессоров вышло с тех времён, даже что-то такое тривиальное как strlen() - это уже проблема, не говоря уже о чём-то большем.https://stackoverflow.com/questions/57650895/why-does-glibcs...
Помимо основных библиотечных функций кодеки на асме вручную ещё оптимизируют.
И тут ещё:
https://stackoverflow.com/questions/33480999/how-can-the-rep...
Помню как то писал на msp430, так там код на gcc генерировал значительно более компактный код, чем написанный на ассемблере. Вручную написанный код хороший, но настолько сильно с оптимизацией вручную не заморачиваются, кроме крайне критичных мест.
Если же взять типичный большой исходник на ассемблере, то большая его часть обычно написана шаблонами и макросами, а чудеса оптимизации только в самых важных местах.
А код на компилируемых языках оптимизируется везде. И на обычном большом проекте ассемблер совсем не выигрывает, и тем более с разгромом.
Примерно в тех временах и осталось
Компиляторы уже другие, процессоры тоже
Для конкретной однокристалки подход конечно лучший до сих пор
А вот для семейства хотя-бы интел разных поколений... Ну не подъёмно это руками, да и компилятор сделает лучше
Так-то при решении сколько-нибудь осмысленной объёмной задачи компилятор почти наверняка справится лучше... Т.е. возможны конечно варианты - но in general на x64 как-то так.
Хватит повторять эти сказки. Не позорься.
А чё так мало желающих лабать на Асме? Неохота парится за 1% прироста производительности.
Из своей практики по обработке изображений, там не 1%, а иногда в лоб переписываешь на векторные инструкции - в 30 раз быстрее, неделю походишь, подумаешь - переписываешь и ещё в 2 раза быстрее, как-то так.
> Из своей практики по обработке изображений, там не 1%, а иногда в лоб переписываешь на векторные инструкции - в 30 раз быстрее, неделю походишь, подумаешь - переписываешь и ещё в 2 раза быстрее, как-то так.Полностью согласен. Если речь идет о либе ли ядре приложения.
Но если речь идет о например вьювере или редакторе изображений, то кол-во такого кода будет невелико относительно UI, бизнеса или обвязки.И есть смысл ускорить именно такой код, а не писать целиком окошки и кнопочки на ASMе.
ну давай, покажи, что ты там напрактиковал, где код?
> Из своей практики по обработке изображений, там не 1%, а иногда в
> лоб переписываешь на векторные инструкции - в 30 раз быстрее, неделю
> походишь, подумаешь - переписываешь и ещё в 2 раза быстрее, как-то
> так.Не-не, не "критический участок специфического кода" на 300 сишных строк - а аналог хотя бы 5-10k чего-нибудь более высокоуровневого.
> Хватит повторять эти сказки. Не позорься.Действительно. В жизни дофига примеров вида "переписал 10000 строк плюсового кода на асм, получил хN к производительности" и вас не затруднит привести хотя бы два, да?
Посмотрел по ссылкам подробности алгоритмов. Составителям тестов следовало бы привлечь специалистов, которые читали что-либо еще, кроме Википедии. Используется неэффективное хранение матриц. На С можно намного увеличить скорость их перемножения.
Из всех перечисленных можно вызывать функции на С. В результате все языки будут одинаково быстрыми.
1) В С++ (Clang, GCC, ICC) можно делать ассемблерные вставки (не вызов ассемблерной функции, хотя это тоже можно). 2) В С++ можно сделать функцию встраиваемой и полностью избежать затрат на её вызов, что для небольших и часто вызываемых функций очень актуально. 3) Нет большого смысла писать на другом языке, а потом оптимизировать производительность, переписывая часть функций на С/С++. Проще сразу писать на С++. Если только вы не поддерживаете какой-то уже готовый проект, изначально написанный на другом языке.
Все это почти не имеет значения, если речь не про системное программирование с критическими участками, где требуется производительность именно процессора. В большинстве случаев все упирается в I/O, будь то память, шина или сеть.
Думаю, они I/O, как Вы выразились, все-таки не учитывали. :)
Тогда еще хуже будет. "200 метров джава-скрипта грузит текста 300 байт"
Тысячи задач, где всё упирается в скорость процессора.
процессор не обязателен, так и запишем
Нет, иначе разрабы умных чатовГПТ не стали бы ныть от тормозов в Python и создавать Mojo.
В новости надо бы добавить уточнение, что результаты получены на> Timing on Apple M1 Macbook Pro
А теперь посмотрим в рейтинг зарплат, за что готовы платить, и увидим, что никаких быстрых языков там не нужно.
Быстрые языки много где нужны. Но там язык только инструмент. Нужна математика, алгоритмы, знание предметной области.Остальным хватит и однопоточного JS за глаза
Или тайпскрипт (͡° ͜ʖ ͡°)
Или его. Шикарный язык, по сравнению с чистым JS.
> Быстрые языки много где нужны. Но там язык только инструмент. Нужна математика,
> алгоритмы, знание предметной области.
> Остальным хватит и однопоточного JS за глазаОх люблю кекспертво в области однопоточного джаваскрипта, знания поражают. Впринципе словосочетание "однопоточный джаваскрипт" уже отражает твоё знание предмета обсуждений.
Тоже увидел данный коммент и аж бомбануло сперва. Но в итоге решил не отвечать, т.к. человек вообще не в курсе что из себя представляет js.
Да, да, я не в курсе.ECMA-262, 14th edition, June 2023
ECMAScript® 2023 Language Specification9.7 Agents
An agent comprises a set of ECMAScript execution contexts, an execution context stack, a running execution context, an Agent Record, and an executing thread. Except for the executing thread, the constituents of an agent belong exclusively to that agent.An agent's executing thread executes a job on the agent's execution contexts independently of other agents, except that an executing thread may be used as the executing thread by multiple agents, provided none of the agents sharing the thread have an Agent Record whose [[CanBlock]] field is true.
While an agent's executing thread executes jobs, the agent is the surrounding agent for the code in those jobs. The code uses the surrounding agent to access the specification-level execution objects held within the agent: the running execution context, the execution context stack, and the Agent Record's fields.
9.4 Execution Contexts
An execution context is a specification device that is used to track the runtime evaluation of code by an ECMAScript implementation. At any point in time, there is at most one execution context per agent that is actually executing code. This is known as the agent's running execution context. All references to the running execution context in this specification denote the running execution context of the surrounding agent.Читать умеем или еще и JS нубам нужно на пальцах обьяснять что javascript однопоточный?
Они путают с web workers или вот с этим https://nodejs.org/dist/latest-v20.x/docs/api/worker_threads..., которые ни разу не треды.
> Тоже увидел данный коммент и аж бомбануло сперва. Но в итоге решил
> не отвечать, т.к. человек вообще не в курсе что из себя
> представляет js.Ты бы показал пример потоков в js лучше.
> Быстрые языки много где нужны. Но там язык только инструмент. Нужна математика,
> алгоритмы, знание предметной области.
> Остальным хватит и однопоточного JS за глазаТам где нужны быстрые языки, как правило не платят денег, я сомневаюсь что разрабы какой-то йоба электроники заплатят мне 12 тысяч долларов, а вот бизнес гои, отвалят мне 12 за джаваскриптик, 15 девопсу несисадминовичу, ещё чирик менеджеру.
А потом ты проснулся? Зарплаты посмотри на JavaScript, на Node.js. Заплатят тебе 12к$. Ну ты и мечтатель.Покажи эти вакансии.
За JavaScript платят значительно меньше чем за C++. И даже за не 10к платят единицам.
> А потом ты проснулся? Зарплаты посмотри на JavaScript, на Node.js. Заплатят тебе
> 12к$. Ну ты и мечтатель.
> Покажи эти вакансии.
> За JavaScript платят значительно меньше чем за C++. И даже за не
> 10к платят единицам.Раскажи мне как за С++ платят больше, средняя зарплата мидла на плюсах 3500, средняя мидла на джаваскрипте 4700.
Ссылки на вакансии
> средняя зарплатаСсылки на что? На средние вакансии?
> средняя зарплата мидла на плюсах 3500, средняя мидла на джаваскрипте 4700Справедливости ради, платят не столько за знания алгоритмов и синтаксиса js (выучить его как раз не проблема совсем), платят скорее за умение работать со стеком всей технологии. В плюсах часто даже гит знать не обязательно в 90% случаев вся работа сводится к алгоритмам и синтаксису.
> В плюсах часто даже гит знать не обязательно в 90% случаев вся работа сводится к алгоритмам и синтаксису.Покажи мне такие вакансии.
Ну ещё две основные профессии связаные с плюсами, это геймдев, и ембеддед/linux kernel developer. В геймдеве работать, это себя не уважать, там платят мало, требуют много, работа сложная, ещё и хотят чтобы ты работал 48 часов в сутки. А в ембедед особо не плотят ибо это либо стартап в котором денег нет, либо завод/оборонка где деньги есть, но тебе их не дадут.
> Ну ещё две основные профессии связаные с плюсами, это геймдев, и ембеддед/linux kernel developer.
> В геймдеве работать, это себя не уважать, там платят мало, требуют много, работа сложная, ещё и хотят чтобы ты работал 48 часов в сутки.И то не везде нужны полюсы, в той же Unity скрипты пишутся на C#
> А в ембедед особо не плотят ибо это либо стартап в котором денег нет, либо завод/оборонка где деньги есть, но тебе их не дадут.
Теоретически есть всякие автомотив, дроны и робототехника - там деньги хорошие, но попасть туда весьма сложно.
Ну автомотив, дроны и робототехника, это и есть те самые заводы и оборонка. Туда же ещё автоматизацию производства, и информационно-измерительные системы.
>> средняя зарплата мидла на плюсах 3500, средняя мидла на джаваскрипте 4700
> Справедливости ради, платят не столько за знания алгоритмов и синтаксиса js (выучить
> его как раз не проблема совсем), платят скорее за умение работать
> со стеком всей технологии. В плюсах часто даже гит знать не
> обязательно в 90% случаев вся работа сводится к алгоритмам и синтаксису.Кстати да, в плюсах не нужен ни гит, пакетного менеджера у них тоже нет, либы ручками подключаешь. И это блд странно, при всей популярности языка, его никто не хочет автоматизировать. Для того же питона или джавы есть всё что угодно и в огромном количестве, разной степени тухлости и актуальнсти, а на плюсы всем насрать, кроме комитета по стандартизации.
Уверен, что нету? Conan, vspkg: да, пошли мы на фиг. То, что их никто не привинчивает к стандарту - это другое. Может даже лучше, что не стандартизуют.
> За JavaScript платят значительно меньше чем за C++.Но и вакансий C++ несравнимо меньше. Плюс часто требуют диплом технического ВУЗа. У меня вообще нет диплома, но я зарабатываю почти 65к евро в год на нелюбимом всеми тут js.
Согласен и с этим не спорю.Я не говорил что он не любимый. Я сам на нём писал и буду писать.
Современный программист - это как работник на заводе, по-сути птушник, 1 год курсов и в бой.В принципе по комментариям на opennet уровень всех этих программистов мы видим.
Джей Сассман с тобой согласен https://habr.com/en/articles/282986/> Сейчас инженеры обычно пишут код для сложного аппаратного обеспечения, которое они не до конца понимают (причем часто это происходит по причине коммерческой тайны, а не в силу лени или недостатка времени — взять ту же Apple и ее технологии).
> Согласно Сассману, сегодня его студенты большую часть своего времени тратят на чтение мануалов к этим библиотекам, чтобы разобраться в том, как связать их вместе с простой целью — чтобы всё заработало и сделало то, что им нужно.
> Джей Сассман с тобой согласен https://habr.com/en/articles/282986/
>> Сейчас инженеры обычно пишут код для сложного аппаратного обеспечения, которое они не до конца понимают (причем часто это происходит по причине коммерческой тайны, а не в силу лени или недостатка времени — взять ту же Apple и ее технологии).
>> Согласно Сассману, сегодня его студенты большую часть своего времени тратят на чтение мануалов к этим библиотекам, чтобы разобраться в том, как связать их вместе с простой целью — чтобы всё заработало и сделало то, что им нужно.Чем это отличается от того что делали технари 100 лет назад, когда изобретали разные костыли, чтобы передать энергию пара в лампочку?
>> Джей Сассман с тобой согласен https://habr.com/en/articles/282986/
>>> Сейчас инженеры обычно пишут код для сложного аппаратного обеспечения, которое они не до конца понимают (причем часто это происходит по причине коммерческой тайны, а не в силу лени или недостатка времени — взять ту же Apple и ее технологии).
>>> Согласно Сассману, сегодня его студенты большую часть своего времени тратят на чтение мануалов к этим библиотекам, чтобы разобраться в том, как связать их вместе с простой целью — чтобы всё заработало и сделало то, что им нужно.
> Чем это отличается от того что делали технари 100 лет назад, когда
> изобретали разные костыли, чтобы передать энергию пара в лампочку?Ты прочитал статью полностью? Похоже что нет. Отличается тем, что тогда систему собирали с нуля, а сейчас ты купишь на маркетплейсе систему для передачи энергии пара в лампочку и будешь собирать конструктор. И когда все заработает, то скажешь что собрал паровой электродвигатель, но объяснит принцип его работы не сможешь как и воссоздать с нуля.
Скорее на js/python много вакансий для начинающих, с соответсвующей оплатой. А на c/c++ требуются готовые профессионалы, и тоже с соотвествующей оплатой.
Итого: вакансии и размеры зарплаты в них не совсем адекватно отображают востребованность.
> Скорее на js/python много вакансий для начинающих, с соответсвующей оплатой. А на
> c/c++ требуются готовые профессионалы, и тоже с соотвествующей оплатой.
> Итого: вакансии и размеры зарплаты в них не совсем адекватно отображают востребованность.Кстати наоборот, на С++ так как дефицит кадров, с большей вероятностью возьмут полного нуля, на зарплату там в 400 долларов, и он будет себе работать. Главное чтобы он читать умел, и с первого раза в рот ложкой попадал. Всё как на хайпе программирования в 2016.
> Кстати наоборот, на С++ так как дефицит кадров, с большей вероятностью возьмут
> полного нуля, на зарплату там в 400 долларов, и он будет
> себе работать. Главное чтобыДа, тут приходится угадывать и перспективнось неопытного программиста, и его личный интерес к подобной работе.
У нас обычно ростят студентов/выпускников, а чтоб попался хороший специалист в небольших городах - это редкость.
Если не нужно результатов, то да.
> никаких быстрых языков там не нужноты уверен? подсказать, где еще больше платят, за один час и в продакшен, можно дальше новый фреймворк изучать.
> А теперь посмотрим в рейтинг зарплат, за что готовы платить, и увидим, что никаких быстрых языков там не нужно.Так все деньги в вэбе, а в вэб узкое горлышко это сеть, поэтому там действительно нативный быстрой код не нужен, а вот читаемость кода нужна и даже очень.
Раст на уровне D и Явы, даже не в первой пятерке, чего собственно и следовало ожидать.
> чего собственно и следовало ожидать26 звёзд за 12 лет намекают что тесты мягко говоря необъективные
Уже 77. Малое число звезд ничего не говорит об объективности, скорее о популярности.
Если правильно отсортировать график, то раст будет на 4 месте по производительности.
А если еще чуть-чуть здесь подкрутить и вон там смухлевать, вообще хорошо станет.
Раст и не про скорость, раст про безопастность и про удобную экосистему отвечающую современным стандартам разработки.
Не согласен.Можно глянуть Rust versus C++ на тестах benchmarksgame, они идут практически вровень (где-то один лучше, где-то другой, но разница в процентах)
benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-gpp.html
Но там код заоптимизирован по самые помидоры, где-то тесты только под sse4, где-то используют AVX-512.Но можно вспомнить еще старую статью (очень старую из 2019 года) opennet.ru/opennews/art.shtml?num=51475
где один сетевой драйвер писали на разных языках.Так что при скорости сравнимой с с++, ты получаешь еще дополнительные проверки компилятора и экосистему в подарок.
Как и предполагалось, после исправление косячного кода на раст, он занял заслуженное второе место.
github.com/attractivechaos/plb2/commit/643606048476eca58ac78032386b763ca146b8ac
Заметьте, в исправлении используют итераторы, которые делают (в идеале) ОДИН раз bounds check. А не индексы, на которые жалуются многие комментаторы тут, что, мол, медленный какой. Тупо переписали на идиоматичный Раст.
К сожалению, этот бенч не может показать что язык лучше других в производительности исполнения. Только то, что он не хуже других, которые рядом стоят. Да и то, этому бенчу надо уделять время .. не все это делают.
Реальную производительность многих ЯПов мы не узнаем просто посмотрев этот сайт :(
Если с другой стороны смотреть, это было исправление косяков компилятора, пришлось делать работу за него."The Clang compiler can apply this optimization ... Some C/C++ programmers say compilers often optimize better than human, but this might not be the case in other languages" - https://github.com/attractivechaos/plb2#optimizing-inner-loops
Это не было исправление косяка компилятора.
Раст делает проверки при обращении к элементу вектора, чтобы не выйти за границы. Но это что-то стоит.
При использовании итератора проверка делается только один раз.
Но это сделано ценой читаемости. Был наивно-простой код, как и в C. А стало:
...
for (cij, &bkj) in ci.iter_mut().zip(bk)
...
Даже если наивный код обложить ручными проверками, получится... читаемее, чем с такой оптимизацией.
> Был наивно-простой код, как и в C... но раст это как бы не си и слава богу)))
Так нечитаемо потому что язык не знаешь.
Это не проблема, думаю за пару недель практики такой код тоже будет легко читаемый.
То же самое и С++ касается, так что лучше выбрать его.
Читаемость имхо не относится к знанию/не знанию языка. Читаемый язык - это такой язык, листинг которого достаточно легко прочитать, не гугля документацию по языку. В этом плане си всё же более легко читаемый (но уступает ряду других).
Ой вей, виноват, не прочитал новость. Это не benchmarks-game. Там всего 4 задачи, не все решены!!, а результаты уже вывесили.Например, для раста не написан bedcov тест. Это провал.
Победили JavaScript, Lua, Julia, Python. Только на этих языках были решены все задачи.
Из них Julia вторая по производительности после clang, где все задаи решены.
Начал учить Flutter и Dart. Язык показался на удивление приятным!А ещё такой производительный. Есть куда расти
> Начал учить Flutter и Dart. Язык показался на удивление приятным!
> А ещё такой производительный. Есть куда растиФлаттер да, он приятный он как Vue.js
vanilla js ещё приятнее
Были у нас такие адепты. Не осилили проект миллионник. Новый менеджер недавно гордился что смогли переписать 92% на TS. А JS код никто нормально не может поддерживать: перепишут если и там что-то придется править.
Может просто нанять техлида и менеджера проекта? Ну ли найти сильную команду, умеющую писать код? Миллион строчек кода на js - это средний проект. Просто 10и же большой, но наличие хорошей документации и полное покрытие тестами для js обязательно, в отличии от ts.
> Миллион строчек кода на js - это средний проект.Если код библиотек не считать, то это много. Вот, например, статистика по коду nginx
-----------------------------------------------------------------------------------
Language files blank comment code
-----------------------------------------------------------------------------------
C 256 54008 6144 153701
C/C++ Header 134 4810 1077 10040А вот статистика по CPython
---------------------------------------------------------------------------------------
Language files blank comment code
---------------------------------------------------------------------------------------
Python 1977 127423 150784 587582
C 326 55467 52447 363671
C/C++ Header 424 17124 10429 184057И заметь, что в код в таких проектах обычно слабо связанный.
> и полное покрытие тестами для js обязательно, в отличии от ts.
Тесты и типизацию некорректно сравнивать. Точно также как сказать "если у тебя есть типы, то тебе не нужны тесты". Понятное дело, что с типами можно не писать тесты на принятие типов, которые нарушают контракт, но в здравом уме никто такие тесты не пишет и в языках с динамической типизацией без типов.
Тесты - это тот же код, по идее чем меньше и проще - тем луче.
Ну вот еще стата для конкретно js исходников gitlab по пути app/assets/javascripts/-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
Vuejs Component 1991 9946 4212 233516
JavaScript 2253 16933 10952 106449
> Миллион строчек кода на jsЭто либо твои фантазии, либо откровенный гoвнoкод. Даже сотня строк для js — это офигеть как много. Если не согласен, докажи обратное, что ты там нагoвнoкoдил на целый миллён строк.
>> Миллион строчек кода на js
> Это либо твои фантазии, либо откровенный гoвнoкод. Даже сотня строк для js
> — это офигеть как много. Если не согласен, докажи обратное, что
> ты там нагoвнoкoдил на целый миллён строк.Он node_modules просто посчитал. А сам он выводит "привет мир".
> Он node_modules просто посчитал. А сам он выводит "привет мир".Вот вот. Если вы добавили код сторонней библиотекив проект, значит это часть кода проекта, а за код добавленной библиотеки ответственность теперь на Вас. Хотя зачем основы объяснять?
>> Он node_modules просто посчитал. А сам он выводит "привет мир".
> Вот вот. Если вы добавили код сторонней библиотекив проект, значит это часть
> кода проекта, а за код добавленной библиотеки ответственность теперь на Вас.Да никто даже код не читает, который добавляет. Что уж говорить если по умолчанию npm добавляет номер зависимости через ^, что предполагает, что патч и минор версии будут автоматом подтягиваться в свежей установке.
Очередной наброс на вентилятор а не тесты!
Давай свои тесты лучше.
В тесте явно не хватает 1С
И HTML
Не осилили его паршивое IDE.
Да Васиков всяких разных
Как js:bun оказался на 5 месте, хотя по цифрам должен был быть на 11м?
"А как тебе такая магия графиков, ИмяХ?" (с)
Просто там график по nqueen + matmul.1. учитываются всего 2 задачи из 4х
2. если у тебя одна супер быстрая, а вторая супер медленная (как случилось с V), то ты можешь обогнать язык, где обе задачи среднячкиВ общем тест нуждается в фиксах и улучшении, зато отлично генерирует срач
Сверху подписано, как отсортировано, но и без этого заметно, что 3-4 тесты не на всех языках сделаны.
Bun очень легкая и быстрая штука, нет тут ничего удивительного, читай внимательнее условия.
Мне вот интересны два момента.
1. В подавляющем большинстве языков для matmul нынче используется OpenBLAS или что-то подобное, откуда там разница в разы? Свой велосипед делали?
2. По-хорошему, раз уж это тест производительности, надо тестировать на предварительно откомпилированых программах, если таковая возможность имеется. Тогда это будут равные условия.
Да, там для каждого языка написали свой велосипед. И эти велосипеды явно разной степени кривизны.
github.com/attractivechaos/plb2/tree/master/srcПосле это пункта, второй уже не имеет никакого значения))
Мля, они про векторизацию что-нибудь слышали? Это задача из разряда кто быстрее заплывёт на дерево.
ну...
во-первых, это может для них сложно)
во-вторых, оно может по разному вести себя на разных платформах (напомню что сабж делался на яблочном М1, который арм)а в третих, ИМХО, думаю даже такой тест может быть полезным.
В смысле "а насколько хорошо работают оптимизации компилятора, если мне оптимизировать лениво".
> а в третих, ИМХО, думаю даже такой тест может быть полезным.
> В смысле "а насколько хорошо работают оптимизации компилятора, если мне оптимизировать
> лениво".В итоге имеем сравнение компиляции, интерпретации и JIT оптимизации :)
Тогда это превратится в соревнование не языков, а библиотек.
да кому интересна эта херабора для проприетарной arm64-darwin??? кто-то будет оптимизировать особенно из крупных вендоров? вы себе представляете чтобы например Оракл или Майкрософт инвестировала в работу своих платформ на маке??????
Пробовали, не осилили: MS например закрыл VS для мака, а вместо переписывания офиса придумали как сделать так чтобы часть работала нативно, а часть - x86 бинарники через эмуляцию (оказалось проще чем переписать).
Неосиляция MS — это проблемы MS. Остальные вполне осиливают, и Oracle в том числе.
Не болтайте ерундой! (С) :DВот софт который Ларри хочет подо всё: https://www.oracle.com/database/technologies/instant-client/...
Есть ли там голубяшка? Есть конечно, но вот ведь нюанс: Instant Client for macOS (Intel x86)
А где же яблло-M1\M2 и иже с ними? А нетути. И не будет походу.От М$ вообще жёсткие анонсы были, deprecated, no longer supported, EoL-ed и прочая, то что по русски звучит коротко: НАХ!
Закапывают мак. У нас заменили (почти) все на Lenovo + W11. Немного Ынтелёвых осталось у дизайнеров и всё. ARM-овые вообще _все_ изЪяли. Хотя при этом - iPhone и iPad - пожалуйста...
Правда не колятся чего вдруг так резко ... типо приказ сверху и всё. Мутно, и не понятно. Лет 10 последних голубяшки прям насильно выдавали и вдруг ВНЕЗАПНА!(С)
> Немного Ынтелёвых осталось у дизайнеров и всё.Дизайнеров надо пересадить на линукс и дать им гимп.
Вы настолько ненавидите дизайнеров?
> Вы настолько ненавидите дизайнеров?Я думаю что это отличный вариант улучшить гимп. Также дизайнеры слишком уж стали выделяться: подавай им обязательно мак, хороший дизайнер как и погромист должен уметь решать задачу в разных условиях.
В отличие от программиста, дизайнеры редко выходят за свою предметную область. По крайней мере в контексте: "Как сделать N на на вот этом". При появлении таких задач, они либо не будут делать N вообще, либо попросят заменить вот это. Так что развитие дизайнерских инструментов под какую-то новую платформу всё же должно исходить от программистов.
в этом исследовании интересен только Swift, который родной для платформый, а он пролетает по тестам, что ожидаем, потому что софт у яблока как и гнуса - дэрмо
Зато реклама хорошая. Помните, какой хайп был вокруг Swift?
А на _чём_ там писать если не на Swift?
Там тебе не форточка \ линукс - с выбором там не забалуешь :)
У меня вся команда со старой работы ушла с Objective-C на него. Кроме одного настырного китайца :)
Вот она вся суть яблочников - выбора тебе не дают, радуйся тому что есть.
> в этом исследовании интересен только Swift, который родной для платформый, а он
> пролетает по тестам, что ожидаем, потому что софт у яблока как
> и гнуса - дэрмоИ почему же софт эпла дерьмо? Откровенно лагающего софта там нет. Плюс айфоны всегда имеют меньше оперативной памяти чем сопоставимые андроид телефоны, и один и тот же софт, на айфоне с 4 гигами оперативной памяти не тормозит, а на андроиде с 4 гигами тормозит. Как так? Ах да потому что меркам гугла, телефон в котором меньше 64 гигов оперативной памяти обязан лагать, так прям в гайдлайнах написано.
>> в этом исследовании интересен только Swift, который родной для платформый, а он
>> пролетает по тестам, что ожидаем, потому что софт у яблока как
>> и гнуса - дэрмо
> И почему же софт эпла дерьмо? Откровенно лагающего софта там нет. Плюс
> айфоны всегда имеют меньше оперативной памяти чем сопоставимые андроид телефоны, и
> один и тот же софт, на айфоне с 4 гигами оперативной
> памяти не тормозит, а на андроиде с 4 гигами тормозит. Как
> так? Ах да потому что меркам гугла, телефон в котором меньше
> 64 гигов оперативной памяти обязан лагать, так прям в гайдлайнах написано.действительно качество софта определяется какими-то мифическими лагами, которых я и на ведре не видел, если это не уепшны
>> в этом исследовании интересен только Swift, который родной для платформый, а он
>> пролетает по тестам, что ожидаем, потому что софт у яблока как
>> и гнуса - дэрмо
> И почему же софт эпла дерьмо? Откровенно лагающего софта там нет. Плюс
> айфоны всегда имеют меньше оперативной памяти чем сопоставимые андроид телефоны, и
> один и тот же софт, на айфоне с 4 гигами оперативной
> памяти не тормозит, а на андроиде с 4 гигами тормозит. Как
> так? Ах да потому что меркам гугла, телефон в котором меньше
> 64 гигов оперативной памяти обязан лагать, так прям в гайдлайнах написано.действительно качество софта определяется какими-то мифическими лагами, которых я и на ведре не видел, если это не уепшный китаец за 100 баксов
я говорю про платформу, ось, а также, средства разработки, которые ты я так понимаю ни разу не видел изнутри, эпловое это самое говенное, что я видел по качеству реализации, если сравнивать разработку для Windows / Linux / Mac / iOS / Android
ведро тоже не сахар, но сильно лучше чем эпловый треш
У эпла всё реализовано как настоящего комерческого юникса. Те это то к чему стремятся линукс-макаkи.
> У эпла всё реализовано как настоящего комерческого юникса. Те это то к
> чему стремятся линукс-макаkи.ты главное не переставай верить в это )))
P.S.
в тот день когда линукс станет похож на это ковнище от эппла можно смело будет уйти в запой с горя
но этого к счастью не произойдет
Линукс ещё хуже. Он собрал в себе все самые плохие практики, которые только можно представить.
> Линукс ещё хуже. Он собрал в себе все самые плохие практики, которые
> только можно представить.у тебя бурная фантазия, клинически бурная
В цикле просто создаём временный массив и удивляемся что GC где-то заработал... https://github.com/attractivechaos/plb2/blob/master/src/csha... - это то что сразу видно. В общем код не прошёл ревью...
Это просто какой-то позор /_- (с)
Неужели они это пилили с 2011 года.
Посмотрите, наконец, нормальный код*.*На указанном ресурсе его нет.
Все интенсивные вычисления делать на С. Таким образом, остальные языки выполняют только роль интерфейса, и смысл рейтинга теряется.
Скорее си выполняет роль интерфейса FFI для всех остальных языков.
Кто-то из зарегистрированных может попросить автора исправить новость?
После изменений расстановка сил немного поменяласьgithub.com/attractivechaos/plb2
github.com/attractivechaos/plb2/blob/master/analysis/rst-m1.png
Там расстановки сил меняется каждые пять минут. Так что лучше подождать.
Зачем исправлять новость? Результаты чем-то не устраивают?
arm64-darwin?
Давай, до свидания.
В общем, как и предполагалось, часть тестов были неоптимальны.
После минорных правок в кодах, раст занял заслуженное второе место, с минимальными расхождением с Си.
Третье место занял D, что в общем не удивительно.
А почетное четвертое - Zig.С 2.70 0.54 1.54 0.84
Rust 2.68 0.56 1.65 ____
D 2.68 0.57 1.60 ____
Zig 2.74 0.56 ____ ____Напомню, что подсчет ведется по сумме двух первых столбцов, т.к. для некоторых языков часть тестов просто не реализовано.
При этом явно есть еще место под оптимизации, напр. зиг отстает в первом тесте и кажется, что его можно вполне довести до уровня остальных. Тоже самое можно сказать про раст в третьем тесте.
UPD: пока писал это сообщение в репу прилетел фикс для V (eb9ee89) и теперь он обходит все языки, даже Си.
V 2.57 0.56
Поэтому можно запастись попкорном и смотреть как компилируемые языки приближаются к некому "идеальному времени выполнения". Как собственно и предполагалось в 1.34.
Там небось на сишке код без минимальных проверок.
А типа в продакшене кто-то будет беспокоиться о проверках?
СИ это же про скорость, а не про корректность работы.
Подумаешь будет CVE, ну так потомки ее найдут, лет через 10.
На самом деле даже не про скорость.
Разве что про скорость отрыгивания кода.
Чем в написании драйверов и прочей in-kernel чешуи тебя не устроил "С" ?! И чем ты его там заменишь? ( скажи ещё - растом :-) )
А понял - ты его вместо 1С решил применить и тебя за это били ногами ... ну дык эта ... поделом! :-DC is high-level assembly language (C) ТЧК!
> Чем в написании драйверов и прочей in-kernel чешуи тебя не устроил "С"
> ?! И чем ты его там заменишь? ( скажи ещё -
> растом :-) )
> А понял - ты его вместо 1С решил применить и тебя за
> это били ногами ... ну дык эта ... поделом! :-D
> C is high-level assembly language (C) ТЧК!Что ты хочешь от человека, который пишет на c#?
Сишарписты хотя бы освоили секретную технику проверки указателя на null перед использованием.
И на фоне сишных дидов это чуть ли не чудо цивилизации.
> C is high-level assembly language (C) ТЧК!Херочка.
Может когда-то так и было. Сишка ведь создавалась под конкретный процессоры, внезапно.
Процуессоров тех давно уже нет, а эту дохлую кобылу всё пинают.> Чем в написании драйверов и прочей in-kernel чешуи тебя не устроил "С" ?!
Кроме инта неопределённого размера?
> И чем ты его там заменишь?
Да Боже Мой! С десяток отличных замен существует.
> там
Для начала хорошо бы из этого вашего "там" изгнать сишку с её интерфейсами, *void, и каллинг конвектион.
Сишечка как раз и создавалась под неопределённый процессор. От сюда кстати и инт неопределённого размера, ибо в те времена крайне весёлые товарищи встречались (в смысле ОС).
Когда вопросы размерностей утряслись там вполне появились знакомые всем размерные инты. Достаточно подключить stdint.h.> каллинг конвектион
Тут достаточно винду изгнать с её 100500 разных ABI.
Под DEC она создавалась, и риски как таковые.А почему куда и от куда эти риски шли, то история забавная.
Что касается интерфейсов, если имеется в виду POSIX, то изгоняй-не изгоняй: он сейчас везде.
>> C is high-level assembly language (C) ТЧК!
>Херочка.Интересное имя ... или это профессия?
>Может когда-то так и было.
>Сишка ведь создавалась под конкретный процессоры, внезапно.Му-ха-ха :) Тогда почему оно есть подо всё что от электричества работает?!?!
Си - гениальнейшая штука! Оно с минимальным asm-лением бутстрапится на ... ВСЁМ! :)
Но если вы увидите что кто то пишет на нем "апплликейшен" - бейте его ногами! :)>Процуессоров тех давно уже нет, а эту дохлую кобылу всё пинают.
Без неё твоё шаприЁ даже не запустится, слишком вы убогие в этой области. Пиши свои "склад\магазины" и гордись собой. Это не сарказм - просто прикинь современный "склад\магазин" на голом Си vs ну пусть видео-драйвер на голом C# ... 8-D
И сразу поймёшь что зубная щётка и веник ... хотя и одно и тоже концептуально ... но есть нюанс(С) :-)>> Чем в написании драйверов и прочей in-kernel чешуи тебя не устроил "С" ?!
>Кроме инта неопределённого размера?Если тебе нужен int определённого размера - то и объяви его явно, что Си что ли не даёт такого сделать или кое чья "проффЭсьЁн де фуа"? :-D
>> И чем ты его там заменишь?
>Да Боже Мой! С десяток отличных замен существует.И толку? Все популярные оси - на сях. ТЧК.
>> там
>Для начала хорошо бы из этого вашего "там" изгнать сишку с её интерфейсами, *void, и каллинг конвектион.Давай - изгоняй, у ваших даже успехи есть: https://learn.microsoft.com/en-us/cpp/cpp/obsolete-calling-c... правдо с __pascal и __fortran пока :)
> И толку? Все популярные оси - на сях. ТЧК.Виндовс на сях?
> Си - гениальнейшая штука! Оно с минимальным asm-лением бутстрапится на ... ВСЁМ! :)
Ох уж эти сказочки, ох уж эти сказочники.
>После минорных правок в кодах, раст занял заслуженное второе место, с минимальными расхождением с Си.Уже третье, остальные языки тоже оптимизировать начали :)
Уже первое
Очевидно, все еще много раз поменяется.
все эти тесты не стоят выеденого яйца. хочешь узнать реальное положение дел - всегда пиши свои
Джулия вышла на 7 место, а в теме про этот ЯП спрашивали "зачем оно нужно?".
А вот зачем - она в nqueen она всего на ~30% хуже СИ (3.47 против 2.70)
И я уверен что остальные задачи тоже можно улучшить.Зато чтобы посчитать математическую задачку достаточно простой и приятной среды расчетов. Особенно если с результатами нужно еще что-то сделать - построить графики, экспортнуть в какой-то формат данных и тд.
И система типов пожалуй самая сбалансированная.
кому нужны твои математические задачки без практического применения
Я тоже про неё вспомнил. Только наоборот - зачем она нужна, если она ближе к PyPy, чем к С?Как она там создавалась? Karpinski claims it has solved the "two-language problem", "We were greedy for a language that is [s]slower than javascript and lua[/s] as fast as C++, with the high-level functionality of Python, R or Matlab".
Бредово - мы сделали кривой тест с отфонарной реализацией алгоритмов, и не смутившись бредовым результатом выложили.Потом 3 раза переделывали )))
А где Хаскель, Ада, Фортран?
Жулия с нативными матрицами где-то в конце?
C# хоть первые пару прогонов тестов не считали? Которые до отработки джита?
Не... тут еще круче
В 2011 мы сделали первую версию супер тестов.
А спустя 12-13 лет выложили вторую, причем настолько кособокую.
Возможно автору нравятся публичные унижения))
И все же я хочу спросить — кто написал двенадцать пулл-реквестов? Всё верно он сделал, сейчас по принципу "в интернете кто-то неправ" сагрятся и допилят.
> двенадцать пулл-реквестов
> И все же я хочу спросить — кто написал двенадцать пулл-реквестов? Всё
> верно он сделал, сейчас по принципу "в интернете кто-то неправ" сагрятся и допилят.Возможно, но идея opennet.ru/openforum/vsluhforumID3/132476.html#29 была хороша)
>БредовоВот полностью согласен! Даже осуждать нечего. Но ведь будут :(
>После оптимизации кода на языке V, данный язык показал лучшие результаты в рейтинге.Вот кстати темная лошадка из новых интересных языков.
>V lang обладает простым синтаксисом, быстрой компиляцией, высокой производительностью и безопасностью. Он не имеет скрытого управления потоком, скрытых выделений памяти, препроцессора и макросов.
>V поддерживает автоматический перевод C => V.
>V может генерировать нативный код напрямую.
>V предлагает отличную производительность на уровне с C и нулевую стоимость взаимодействия с C13.
>V может использоваться для расширения существующих программ на C/C++14.
>V может использоваться для расширения существующих программ на C/C++14.Очередная нескушная сишка.
>из новых интересных языков
Пориджи настолько отупели, что изобретают свои ЯП вместо того чтобы Хаскель осилить.
> Очередная нескушная сишка.Ты когда меняешь жигулятор на современную тачку, тоже бухтишь "очередная нескучная классика")?
Ну подумаешь ездит так же, но ломается реже, более комфортная и надежная.> Пориджи настолько отупели, что изобретают свои ЯП вместо того чтобы Хаскель осилить.
Угу, тогда можно будеть умничать по поводу монад и функторов.
Тут недавно один малохольный предлагал учить школьников "основам лямбда-исчисления и теории категорий".Назови хотя бы 2-3 серьезные прогрмаммы написанных на хаскеле? Например какой-нибудь редактор, прикладное ПО или ОС ?
Я знаю только House, но он выглядит как отрыжка из 90х.
Leksah был нехлох, но уже кажись помер, как и Yi (который еще раньше).Из более менее нормального xmonad, но во-первых Хсы уже закапывают -> ненужно,
а во-вторых "фича" типа 'Отличительной особенностью XMonad является конфигурирование путём написания программного кода на языке Haskell' - только для фанатиков ФП.
Монады - это банальная вещь.
Как только нужно работать с IO сложнее хеллоу ворда, их приходиться переизобретать, если их и так нету в вашем ЯП.
Сишники вот переизобретают извращенными хаками.В расте оно по умолчанию для всего IO.
> Назови хотя бы 2-3 серьезные прогрмаммы написанных на хаскеле? Например какой-нибудь редактор
Назови хотя бы 2-3 серьезные прогрмаммы написанных на V? Например какой-нибудь редактор
Назови хотя бы 2-3 серьезные прогрмаммы написанных на Zig? Например какой-нибудь редактор
Назови хотя бы 2-3 серьезные прогрмаммы написанных на Java Script? Например какой-нибудь редакторОй, на ЖС то серьездных редакторов есть.
Вы суть упускаете. В Хаскеле есть всё, включая совметимость с сишкой.
Все эти изобретатели нескучной сишки делают кривое подмножества Хаскеля, зачастую не понимаяя теории ЯП, не проведя никакой анализ, а просто реализуя свои хотелки велосипедным способом. Когда всё уже много лет как придуманно и реализованно.Раст хотя-бы что-то сделал правильно, и делает упор на инфраструктуру.
А без развитой инфраструктуры ваши D E F G V Z и прочие наколенные поделки - нафиг ненужны.
А реально не нужен только Хаскель и его функциональная братия. Натурально вывих мозгов ради ачивки «мам, навука!».
> А реально не нужен только Хаскель и его функциональная братия. Натурально вывих
> мозгов ради ачивки «мам, навука!».
> Вот кстати темная лошадка из новых интересных языков.
> ради ачивки «мам, навука!».Вот я иговорю, интересных языков и так навалом.
> функциональная братия
Функциональщина сейчас везде.
> Натурально вывих мозгов
И зачем нам преподают математику, блииин сложна, оно мне ненужно, я буду слесарем зачем нам математика?
Ууууу вы ви х м о з г о в очень сложнааааааа111(((((Ну, если банальные вещи широко адаптировные индустрией для вас вывих мозгов... Как вы с указателями на войд справляетесь? Ну понятно - никак.
> Функциональщина сейчас везде.Отдельные функции и подходы, типа reduce/map. И в общем-то все.
Ну назови-ка, крупные опенсорс проекты написанные на функциональных языках.> И зачем нам преподают математику, блииин сложна, оно мне ненужно, я буду слесарем зачем нам математика?
> Ууууу вы ви х м о з г о в очень сложнааааааа111(((((Ну, твой сраказм уже показывет уровень твоего, так сказать, интеллекта.
На бумажке все эти идеи функционального программирования выглядят отлично. Просто идеальные мат. модели, можно писать курсовые и диссертации. И с презрением, свысока смотреть на остальных.
Хвастаться наличием чистых функций и функции высших порядков (хотя что первые, что последние есть и в императивных).А потом оказывается, что модель вычислений у тебя нестрогая. И функции могут выполняться в общем-то в любом порядке. И всё, ты обделался.
Потому что ввод-вывод в случайной порядке, ну очень порадует юзера.
И приходится в красивейший язык функционального программирования вкорячивать императивные механизмы, потому что без них он просто овно.Ну и такие мелочи как необходимость сборщика мусора, из-за чего что-то серьезное на них не построишь.
> Ну, если банальные вещи широко адаптировные индустрией для вас вывих мозгов... Как
> вы с указателями на войд справляетесь? Ну понятно - никак.Ты не путай "банальные вещи" типа отдельных функций и подход при котором "прочитать пользовательский ввод" ломает всю красоту функциональщины.
Мы просто возьмем удобные подходы и перенесем в свои императивки, а "вещи широко адаптировные индустрией" (где? что?) пусть себе оставят фанатики.
> Ну назови-ка, крупные опенсорс проекты написанные на функциональных языках.Вы прикалываетесь?
Вперёд гугл крупные опенсорс проекты JS> Хвастаться наличием чистых функций и функции
Кто хвастается, эти люди сейчас с вами в одной комнате?
> На бумажке все эти идеи функционального программирования выглядят отлично. Просто идеальные мат. модели
Они полезны практически. И применяются во всех современных ЯП.
> "прочитать пользовательский ввод" ломает всю красоту функциональщиныНе ломает.
> Ну и такие мелочи как необходимость сборщика мусора, из-за чего что-то серьезное на них не построишь.
В чём-то серьёзном и большом вам сборщик мусора мешает? Обычно, его реализуют сами в чём-то серьёзном, если его нет изначально.
> Мы просто возьмем удобные подходы и перенесем в свои императивкиВы, сейчас один, сидите запертый в комнате, в трусах, и фантазируете о некой общности которая наделила вас правом говорить от её имени.
>Ну назови-ка, крупные опенсорс проекты написанные на функциональных языках.Конкурент этого сайта - LOR ... Scala 32.8% - считается?
Да не будет скоро никаких "20 языков" !!! Учитывая какие изменения вводятся в КАЖДЫЙ язык и насколько они идентичны !!! понятно что язык скоро будет ОДИН ! тот на котором ИИ будет писать, а кожаным придётся подстраиваться под эту лапшу :(
Ruby обогнал CPython. Поверить не могу.
В языке программирования главное то, что он язык - для людей. И только потом производительность. При этом разумеется хочется максимальную производительность, но только после удобства самого языка.Что касается этих «типовых» тестов - они нифига не типовые. В реальном мире ваще не это нужно. В реальном мире нужно удобство подключения библиотек, удобная сборка, хорошие сообщения об ошибках, безопасность, креши, концепции упрощающие переиспользование кода - трейты, классы, енумы, аннотации, макросы, асинк/авейт и так далее; поддержка IDE, хорошая документация, друэелюбное сообщество.
А скорость перемножения матриц это не типовая задача, это офигенно нишевая задача, где если вам нужно выжать максимальный перформанс, то вы и на асме вставки сделаете.
>В языке программирования главное то, что он язык - для людей. И только потом производительность.Знал бы ты сколько ЯП созданных под этим флагом гниёт на обочине ...
Но не все: ряба, пейстон и жЫЭс таки пока живут - видимо чего-то в них есть что народ "цепляет" :)>В реальном мире ваще не это нужно. В реальном мире нужно [...]
розовое сено для говорящих пони. Без этого всё тобой перечисленное - "ваще не это нужно".
Ж:-D
> то вы и на асме вставки сделаете.Ну да, ну да. На Асме. А ниче что это весьма проблематично с популяризацией в общем сегменте ARM64, RISC V не говоря уж и о том что и PowerPC и MIPS до сих пор живут в таких узких сегментах как принтеры, роутеры и т.п.. Забодаешься под все архитектура АСМ использовать для какой нибудь общей библиотеки - для примера.
А теперь надо посчитать реальную стоимость языков программирования для бизнеса в единицах иизмерения "доллар на час разработки".
> А теперь надо посчитать реальную стоимость языков программирования для бизнеса в единицах измерения "доллар на час разработки".Это сильно зависит от опыта и квалификации программиста на конкретном языке, от широты применения языка, качества и количества библиотек и стороннего кода на каждом языке и множества других факторов, а также, разумеется, от решаемой задачи. Например, писать логику сайтов на С++, наверно, не очень умно, так же как писать высокопроизводительный код на JavaScript, Perl, Python, Ruby и т.д.
> писать логику сайтов на С++, наверно, не очень умноСмотря каких сайтов. Библиотеки на C++ для сайтов есть и некоторые весьма успешны.
C, Rust, Nim. Всё, расходимсяhttps://github.com/attractivechaos/plb2/blob/master/analysis...
Еще Julia приятно удивила, пятое место для несистемного языка совсем неплохо.
Конечно, если ни Паскаль, ни Фортран не рассматривать... :-)
Ага, Оберон туда же
24-я версия графиков:C, Rust, Nim
> Дополнение 1: В реализации на языках Rust, D и Julia внесены исправления, которые позволили Rust занять второе место, D - третье, Julia - 7 (вместо 16).Теперь на этой версии Rust не работает ничего кроме этого теста, и растоманы очередной раз планируют менять архитектуру языка :))) facepalm
