А с производительностью кода всё так же плохо?
Взя...
# russiana
aleksey.tomin
08/25/2020, 9:27 AMА с производительностью кода всё так же плохо?
Взял ради забавы математический тестик - https://github.com/Mark-Kovalyov/CardRaytracerBenchmark/blob/master/java/CardRaytracer.java
Удалил оттуда всё IO, конвертировал в kotlin и получил (макбук-про 15го года) 5m52.234s вместо 0m22.359s для java/JDK14
В 16 раз дольше это перебор, на мой взгляд.
Или код плохой? https://github.com/alekseytomin/CardRaytracerBenchmark/blob/kotlin-native/kotlin-native/src/nativeMain/kotlin/app.kt
g
gildor
08/25/2020, 9:32 AMна какой платформе?
gildor
08/25/2020, 9:33 AMааа вижу, это kotlin/native, ну так то ожидаемо конечяно, но да, 16 раз выглядит не очень, надо видимо мерить подробней
a
altavir
08/25/2020, 11:39 AMНа нативе своя специфика и код из JVM нельзя туда напряму транслировать и ожидать той же производительности.
altavir
08/25/2020, 11:40 AMПосмотрите в первую очередь боксинг и те места, где эскейп-анализ нужен
a
aleksey.tomin
08/25/2020, 11:40 AMНу там чистая математика...
a
altavir
08/25/2020, 11:40 AMПлюс на JDK14 работает авто-векторизация. Попробуйте на старых JDK
a
aleksey.tomin
08/25/2020, 11:46 AMДа там и на java-то написано так себе- без прогрева 🙂
На 8ке 24с работает
a
altavir
08/25/2020, 11:47 AMну то есть оно и не векторизуется.
altavir
08/25/2020, 11:48 AMНу вот такие вещи вообще нельзя делать в нативе: https://github.com/Mark-Kovalyov/CardRaytracerBenchmark/blob/e951e091b2ec87f7621a08eae7d6defdf63accb0/java/CardRaytracer.java#L142
altavir
08/25/2020, 11:49 AMТам лишняя аллокация вообще низачем. В JVM оно скаляризуется, а вот в нейтиве вряд ли
a
aleksey.tomin
08/25/2020, 12:11 PMДа, одно это сильно улучшило ситуацию: 3m45.265s
a
altavir
08/25/2020, 12:12 PMНу это то, что мне в глаза сразу бросилось при беглом просмотре, я уверен, что там еще куча мест.
a
aleksey.tomin
08/25/2020, 12:14 PMВозможно.
Кстати, что-то вроде в 1.4 с памятью поправили -типа по-другому можно выделять. Надо будет найти...
a
altavir
08/25/2020, 12:15 PMЭто не спасет. Тут просто лишняя аллокация. Как не выделяй. Такие вещи убираются только при помощи продвинутого escape analysis. Его просто нет в нативных компиляторах.
a
aleksey.tomin
08/25/2020, 12:19 PMЯ убрал.
Есть
-Xallocator=mimallocaleksey.tomin
08/25/2020, 12:57 PMО, теперь 1m26s - уже в 3 раза разница 🙂
Притом, что скорость никто не обещал - результат нормальный
a
altavir
08/25/2020, 2:12 PMНу там надо ручками код посмотреть и клонировать скорее не джавовую реализацию, а сишную. Тогда производительность будет какая надо
altavir
08/25/2020, 2:12 PMМы просто все очень ленивые после JVM
t
thevery
08/27/2020, 3:48 PM@altavir как будто это^ что-то плохое)
a
aleksey.tomin
08/27/2020, 3:55 PMМы просто все очень ленивые после JVMЭто не лень. Это просто уверенность в инструменте. Когда имеешь дело с С - постоянно как по минному полю идёшь. Один неверный шаг- и сообщение об ошибке разбудит ктулху 👹
a
altavir
08/27/2020, 4:27 PMНу вот в K-N такого не будет, но по перформансу легко провалиться
t
thevery
08/27/2020, 4:32 PMВ kn не только это, но ещё и модель памяти стреляет на каждом шагу
a
altavir
08/27/2020, 4:33 PMПример в студию пожалуйста. В кого она стреляет и что это за шаги. Насколько я знаю, там только одно такое место
t
thevery
08/27/2020, 4:34 PMMutabilityException и фризинг же
thevery
08/27/2020, 4:34 PMПонятно что это не для математики, а для приложений, но проще не становится
thevery
08/27/2020, 4:35 PM@altavir да где угодно можно поймать, собственно обещали уже сделать LAX-модель, чтобы можно было нормально код писать сразу и под native
a
aleksey.tomin
08/27/2020, 4:39 PM@thevery MutabilityException это как?
Но вообще текущая модель памяти в native заточена под immutable. Реализация многопоточной очереди доставила мне немало весёлых минут, и то- сделал я весьма неоптимально 🙂
t
thevery
08/27/2020, 4:40 PMa
altavir
08/27/2020, 4:40 PMМногопоточная очередь реализуется каналом и не надо там городить что-то свое. А ошибка возникает в основном когда используется глобальный стейт или сингетон со стейтом
altavir
08/27/2020, 4:41 PMСобтсвенно конкуррентой модификации объектов не должно быть и в JVM, но там есть шанс, что вас виртуальная машина спасет.
t
thevery
08/27/2020, 4:42 PMКаналы не решают проблему фризов
a
aleksey.tomin
08/27/2020, 4:42 PMМногопоточная очередь реализуется каналомhttps://kotlinlang.org/docs/reference/coroutines/channels.html - это?
a
altavir
08/27/2020, 4:42 PMда
👍 1
t
thevery
08/27/2020, 4:45 PMСобственно даже в корутинах есть проблемы из-за memory model
a
altavir
08/27/2020, 4:46 PMЕсть и поэтому там добавляют релакс-модель. Но в целом та модель, что есть - хороша.
altavir
08/27/2020, 4:46 PMСобственно вариант, когда релакс модель только внутри корутин я считаю идеальным.
t
thevery
08/27/2020, 4:47 PMImmutable - это хорошо, а вот freeze - это плохо
a
altavir
08/27/2020, 4:47 PMА как одно без другого существовать должно?
t
thevery
08/27/2020, 4:49 PMУточню - проблема freeze в заморозке всего окружения, вместо одного объекта.
a
altavir
08/27/2020, 4:49 PMну придумайте как сделать лучше.
t
thevery
08/27/2020, 4:50 PMНу есть detach или как там его, только это дико неудобно
thevery
08/27/2020, 4:51 PMИ я жду lax всё же
a
altavir
08/27/2020, 4:51 PMОт сюда мораль, не должно быть изменяемых состояний в многопоточности вообще. Все операции через корутины. Многопоточность - это сложно.
t
thevery
08/27/2020, 4:52 PMКорутины - это отдельная боль. А если двигаться к "как правильно" вместо "как удобно", можно и до скалы докатиться
➕ 1
thevery
08/27/2020, 4:54 PMОпять же типичный kmm вообще плохо заточен под отсутствие многопоточности (при этом у него нет проблемы с полезной немутабельностью в целом, проблема только во фризах)
➕ 1
2 Views