The OpenNET Project / Index page

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

Сравнение эффективности 20 языков программирования

03.01.2024 10:56

Опубликована вторая редакция проекта PLB (Programming Language Benchmark), нацеленного на тестирование производительности решения типовых задач на различных языках программирования. В отличие от первой редакции, опубликованной в 2011 году, новый вариант измеряет производительность кода для умножения матриц и решения задачи расстановки 15-ферзей, а также дополнительно оценивает поиск решений в игре Судоку и определение пересечений двух массивов. Код для тестирования был написан на 20 языках программирования.

Наиболее высокую производительность показала реализация тестовых приложений на языке Си (при компиляции в clang). На втором месте оказался язык Zig, на третьем Nim, на четвёртом Mojo. Далее примерно на одном уровне следуют D, Java, JavaScript-платформа Bun и Rust (см. дополнение), а после них Go, Crystal и V.

Относительно хорошие результаты также показали Node.js, Dart, Lua и C#. Хорошие результаты у Java и C# объясняются использованием отдельной стадии JIT-компиляции, в то время как в Dart, Bun, Node.js, Julia, LuaJIT, PHP, PyPy и Ruby3 (YJIT) JIT-компиляция выполняется на лету и затрагивает только часто выполняемый код. JavaScript-платформа Bun заметно обогнала Node.js. Относительно медленными оказались результаты у Julia и Swift. Наихудшие показатели производительности продемонстрировали PHP, Ruby, Perl и CPython, при этом производительность PHP оказалась примерно в 4 раза выше, чем CPython.

Дополнение 1: В реализации на языках Rust, D и Julia внесены исправления, которые позволили Rust занять второе место, D - третье, Julia - 7 (вместо 16).

