https://kotlinlang.org logo
#russian
Title
# russian
a

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
на какой платформе?
ааа вижу, это kotlin/native, ну так то ожидаемо конечяно, но да, 16 раз выглядит не очень, надо видимо мерить подробней
a

altavir

08/25/2020, 11:39 AM
На нативе своя специфика и код из JVM нельзя туда напряму транслировать и ожидать той же производительности.
Посмотрите в первую очередь боксинг и те места, где эскейп-анализ нужен
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
ну то есть оно и не векторизуется.
Ну вот такие вещи вообще нельзя делать в нативе: https://github.com/Mark-Kovalyov/CardRaytracerBenchmark/blob/e951e091b2ec87f7621a08eae7d6defdf63accb0/java/CardRaytracer.java#L142
Там лишняя аллокация вообще низачем. В 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=mimalloc
но непонятно, куда это писать
О, теперь 1m26s - уже в 3 раза разница 🙂 Притом, что скорость никто не обещал - результат нормальный
a

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 PM
MutabilityException и фризинг же
Понятно что это не для математики, а для приложений, но проще не становится
@altavir да где угодно можно поймать, собственно обещали уже сделать LAX-модель, чтобы можно было нормально код писать сразу и под native
a

aleksey.tomin

08/27/2020, 4:39 PM
@thevery MutabilityException это как? Но вообще текущая модель памяти в native заточена под immutable. Реализация многопоточной очереди доставила мне немало весёлых минут, и то- сделал я весьма неоптимально 🙂
a

altavir

08/27/2020, 4:40 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
Есть и поэтому там добавляют релакс-модель. Но в целом та модель, что есть - хороша.
Собственно вариант, когда релакс модель только внутри корутин я считаю идеальным.
t

thevery

08/27/2020, 4:47 PM
Immutable - это хорошо, а вот 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 или как там его, только это дико неудобно
И я жду lax всё же
a

altavir

08/27/2020, 4:51 PM
От сюда мораль, не должно быть изменяемых состояний в многопоточности вообще. Все операции через корутины. Многопоточность - это сложно.
t

thevery

08/27/2020, 4:52 PM
Корутины - это отдельная боль. А если двигаться к "как правильно" вместо "как удобно", можно и до скалы докатиться
1
Опять же типичный kmm вообще плохо заточен под отсутствие многопоточности (при этом у него нет проблемы с полезной немутабельностью в целом, проблема только во фризах)
1
2 Views