Comments 30
вы показали классный пример, помню как я за бенниБокс повторял это на свинге ), чтобы отрисовать летящие точки
на LWJGL3(там все пакеты настроены на яве) там была бы 1 частица ) просто по вектору позиций идём кидаем трансформы и рисуем цвета(еще пред фишку показал синк матрикс стартуем с 2д и далее просто ставим координаты) - это пред инстансинг по сути тот же инстанс, но снаружи
еще можно попробовать в дополнении к векторизации собрать билд через graalvm
просто javafx например на фрибсд нету, и грааля тоже
и какое-нибудь дерево бинарное например BVH и всё что можно докинуть на минмакс -аабб я только тестил
кесарю кесарево, java - это энтерпрайз, там она хороша и никакой раст там не нужен. Попробуйте налабать на расте какой нибудь банковский проект и сравните насколько позже вы выкатите mvp по сравнению с java
возможно, никому кроме автора не интересно выполнять GPU задачи на CPU в "классической" библиотеке для рисования кнопачек, ну или и в самом деле .parallel() тут не к месту употреблен и нерфит перформанс в разделении огромной динамической коллекции с неконстантной скоростью доступа. А какие потоки там были использованы, может все считалось на одном ядре виртуальными? А может jdk в макоси на проприетарном арм в simd что-то делает не совсем оптимально? Если бы мы это знали, но мы этого не знаем.. Поэтому психически здоровые люди проверяют на разных платформах/библиотеках эквивалентный код, а не вот это вот все. Ну или они доводят расследование до конца показывая откуда велось нападение. Неужели было настолько стыдно показать код на раст?
Parallel на каждый чанк ведь, то-есть на четыре точки - ну очень странное решение. "Даже хуже - ошибка!" Надо было точки на CPU_COUNT поделить, конечно, и и это параллелить, а чанки уже внутри cpu. Ну и сообще сравнить с однопоточной схемой - она может оказаться и быстрее чем то, что есть, с микротасками.
интересно, что он не приводя детальных метрик все таки сделал противоречащий здравому смыслу вывод о более быстром относительно хипа нативном выделении памяти. Возможно он все таки использовал compile time массивы фиксированного размера в раст и динамические в джаве? Вообще, это похоже на проекционное мнение про "закостеленый" ооп дизайн супротив "прогрессивного" процедурного кода языка без классов. Или я просто :sarcasm там не разглядел?
Одна из важных претензий к быстроте Java / C# это время старта приложения. Значительное время занимает загрузка runtime и jit-компиляция. В статье про это ни слова, а ведь это живые деньги например в serverless.
ну какое значительное? если у вас такая программа из трех классов то то на современном железе это несколько сот миллисекунд (я про java говорю, про .net не знаю ничего). медленный старт больших серверов связан с активным сканирование классов, поиском метаданных и динамической кодогенерацией, а если у вас простая консольная программа то тут более-менее быстро. ну и нужно подождать 20к вызовов метода для сбора статистики чтоб эффективно и агрессивно его скомпилировать
А как же aot
C# так уж точно быстро стартует, если не иметь тысячи классов в главном модуле (сборке с точкой входа). Да не сравнится с asm/c/c++, возможно и растом.. Но написать приложение на шарпе в разы быстрее чем на них)
+с нета 8 или 9 работает Native AOT компиляция, там разрыв еще меньше, только весит больше
Интересно какая разница в потреблении памяти?
Сравнивать специфические оптимизации на редком в области вычислений процессоре это конечно сектор-приз. Множит смысл статьи на ноль.
в этом и есть смысл java - пишешь 1 раз а оно дальше оптимально выполняется на конкретном железе где вы запускаете. точно так же сейчас активно в нее внедряют gpu вычисления чтоб не слишком сильно переживать что у вас там за железка будет стоять в серверной. ваша позиция и ей подобные в чем-то забавные, они звучат примерно так: java это отстой, потому что там vm тянется, нужно время на ее старт + еще память для нее, не то что наши компактные быстрые нативные программы, а когда эта vm генерирует целевой оптимизированный код потому что она знает на чем запущена и еще реальный профиль выполнения на конкретных данных то это не, это уже жульничество ;)
дальше оптимально
Откуда такие данные про оптимизацию на Эппл М1 ?
Сколько я баек наслушался от дотнетчиков, что джит в процессе исполнения переоптимизирует 10 раз под идеальный код. Только ни один свои слова не подтвердил.
А так да, любой язык с GC умножает потребление памяти примерно на 2.
а любой язык без gc умножает затраты на 2 и во столько же риск инсульта у разработчиков ;) я с .net не знаком и на сколько знаю vm у него сильно проще чем у java (и это еще надо учесть что в java 2 vm с разными компиляторами, та что graalvm бывает и в 2 раза ускоряет программы просто за счет более умного-нового jit). разница не только в том что vm знает железо но и еще знает данные над которыми работает алгоритм (это часто даже важнее), разница легко вычисляется и в java и нативных языках, в java вы можете скомандовать компилировать код без учета профиля выполнения - не ждать 20 тысяч вызовов и компилировать раньше, сразу, примерно так как это делает ваш c++ компилятор и разница по горячим методам там будет в разы если не 10 раз для некоторых участков. И нативные языки на сколько знаю имеют режим сборки профиля на тестовых данных-прогонах и учет их при финальном билде, вроде это может дать 30% (если не путаю ff так билдят и там профиль дает такой прирост). Так что тут не то что вам должен кто-то подтвердить, а вы сами должны взять и посмотреть.
Блаженны верующие.
А у нас тут технический ресурс.
вы опять про веру и то, что вам должны что-то доказать и показать, я ж сказал, есть тесты, их демонстрировали на одной из java конф в контексте ускорения старта приложения, мол почему лучше все же немного подождать и дать vm собрать статистику по выполнению кода, 20 тысяч дефолтных итераций. был пример когда через vm опции вместо 20 тысяч ставили меньше и бенчмарки сразу заметно проседали. Вы сейчас пытаетесь оспорить основы
Это действительно байки, поскольку режима у ленивой компиляции в .Net всего два.
RuyJiT собирает метод максимально быстро и пытается его оптимизировать, если считает его важным (обычно один раз!). При этом при такой рекомпиляции могут возникать проблемы всех цветов и оттенков. Например при функциях с узкими циклами компилятор выполняет OSR (on-stack replacement), т.е. компилирует две версии функции и выполняет jump из одного в другую прямо во время его выполнения. Технология то крутая! Но она не поддерживает PGO и получается комическая ситуация, где метод с циклом в 5000 итераций выделяет массив на стеке, а на 50000 итераций массив выделяется на куче, поскольку OSR сломала escape-analysis, который часть PGO.
Сейчас многие подобные угловые случаи активно чинятся и команда .Net выкатывает больше оптимизаций, чем любой другой язык в последнее время, но текущие решения очень далеки от идеального кода, изредка даже от Джавы.
И это в пределах x86, сборки под ARM известно менее оптимальны (хотя и неплохие), а вот RISC-V это тихий ужас, лишённый даже базовых оптимизаций.
Так что в целом ты вы правы, но винить GC стоит не всегда. Java и C# оба умеют аллоцировать классы и коллекции на стеке, а в .NET и вовсе можно написать функциональный код без единого вызова GC, главное захотеть
Также в шарпе уже несколько лет как есть кучи оптимизаций в сторону натива (NativeMemory, NativeLibrary, улучшенный PInvoke, Aot и прочие прелести).
GC вообще спаситель во многих случаях, но в некоторых ситуациях - любители бдсм чистого си и плюсов правы, он может что-то не так сделать
В оригинальном каменте речь шла про джаву, виртуальная машина которой действительно может перекомпилировать метод несколько раз, если посчитает нужным. В виртуальную машину(ы) джавы вбухано нереальное количество времени и оптимизаций и этот процесс продолжается, дотнет только-только начал шевелится в этом направлении.
Java никогда не был хайпом девяностых.
Он был хайпом нулевых.
Учим историю прежде чем писать такие глупости.
Зы. Это пишет человек который познакомилсч с этим языком, когда приложеньица запускалась в боакзере Netsacpe в Freebsd в аиде applets
первая JavaONE - это 1996
Припоминаю я свою первую конференцию JavaONE. Первая продажа акций Netscape в августе 1995-го взбудоражила мир до лихорадки из-за сети Интернет. Java была представлена как способ разработки программ для сети Интернет. Удивительно как много было разработчиков Windows на первой и второй конференциях JavaONE. Выглядело это скорее как конференция по Windows-OS/2 минувших дней. Казалось, что я там всех знаю. Чувствовал себя как дома. На самом деле, я смекал из-за чего мы были там. Интернет был платформой «используемой всеми, не принадлежащей никому». Он также стал приютом для сообществ открытого ПО (OSS).
Напряженность между OSS разработчиками и Sun заметно ощущалась. Мы — виндузятники — смотрели на это с изумлением. Сообщества открытого ПО боялись, что Java была троянским конём, придуманным Sun, дабы завладеть сферой ПО для Интернет. Это как раз то, что случилось с разработчиками Windows и объясняло, с чего мы собрались на JavaONE. Целыми толпами.
"Хайп" не может длиться 30 лет
А почему это в хабах Kotlin и Ruby? Ладно ещё Котлин, там можно завести Swing, но Руби...
Java — язык, который все любят хейтить. Уже давно за ним закрепилась репутация застоявшегося, неповоротливого, раздутого монстра
Вы не путаете Java и Spring?
Зачем эта непонятная константа 1000 / 60? Не лучше ли просто написать явно, указав в комменте, что это, например, в герцах?
Такой подход позволяет выходить за пределы 60 FPS
Может, не выходить?
Про кучу не понял. Я не изучал внимательно весь код, но где там работа с кучей в цикле? Если она явная, то можно же вынести за цикл и переиспользовать?
А вообще, в данном коде все локальные переменые простые. А если работать с мелкими составными объектами, то всё, опять куча. Поэтому без танцев с бубном красивый вычислительный алгоритм часто на Джаве не напишешь.
предпочёл использовать библиотеку
wget https://repo1.maven.org/maven2/[...].jar && [...]
Java медленная, и это хорошо.
Тут как-то был челлендж: обработать файл с миллиардом записей. Вот ссылка на ютуб: https://youtu.be/_w4-BqeeC0k?si=73agjjRk5XtEx7HS
Java укатала всех, включая C. Менее 2 секунд! Понятно, что там глубокая оптимизация. И unsafe, и SIMD, и SWAR, и прочие зверушки... Так что, как серверная экосистема, я считаю, эта одна из лучших.
Насколько Java быстрая?