Дополнение 2: После оптимизации кода на языке V, данный язык показал лучшие результаты в рейтинге.

  1. Главная ссылка к новости (https://news.ycombinator.com/i...)
  2. OpenNews: Сравнение производительности сетевого драйвера в вариантах на 10 языках программирования
  3. OpenNews: С++ поднялся на 3 место в рейтинге языков программирования Tiobe
  4. OpenNews: Анализ изменения популярности языков программирования в выходные дни
  5. OpenNews: Проект по тестированию эффективности языков программирования
  6. OpenNews: Опубликованы тесты простейших приложений на различных языках программирования.
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/60384-lang
Ключевые слова: lang, benchmark
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (383) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 11:05, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +21 +/
    Опять всё переписывать...
     
     
  • 2.4, Аноним (4), 11:08, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Ну, если тебя высосанная из пальца синтетика с сомнительными результатами мотивирует, то -- вперёд.
     
     
  • 3.145, YetAnotherOnanym (ok), 14:30, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Ага, а в реальных-то приложениях интерпретируемое недоразумение всех порвёт, канешна.
     
     
  • 4.146, Аноним (4), 14:37, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +7 +/
    В реальных приложениях вычисления будут на си/ассемблере/фортране и да, порвёт.
     
     
  • 5.149, YetAnotherOnanym (ok), 14:49, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Так здесь си и так всех обскакал. Мой сарказм был в адрес комментария 2.4, в котором Аноним почему-то оспорил обоснованность такого результата.
     
     
  • 6.331, Прохожий (??), 07:47, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    В некоторых реальных приложениях далеко не всегда важна скорость выполнения кода, а куда важнее скорость разработки.
    Например, автоматизация какой-то рутины из области системного администрирования.
     
     
  • 7.332, Илья (??), 08:06, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Скорость разработки важна в первые 2 недели.

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

     
  • 7.371, YetAnotherOnanym (ok), 13:49, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для автоматизации рутины из области системного администрирования десятки лет назад придуманы shell и awk.
    Язык с высокой скоростью разработки нужен, чтобы быстренько накарябать подобие работающей системы, пригодной для минимальной нагрузки. Потом её можно спихнуть инвестору, и пусть сношается как хочет, а самому затеять новый стартап.
     
  • 7.474, Аноним (474), 06:41, 08/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А потом выясняется, что скорость разработки обратно пропорциональна качеству оптимизации и количеству багов в коде. Но смузи сам себя не выпьет.
     
     
  • 8.476, Аноним (-), 14:35, 08/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Конечно, мы сами его выпьем, пока будем думать над кодом Это только у адептов д... текст свёрнут, показать
     
  • 4.321, GG (ok), 04:03, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В реальных приложениях зарплата программиста стоит гораздо дороже аренды или покупки сервера
     
     
  • 5.370, YetAnotherOnanym (ok), 13:44, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это пока нет по-настоящему серьёзной нагрузки. Когда она появляется - контора оказывается в том же положении, в котором когда-то оказался ФБ, которому пришлось пилить свой ПХП. А так, для стартапа, задача которого продать инвестору прототип - вполне годится, да.
     
     
  • 6.383, Аноним (383), 19:06, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот, кстати, да – в списке нет Hack. Интересно было бы посмотреть на результаты.
     
  • 6.415, Котофалк (?), 18:26, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Когда она появляется

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

     
  • 5.427, Ivan7 (ok), 02:17, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Если производительность языков отличается в десятки и сотни раз, а вы, например, занимаетесь обработкой данных, то производительность очень важна, т.к. на медленных языках вы можете просто не дождаться окончания работы программы, т.к. вместо 1 секунды вам приходится ждать сотни секунд, вместо 1 минуты - сотни минут, т.е. N часов. Запустите тесты, чтобы просто это прочувствовать, и все вопросы сами собой отпадут. Я запустил у себя данные тесты для нескольких языков. Признаюсь, окончания некоторых тестов я не дождался.
     
     
  • 6.430, GG (ok), 02:50, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А если бы у бабушки были бы колёсики...

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

     
     
  • 7.433, Ivan7 (ok), 05:07, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > А если бы у бабушки были бы колёсики... Но в реальной жизни программирование так не работает.

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

     
  • 6.434, Ivan7 (ok), 05:48, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Результаты проведённых мной тестов последний вариант с github для x86-64 для C... большой текст свёрнут, показать
     
  • 6.435, Ivan7 (ok), 06:53, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    И ещё в догонку результаты тестирования D на x86-64 matmul nque... большой текст свёрнут, показать
     
  • 6.438, Ivan7 (ok), 08:22, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И ещё результаты тестирования Go (из MSYS2), Julia и Node.js (с их официальных сайтов) на x86-64 Haswell под Windows 10:

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

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

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

     
  • 6.442, Ivan7 (ok), 09:56, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И напоследок LuaJIT и PyPy на x86-64 Haswell под Win 10 LuaJIT мне пришлось ско... большой текст свёрнут, показать
     
     
  • 7.444, Ivan7 (ok), 11:52, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Последовательность тестов здесь такая же, как и в других моих сообщениях:
                  matmul   nqueen   sudoku   bedcov
     
  • 6.443, Ivan7 (ok), 11:35, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну и для полноты картины ещё тест пачки компиляторов С от Intel и Microsoft для ... большой текст свёрнут, показать
     
  • 6.447, Аноним (447), 12:43, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо за тесты.
    Дополню (потому что в сообщениях увидел только про указание целевой архитектуры), что для раста тоже можно указать уровень оптимизации -C opt-level=3
    https://doc.rust-lang.org/stable/rustc/codegen-options/index.html#opt-level

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

     
     
  • 7.454, Ivan7 (ok), 16:38, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    В Makefile для тестов на Расте уже были указаны опции -C debuginfo 0 -C opt-leve... большой текст свёрнут, показать
     
  • 7.455, Ivan7 (ok), 17:50, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Поклонникам Раста Добавил дополнительные опции компиляции и ситуация в тесте nq... большой текст свёрнут, показать
     
  • 6.456, Ivan7 (ok), 18:57, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Для тестов 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)

     
  • 6.457, Ivan7 (ok), 19:49, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Добавление 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)

     

     ....большая нить свёрнута, показать (27)

  • 1.2, Аноним (2), 11:07, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +16 +/
    А теперь надо сравнить эти языки на обработке юникодного текста. И не забыть сравнить время, затраченное на написание кода для всех тестов
     
     
  • 2.9, наука_кандидатов (?), 11:19, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –17 +/
    C и C++ сразу отлетают в таком случае, поскольку вообще никак не умеют в юникодные строки. Задача "оставить в строке только буквы алфавитов X и Y" на этих языках нерешаема.
     
     
  • 3.13, пох.. (?), 11:26, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –10 +/
    за такую задачу надо сразу бить ее постановщика лопатой по хлебалу.

    (в одном интересном языке принято записывать звуки, отсутствующие в алфавите, с помощью апострофа. Догадываешься что происходит при попытке ввести мои паспортные данные в такой вот хрени?)

     
  • 3.30, qetuo (?), 11:42, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +9 +/
    О как. А libicu на чем написана, напомните?
     
     
  • 4.124, Аноним (124), 13:41, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Которая зачастую и используется во всяких других решениях чтобы работать нормально, в т.ч. для SQLite для нормального текстового поиска приходится пересобирать с ней
     
     
  • 5.141, Аноним (4), 14:16, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    ICU это единственная адекватная реализация юникода. И, кроме того, универсальная. А так, на каждой проприетарной платформе свои собственные utf8/utf16.
     
  • 3.32, Герострат (?), 11:45, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Что значит "умеет в юникодные строки"? Чем юникодная строка отличается от любой другой?
     
     
  • 4.38, Аноним (4), 11:57, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Тем, что предсказать количество байт, необходимое под определённое число символьных единиц, а также, сколько будет каждая из них, невозможно. Это накладывает определённые ограничения на работу с текстом, но, на практике, строки бывают только такими. Если, конечно, это не UTF-32, там размер предсказуемый. Понятное дело, накладные расходы в любом случае довольно серьёзные, по сравнению с обработкой однобайтных строк.
     
     
  • 5.57, пох.. (?), 12:16, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –5 +/
    это не про unicode, это про utf8/16 - два самых уе6-щных в мире способа его кодирования.
    виндовый ucs2 вполне себе fixed width.

     
     
  • 6.74, Аноним (4), 12:29, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    В венде, кстати, самый убогий и проблемный юникод, не понимаю, откуда твои восторги. Компромиссное решение конечно было, спасибо хоть теперь utf8 приняли. Но после этого перекодированый utf16 в utf8 может отправлять её в бсод. Когда в одних местах огрызок utf16 и в других местах огрызок utf8, это весело тоже.
     
  • 6.76, Аноним (76), 12:30, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > ucs2

    но ведь там нет эмодзи !

     
     
  • 7.93, пох.. (?), 12:43, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    увы. Поэтому в современной венде тоже помойка из где-то 16, где-то 8, а где-то и вообще восьмибитных кодировок для совместимости.
     
  • 6.125, Аноним (124), 13:43, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В винде все "любят" BOM с которым проблемы и грабли в каждом втором кейсе, а в собственно кодировки нормально не умеют
     
  • 6.135, sena (ok), 14:03, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > ucs2 вполне себе fixed width

    Это только если выкинуть часть юникода.

     
  • 5.92, Аноним (-), 12:43, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В чистых сях, если предказать невозможно размер строки, используют 2 пути:
    1. Используют аллокаторы.
    2. Используют массив, превыщающий размеры вводимых данных, с дополнительной проверочной функцией выхода массива за пределы допустимого размера.

    >Понятное дело, накладные расходы в любом случае довольно серьёзные, по сравнению с обработкой однобайтных строк.

    Понятие "накладные расходы" пришло из языков высокого уровня, где программисты отучились соображать, как в оперативной памяти располагаются данные. Чисто-сишник не знает таких слов, как "накладные расходы. Он просто видит задачу, и её делает. А Си плюс-плюс объектно-ориетрированный язык, в нём проблем с работой со строками вообще не существует.

     
     
  • 6.121, Аноним (-), 13:29, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +9 +/
    > Чисто-сишник не знает таких слов, как "накладные расходы. Он просто видит задачу, и выходит за границы массива.

    Я поправил, не благодари)

     
  • 6.174, Аноним (174), 16:13, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Полная фигня. В сях есть 2 путя:
    1) нуль-терминировнная строка, начиная с некоторого адреса
    2) адрес на начало буфера со строкой и его длина в байтах

    Размер данных нужно не предсказывать, а декларировать, иначе вы что-то не так делаете.
    Можно ещё работать с потоком, но это просто наворот логики над вторым случаем.

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

     
  • 6.333, Илья (??), 08:10, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Чем бы дитя не решилось, лишь бы не брать c#
     
  • 6.514, _kp (ok), 15:52, 01/02/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >>В чистых сях..

    В смысле "чистых"? без библиотек, в стиле велосипедостроения? Так оно нерационально.

    >> А Си плюс-плюс... в нём проблем с работой со строками вообще не существует.

    И там реализация работы со строками не в языке, а в библиотеках. Ладно, в том числе в стоковых. Кстати, если не "шашечки, а ехать", то и в Си проблемы нет.

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

     
  • 5.147, YetAnotherOnanym (ok), 14:42, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Пффф... тоже мне проблема.
     
  • 4.59, Аноним (59), 12:17, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    «От любой другой» — это от ASCII? Примерно всем.
     
     
  • 5.126, Аноним (124), 13:45, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    При одном и том же наборе символов примерно ничем) А потом выясняется что ASCII в реале тебе не хватает и начинается цирк с теми, кто изначально использовал ASCII only подход
     
  • 3.49, Аноним (49), 12:07, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > C и C++ сразу отлетают в таком случае, поскольку вообще никак не умеют в юникодные строки

    Звездёж наглый. https://en.cppreference.com/w/cpp/language/string_literal u8 и https://en.cppreference.com/w/cpp/locale/codecvt_utf8 .

     
     
  • 4.64, Аноним (447), 12:22, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    std::codecvt_utf8
    (deprecated in C++17)
    (removed in C++26)
     
     
  • 5.150, Аноним (150), 14:51, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Преобразование между кодировками юникода и wide character string != "вообще никак не умеют в юникодные строки". В юникод C++ умеет, как ты можешь убедиться открыв эту страничку в написанном на C++ Google Chromium. Там, где нужны преобразования между кодировками, рекомендуется использовать ICU (в Chromium используется именно эта библиотека). Остальным хватит https://en.cppreference.com/w/cpp/language/character_literal

    P.S. А теперь можешь попробовать рассказать, как твой любимый ЯП X поддерживает Юникод на уровне ICU.

     
  • 3.52, Аноним (52), 12:11, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не то чтобы гуру в си юникоде, но даже без libicu всё работает нормально. Сами по себе строки и регексы в них - без проблем вообще.
     
  • 3.90, Netcat (?), 12:42, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    wchar_t нет?
     
     
  • 4.106, Аноним (-), 13:03, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >wchar_t нет?

    Есть. А он имеет ввиде резиновый utf8.

     
  • 4.151, Аноним (150), 14:55, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Забудь про эту нестандартную гадость. Либо char32_t, либо UTF-8.
     
  • 3.128, Аноним (128), 13:50, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >C и C++ сразу отлетают в таком случае, поскольку вообще никак не умеют в юникодные строки.

    С++20 имеет юникодные типы.

     
  • 3.182, fidoman (ok), 17:06, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    C вообще "в строки" не умеет, если уж на то пошло, использовать функции стандартной C библиотеки для работы со строками - это надо быть наглухо отшибленным.
    Но это не значит, что нельзя реализовать работу со строками, просто используя C как продвинутый ассемблер.
     

  • 1.3, Аноним (3), 11:07, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А почему GCC не участвовал в этом соревновании?
     
     
  • 2.6, Dzen Python (ok), 11:12, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Тогда все эти зиги и нимы с моджо не получили бы первые места, естественно. Пришлось бы шаманить с разворачиванием циклов для луДшей синтетики
     
     
  • 3.51, Витюшка (?), 12:10, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Получили бы, после того как ты написал поддержку Zig в gcc.
     
     
  • 4.105, Аноним (-), 13:00, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А есть какие-то предпосылки для этого?
    Зиг вроде и от шланга хотел отказываться.
     
     
  • 5.132, Витюшка (?), 13:59, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Конечно от llvm он никогда не уйдет (и не планировал).

    Они хотели отвязаться от llvm инфраструктуры, а мы их неправильно поняли (был огромный батхерт в GitHub).

    Те генерировать напрямую llvm bc файлы. Всё что выше будет написано на Zig.

    https://llvm.org/docs/BitCodeFormat.html

     
     
  • 6.184, Самый умный из вас (?), 17:18, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Отказываются от llvm, но оставляют слой совместимости, кому нужен. Перечитай гитхаб ещё раз
     
  • 4.122, Аноним (122), 13:38, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не, гендерфлюид не напишет. Он только токсить в комментах горазд.
     
     
  • 5.127, Аноним (124), 13:46, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На самом деле Zig и раст - это разные штуки
     
  • 2.35, Archer73 (ok), 11:50, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    По тестам Phoronix актуальный gcc в среднем чуть медленнее clang
    https://www.phoronix.com/review/gcc-clang-eoy2023/8
     
     
  • 3.50, Аноним (4), 12:09, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Все, кто хоть немного интересовался вопросом, понимают, что это булшит. Но у шланга есть грязные менее универсальные к входным данным оптимизации (aka лапша из goto), которые во многих случаях дают хороший результат.

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

     
     
  • 4.95, Аноним (-), 12:53, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Скажем так, код скомпилированный пр помощи GCC будет "качественным". ГНУ-тым, как "кровь из носу" тупая производительность, "во чтобы та ни стало", не нужна, они взрослые люди и переболели этой детской болезнью.
     
  • 4.346, Аноним (346), 09:56, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >> лапша из goto

    Это приведение кода на этапе препроцессинга к тождественному используя case switch и дальше по методике Jump-table-based switch в ассемблер известной аж с 1970-х и крайне актуальной в условиях Out of order execution процессоров.
    Ноу хау тут не в приведении case-switch к jump-table, это делает и gcc, а в строгом доказательстве тождественности изначального кода и препроцессированного. Чтобы получить предсказуемую производительность, используй case-switch везде изначально, в чем проблема тут, я не понимаю.

     
  • 2.94, olelukoie (ok), 12:46, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Потому что надо новость внимательно читать. Там в заголовке обоих графиков черным по белому написано «arm64-darwin». А что это такое? Правильно, это новые макбуки. И GCC там еще даже рядом не пробегал (я нашел только экспериментальную ветку, еще не включенную в официальный релиз).
     
     
  • 3.109, Аноним (-), 13:15, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +12 +/
    > Потому что надо новость внимательно читать. Там в заголовке обоих графиков черным по белому написано «arm64-darwin».

    Ну ты сказанул!
    Ты бы еще предложил "разобраться в теме, а потом потом только комментировать"

     
  • 2.130, Аноним (128), 13:53, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >А почему GCC не участвовал в этом соревновании?

    Так Darwin-платформа же. Им там религия запрещала GCC >4.2.2 использовать. Вам же неинтересны будут тесты на этой версии GCC?

     
  • 2.157, Аноним (157), 15:34, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Минуттачку, а где имплементации на ассемблере? На гольном AMD64 и AMD64+AVX?
     
     
  • 3.243, Анонин (?), 21:36, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    И как ты его запустишь на Apple M1 на котором тестит автор?
    Через трансляцию... ну это будет не слишком показательно.
     
     
  • 4.249, Аноним (59), 21:46, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Для aarch64 нет ассемблера?
     
     
  • 5.308, Анонин (?), 01:56, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Есть. Но он предлагает же "AMD64 и AMD64+AVX"
     

  • 1.5, Dzen Python (ok), 11:11, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А смысл заниматься подобным онанизмом, если и так понятно, что (по времени исполнения) компилируевые < байт-код < интерпретируемые?

    Нет, серьёзно.

     
     
  • 2.23, Anonymus (?), 11:31, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > PyPy < CPython

    Тут всё правильно?

     
  • 2.116, Аноним (116), 13:24, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –7 +/
    Байт-код с JIT бывает быстрее компилируемого
     
     
  • 3.515, _kp (ok), 15:56, 01/02/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Не бывает. Выбает хреновый результат компиляции, которая аж хуже jit.
    И бывают махинации с условиями тестов.
     
  • 2.334, vvm13 (ok), 08:37, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Какой величины разница между указанными группами. И какая разница внутри групп. Например, JS vs Ruby. Это любопытно.
     
  • 2.336, Илья (??), 08:41, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Смысл в том, что как ты пайфон не оптимизируй, он все равно медленнее на порядок чем тот же msil или clang.

    Msil, к слову, давно в нативный аот умеет

     

  • 1.7, Аноним (7), 11:15, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Их бы сравнения да фронтоделам в уши.
    Один дискорд поражает своей "эффективностью"
     
     
  • 2.79, Аноним (79), 12:31, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Их бы сравнения да фронтоделам в уши.
    > Один дискорд поражает своей "эффективностью"

    Я вам секрет страшный открою - фронтоделам и прочим вэбманкам фиолетово, они живут в парадигме - мы лабаем, а пользователю, если нужно запускать наш чудокод следует если что докупить дополнительных железок на апгрейд его "устаревшего гроба"!

     
  • 2.111, Аноним (-), 13:17, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Мне платят за код, а не за оптимизации под устаревшие платформы.
    Если надо будет сделать так, чтобы оно запускалось на некрожелезе - то я готов это сделать за отдельный прайс.
     
     
  • 3.228, Аноним (228), 20:45, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А штоб сразу — и то, и то, не? Ну так какой ты программист, ремесленник
     
     
  • 4.259, Аноним (-), 22:22, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Обычный инженер.
    Вот представь что тебе скажуст спроектить ДВС. Ты спросишь "а какое топливо, мощность и тд".
    А потом к тебе придут с притензией "а чего на А76 не стартует".

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

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

     
     
  • 5.345, Аноним (345), 09:36, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Голимые отмазки.
     
  • 3.470, Анонист (?), 18:02, 07/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Зря минусуют человека сверху. За оптимизацию кодеру может и прилететь, ибо он тратит часы (деньги) своего работодателя. Вот если у бизнеса появится задача "чтобы запускалось на ведре", то тогда оптимизация и начнётся. Но это происходит только в тех случаях когда замена железа стоит сильно дороже (см. терминалы, индустриальное оборудование, клиент на северном полюсе).
     
     
  • 4.497, zurapa (ok), 20:07, 10/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, зря ли Это философский вопрос Бизнесу нужно, чтобы продукт покупался и б... большой текст свёрнут, показать
     

  • 1.8, Аноним (8), 11:17, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    Каким это образом Zig, Mojo и Nim получают первые 3 места, если задача Судоку на них не решалась вообще (еще и Пересечение массивов у Zig и Mojo)? Логичней было б прибавить к полному времени выполнения на них бесконечность а не нули.
     
     
  • 2.15, пох.. (?), 11:27, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Каким это образом Zig, Mojo и Nim получают первые 3 места, если задача Судоку на них не решалась вообще

    и почему тогда не победил brainfuck, вот что непонятно!

     

  • 1.10, Аноним (10), 11:19, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Вот и очередное доказательство, что ужасный ржавый проигрывает божественному зигу
     
     
  • 2.16, Анонин (?), 11:28, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +12 +/
    Проигрывает в matmul, выигрывает в nqueens.
    Но остальные две задачи зиг вообще не решил... поэтому, по мнению авторов, он быстрее чем раст.
    Тогда проще было вообще не решать задачи и стать лучшим языком!))
     
     
  • 3.159, Аноним (159), 15:36, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Проигрывает в matmu

    Причем проигрывает лишь потому, что эти горе-сравнители используют в mathmul доступ к элементам Vec с проверкой границ. Я даже, блждад, не задумались: а почему же такая разница?

     
     
  • 4.176, Аноним (-), 16:27, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Такое впечатление, что код писал один и тот же ч̶а̶т̶ ̶Ж̶П̶Т̶ человек просто транслируя код с одного языка на другой "в лоб".
    В том же свифте можно оптимизировать судоку и сделать её быстрее.

    А может цель была в "написать тесты языков без оптимизаций", чтобы посмотреть, как они работают со штатными настройками компилятора.

     
     
  • 5.489, Бывалый смузихлёб (?), 12:05, 09/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Да и на ноде отчасти можно
    По крайней мере, ранее можно было выставить количество вызовов конкретных функций для начала следующего уровня оптимизации

    Там, получается, первые несколько раз функция исполняется тупо интерпретатором, ещё после нескольких вызовов делаются какие-то оптимизации, и в конце-концов( после кучи вызовов ) - уже JITифицируется. Но при условии что все разы функция не менялась. Каждое изменение - обнуление счётчика. Для каждого следующего этапа надо сотни-тысячи вызовов.
    По умолчанию выставленные уровни - это некий компромисс для разных устройств между относительно быстрой работой и начальным запуском
    В производительности - JITифицированный жс-код был быстрее интерпретируемого в десятки-сотни раз

     
  • 4.178, Аноним (159), 16:39, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > горе-сравнители используют в mathmul доступ к элементам Vec с проверкой границ.

    Уже исправили.

    https://github.com/attractivechaos/plb2/commit/643606048476eca58ac78032386b763

     
     
  • 5.197, Аноним (-), 18:20, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ого, круто.
    Очень оперативно испаравили, неужели создатель этих тестов сидит на пенькt и читает как его детище в комментариях обкладывают)?

    Теперь раст на втором месте!
    Ну что фанаты zig/nim/mojo, сьели?

     
     
  • 6.295, Аноним (295), 01:27, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вообще-то на третьем, и то до момента, когда Zig или Nim тоже оптимизировать начнут.
     
  • 5.198, an2 (?), 18:22, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Разве этот код можно так же легко читать как Си?
     
     
  • 6.206, Аноним (-), 18:42, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Да, достаточно поработать недельку-две и становится привычно.
    В СИ тоже есть макросы которые местами содом и гоморра, но люди как-то привыкают
     
  • 6.296, Аноним (295), 01:28, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Как писал классик, можно посидеть на горячей плите - тоже привыкнешь :)
     
  • 6.486, Пряник (?), 10:42, 09/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Скорее нельзя такое сравнивать.  Vec<Vec<f64>> - это тип данных (обощённо <T>), &mut - ссылка (прощай, указатели!), vec![0f64; n] - макрос создания пустого вектора из массива (можно и Vec::from([0f64, n])), iter() - превратить в итератор (привет питон, странно, что не as_iter),
     

  • 1.11, Аноним (11), 11:23, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Как часто вы умножаете матрицы в ваших программах?
     
     
  • 2.36, Тот_ещё_аноним (ok), 11:56, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Удивительно, но часто
    Клиент калькулятор на сайт попросил, умножение матриц внутри, php
     
     
  • 3.47, фнон (?), 12:05, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    хм... мне казалось, что мат. либы должны быть уже или написаны, или быть в std.
    Или это какой-то особый калькулятор?
     
     
  • 4.110, Аноним (-), 13:16, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Функция "Умножение матриц", не являяется математической библиотекой.
     
  • 4.325, Тот_ещё_аноним (ok), 04:26, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Понятно, что не калькулятор виндоуз
    Методика в тз, "умножение матриц" похоже по сложности
     
  • 3.516, _kp (ok), 16:01, 01/02/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну php, так php. Но если речь не о интерактивном калькуляторе, где на время можно забить, то нужно использовать библиотеки, использовать avx и подобные фичи процессоров.
     
  • 2.134, Аноним (128), 14:00, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Чаще всего в одностраничном коде на CPython. Прямо скажем, часто.
     
     
  • 3.261, Аноним (261), 22:26, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    во-первых, ты трепло, во-вторых, вон из профессии, если ты это делаешь без numpy
     
     
  • 4.298, Аноним (128), 01:34, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Во-первых, я не чистый кодер в какой-либо софтверной компании. А, скажем так, работаю в области связанной с ЦОС. Во-вторых, а где ты увидел, что я написал, что без NumPy?
     
  • 4.421, Ivan7 (ok), 00:58, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Python в десятки и сотни раз медленнее C/C++. Тесты это ясно показывают. Никакой numpy, который сам написан на С, радикально не поможет. Кроме того, нахрена язык, если с ним в обязательном порядке нужно использовать костыль в виде numpy, который может ограниченно помочь только в узком круге задач? Короче говоря, пиши обработку данных сразу на C++ и не теребонькай одно место. Если бы программисту на С++ сказали, что он придурок, если не использует что-то вроде numpy, - это было бы очень комично)
     
     
  • 5.517, KawaiiSelbst (?), 07:07, 08/02/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ivan7 Я конечно прошу прощения, но довольно некорректно называть библиотеки к па... большой текст свёрнут, показать
     
  • 2.418, Александр (??), 23:30, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Геймдев. Частенько. Правда сами функции не пишем: либо из движка, либо из библиотеки.
     
     
  • 3.487, Пряник (?), 10:44, 09/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Наверное, Dwarf Fortress обновляет мир так.
     

  • 1.12, Аноним (-), 11:26, 03/01/2024 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • +/
     

  • 1.14, Аноним (14), 11:27, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    я так понимаю, что сравнение велось по суммарному времени для всех 4 тестов, а почему на 1 диаграмме для zig, nim, mojo и др. не все тесты отражены? или они мгновенно отработали?
     
     
  • 2.22, Аноним (447), 11:31, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что для zig и mojo еще не написали sudoku и bedcov, а для nim - bedcov.
    Зачем при этом делать такую диаграму - вопрос к автору.
     
     
  • 3.26, Аноним (14), 11:34, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    мне показалось или новость исправили?
     
     
  • 4.28, Аноним (14), 11:38, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    теперь первый си
     
  • 3.39, Анонус (?), 11:59, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Могли бы в ЧатЖПТ заказать. Возможно и не самый оптимальный вариант будет, но лучше чем ничего.
     

  • 1.17, Советский инженер (ok), 11:28, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    '''rust
    fn matmul(n: usize, a: Vec<Vec<f64>>, b: Vec<Vec<f64>>) -> Vec<Vec<f64>>
    '''

    какойто додик упоротый передает вектора в функцию по значению !!!
    это даже не смешно.

    всратые клоуны

     
     
  • 2.21, пох.. (?), 11:30, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > какойто додик упоротый передает вектора в функцию по значению !!!
    > это даже не смешно.

    "appease clippy"

     
  • 2.31, qetuo (?), 11:45, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Передает. Но в Rust по умолчанию используется "перемещение", поэтому никаких промежуточных аллокаций и копирований содержимого происходить не будет.
     
     
  • 3.129, Аноним (124), 13:52, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Оказывается раст не защищает от полного непонимания происходящего и, как следствие, говнокода) удивительно... восхитительно...
     
     
  • 4.131, Аноним (-), 13:59, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Но, только для тех, кто не читал документацию.
     
     
  • 5.248, Вы забыли заполнить поле Name (?), 21:45, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Но, только для тех, кто не читал документацию.

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

     
     
  • 6.262, Аноним (-), 22:27, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А я что говорил "автор оригинального комментария" хорошо разбирается в расте?
    Тут половина пишущих в теме про него - ваще не бумбум.
    Чего только витюшка стоит.
     
     
  • 7.289, Витюшка (?), 00:57, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Помнят, любят))) Но обычно по факту сказать нечего.
     
  • 3.190, Советский инженер (ok), 18:03, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    размер Vec<T> 24 байта.
    так что передача в функцию не такая уж и бесплатная.
    через регистпы не пролезет.


    ну и сам вызов мува. это как никак а вызов функции.

     
     
  • 4.232, Витюшка (?), 20:54, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Как это вызов функции?😨
    А как же Zero Cost Abstractions?
     
  • 4.499, qetuo (?), 01:43, 11/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Полная чушь.

    > размер Vec<T> 24 байта.
    > так что передача в функцию не такая уж и бесплатная.
    > через регистпы не пролезет.

    24 = 3 * 8 = 3 РОНа из 14 свободно доступных на x86_64. А еще есть FPU регистры, которыми тоже можно пользоваться. И даже если там будет спилл, он будет разовым и никакого абсолютно влияния на результаты не окажет.

    > ну и сам вызов мува. это как никак а вызов функции.

    Никакого вызова там нет, это 3 mov.

     
  • 2.84, Alladin (?), 12:37, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    сьто?, Vec представляет из себя указатель и ты переместил/скопировал указатель в функцию.

    ты бы лучше спросил зачем им аллокация в аллокации.

     
     
  • 3.102, Советский инженер (ok), 12:57, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >Vec представляет из себя указатель

    указатель и счетчик занятого

     
     
  • 4.266, Вы забыли заполнить поле Name (?), 22:58, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >>Vec представляет из себя указатель
    > указатель и счетчик занятого

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

     
     
  • 5.272, Советский инженер (ok), 23:35, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >Пытаешься свернуть с темы?

    Э, с какой темы?
    Или ты тоже считаешь что передача указателя на массив и вектора в функцию равнозначны с точки зрения производительности?

     
  • 2.85, Sw00p aka Jerom (?), 12:38, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    задам вопрос не по теме, зачем какой либо функции возвращать значение return-ом, если назначение (dst) возвращаемого значения можно передать указателем в качестве аргумента фукнции?
     
  • 2.136, Витюшка (?), 14:03, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Rust программисты не знают семантику перемещения в своём языке 😀🥳 Почему это неудивительно?

    А потом будут рассказывать нам про то какие классные и безопасные программы эти г...кодеры пишут.

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

     
     
  • 3.144, Аноним (-), 14:29, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А кто сказал что Советские инжинеры в нем разбираются)
    Вот ты тоже про Раст комментировал, даже доку не прочитав.
    А так осуждаешь, как-будто сам никогда не умничал в темах, в которых не разбираешься)
     
     
  • 4.148, Витюшка (?), 14:43, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Я как раз доку прочитал. И про borrow checker читал. И про move семантику.

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

    В lifetime я конечно плыву, но я них и не говорю.

     
  • 3.209, Советский инженер (ok), 18:46, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >Rust программисты не знают семантику перемещения в своём языке

    И тем не менее  в zig версии использовались слайсы.
    Не пояснишь а чего ж так?

     
     
  • 4.234, Витюшка (?), 20:56, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Поподробнее свою мысль разверни
     
  • 3.235, Иисус (?), 20:56, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Rust-погромисты вполне себе знают. Приведённый пример кода явно написан человеком, который не умеет писать на Rust. Vec внутри Vec для двумерного массива это, кринж, как сейчас модно говорить. И это будет так для любых языков без GC.

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

    Вывод какой? Все подобные исследования не позволяют судить о том, что одни языки лучше других в чём либо. Разве только на уровне "компилируемые ЯП обычно быстрее интерпретируемых". Но мы это и так знаем.

     
     
  • 4.240, Аноним (240), 21:26, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Тут не бодание фишками, а сравнение что будет если тратить мало времени и делать код чтобы работало выполняя синтетическую нагрузку.
    То чего можно вдальнейшем достичь достигается гуру, которым это не лень.
    Работать работу это вам не выдавать нагора все лучшее и сразу показывая видишь мускул этот конкретно чуть больше? Значит я лучше тебя во всем.
    Все правда давно разочаровались в кодерах. Одного тытрупа хватает с жирновебом.
    Работает? Канает? Вот и не гунди.
     
  • 4.253, Аноньимъ (ok), 21:56, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Исус прав.
     
  • 4.297, Аноним (295), 01:32, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Можно подумать код на Nim и Zig писали программисты с большим опытом на них.
     
  • 4.309, Sw00p aka Jerom (?), 01:59, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Вывод какой? Все подобные исследования не позволяют судить о том, что одни языки лучше других в чём либо.

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

    пс: понятие "оптимальный" пока без строгого определения, надо думать.


     
     
  • 5.330, Аноним (240), 05:17, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А никто не запрещает байт кодовые языки сделать компиляемыми.
    Вот жабокод внутренний это и есть жаба, а то что человек пишет отличается.
    Языки нужны что оперировать иначе. Подключить биюлиотеку на Си к языку высокого уровня можно, натаскать нейросетку на оптимизацию тоже есть возможность.
    Тут вопрос скорее в том почему до сих пор результат отличается кроме диначимеской типизации чтоб тормознее было.
    То что вагоны циклов можно смягчить кешем жо определенной степени и так понятно, а потом идет работа с данными.
    Нам показывают время, а в реальности надо смотреть сколько времени шла работа, а не ожиданте данных.
     
  • 3.250, Вы забыли заполнить поле Name (?), 21:46, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Rust программисты не знают семантику перемещения в своём языке 😀🥳 Почему
    > это неудивительно?
    > А потом будут рассказывать нам про то какие классные и безопасные программы
    > эти г...кодеры пишут.
    > Не удивлюсь что про перемещение сказал как раз не программист на Rust,
    > а любопытствующий.

    Этот "советский инженер" с пеной у рта постоянно топит за раст. Наконец-то показал свою сущность ыксперта :D

     
  • 2.329, Аноним (-), 05:04, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Vec -- это если что типа "умный указатель". Но даже это не важно: то, что ты называешь "передачей по значению", в расте на самом деле передача овнершипа, а вот будет ли она на уровне ассемблера реализована передачей указателя или копированием значения в регистры -- это забота компилятора.
     
     
  • 3.335, Советский инженер (ok), 08:39, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >в расте на самом деле передача овнершипа, а вот будет ли она на уровне ассемблера реализована передачей указателя или копированием значения в регистры -- это забота компилятора

    как я писал выше, Vec<T> занимает 24 байта для 64-битной системы, т.е. в регистры он не пролезет. передача будет через стек.
    Плюс, это передача в функцию. если она не заинлайнится (а она не инлайнится, я проверил) то накладные расходы будут, и будут выше, чем передача в функцию указателей (ссылок)

     
     
  • 4.403, Аноним (-), 10:04, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > передача будет через стек.

    Если раст откажется проталкивать значение в функцию через регистры, то он положит в %rdi адрес этого значения. Куда он будет класть адрес на arm64 я не знаю, но спорить готов, что тоже в какой-нибудь регистр.

     

  • 1.19, фнон (?), 11:29, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Т.е если взять брейнфак, где нет ни одной реализованной задачи - то он победит, тк время будет минимально?
    (Эти гении "добавляют 0 времени" для нерешенной задачи /_-)
    Максимально глупые условия теста.
     
     
  • 2.223, Аноним (223), 20:40, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Только общие тесты повлияли на рейтинг.
     
  • 2.299, Аноним (295), 01:34, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А еще они не добавляют единицу в делитель для нерешенной задачи, но для тебя это слишком сложная математика.  
     

  • 1.20, Аноним (20), 11:30, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +12 +/
    Где FPC? Где Fortran?
     
     
  • 2.40, Тот_ещё_аноним (ok), 12:00, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    См результаты Си
     
  • 2.349, Аноним (349), 11:08, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Fortran бы себя мог показать очень хорошо на этих задачах.
     

  • 1.25, Аноним (25), 11:33, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > производительность PHP оказалась примерно в 4 раза выше, чем CPython.

    Воистину не тормозит!

     
     
  • 2.48, Аноним (48), 12:06, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    PHP фреймворки эффективно устраняют это недоразумение.
     
     
  • 3.251, Вы забыли заполнить поле Name (?), 21:47, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > PHP фреймворки эффективно устраняют это недоразумение.

    В питон джит завезут скоро.

     
  • 2.55, Аноним (4), 12:15, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –5 +/
    >> производительность PHP оказалась примерно в 4 раза выше, чем CPython.
    > Воистину не тормозит!

    PHP не ЯП.

     
  • 2.267, Аноним (261), 23:13, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    потому что как мининим реализацию на питоне писал какой-то кретин (вроде тебя), питона не знающий, убедиться в этом легко, посмотрев на реализацию matmul с использованием вложенных циклов в стиле си https://github.com/attractivechaos/plb2/blob/master/src/python/matmul.py
     

  • 1.29, Анонин (?), 11:40, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Вообще очень классный вброс!
    Сейчас набегут со словами:
    "Вы написали на моем любимом языка какое-то овно! Сейчас я покажу вам как надо писать!!11"
    Так что ждем третью версию тестов))
     
     
  • 2.60, Витюшка (?), 12:17, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Кроме Rust. Они обосрались и не смогли написать самый простой мьютекс ещё в прошлой ветке.
     
     
  • 3.67, Анонин (?), 12:24, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Странно, вроде обосрался ты запутавшись в волотилях аж в 60 строках кода...
    А они умные люди - решили не тратить свое время на новый год на какую-то фигню.
     
     
  • 4.112, Витюшка (?), 13:20, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я как раз не запутался, я его не использовал до этого. Это нормально для программистов, которые пишут больше чем 0 строк кода 😀😀😀

    Только в Rust все пишут сразу безопасно и идеально. Но теперь мы поняли как 😀😀😀

    Лучшая программа - это ненаписанная программа. По версии Rust фанатиков.

    И, кстати, если бы я и не сказал, никто бы и не узнал.

     
     
  • 5.118, Аноним (-), 13:25, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Лучшая программа - это ненаписанная программа. По версии Rust фанатиков.

    Странно, тебе вроде кинули код мютексов на расте.
    Код есть - есть. Какие вопросы?

     
     
  • 6.138, Витюшка (?), 14:12, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Спор был. Я пишу СВОЙ код, он пишет СВОЙ код. Потом я доказываю корректность на листочке. А он с помощью безопасного Rust (borrow checker).

    Но до этой стадии мы так и не дошли. Остановились на 0 строк кода.

    Или вы никогда сами ничего не пишете и всегда берёте "production ready, проверенный годами" код для экспериментов в одном файле? Те сами ничего написать не можете?

    Использовать "в production" никто не предлагал. Зато разобраться как работают мьютексы было бы очень полезно, тем более для профессиональных программистов низкого уровня.

     
  • 5.119, Анонин (?), 13:26, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Угу, только "фанатики" раст тебе предоставили рабочую написанную программу "проверенную годами" (с).
    А ты... ну, что смог, то смог. Есть куда расти.

    > И, кстати, если бы я и не сказал, никто бы и не узнал.

    ... думаешь ты.
    Но даже если это так, то это как бы намекает, насколько всем непофиг на твои потуги)))

     
     
  • 6.137, Витюшка (?), 14:06, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Так и я мог скинуть "проверенную годами". Вы то зачем тогда? Брать того программиста и дело с концом. А вас на пересылку JSON-чиков.

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

    Я разве где-то говорил что на Rust нельзя мьютекс написать???

     

  • 1.33, Bottle (?), 11:48, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Очень всратый бенчмарк, кроме того, что не на всех языках решены все задачи, так езё задач мало.
    The Benchmarks Game гораздо информативней.
     
     
  • 2.86, Alladin (?), 12:40, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    зиг тупо луДше:)
     
  • 2.139, Аноним (-), 14:13, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    С одной стороны да, 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,
    Сомневаюсь, что с таким будут запариваться, кроме очень нагруженных участков программы

     
     
  • 3.256, Аноньимъ (ok), 22:02, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Вот только в llvm есть векторные инструкции.

    И они есть почти во всех цп современных.

    И в С# внезапно есть.

    А что там компилятор под конкретную платформу сгенерит то другой вопрос совершенно.

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

    А вот вставлять х86 ассемблер - нет.

     

  • 1.34, Анонн (?), 11:49, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Такое ощущение, что все компилируемые языки должны асимптотически сходиться к одним значения.
    У автора V и rust немного обгоняют Си в nqueen.
    А в matmul V проигрывает Си около 6 раз - 3.17 vs 0.54!
    Предположу, что там что-то неправильно реализовали.
     
     
  • 2.56, Archer73 (ok), 12:16, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не понятно каким компилятором собирался код V. В makefile есть только опция -prod. Лучше было бы явно задать в качестве компилятора gcc, и добавить опции fast_math и no_bounds_checking. Возможно это ничего не поменяет, но явное лучше неявного.
     
     
  • 3.192, Аноним (128), 18:11, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    V в GCC уже завезли, когда?
     
  • 3.287, Igor (??), 00:48, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    в яблочной секте arm64-darwin нет компилятора gcc - он предан анафеме!
     
  • 2.219, anonimus (?), 20:10, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Можно посмотреть на реализацию matmul с использованием вложенных циклов в стиле C-like и понять, что человек не утруждал себя использовать возможности языка для ускорения работы кода. Сравнение такое напоминает сравнение писюна с огурцом и не более.
    (https://github.com/attractivechaos/plb2/blob/master/src/python/matmul.py)
     
     
  • 3.300, Аноним (295), 01:38, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Тогда остальные программы тоже нужно ускорить оптимизациями.
     
  • 2.426, Ivan7 (ok), 02:07, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Такое ощущение, что все компилируемые языки должны асимптотически сходиться к одним значения.
    > У автора V и rust немного обгоняют Си в nqueen.
    > А в matmul V проигрывает Си около 6 раз - 3.17 vs 0.54!
    > Предположу, что там что-то неправильно реализовали.

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

     

  • 1.37, Анонус (?), 11:57, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Было бы здорово увидеть решение на asm для эталона.
     
     
  • 2.42, Тот_ещё_аноним (ok), 12:03, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Разница с Си будет доли %
     
     
  • 3.46, Аноним (46), 12:05, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Не смеши мои тапки, Си от голого ассемблера отстаёт в десятки раз. Проверено ещё во времена msdos и 8086 процессора.
     
     
  • 4.69, Аноним (59), 12:26, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Вспомнила бабка, как девкой была. Сейчас компилятор так наоптимизирует, что кожаный движок в жизни не догадался бы так написать. Да и тогда не было никаких десятков раз, конечно.
    А тут ведь у нас про математику? Программирование 8087 на ассемблере — занятие для законченного мазохиста.
     
     
  • 5.80, Аноним (4), 12:34, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Оптимизации это хорошо (потому что компилятор в теории лучше знает об особенностях каждой архитектуры), но, в конечном счёте, без ручного ассемблера сегодня не обойтись.
     
  • 5.142, Аноним (142), 14:19, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Человек руками на mmx/sse так напишет, что никакому оптимизирующему компиллятору никогда не удастся. Много раз так делал.
     
     
  • 6.166, Аноним (166), 15:41, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Демосцена тому пример. Никакой си не сможет даже близко того, что делают парни на ассемблере. Причем ассемблер вопреки бытующему мнению на самом деле очень простой язык, может быть даже самый простой.
     
     
  • 7.175, Аноним (59), 16:20, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Трудоёмкость такого программирования такова, что в реальной жизни оно нигде не пригодится.
    И на ассемблере пишутся в основном совсем уж маленьких демках. Тот же .kkrieger написан в основном на Си (и то авторы признавались, что ну его нафиг такой опыт).
    Ассемблер — простой язык, да. Программировать только на нём сложно.
     
     
  • 8.292, Аноним (240), 01:18, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Человек, ты вещаешь про х86 или может армы, а вот для Эльбрусов заявлено что пер... текст свёрнут, показать
     
     
  • 9.294, Аноним (59), 01:25, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А пруфец на заявление можно Потому что это даже для x86 звучит фантастикой, а д... текст свёрнут, показать
     
  • 7.186, Аноним (-), 17:32, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А сколько ты будешь этот идеальный код писать?
    Особенно проект уровня, ну хотя бы текстовый редактор?
    Думаю речь пойдет о годах, если не больше.

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

     
  • 7.211, Ivan7 (ok), 18:55, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Эффективнее всего делать ассемблерные вставки для C++, компилировать код С++, дизассемблировать и изучать дизассемблированные листинги, чтобы потом писать более эффективный код на С++ и ассемблере. Нужно грамотно сочетать С++ с ассемблером, используя преимущества обоих. Писать программы на голом ассемблере смысла нет, и даже вредно, а вот сочетать С++ и ассемблер - это действительно интересно и полезно.
     
     
  • 8.293, Аноним (59), 01:22, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Дизассемблированный код C 8212 это страшная вещь ... текст свёрнут, показать
     
  • 7.268, Аноним (261), 23:17, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    суть демосцены не в оптимизации производительности, а размере исполняемого файла
     
  • 5.161, Аноним (166), 15:38, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Сейчас компилятор так наоптимизирует

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

     
     
  • 6.173, Аноним (59), 16:10, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И только с хелловорлдом это и сработает. Килобайты — это оверхед для любой сишной программы. Но на всякий случай напомню, что страница памяти у нас — минимум 4 килобайта.
     
  • 4.263, an2 (?), 22:28, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Но из-за того, сколько процессоров вышло с тех времён, даже что-то такое тривиальное как strlen() - это уже проблема, не говоря уже о чём-то большем.

    https://stackoverflow.com/questions/57650895/why-does-glibcs-strlen-need-to-be

    Помимо основных библиотечных функций кодеки на асме вручную ещё оптимизируют.

     
     
  • 5.265, an2 (?), 22:31, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    И тут ещё:
    https://stackoverflow.com/questions/33480999/how-can-the-rep-stosb-instruction
     
  • 4.278, _kp (ok), 00:12, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
       Помню как то писал на msp430, так там код на gcc генерировал значительно более компактный код, чем написанный на ассемблере. Вручную написанный код хороший, но настолько сильно с оптимизацией вручную не заморачиваются, кроме крайне критичных мест.
       Если же взять типичный большой исходник на ассемблере, то большая его часть обычно написана шаблонами и макросами, а чудеса оптимизации только в самых важных местах.
    А код на компилируемых языках оптимизируется везде. И на обычном большом проекте ассемблер совсем не выигрывает, и тем более с разгромом.
     
  • 4.326, Тот_ещё_аноним (ok), 04:41, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Примерно в тех временах и осталось
    Компиляторы уже другие, процессоры тоже
    Для конкретной однокристалки подход конечно лучший до сих пор
    А вот для семейства хотя-бы интел разных поколений... Ну не подъёмно это руками, да и компилятор сделает лучше
     
  • 3.120, User (??), 13:28, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Так-то при решении сколько-нибудь осмысленной объёмной задачи компилятор почти наверняка справится лучше... Т.е. возможны конечно варианты - но in general на x64 как-то так.
     
     
  • 4.163, Аноним (166), 15:39, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Хватит повторять эти сказки. Не позорься.
     
     
  • 5.193, Аноним (128), 18:13, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А чё так мало желающих лабать на Асме? Неохота парится за 1% прироста производительности.
     
     
  • 6.215, Аноним (142), 19:38, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Из своей практики по обработке изображений, там не 1%, а иногда в лоб переписываешь на векторные инструкции - в 30 раз быстрее, неделю походишь, подумаешь - переписываешь и ещё в 2 раза быстрее, как-то так.
     
     
  • 7.216, Аноним (-), 19:44, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Из своей практики по обработке изображений, там не 1%, а иногда в лоб переписываешь на векторные инструкции - в 30 раз быстрее, неделю походишь, подумаешь - переписываешь и ещё в 2 раза быстрее, как-то так.

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

    И есть смысл ускорить именно такой код, а не писать целиком окошки и кнопочки на ASMе.


     
  • 7.269, Аноним (261), 23:21, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    ну давай, покажи, что ты там напрактиковал, где код?
     
  • 7.380, User (??), 17:57, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Из своей практики по обработке изображений, там не 1%, а иногда в
    > лоб переписываешь на векторные инструкции - в 30 раз быстрее, неделю
    > походишь, подумаешь - переписываешь и ещё в 2 раза быстрее, как-то
    > так.

    Не-не, не "критический участок специфического кода" на 300 сишных строк - а аналог хотя бы 5-10k чего-нибудь более высокоуровневого.

     
  • 5.381, User (??), 18:00, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Хватит повторять эти сказки. Не позорься.

    Действительно. В жизни дофига примеров вида "переписал 10000 строк плюсового кода на асм, получил хN к производительности" и вас не затруднит привести хотя бы два, да?

     
  • 2.61, Аноним (61), 12:20, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Посмотрел по ссылкам подробности алгоритмов. Составителям тестов следовало бы привлечь специалистов, которые читали что-либо еще, кроме Википедии. Используется неэффективное хранение матриц. На С можно намного увеличить скорость их перемножения.
     
  • 2.194, Аноним (61), 18:13, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Из всех перечисленных можно вызывать функции на С. В результате все языки будут одинаково быстрыми.
     
     
  • 3.317, Ivan7 (ok), 02:38, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    1) В С++ (Clang, GCC, ICC) можно делать ассемблерные вставки (не вызов ассемблерной функции, хотя это тоже можно). 2) В С++ можно сделать функцию встраиваемой и полностью избежать затрат на её вызов, что для небольших и часто вызываемых функций очень актуально. 3) Нет большого смысла писать на другом языке, а потом оптимизировать производительность, переписывая часть функций на С/С++. Проще сразу писать на С++. Если только вы не поддерживаете какой-то уже готовый проект, изначально написанный на другом языке.
     

  • 1.45, Аноним (46), 12:04, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Все это почти не имеет значения, если речь не про системное программирование с критическими участками, где требуется производительность именно процессора. В большинстве случаев все упирается в I/O, будь то память, шина или сеть.
     
     
  • 2.63, Аноним (61), 12:21, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Думаю, они I/O, как Вы выразились, все-таки не учитывали. :)
     
  • 2.70, FF (?), 12:27, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тогда еще хуже будет. "200 метров джава-скрипта грузит текста 300 байт"
     
  • 2.72, Аноним (59), 12:28, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Тысячи задач, где всё упирается в скорость процессора.
     
  • 2.77, FF (?), 12:31, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    процессор не обязателен, так и запишем
     
  • 2.488, Пряник (?), 10:48, 09/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, иначе разрабы умных чатовГПТ не стали бы ныть от тормозов в Python и создавать Mojo.
     

  • 1.54, Анонус (?), 12:14, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    В новости надо бы добавить уточнение, что результаты получены на

    > Timing on Apple M1 Macbook Pro

     
  • 1.58, Аноним324 (ok), 12:16, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А теперь посмотрим в рейтинг зарплат, за что готовы платить, и увидим, что никаких быстрых языков там не нужно.
     
     
  • 2.65, Витюшка (?), 12:22, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Быстрые языки много где нужны. Но там язык только инструмент. Нужна математика, алгоритмы, знание предметной области.

    Остальным хватит и однопоточного JS за глаза

     
     
  • 3.78, Аноним (447), 12:31, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Или тайпскрипт (͡° ͜ʖ ͡°)
     
     
  • 4.113, Витюшка (?), 13:21, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Или его. Шикарный язык, по сравнению с чистым JS.
     
  • 3.101, Аноним324 (ok), 12:56, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Быстрые языки много где нужны. Но там язык только инструмент. Нужна математика,
    > алгоритмы, знание предметной области.
    > Остальным хватит и однопоточного JS за глаза

    Ох люблю кекспертво в области однопоточного джаваскрипта, знания поражают. Впринципе словосочетание "однопоточный джаваскрипт" уже отражает твоё знание предмета обсуждений.

     
     
  • 4.155, Аноним (166), 15:28, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Тоже увидел данный коммент и аж бомбануло сперва. Но в итоге решил не отвечать, т.к. человек вообще не в курсе что из себя представляет js.
     
     
  • 5.165, Витюшка (?), 15:41, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Да, да, я не в курсе ECMA-262, 14th edition, June 2023 ECMAScript 174 2023 La... большой текст свёрнут, показать
     
     
  • 6.224, Вы забыли заполнить поле Name (?), 20:40, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Они путают с web workers или вот с этим https://nodejs.org/dist/latest-v20.x/docs/api/worker_threads.html, которые ни разу не треды.
     
  • 5.390, Вы забыли заполнить поле Name (?), 00:39, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Тоже увидел данный коммент и аж бомбануло сперва. Но в итоге решил
    > не отвечать, т.к. человек вообще не в курсе что из себя
    > представляет js.

    Ты бы показал пример потоков в js лучше.

     
  • 3.103, Аноним324 (ok), 12:58, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Быстрые языки много где нужны. Но там язык только инструмент. Нужна математика,
    > алгоритмы, знание предметной области.
    > Остальным хватит и однопоточного JS за глаза

    Там где нужны быстрые языки, как правило не платят денег, я сомневаюсь что разрабы какой-то йоба электроники заплатят мне 12 тысяч долларов, а вот бизнес гои, отвалят мне 12 за джаваскриптик, 15 девопсу несисадминовичу, ещё чирик менеджеру.

     
     
  • 4.117, Витюшка (?), 13:24, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А потом ты проснулся? Зарплаты посмотри на JavaScript, на Node.js. Заплатят тебе 12к$. Ну ты и мечтатель.

    Покажи эти вакансии.

    За JavaScript платят значительно меньше чем за C++. И даже за не 10к платят единицам.

     
     
  • 5.133, Аноним324 (ok), 14:00, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > А потом ты проснулся? Зарплаты посмотри на JavaScript, на Node.js. Заплатят тебе
    > 12к$. Ну ты и мечтатель.
    > Покажи эти вакансии.
    > За JavaScript платят значительно меньше чем за C++. И даже за не
    > 10к платят единицам.

    Раскажи мне как за С++ платят больше, средняя зарплата мидла на плюсах 3500, средняя мидла на джаваскрипте 4700.

     
     
  • 6.140, Витюшка (?), 14:14, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ссылки на вакансии
     
     
  • 7.143, Аноним (447), 14:20, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > средняя зарплата

    Ссылки на что? На средние вакансии?

     
  • 6.158, Аноним (166), 15:35, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > средняя зарплата мидла на плюсах 3500, средняя мидла на джаваскрипте 4700

    Справедливости ради, платят не столько за знания алгоритмов и синтаксиса js (выучить его как раз не проблема совсем), платят скорее за умение работать со стеком всей технологии. В плюсах часто даже гит знать не обязательно в 90% случаев вся работа сводится к алгоритмам и синтаксису.

     
     
  • 7.225, Вы забыли заполнить поле Name (?), 20:41, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > В плюсах часто даже гит знать не обязательно в 90% случаев вся работа сводится к алгоритмам и синтаксису.

    Покажи мне такие вакансии.

     
  • 7.363, Аноним324 (ok), 13:10, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну ещё две основные профессии связаные с плюсами, это геймдев, и ембеддед/linux kernel developer. В геймдеве работать, это себя не уважать, там платят мало, требуют много, работа сложная, ещё и хотят чтобы ты работал 48 часов в сутки. А в ембедед особо не плотят ибо это либо стартап в котором денег нет, либо завод/оборонка где деньги есть, но тебе их не дадут.
     
     
  • 8.365, Аноним (-), 13:18, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    И то не везде нужны полюсы, в той же Unity скрипты пишутся на C Теоретически ес... текст свёрнут, показать
     
     
  • 9.369, Аноним324 (ok), 13:23, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну автомотив, дроны и робототехника, это и есть те самые заводы и оборонка Туда... текст свёрнут, показать
     
  • 7.366, Аноним324 (ok), 13:19, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> средняя зарплата мидла на плюсах 3500, средняя мидла на джаваскрипте 4700
    > Справедливости ради, платят не столько за знания алгоритмов и синтаксиса js (выучить
    > его как раз не проблема совсем), платят скорее за умение работать
    > со стеком всей технологии. В плюсах часто даже гит знать не
    > обязательно в 90% случаев вся работа сводится к алгоритмам и синтаксису.

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

     
     
  • 8.425, Александр (??), 01:57, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Уверен, что нету Conan, vspkg да, пошли мы на фиг То, что их никто не привинч... текст свёрнут, показать
     
  • 5.156, Аноним (166), 15:31, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > За JavaScript платят значительно меньше чем за C++.

    Но и вакансий C++ несравнимо меньше. Плюс часто требуют диплом технического ВУЗа. У меня вообще нет диплома, но я зарабатываю почти 65к евро в год на нелюбимом всеми тут js.

     
     
  • 6.171, Витюшка (?), 15:47, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Согласен и с этим не спорю.

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

    В принципе по комментариям на opennet уровень всех этих программистов мы видим.

     
     
  • 7.226, Вы забыли заполнить поле Name (?), 20:43, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Джей Сассман с тобой согласен https://habr.com/en/articles/282986/

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

     
     
  • 8.367, Аноним324 (ok), 13:21, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Чем это отличается от того что делали технари 100 лет назад, когда изобретали ра... текст свёрнут, показать
     
     
  • 9.378, Вы забыли заполнить поле Name (?), 16:31, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ты прочитал статью полностью Похоже что нет Отличается тем, что тогда систему ... большой текст свёрнут, показать
     
  • 5.279, _kp (ok), 00:17, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Скорее на js/python много вакансий для начинающих, с соответсвующей оплатой. А на c/c++ требуются готовые профессионалы, и тоже с соотвествующей оплатой.
    Итого: вакансии и размеры зарплаты в них не совсем адекватно отображают востребованность.
     
     
  • 6.384, Аноним324 (ok), 20:58, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Скорее на js/python много вакансий для начинающих, с соответсвующей оплатой. А на
    > c/c++ требуются готовые профессионалы, и тоже с соотвествующей оплатой.
    > Итого: вакансии и размеры зарплаты в них не совсем адекватно отображают востребованность.

    Кстати наоборот, на С++ так как дефицит кадров, с большей вероятностью возьмут полного нуля, на зарплату там в 400 долларов, и он будет себе работать. Главное чтобы он читать умел, и с первого раза в рот ложкой попадал. Всё как на хайпе программирования в 2016.

     
     
  • 7.388, _kp (ok), 00:10, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/

    > Кстати наоборот, на С++ так как дефицит кадров, с большей вероятностью возьмут
    > полного нуля, на зарплату там в 400 долларов, и он будет
    > себе работать. Главное чтобы

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


     
  • 2.68, Аноним (61), 12:24, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Если не нужно результатов, то да.
     
  • 2.73, FF (?), 12:28, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > никаких быстрых языков там не нужно

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

     
  • 2.167, Аноним (166), 15:44, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > А теперь посмотрим в рейтинг зарплат, за что готовы платить, и увидим, что никаких быстрых языков там не нужно.

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

     

     ....большая нить свёрнута, показать (31)

  • 1.62, Аноним (62), 12:21, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Раст на уровне D и Явы, даже не в первой пятерке, чего собственно и следовало ожидать.
     
     
  • 2.75, Аноним (75), 12:29, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > чего собственно и следовало ожидать

    26 звёзд за 12 лет намекают что тесты мягко говоря необъективные

     
     
  • 3.310, Аноним (295), 02:05, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Уже 77. Малое число звезд ничего не говорит об объективности, скорее о популярности.
     
  • 2.97, ИмяХ (ok), 12:54, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Если правильно отсортировать график, то раст будет на 4 месте по производительности.
     
     
  • 3.311, Аноним (295), 02:05, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А если еще чуть-чуть здесь подкрутить и вон там смухлевать, вообще хорошо станет.
     
  • 2.168, Аноним (166), 15:45, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Раст и не про скорость, раст про безопастность и про удобную экосистему отвечающую современным стандартам разработки.
     
     
  • 3.177, Аноним (-), 16:36, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Не согласен.

    Можно глянуть 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
    где один сетевой драйвер писали на разных языках.

    Так что при скорости сравнимой с с++, ты получаешь еще дополнительные проверки компилятора и экосистему в подарок.

     
  • 2.199, Аноним (-), 18:23, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Как и предполагалось, после исправление косячного кода на раст, он занял заслуженное второе место.
    github.com/attractivechaos/plb2/commit/643606048476eca58ac78032386b763ca146b8ac
     
     
  • 3.227, Аноним (227), 20:43, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Заметьте, в исправлении используют итераторы, которые делают (в идеале) ОДИН раз bounds check. А не индексы, на которые жалуются многие комментаторы тут, что, мол, медленный какой. Тупо переписали на идиоматичный Раст.
     
  • 3.229, Аноним (227), 20:47, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    К сожалению, этот бенч не может показать что язык лучше других в производительности исполнения. Только то, что он не хуже других, которые рядом стоят. Да и то, этому бенчу надо уделять время .. не все это делают.
    Реальную производительность многих ЯПов мы не узнаем просто посмотрев этот сайт :(
     
  • 3.231, Аноним (231), 20:51, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Если с другой стороны смотреть, это было исправление косяков компилятора, пришлось делать работу за него.

    "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

     
     
  • 4.245, Анонин (?), 21:40, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это не было исправление косяка компилятора.
    Раст делает проверки при обращении к элементу вектора, чтобы не выйти за границы. Но это что-то стоит.
    При использовании итератора проверка делается только один раз.
     
     
  • 5.254, Аноним (231), 21:58, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Но это сделано ценой читаемости. Был наивно-простой код, как и в C. А стало:
    ...
    for (cij, &bkj) in ci.iter_mut().zip(bk)
    ...
    Даже если наивный код обложить ручными проверками, получится... читаемее, чем с такой оптимизацией.
     
     
  • 6.260, Анонин (?), 22:25, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Был наивно-простой код, как и в C

    ... но раст это как бы не си и слава богу)))

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

     
     
  • 7.312, Аноним (295), 02:08, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    То же самое и С++ касается, так что лучше выбрать его.
     
  • 7.428, Александр (??), 02:32, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Читаемость имхо не относится к знанию/не знанию языка. Читаемый язык -  это такой язык, листинг которого достаточно легко прочитать, не гугля документацию по языку. В этом плане си всё же более легко читаемый (но уступает ряду других).
     
  • 3.233, Аноним (227), 20:54, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ой вей, виноват, не прочитал новость. Это не benchmarks-game. Там всего 4 задачи, не все решены!!, а результаты уже вывесили.

    Например, для раста не написан bedcov тест. Это провал.

     

  • 1.66, Аноним (48), 12:23, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +9 +/
    Победили JavaScript, Lua, Julia, Python. Только на этих языках были решены все задачи.
     
     
  • 2.337, Аноним (337), 08:43, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Из них Julia вторая по производительности после clang, где все задаи решены.
     

  • 1.71, Витюшка (?), 12:27, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Начал учить Flutter и Dart. Язык показался на удивление приятным!

    А ещё такой производительный. Есть куда расти

     
     
  • 2.104, Аноним324 (ok), 12:59, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Начал учить Flutter и Dart. Язык показался на удивление приятным!
    > А ещё такой производительный. Есть куда расти

    Флаттер да, он приятный он как Vue.js

     
     
  • 3.169, Аноним (166), 15:46, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    vanilla js ещё приятнее
     
     
  • 4.183, Аноним (183), 17:08, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Были у нас такие адепты. Не осилили проект миллионник. Новый менеджер недавно гордился что смогли переписать 92% на TS. А JS код никто нормально не может поддерживать: перепишут если и там что-то придется править.
     
     
  • 5.207, tty0 (?), 18:45, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Может просто нанять техлида и менеджера проекта? Ну ли найти сильную команду, умеющую писать код? Миллион строчек кода на js - это средний проект. Просто 10и же большой, но наличие хорошей документации и полное покрытие тестами для js обязательно, в отличии от ts.
     
     
  • 6.255, Вы забыли заполнить поле Name (?), 21:58, 03/01/2024 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 6.258, Вы забыли заполнить поле Name (?), 22:14, 03/01/2024 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 6.276, Аноним (276), 00:05, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Миллион строчек кода на js

    Это либо твои фантазии, либо откровенный гoвнoкод. Даже сотня строк для js — это офигеть как много. Если не согласен, докажи обратное, что ты там нагoвнoкoдил на целый миллён строк.

     
     
  • 7.324, Вы забыли заполнить поле Name (?), 04:19, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> Миллион строчек кода на js
    > Это либо твои фантазии, либо откровенный гoвнoкод. Даже сотня строк для js
    > — это офигеть как много. Если не согласен, докажи обратное, что
    > ты там нагoвнoкoдил на целый миллён строк.

    Он node_modules просто посчитал. А сам он выводит "привет мир".

     
     
  • 8.512, tty0 (?), 15:22, 28/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Вот вот Если вы добавили код сторонней библиотекив проект, значит это часть код... текст свёрнут, показать
     
     
  • 9.513, Вы забыли заполнить поле Name (?), 18:13, 28/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Да никто даже код не читает, который добавляет Что уж говорить если по умолчани... текст свёрнут, показать
     

  • 1.82, Аноним (82), 12:36, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Очередной наброс на вентилятор а не тесты!
     
     
  • 2.307, Аноним (295), 01:55, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Давай свои тесты лучше.
     

  • 1.88, фнон (?), 12:41, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    В тесте явно не хватает 1С
     
     
  • 2.152, еропка (?), 15:04, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    И HTML
     
  • 2.162, commiethebeastie (ok), 15:39, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Не осилили его паршивое IDE.
     
  • 2.187, Аноним (128), 17:38, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Да Васиков всяких разных
     

  • 1.99, ИмяХ (ok), 12:55, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Как js:bun оказался на 5 месте, хотя по цифрам должен был быть на 11м?
     
     
  • 2.107, Аноним (-), 13:04, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    "А как тебе такая магия графиков, ИмяХ?" (с)
    Просто там график по nqueen + matmul.

    1. учитываются всего 2 задачи из 4х
    2. если у тебя одна супер быстрая, а вторая супер медленная (как случилось с V), то ты можешь обогнать язык, где обе задачи среднячки

    В общем тест нуждается в фиксах и улучшении, зато отлично генерирует срач

     
  • 2.221, Аноним (231), 20:31, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Сверху подписано, как отсортировано, но и без этого заметно, что 3-4 тесты не на всех языках сделаны.
     
  • 2.306, Аноним (295), 01:54, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Bun очень легкая и быстрая штука, нет тут ничего удивительного, читай внимательнее условия.
     

  • 1.108, corvuscor (ok), 13:14, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Мне вот интересны два момента.
    1. В подавляющем большинстве языков для matmul нынче используется OpenBLAS или что-то подобное, откуда там разница в разы? Свой велосипед делали?
    2. По-хорошему, раз уж это тест производительности, надо тестировать на предварительно откомпилированых программах, если таковая возможность имеется. Тогда это будут равные условия.
     
     
  • 2.115, Анонин (?), 13:23, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Да, там для каждого языка написали свой велосипед. И эти велосипеды явно разной степени кривизны.
    github.com/attractivechaos/plb2/tree/master/src

    После это пункта, второй уже не имеет никакого значения))

     
     
  • 3.164, commiethebeastie (ok), 15:41, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Мля, они про векторизацию что-нибудь слышали? Это задача из разряда кто быстрее заплывёт на дерево.
     
     
  • 4.179, Аноним (-), 16:39, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    ну...
    во-первых, это может для них сложно)
    во-вторых, оно может по разному вести себя на разных платформах (напомню что сабж делался на яблочном М1, который арм)

    а в третих, ИМХО, думаю даже такой тест может быть полезным.
    В смысле "а насколько хорошо работают оптимизации компилятора, если мне оптимизировать лениво".

     
     
  • 5.382, commiethebeastie (ok), 19:02, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > а в третих, ИМХО, думаю даже такой тест может быть полезным.
    > В смысле "а насколько хорошо работают оптимизации компилятора, если мне оптимизировать
    > лениво".

    В итоге имеем сравнение компиляции, интерпретации и JIT оптимизации :)

     
  • 2.305, Аноним (295), 01:51, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Тогда это превратится в соревнование не языков, а библиотек.
     

  • 1.153, penetrator (?), 15:17, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    да кому интересна эта херабора для проприетарной arm64-darwin??? кто-то будет оптимизировать особенно из крупных вендоров? вы себе представляете чтобы например Оракл или Майкрософт инвестировала в работу своих платформ на маке??????
     
     
  • 2.181, Аноним (183), 17:01, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Пробовали, не осилили: MS например закрыл VS для мака, а вместо переписывания офиса придумали как сделать так чтобы часть работала нативно, а часть - x86 бинарники через эмуляцию (оказалось проще чем переписать).
     
  • 2.244, Аноним (59), 21:37, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Неосиляция MS — это проблемы MS. Остальные вполне осиливают, и Oracle в том числе.
     
     
  • 3.318, _ (??), 03:48, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не болтайте ерундой! (С) :D

    Вот софт который Ларри хочет подо всё: https://www.oracle.com/database/technologies/instant-client/downloads.html
    Есть ли там голубяшка? Есть конечно, но вот ведь нюанс: Instant Client for macOS (Intel x86)
    А где же яблло-M1\M2 и иже с ними? А нетути. И не будет походу.

    От М$ вообще жёсткие анонсы были, deprecated, no longer supported, EoL-ed и прочая, то что по русски звучит коротко: НАХ!

    Закапывают мак. У нас заменили (почти) все на Lenovo + W11. Немного Ынтелёвых осталось у дизайнеров и всё. ARM-овые вообще _все_ изЪяли. Хотя при этом - iPhone и iPad - пожалуйста...
    Правда не колятся чего вдруг так резко ... типо приказ сверху и всё. Мутно, и не понятно. Лет 10 последних голубяшки прям насильно выдавали и вдруг ВНЕЗАПНА!(С)

     
     
  • 4.328, Вы забыли заполнить поле Name (?), 05:03, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Немного Ынтелёвых осталось у дизайнеров и всё.

    Дизайнеров надо пересадить на линукс и дать им гимп.

     
     
  • 5.372, Аноним (447), 14:57, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вы настолько ненавидите дизайнеров?
     
     
  • 6.377, Вы забыли заполнить поле Name (?), 16:23, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Вы настолько ненавидите дизайнеров?

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

     
     
  • 7.429, Александр (??), 02:49, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    В отличие от программиста, дизайнеры редко выходят за свою предметную область. По крайней мере в контексте: "Как сделать N на на вот этом". При появлении таких задач, они либо не будут делать N вообще, либо попросят заменить вот это. Так что развитие дизайнерских инструментов под какую-то новую платформу всё же должно исходить от программистов.
     

  • 1.154, penetrator (?), 15:22, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    в этом исследовании интересен только Swift, который родной для платформый, а он пролетает по тестам, что ожидаем, потому что софт у яблока как и гнуса - дэрмо
     
     
  • 2.304, Аноним (295), 01:50, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Зато реклама хорошая. Помните, какой хайп был вокруг Swift?
     
     
  • 3.319, _ (??), 03:55, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А на _чём_ там писать если не на Swift?
    Там тебе не форточка \ линукс - с выбором там не забалуешь :)
    У меня вся команда со старой работы ушла с Objective-C на него. Кроме одного настырного китайца :)
     
     
  • 4.407, Аноним (407), 12:46, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Вот она вся суть яблочников - выбора тебе не дают, радуйся тому что есть.
     
  • 2.361, Аноним324 (ok), 13:07, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > в этом исследовании интересен только Swift, который родной для платформый, а он
    > пролетает по тестам, что ожидаем, потому что софт у яблока как
    > и гнуса - дэрмо

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

     
     
  • 3.461, penetrator (?), 03:11, 07/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >> в этом исследовании интересен только Swift, который родной для платформый, а он
    >> пролетает по тестам, что ожидаем, потому что софт у яблока как
    >> и гнуса - дэрмо
    > И почему же софт эпла дерьмо? Откровенно лагающего софта там нет. Плюс
    > айфоны всегда имеют меньше оперативной памяти чем сопоставимые андроид телефоны, и
    > один и тот же софт, на айфоне с 4 гигами оперативной
    > памяти не тормозит, а на андроиде с 4 гигами тормозит. Как
    > так? Ах да потому что меркам гугла, телефон в котором меньше
    > 64 гигов оперативной памяти обязан лагать, так прям в гайдлайнах написано.

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

     
  • 3.462, penetrator (?), 03:17, 07/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    действительно качество софта определяется какими-то мифическими лагами, которых ... большой текст свёрнут, показать
     
     
  • 4.471, Аноним324 (ok), 19:16, 07/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    У эпла всё реализовано как настоящего комерческого юникса. Те это то к чему стремятся линукс-макаkи.
     
     
  • 5.485, penetrator (?), 21:03, 08/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > У эпла всё реализовано как настоящего комерческого юникса. Те это то к
    > чему стремятся линукс-макаkи.

    ты главное не переставай верить в это )))

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

     
     
  • 6.492, Аноним324 (ok), 17:50, 09/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Линукс ещё хуже. Он собрал в себе все самые плохие практики, которые только можно представить.
     
     
  • 7.493, penetrator (?), 03:10, 10/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Линукс ещё хуже. Он собрал в себе все самые плохие практики, которые
    > только можно представить.

    у тебя бурная фантазия, клинически бурная

     

  • 1.180, Аноним (183), 16:58, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    В цикле просто создаём временный массив и удивляемся что GC где-то заработал... https://github.com/attractivechaos/plb2/blob/master/src/csharp/sudoku.cs#L88 - это то что сразу видно. В общем код не прошёл ревью...
     
     
  • 2.185, Аноним (-), 17:26, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это просто какой-то позор /_- (с)
    Неужели они это пилили с 2011 года.
     
     
  • 3.196, Аноним (61), 18:18, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Посмотрите, наконец, нормальный код*.

    *На указанном ресурсе его нет.

     

  • 1.195, Аноним (61), 18:16, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Все интенсивные вычисления делать на С. Таким образом, остальные языки выполняют только роль интерфейса, и смысл рейтинга теряется.
     
     
  • 2.213, Анонин (?), 19:03, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Скорее си выполняет роль интерфейса FFI для всех остальных языков.
     

  • 1.200, Аноним (-), 18:27, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кто-то из зарегистрированных может попросить автора исправить новость?
    После изменений расстановка сил немного поменялась

    github.com/attractivechaos/plb2
    github.com/attractivechaos/plb2/blob/master/analysis/rst-m1.png

     
     
  • 2.212, Анонин (?), 19:00, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Там расстановки сил меняется каждые пять минут. Так что лучше подождать.
     
  • 2.303, Аноним (295), 01:48, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем исправлять новость? Результаты чем-то не устраивают?
     

  • 1.201, Tron is Whistling (?), 18:29, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    arm64-darwin?
    Давай, до свидания.
     
  • 1.205, Анонн (?), 18:41, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    В общем, как и предполагалось, часть тестов были неоптимальны.
    После минорных правок в кодах, раст занял заслуженное второе место, с минимальными расхождением с Си.
    Третье место занял 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 ____ ____

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

     
     
  • 2.210, Анонн (?), 18:50, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    UPD: пока писал это сообщение в репу прилетел фикс для V (eb9ee89) и теперь он обходит все языки, даже Си.
    V 2.57 0.56
    Поэтому можно запастись попкорном и смотреть как компилируемые языки приближаются к некому "идеальному времени выполнения". Как собственно и предполагалось в 1.34.
     
  • 2.239, Аноньимъ (ok), 21:21, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Там небось на сишке код без минимальных проверок.
     
     
  • 3.246, Аноним (-), 21:41, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А типа в продакшене кто-то будет беспокоиться о проверках?
    СИ это же про скорость, а не про корректность работы.
    Подумаешь будет CVE, ну так потомки ее найдут, лет через 10.
     
     
  • 4.274, Аноньимъ (ok), 23:55, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • –6 +/
    На самом деле даже не про скорость.
    Разве что про скорость отрыгивания кода.
     
     
  • 5.322, _ (??), 04:08, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Чем в написании драйверов и прочей in-kernel чешуи тебя не устроил "С" ?! И чем ты его там заменишь? ( скажи ещё - растом :-) )
    А понял - ты его вместо 1С решил применить и тебя за это били ногами ... ну дык эта ... поделом! :-D

    C is high-level assembly language (C) ТЧК!

     
     
  • 6.327, Вы забыли заполнить поле Name (?), 05:01, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Чем в написании драйверов и прочей in-kernel чешуи тебя не устроил "С"
    > ?! И чем ты его там заменишь? ( скажи ещё -
    > растом :-) )
    > А понял - ты его вместо 1С решил применить и тебя за
    > это били ногами ... ну дык эта ... поделом! :-D
    > C is high-level assembly language (C) ТЧК!

    Что ты хочешь от человека, который пишет на c#?

     
     
  • 7.353, Аноньимъ (ok), 11:39, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Сишарписты хотя бы освоили секретную технику проверки указателя на null перед использованием.
    И на фоне сишных дидов это чуть ли не чудо цивилизации.
     
  • 6.352, Аноньимъ (ok), 11:37, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > C is high-level assembly language (C) ТЧК!

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

    > Чем в написании драйверов и прочей in-kernel чешуи тебя не устроил "С" ?!

    Кроме инта неопределённого размера?

    > И чем ты его там заменишь?

    Да Боже Мой! С десяток отличных замен существует.

    > там

    Для начала хорошо бы из этого вашего "там" изгнать сишку с её интерфейсами, *void, и каллинг конвектион.

     
     
  • 7.431, Александр (??), 03:04, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Сишечка как раз и создавалась под неопределённый процессор. От сюда кстати и инт неопределённого размера, ибо в те времена крайне весёлые товарищи встречались (в смысле ОС).
    Когда вопросы размерностей утряслись там вполне появились знакомые всем размерные инты. Достаточно подключить stdint.h.

    > каллинг конвектион

    Тут достаточно винду изгнать с её 100500 разных ABI.

     
     
  • 8.473, Аноньимъ (ok), 19:45, 07/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Под DEC она создавалась, и риски как таковые А почему куда и от куда эти риски ... текст свёрнут, показать
     
  • 7.432, Александр (??), 03:07, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Что касается интерфейсов, если имеется в виду POSIX, то изгоняй-не изгоняй: он сейчас везде.
     
  • 7.436, _ (??), 08:06, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Интересное имя или это профессия Му-ха-ха Тогда почему оно есть подо всё... большой текст свёрнут, показать
     
     
  • 8.472, Аноньимъ (ok), 19:24, 07/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Виндовс на сях Ох уж эти сказочки, ох уж эти сказочники ... текст свёрнут, показать
     
  • 2.302, Аноним (295), 01:46, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >После минорных правок в кодах, раст занял заслуженное второе место, с минимальными расхождением с Си.

    Уже третье, остальные языки тоже оптимизировать начали :)

     
     
  • 3.402, Cucumber (?), 08:51, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Уже первое
     
     
  • 4.406, Аноним (407), 12:44, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Очевидно, все еще много раз поменяется.
     
  • 2.315, Аноним (315), 02:17, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    все эти тесты не стоят выеденого яйца. хочешь узнать реальное положение дел - всегда пиши свои
     

  • 1.217, Аноним (-), 19:54, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Джулия вышла на 7 место, а в теме про этот ЯП спрашивали "зачем оно нужно?".
    А вот зачем - она в nqueen она всего на ~30% хуже СИ (3.47 против 2.70)
    И я уверен что остальные задачи тоже можно улучшить.

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

     
     
  • 2.301, Аноним (295), 01:45, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    И система типов пожалуй самая сбалансированная.
     
  • 2.313, Аноним (315), 02:15, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    кому нужны твои математические задачки без практического применения
     
  • 2.356, Аноним (231), 12:16, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Я тоже про неё вспомнил. Только наоборот - зачем она нужна, если она ближе к 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".

     

  • 1.237, Аноньимъ (ok), 21:19, 03/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Бредово - мы сделали кривой тест с отфонарной реализацией алгоритмов, и не смутившись бредовым результатом выложили.

    Потом 3 раза переделывали )))

    А где Хаскель, Ада, Фортран?

    Жулия с нативными матрицами где-то в конце?

    C# хоть первые пару прогонов тестов не считали? Которые до отработки джита?

     
     
  • 2.242, Аноним (-), 21:35, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Не... тут еще круче
    В 2011 мы сделали первую версию супер тестов.
    А спустя 12-13 лет выложили вторую, причем настолько кособокую.
    Возможно автору нравятся публичные унижения))
     
     
  • 3.280, Аноним (231), 00:31, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    И все же я хочу спросить — кто написал двенадцать пулл-реквестов? Всё верно он сделал, сейчас по принципу "в интернете кто-то неправ" сагрятся и допилят.
     
     
  • 4.347, Аноним (231), 10:03, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > двенадцать пулл-реквестов

    Уже 23.
    https://github.com/attractivechaos/plb2/pulls

     
  • 4.358, Аноним (-), 12:38, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > И все же я хочу спросить — кто написал двенадцать пулл-реквестов? Всё
    > верно он сделал, сейчас по принципу "в интернете кто-то неправ" сагрятся и допилят.

    Возможно, но идея opennet.ru/openforum/vsluhforumID3/132476.html#29 была хороша)


     
  • 2.323, _ (??), 04:10, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >Бредово

    Вот полностью согласен! Даже осуждать нечего. Но ведь будут :(

     

  • 1.314, Аноним (295), 02:16, 04/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >После оптимизации кода на языке V, данный язык показал лучшие результаты в рейтинге.

    Вот кстати темная лошадка из новых интересных языков.

    >V lang обладает простым синтаксисом, быстрой компиляцией, высокой производительностью и безопасностью. Он не имеет скрытого управления потоком, скрытых выделений памяти, препроцессора и макросов.
    >V поддерживает автоматический перевод C => V.
    >V может генерировать нативный код напрямую.
    >V предлагает отличную производительность на уровне с C и нулевую стоимость взаимодействия с C13.
    >V может использоваться для расширения существующих программ на C/C++14.

     
     
  • 2.354, Аноньимъ (ok), 11:42, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • –4 +/
    >V может использоваться для расширения существующих программ на C/C++14.

    Очередная нескушная сишка.

    >из новых интересных языков

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

     
     
  • 3.357, Аноним (-), 12:28, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ты когда меняешь жигулятор на современную тачку, тоже бухтишь очередная нескучн... большой текст свёрнут, показать
     
     
  • 4.375, Аноньимъ (ok), 15:47, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Монады - это банальная вещь Как только нужно работать с IO сложнее хеллоу ворда... большой текст свёрнут, показать
     
     
  • 5.401, Аноним (401), 08:18, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А реально не нужен только Хаскель и его функциональная братия. Натурально вывих мозгов ради ачивки «мам, навука!».
     
     
  • 6.404, Аноньимъ (ok), 11:24, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > А реально не нужен только Хаскель и его функциональная братия. Натурально вывих
    > мозгов ради ачивки «мам, навука!».
    > Вот кстати темная лошадка из новых интересных языков.
    > ради ачивки «мам, навука!».

    Вот я иговорю, интересных языков и так навалом.

    > функциональная братия

    Функциональщина сейчас везде.

    > Натурально вывих мозгов

    И зачем нам преподают математику, блииин сложна, оно мне ненужно, я буду слесарем зачем нам математика?
    Ууууу вы ви х м о з г о в очень сложнааааааа111(((((

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

     
     
  • 7.405, Аноним (-), 11:51, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Отдельные функции и подходы, типа reduce map И в общем-то все Ну назови-ка, кр... большой текст свёрнут, показать
     
     
  • 8.409, Аноньимъ (ok), 13:36, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Вы прикалываетесь Вперёд гугл крупные опенсорс проекты JS Кто хвастается, эти л... текст свёрнут, показать
     
  • 8.410, Аноньимъ (ok), 13:38, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Вы, сейчас один, сидите запертый в комнате, в трусах, и фантазируете о некой общ... текст свёрнут, показать
     
  • 8.437, _ (??), 08:18, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Конкурент этого сайта - LOR Scala 32 8 - считается ... текст свёрнут, показать
     

     ....большая нить свёрнута, показать (9)

  • 1.343, Аноним (343), 09:18, 04/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Да не будет скоро никаких "20 языков" !!!  Учитывая какие изменения вводятся в КАЖДЫЙ  язык и насколько они идентичны !!!  понятно что язык скоро будет ОДИН ! тот на котором ИИ будет писать, а кожаным придётся подстраиваться под эту лапшу :(
     
  • 1.348, Аноним (348), 10:29, 04/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Ruby обогнал CPython. Поверить не могу.
     
  • 1.374, Аноним (374), 15:34, 04/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    В языке программирования главное то, что он язык - для людей. И только потом производительность. При этом разумеется хочется максимальную производительность, но только после удобства самого языка.

    Что касается этих «типовых» тестов - они нифига не типовые. В реальном мире ваще не это нужно. В реальном мире нужно удобство подключения библиотек, удобная сборка, хорошие сообщения об ошибках, безопасность, креши, концепции упрощающие переиспользование кода - трейты, классы, енумы, аннотации, макросы, асинк/авейт и так далее; поддержка IDE, хорошая документация, друэелюбное сообщество.

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

     
     
  • 2.439, _ (??), 08:25, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >В языке программирования главное то, что он язык - для людей. И только потом производительность.

    Знал бы ты сколько ЯП созданных под этим флагом гниёт на обочине ...
    Но не все: ряба, пейстон и жЫЭс таки пока живут - видимо чего-то в них есть что народ "цепляет" :)

    >В реальном мире ваще не это нужно. В реальном мире нужно [...]

    розовое сено для говорящих пони. Без этого всё тобой перечисленное - "ваще не это нужно".
    Ж:-D

     
  • 2.511, bOOster (ok), 07:20, 15/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > то вы и на асме вставки сделаете.

    Ну да, ну да. На Асме. А ниче что это весьма проблематично с популяризацией в общем сегменте ARM64, RISC V не говоря уж и о том что и PowerPC и MIPS до сих пор живут в таких узких сегментах как принтеры, роутеры и т.п.. Забодаешься под все архитектура АСМ использовать для какой нибудь общей библиотеки - для примера.

     

  • 1.386, Аноним (386), 23:55, 04/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А теперь надо посчитать реальную стоимость языков программирования для бизнеса в единицах иизмерения "доллар на час разработки".
     
     
  • 2.424, Ivan7 (ok), 01:51, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > А теперь надо посчитать реальную стоимость языков программирования для бизнеса в единицах измерения "доллар на час разработки".

    Это сильно зависит от опыта и квалификации программиста на конкретном языке, от широты применения языка, качества и количества библиотек и стороннего кода на каждом языке и множества других факторов, а также, разумеется, от решаемой задачи. Например, писать логику сайтов на С++, наверно, не очень умно, так же как писать высокопроизводительный код на JavaScript, Perl, Python, Ruby и т.д.

     
     
  • 3.491, Аноним (491), 12:59, 09/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > писать логику сайтов на С++, наверно, не очень умно

    Смотря каких сайтов. Библиотеки на C++ для сайтов есть и некоторые весьма успешны.

     

  • 1.440, Аноним (228), 08:59, 06/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    C, Rust, Nim. Всё, расходимся

    https://github.com/attractivechaos/plb2/blob/master/analysis/rst-m1.png

     
     
  • 2.475, Аноним (475), 14:15, 08/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Еще Julia приятно удивила, пятое место для несистемного языка совсем неплохо.
     

  • 1.441, GSG (?), 09:53, 06/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Конечно, если ни Паскаль, ни Фортран не рассматривать... :-)
     
     
  • 2.490, Аноним (491), 12:55, 09/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, Оберон туда же
     

  • 1.505, Аноним (505), 19:13, 11/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    24-я версия графиков:

    C, Rust, Nim

    https://i.ibb.co/9qw28cb/template.png?v24

     
  • 1.510, bOOster (ok), 07:11, 15/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Дополнение 1: В реализации на языках Rust, D и Julia внесены исправления, которые позволили Rust занять второе место, D - третье, Julia - 7 (вместо 16).

    Теперь на этой версии Rust не работает ничего кроме этого теста, и растоманы очередной раз планируют менять архитектуру языка :))) facepalm

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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