As for performance of boxing, I think I found a re...
# datasciencea
altavir
12/26/2018, 7:03 PMAs 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.
k
kyonifer
12/26/2018, 7:06 PMI 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
a
altavir
12/26/2018, 7:08 PMI 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.
k
kyonifer
12/26/2018, 7:09 PMmost 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
12/26/2018, 7:10 PMin 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
a
altavir
12/26/2018, 7:11 PMThis 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
ByteBufferk
kyonifer
12/26/2018, 7:12 PMso 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]matrix: Matrixkyonifer
12/26/2018, 7:12 PMand you're back to the same issue, unless you want to expose
Anykyonifer
12/26/2018, 7:13 PMor in your case,
ByteBuffera
altavir
12/26/2018, 7:14 PMYes, 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.
k
kyonifer
12/26/2018, 7:16 PMI 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
a
altavir
12/26/2018, 7:17 PMFor this we need performance tests. Those things are not always obvious.
altavir
12/26/2018, 7:17 PMAlso we need use-cases to understand which operations are really bottlenecks.
k
kyonifer
12/26/2018, 7:18 PMagreed. 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.
a
altavir
12/26/2018, 7:19 PMGreat idea. I have to wrap up for today, but I hope for further discussion.
k
kyonifer
12/26/2018, 7:20 PMfrankly, 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
a
altavir
12/26/2018, 7:21 PMWhy not? I have something similar, it is just syntactic sugar and used only once.
k
kyonifer
12/26/2018, 7:23 PMits 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
12/26/2018, 7:23 PMwithout it things get very slow for code trying to consume a Matrix interface
4 Views