e
Поэтому стандартный код от джавистов там не запуститься. А вот скала тру-хардкор-ФП идёт там на ура сразу же
🤔🤔🤔
Size: a a a
2020 June 11
DS
Я так запускал дотти + котоэффекты и т.п. на граале, запустилось с первой попытки.
DS
Но да, там в коде 0 рефлексии
e
а бенчил?
DS
а бенчил?
Я бенчил только по памяти, потому что это proof-of-concept по этому поводу. По потреблению памяти выиграл очень много.
t
Вот им и нужен грааль-аот. Он аот компилирует приложения под JVM в приличный нативный код.
И при этом, в отличие от всяких scala, kotlin native ещё и имеет человеческий сборщик мусора, что очень важно.
И при этом, в отличие от всяких scala, kotlin native ещё и имеет человеческий сборщик мусора, что очень важно.
вы хотите сказать, что на этом можно запустить сервер minecraft, не продав амазону почки?
DS
Т.е. 20-40 Мб вместо сотен у полноценной JVM
e
блин хочу доклад найти.. эээхз
DS
вы хотите сказать, что на этом можно запустить сервер minecraft, не продав амазону почки?
С minecraft не знаю, там вожможно слишком много грязной, неподдерживаемой граалем магии используется.
t
это да, возможно
t
но может если вдруг
t
я когда-то пробовал сконвертировать craftbukkit в плюсы, безуспешно.
t
и видел где-то готовый компилятор из java в c++, тоже безрезультатно
e
блин хочу доклад найти.. эээхз
r
я не могу делиться кодом. поэтому постарался придумать похожий пример.
представь себе какой-нибудь ПИД-регулятор, реализованный в виде класса, который принимает поступающие данные (итеративно), и дает считывать текущие показатели коррекции (конст-методом).
допустим, мы хотим промоделировать, какие параметры ПИД-регулятора приводят в лучшему результату по совокупности метрик.
метрики - это чистые функции, которые зависят от выхлопа ПИД-регулятора (который имеет состояние) и от ряда агрегирующих функций (ну, предположим, пусть будет эстиматор Зигеля и линейная регрессия методом наименьших квадратов). МНК, в свою очередь, зависит от значения ковариации и стандартного отклонения.
С точки зрения элегантности архитектуры, было бы неплохо, если бы мы могли скармливать новые данные в классы высшего уровня - в классы, реализующие метрики. Те бы у себя внутри инстанцировали бы классы ПИД-регуляторов и скормили бы им данные, те бы передали данны на уровень ниже, еще на уровень ниже, и так до самых дальних узлов графа зависимостей.
На практике это значит, что если у нас есть миллион метрик, то у нас будет несколько миллионов дублирующися регуляторов, на каждый из них будет еще в несколько раз больше линрегов, а те, в свою очередь, инстанцируют еще в несколько раз больше расчитывателй стдев. Проблема заключается в том, что у нас многие узлы этого графа зависимостей считаются глупо — по нескольку раз, в соответствии с количеством входящих ребер, и наш граф зависимостей становится деревом.
Мое нынешнее решение - некрасивое. Я скармливаю данные не "голове" графа, не самим метрикам — а "хвосту", т.е. самым примитивным агрегирующим функциям без зависимостей, т.е. без исходящих узлов, а остальные узлы формулирую как чистые функции (очевидно, без состояния), которые используют выхлоп этих агрегирующих функций.
Я думал насчет красивого решения, где скармливание данных в верхний класс расчета метрики не мутирует приватный инстанс ПИД-регулятора, а возвращает иммутабельное следующее его состояние - и аналогично со статистическими вычислителями, следующее состояние является иммутабельной копией.
При таком подходе было бы возможно переиспользование копий одного и того же ПИД-регулятора в разных метриках, которые бы адвансились независимо друг от друга, и красиво бы дедуплицировались.
На самом деле красивой дедупликации не произошло, и вышло и медленно, и прожорливо.
представь себе какой-нибудь ПИД-регулятор, реализованный в виде класса, который принимает поступающие данные (итеративно), и дает считывать текущие показатели коррекции (конст-методом).
допустим, мы хотим промоделировать, какие параметры ПИД-регулятора приводят в лучшему результату по совокупности метрик.
метрики - это чистые функции, которые зависят от выхлопа ПИД-регулятора (который имеет состояние) и от ряда агрегирующих функций (ну, предположим, пусть будет эстиматор Зигеля и линейная регрессия методом наименьших квадратов). МНК, в свою очередь, зависит от значения ковариации и стандартного отклонения.
С точки зрения элегантности архитектуры, было бы неплохо, если бы мы могли скармливать новые данные в классы высшего уровня - в классы, реализующие метрики. Те бы у себя внутри инстанцировали бы классы ПИД-регуляторов и скормили бы им данные, те бы передали данны на уровень ниже, еще на уровень ниже, и так до самых дальних узлов графа зависимостей.
На практике это значит, что если у нас есть миллион метрик, то у нас будет несколько миллионов дублирующися регуляторов, на каждый из них будет еще в несколько раз больше линрегов, а те, в свою очередь, инстанцируют еще в несколько раз больше расчитывателй стдев. Проблема заключается в том, что у нас многие узлы этого графа зависимостей считаются глупо — по нескольку раз, в соответствии с количеством входящих ребер, и наш граф зависимостей становится деревом.
Мое нынешнее решение - некрасивое. Я скармливаю данные не "голове" графа, не самим метрикам — а "хвосту", т.е. самым примитивным агрегирующим функциям без зависимостей, т.е. без исходящих узлов, а остальные узлы формулирую как чистые функции (очевидно, без состояния), которые используют выхлоп этих агрегирующих функций.
Я думал насчет красивого решения, где скармливание данных в верхний класс расчета метрики не мутирует приватный инстанс ПИД-регулятора, а возвращает иммутабельное следующее его состояние - и аналогично со статистическими вычислителями, следующее состояние является иммутабельной копией.
При таком подходе было бы возможно переиспользование копий одного и того же ПИД-регулятора в разных метриках, которые бы адвансились независимо друг от друга, и красиво бы дедуплицировались.
На самом деле красивой дедупликации не произошло, и вышло и медленно, и прожорливо.
> При таком подходе было бы возможно переиспользование копий одного и того же ПИД-регулятора в разных метриках
Разделить состояние регулятора и его параметры. Переиспользовать-то нужно не объект ПИД-регулятор, а функцию обновления состояния и параметры этой функции.
Разделить состояние регулятора и его параметры. Переиспользовать-то нужно не объект ПИД-регулятор, а функцию обновления состояния и параметры этой функции.
t
похоже, люди запускают и рады
DS
Сравнивалось одно говно в виде spring и второе говно в виде rocket
DS
Лол
DS
Потрясающее сравнение
e
сделай свое :)
ну как ты говоришь что скалка норм, я бы глянул
ну как ты говоришь что скалка норм, я бы глянул