Size: a a a

2020 October 25

A

Alex in graalvm_ru
да, флинк и спарк очень много кодогенерации в рантайме, поэтому не запустится
причем заметно больше чем в спринге с их DI

разобраться запрос - построить план - на основе статистики сделать его оптимизацию - сгенерировать код java - janino compiler - выполнить на воркерах

p.s. у спарка janino compiler сразу проверить на драйвере что код скомпилировался, отослать сорс код на воркеры, они повторно компилируют и выполняют его
у флинка байткод или сорскод на воркеры уходят я не помню
источник

A

Alex in graalvm_ru
Oleg Shelajev
Jit watch не будет к сожалению работать формат логов мне кажется не такой
да, посмотрел, тикет висит на emil compiler events, сейчас только самому логи парсить
источник

ПФ

Паша Финкельштейн... in graalvm_ru
Alex
да, флинк и спарк очень много кодогенерации в рантайме, поэтому не запустится
причем заметно больше чем в спринге с их DI

разобраться запрос - построить план - на основе статистики сделать его оптимизацию - сгенерировать код java - janino compiler - выполнить на воркерах

p.s. у спарка janino compiler сразу проверить на драйвере что код скомпилировался, отослать сорс код на воркеры, они повторно компилируют и выполняют его
у флинка байткод или сорскод на воркеры уходят я не помню
Да, джанино в этом плане гениален, практически пикл. Но для ni смерть, хотя казалось бы
источник
2020 October 26

OS

Oleg Shelajev in graalvm_ru
если интересно кстати - вот ишшуе https://github.com/dotnet/runtime/issues/43805
источник

P

Parra in graalvm_ru
what's the disassembler of both programs?
источник

OS

Oleg Shelajev in graalvm_ru
Didn't check. Didn't run the .net version at all. Do you think it's important?
источник

P

Parra in graalvm_ru
Oleg Shelajev
Didn't check. Didn't run the .net version at all. Do you think it's important?
absolutely, otherwise it's impossible to know what's happening behind scenes
источник

P

Parra in graalvm_ru
it would be cool to have the intermediate language disassembly of both and the final resulting assembler for some target architecture (for example, the one that the benchmarks are being run)
источник

P

Parra in graalvm_ru
also it would be interesting to have the telemetry of the GC (or running the same tests with the GC completely disabled in order to avoid noise)
источник

P

Parra in graalvm_ru
there are many factors that can influence in the performance
источник

OS

Oleg Shelajev in graalvm_ru
Yes and it all depends on the level of details one needs. Sometimes the wallclock measurements are enough
источник

P

Parra in graalvm_ru
I also think that it is a microbenchmark
источник

OS

Oleg Shelajev in graalvm_ru
It's an example I wouldn't even call it a benchmark
источник

P

Parra in graalvm_ru
exactly
источник

P

Parra in graalvm_ru
it is cool if you want to understand how each runtime JITs the code
источник

P

Parra in graalvm_ru
but it's not something relevant for measurements
источник

OS

Oleg Shelajev in graalvm_ru
Sorry I don't understand your point here
источник

P

Parra in graalvm_ru
Oleg Shelajev
Sorry I don't understand your point here
I mean that code is a toy, it can be used for learning, but it isn't a valid benchmark to me
источник

P

Parra in graalvm_ru
Parra
it would be cool to have the intermediate language disassembly of both and the final resulting assembler for some target architecture (for example, the one that the benchmarks are being run)
you can investigate this and learn a lot about how both compilers/runtimes work
источник

OS

Oleg Shelajev in graalvm_ru
Parra
I mean that code is a toy, it can be used for learning, but it isn't a valid benchmark to me
Literally nobody said otherwise right? I don't think looking into this example will teach a lot about either runtime. But I guess it depends on the tenacity of the investigation
источник