Using ring/circular buffer for Series class

[Abasz]

I wonder whether you have considered swapping the shift() of the Array in the Series class to use a ring buffer.

As part of the final touches of the new ESPRM release I was doing benchmarking and I just realized that I dont use ring buffer but rather vector.erase(begin()) that essentially shifts the values which is the same as unshift() in javascript. The big difference that erase in cpp uses move() when it can and copy only when it must which very efficient (as only the pointer reference is moved). So for me testing the ring buffer did not bring significant benefit. But I wonder if this is the same for javascript that is rather inefficient.

Have you ever tried this? Also you need to keep in mind that the ring buffer implementation should be free from modulus as that is expensive too (well not sure in javascript, it surely is in embedded :))

[JaapvanEkris]

Thanks for the pointer (pun intended)!

I wonder whether you have considered swapping the shift() of the Array in the Series class to use a ring buffer.

Have you ever tried this? Also you need to keep in mind that the ring buffer implementation should be free from modulus as that is expensive too (well not sure in javascript, it surely is in embedded :))

I have tried. The easiest implementation is using Modula the buffer size. ORM uses series a lot, but I get a similar result: no significant performance improvement. It did make code more difficult to understand, so I ditched it.

Please note: version 0.9.7 contains some mathematical improvements in MovingWindowRegressor.js. It makes the moving regressor (formally part of Flywheel.js) less vulnerable to outliers by incorporating a local Goodness of Fit and a Gaussian Kernel. Testing in the last week convinced me it really is a practical improvement at almost no cost. I even consider shortening the FlankLength of the C2 ReowErg from 12 to 11...

[Abasz]

It did make code more difficult to understand, so I ditched it.

Same, so i reverted it too :):)): especially the branching that was neccesary to avoid modulo. I could not believe this si i did a lot of research amd apparently most compilers use one block of memmove for trivial types so essentially this is becomes a very very efficient operation. but i am surprised that something similar is happening im node impellememtation of JavaScript.

MovingWindow regressor

thanks for the note, i will check it. it will be in the next release any way.

[Abasz]

MovingWindow regressor [...] at almost no cost

I will shortly not care about performance becuase I just found approx 14% improvement on max execution time (and 16% the nromal) by fixing a bug (1 number!!!!) in my manual memory management (approx. 5% - I misscalculated by half the requried memory for the final flattened vector so it was doing approx one additionla reallocation that could be extremely inefficient when vector has values) and using c++20 std::ranges::copy and std::view::join for flattening (approx. 9%). std::view::join does not do allocation (compared to the loop copy) as it does not oen the data, its just a view so I suspect the CPU can copy in one big chunk kind of thing or the compiler do optimisations that it would not be able on a loop. Anyway the latter was very supprising to me becuase I was expecting that the bottle neck is always the memory allocation but apparently not.

This is an important milestone beucase now with flank lenght of 18 we are below 4milis with the worst case execution time, and around 3.5milis for the general case per new impulse

[JaapvanEkris]

I will shortly not care about performance becuase I just found approx 14% improvement on max execution time (and 16% the nromal) by fixing a bug (1 number!!!!) in my manual memory management

Know the feeling! Good work finding that kind of issue in your own code. It is tough finding thos kind of issues.

This is an important milestone beucase now with flank lenght of 18 we are below 4milis with the worst case execution time, and around 3.5milis for the general case per new impulse

That is impressive!