DS
Дико важно
Вот им и нужен грааль-аот. Он аот компилирует приложения под JVM в приличный нативный код.
И при этом, в отличие от всяких scala, kotlin native ещё и имеет человеческий сборщик мусора, что очень важно.
Size: a a a
2020 June 11
e
не гуглится грааль-аот, скинь полное название ))
DF
Gcj был ещё году в 98 кек
DF
Но не взлетел
ЕС
не гуглится грааль-аот, скинь полное название ))
Graalvm
e
thx
DS
не гуглится грааль-аот, скинь полное название ))
e
полезно
но только сборщик мусора есть, нуу ладно
но только сборщик мусора есть, нуу ладно
t
По такому описанию не очень понятно, что именно ты хочешь сделать. Есть минимальный пример именно в коде?
я не могу делиться кодом. поэтому постарался придумать похожий пример.
представь себе какой-нибудь ПИД-регулятор, реализованный в виде класса, который принимает поступающие данные (итеративно), и дает считывать текущие показатели коррекции (конст-методом).
допустим, мы хотим промоделировать, какие параметры ПИД-регулятора приводят в лучшему результату по совокупности метрик.
метрики - это чистые функции, которые зависят от выхлопа ПИД-регулятора (который имеет состояние) и от ряда агрегирующих функций (ну, предположим, пусть будет эстиматор Зигеля и линейная регрессия методом наименьших квадратов). МНК, в свою очередь, зависит от значения ковариации и стандартного отклонения.
С точки зрения элегантности архитектуры, было бы неплохо, если бы мы могли скармливать новые данные в классы высшего уровня - в классы, реализующие метрики. Те бы у себя внутри инстанцировали бы классы ПИД-регуляторов и скормили бы им данные, те бы передали данны на уровень ниже, еще на уровень ниже, и так до самых дальних узлов графа зависимостей.
На практике это значит, что если у нас есть миллион метрик, то у нас будет несколько миллионов дублирующися регуляторов, на каждый из них будет еще в несколько раз больше линрегов, а те, в свою очередь, инстанцируют еще в несколько раз больше расчитывателй стдев. Проблема заключается в том, что у нас многие узлы этого графа зависимостей считаются глупо — по нескольку раз, в соответствии с количеством входящих ребер, и наш граф зависимостей становится деревом.
Мое нынешнее решение - некрасивое. Я скармливаю данные не "голове" графа, не самим метрикам — а "хвосту", т.е. самым примитивным агрегирующим функциям без зависимостей, т.е. без исходящих узлов, а остальные узлы формулирую как чистые функции (очевидно, без состояния), которые используют выхлоп этих агрегирующих функций.
Я думал насчет красивого решения, где скармливание данных в верхний класс расчета метрики не мутирует приватный инстанс ПИД-регулятора, а возвращает иммутабельное следующее его состояние - и аналогично со статистическими вычислителями, следующее состояние является иммутабельной копией.
При таком подходе было бы возможно переиспользование копий одного и того же ПИД-регулятора в разных метриках, которые бы адвансились независимо друг от друга, и красиво бы дедуплицировались.
На самом деле красивой дедупликации не произошло, и вышло и медленно, и прожорливо.
представь себе какой-нибудь ПИД-регулятор, реализованный в виде класса, который принимает поступающие данные (итеративно), и дает считывать текущие показатели коррекции (конст-методом).
допустим, мы хотим промоделировать, какие параметры ПИД-регулятора приводят в лучшему результату по совокупности метрик.
метрики - это чистые функции, которые зависят от выхлопа ПИД-регулятора (который имеет состояние) и от ряда агрегирующих функций (ну, предположим, пусть будет эстиматор Зигеля и линейная регрессия методом наименьших квадратов). МНК, в свою очередь, зависит от значения ковариации и стандартного отклонения.
С точки зрения элегантности архитектуры, было бы неплохо, если бы мы могли скармливать новые данные в классы высшего уровня - в классы, реализующие метрики. Те бы у себя внутри инстанцировали бы классы ПИД-регуляторов и скормили бы им данные, те бы передали данны на уровень ниже, еще на уровень ниже, и так до самых дальних узлов графа зависимостей.
На практике это значит, что если у нас есть миллион метрик, то у нас будет несколько миллионов дублирующися регуляторов, на каждый из них будет еще в несколько раз больше линрегов, а те, в свою очередь, инстанцируют еще в несколько раз больше расчитывателй стдев. Проблема заключается в том, что у нас многие узлы этого графа зависимостей считаются глупо — по нескольку раз, в соответствии с количеством входящих ребер, и наш граф зависимостей становится деревом.
Мое нынешнее решение - некрасивое. Я скармливаю данные не "голове" графа, не самим метрикам — а "хвосту", т.е. самым примитивным агрегирующим функциям без зависимостей, т.е. без исходящих узлов, а остальные узлы формулирую как чистые функции (очевидно, без состояния), которые используют выхлоп этих агрегирующих функций.
Я думал насчет красивого решения, где скармливание данных в верхний класс расчета метрики не мутирует приватный инстанс ПИД-регулятора, а возвращает иммутабельное следующее его состояние - и аналогично со статистическими вычислителями, следующее состояние является иммутабельной копией.
При таком подходе было бы возможно переиспользование копий одного и того же ПИД-регулятора в разных метриках, которые бы адвансились независимо друг от друга, и красиво бы дедуплицировались.
На самом деле красивой дедупликации не произошло, и вышло и медленно, и прожорливо.
e
ааа блин
DS
полезно
но только сборщик мусора есть, нуу ладно
но только сборщик мусора есть, нуу ладно
Ну а как иначе? Речь про языки со сборкой мусора.
e
вспомнил, кто то показывал граль этот на каком то докладе
e
и сказали короче что гауно полное
ща найду доклад, если найду ...
ща найду доклад, если найду ...
e
я не могу делиться кодом. поэтому постарался придумать похожий пример.
представь себе какой-нибудь ПИД-регулятор, реализованный в виде класса, который принимает поступающие данные (итеративно), и дает считывать текущие показатели коррекции (конст-методом).
допустим, мы хотим промоделировать, какие параметры ПИД-регулятора приводят в лучшему результату по совокупности метрик.
метрики - это чистые функции, которые зависят от выхлопа ПИД-регулятора (который имеет состояние) и от ряда агрегирующих функций (ну, предположим, пусть будет эстиматор Зигеля и линейная регрессия методом наименьших квадратов). МНК, в свою очередь, зависит от значения ковариации и стандартного отклонения.
С точки зрения элегантности архитектуры, было бы неплохо, если бы мы могли скармливать новые данные в классы высшего уровня - в классы, реализующие метрики. Те бы у себя внутри инстанцировали бы классы ПИД-регуляторов и скормили бы им данные, те бы передали данны на уровень ниже, еще на уровень ниже, и так до самых дальних узлов графа зависимостей.
На практике это значит, что если у нас есть миллион метрик, то у нас будет несколько миллионов дублирующися регуляторов, на каждый из них будет еще в несколько раз больше линрегов, а те, в свою очередь, инстанцируют еще в несколько раз больше расчитывателй стдев. Проблема заключается в том, что у нас многие узлы этого графа зависимостей считаются глупо — по нескольку раз, в соответствии с количеством входящих ребер, и наш граф зависимостей становится деревом.
Мое нынешнее решение - некрасивое. Я скармливаю данные не "голове" графа, не самим метрикам — а "хвосту", т.е. самым примитивным агрегирующим функциям без зависимостей, т.е. без исходящих узлов, а остальные узлы формулирую как чистые функции (очевидно, без состояния), которые используют выхлоп этих агрегирующих функций.
Я думал насчет красивого решения, где скармливание данных в верхний класс расчета метрики не мутирует приватный инстанс ПИД-регулятора, а возвращает иммутабельное следующее его состояние - и аналогично со статистическими вычислителями, следующее состояние является иммутабельной копией.
При таком подходе было бы возможно переиспользование копий одного и того же ПИД-регулятора в разных метриках, которые бы адвансились независимо друг от друга, и красиво бы дедуплицировались.
На самом деле красивой дедупликации не произошло, и вышло и медленно, и прожорливо.
представь себе какой-нибудь ПИД-регулятор, реализованный в виде класса, который принимает поступающие данные (итеративно), и дает считывать текущие показатели коррекции (конст-методом).
допустим, мы хотим промоделировать, какие параметры ПИД-регулятора приводят в лучшему результату по совокупности метрик.
метрики - это чистые функции, которые зависят от выхлопа ПИД-регулятора (который имеет состояние) и от ряда агрегирующих функций (ну, предположим, пусть будет эстиматор Зигеля и линейная регрессия методом наименьших квадратов). МНК, в свою очередь, зависит от значения ковариации и стандартного отклонения.
С точки зрения элегантности архитектуры, было бы неплохо, если бы мы могли скармливать новые данные в классы высшего уровня - в классы, реализующие метрики. Те бы у себя внутри инстанцировали бы классы ПИД-регуляторов и скормили бы им данные, те бы передали данны на уровень ниже, еще на уровень ниже, и так до самых дальних узлов графа зависимостей.
На практике это значит, что если у нас есть миллион метрик, то у нас будет несколько миллионов дублирующися регуляторов, на каждый из них будет еще в несколько раз больше линрегов, а те, в свою очередь, инстанцируют еще в несколько раз больше расчитывателй стдев. Проблема заключается в том, что у нас многие узлы этого графа зависимостей считаются глупо — по нескольку раз, в соответствии с количеством входящих ребер, и наш граф зависимостей становится деревом.
Мое нынешнее решение - некрасивое. Я скармливаю данные не "голове" графа, не самим метрикам — а "хвосту", т.е. самым примитивным агрегирующим функциям без зависимостей, т.е. без исходящих узлов, а остальные узлы формулирую как чистые функции (очевидно, без состояния), которые используют выхлоп этих агрегирующих функций.
Я думал насчет красивого решения, где скармливание данных в верхний класс расчета метрики не мутирует приватный инстанс ПИД-регулятора, а возвращает иммутабельное следующее его состояние - и аналогично со статистическими вычислителями, следующее состояние является иммутабельной копией.
При таком подходе было бы возможно переиспользование копий одного и того же ПИД-регулятора в разных метриках, которые бы адвансились независимо друг от друга, и красиво бы дедуплицировались.
На самом деле красивой дедупликации не произошло, и вышло и медленно, и прожорливо.
еще есть
https://github.com/bodil/im-rs
он кстати побыстрее должен быть, чем тот который скидывал
ну и так, чисто сорцы потыкать и может скомпилить свои числодробилки для интереса
https://github.com/bodil/im-rs
он кстати побыстрее должен быть, чем тот который скидывал
ну и так, чисто сорцы потыкать и может скомпилить свои числодробилки для интереса
DS
и сказали короче что гауно полное
ща найду доклад, если найду ...
ща найду доклад, если найду ...
Грааль хорошо работает, проблема в другом - там не работает рефлексия
DS
толком
t
еще есть
https://github.com/bodil/im-rs
он кстати побыстрее должен быть, чем тот который скидывал
ну и так, чисто сорцы потыкать и может скомпилить свои числодробилки для интереса
https://github.com/bodil/im-rs
он кстати побыстрее должен быть, чем тот который скидывал
ну и так, чисто сорцы потыкать и может скомпилить свои числодробилки для интереса
ну, просто взять и скомпилить нельзя, как понимаешь, нужно портировать целиком
AZ
А в чем мусор?
DS
и сказали короче что гауно полное
ща найду доклад, если найду ...
ща найду доклад, если найду ...
Поэтому стандартный код от джавистов там не запуститься. А вот скала тру-хардкор-ФП идёт там на ура сразу же
e
А в чем мусор?
не, норм код на самом деле
уже неактуально
уже неактуально