Here is the promised article by <@UGB1USA2J> about...

# mathematics

[altavir]

Here is the promised article by @Iaroslav Postovalov about AST-based optimization of kmath expressions during runtime: https://medium.com/@postovalovya/expression-optimization-with-jvm-bytecode-generation-b50304b96619

[Ilya Muradyan]

Looks great! Is it possible to get a working Class<*> instance by giving it an expression string? I'd like to try it out

Some points:
1. You may try to generate "primitive" versions of Expression and Algebra (Instead of using generics) interfaces to avoid boxing issues and performance regression
2. Operations seem to fit enum type naturally. You won't need using string identifiers and map lookup, just define enum with appropriate methods

Also, it would be great to see more detailed performance analysis, with different optimisations enabled and with different sizes of expressions.

[altavir]

I believe @Iaroslav Postovalov did all that, he can address the question. There are benchmarks in the repository as well.

[altavir]

An important thing that I expected and @Iaroslav Postovalov confirmed is that JIT is almost as effective as byte-code generation when all types are known in advance and we do not generate nested functions.

[Iaroslav Postovalov]

@Ilya Muradyan hello, we actually get class object and provide its instance to the user

[Iaroslav Postovalov]

@Ilya Muradyan boxing issue is partially optimized by inserting calls to primitive methods, not to bridge methods, so only the return value is being boxed. It's nice idea to create specialized methods for double/int/long

[Iaroslav Postovalov]

@Ilya Muradyan I'm not good in building complex performance comparisons and distributions.

[Iaroslav Postovalov]

@Ilya Muradyan string operations IDs are designed at core module. however, it's possible to replace methodNameAdapters with enum, thanks for advice.

[Ilya Muradyan]

Thank you for answers! One more q: how many arguments map access operations will be performed for expression "x*x*x"? One or three?

[altavir]

I believe that it will be a tree with 3 nodex, each of those use 2-argument primitive operation. In AST the tree will be traversed and flattened.

[Iaroslav Postovalov]

I think, 3

[Iaroslav Postovalov]

Thanks for idea of optimization

[Iaroslav Postovalov]

@Ilya Muradyan but there is a possible problem. map can be mutable or return random values

[Iaroslav Postovalov]

I don't want to make complicated contract for input map

[Ilya Muradyan]

Different values for the same key? This contract seems to be natural, but I agree, there could the cases

[Iaroslav Postovalov]

Yes. Optimizations like this must be opt-in, and during profiling I didn't noticed any problems because of HashMap.get

[altavir]

HashMap.get is super-optimized on JVM, so the access cost is close to the array access. It should be profiled of course.

[Iaroslav Postovalov]

I'll review x*x*x expression.

[altavir]

The MST interpretter actually allows caching the value of the variable. But I do not think it is relevant right now.