As for performance of boxing, I think I found a remedy. You can look here: <https://github.com/altav...

# datascience

[altavir]

As for performance of boxing, I think I found a remedy. You can look here: https://github.com/altavir/kmath/tree/dev/kmath-core/src/jvmMain/kotlin/scientifik/kmath/structures documentation is thin yet. But preliminary tests show no performance loss against non-boxing code.

[kyonifer]

I will take a look for sure. Note though that one goal of koma was not to reinvent the wheel for every numerical algorithm, and instead to call into things like blas that have been battle tested for many years. To do so we've made an abstract interface which can have implementations into high performance platform libraries like intel MKL. at that point, you are back to trying to use getters on an interface without boxing

[altavir]

I completely agree with that. We need just to create some interfaces and then attach existing implementations to them. As for boxing interface, well I did not try to do it, so can't be sure about how hard it is.

[kyonifer]

most of the codegen and extension functions are designed to eliminate performance issues when writing code against a generic Matrix or NDArray interface. its the primary source of ugliness in koma

[kyonifer]

in theory, once valhalla is released, we should be able to delete the codegen and replace with normal code using value generics. so my current strategy has been to live with the codegen and hope that happens soon

[altavir]

This one I think, I solved (need to check all border cases though). For basic numbers it is solved by delegating operations to context and inlining some things.

The idea of the approach above is to allocate a ByteBuffer or its multiplatform analog from kotlinx-io and manually allocating primitives there. It is wrapped in context-oriented way so middle-level user does not need to think about it.

[kyonifer]

so i understand that strategy for e.g. allocating a complex without making an object. But at the end of the day you need to call matrix[i] where matrix: Matrix right?

[kyonifer]

and you're back to the same issue, unless you want to expose Any to the end user

[kyonifer]

or in your case, ByteBuffer

[altavir]

Yes, when you extract an object, it will be boxed. We can avoid it by inlining (store only buffer reference), but I am not sure, that it will really save something.

[kyonifer]

I think I agree you can easily write something with opaque byte buffers on the backend which does the work. but when you get to trying to write a nice numpy-esque interface on top of it, you have to either give up performance or static types if you want to avoid codegen

[altavir]

For this we need performance tests. Those things are not always obvious.

[altavir]

Also we need use-cases to understand which operations are really bottlenecks.

[kyonifer]

agreed. perhaps i should make an issue to collect the tests we've run across all three platforms and publish it somewhere. so far, i've not had anyone outside our team interested.

[altavir]

Great idea. I have to wrap up for today, but I hope for further discussion.

[kyonifer]

frankly, i've become discouraged by the results we've gotten so far and have lost some steam as a result. banging our heads against kotlin's type system and crazy performance workarounds like https://github.com/kyonifer/koma/blob/master/koma-core-api/common/src/koma/ndarray/NDArray.kt#L70 make one lose their resolve quickly

[altavir]

Why not? I have something similar, it is just syntactic sugar and used only once.

[kyonifer]

its just one example. the lines just above that link are another. the codegen for the default implementations are another. then we got to trying to write a generic matrix exponential and found we yet again needed codegen

[kyonifer]

without it things get very slow for code trying to consume a Matrix interface