Arrow like storage over ByteBuffer to allow dual JVM buffer exchange

[JaroslavTulach]

Pull Request Description

• speeding up Mean.average benchmark
• the idea is to reuse work done by Exchanging direct ByteBuffers between the dual JVMs #13904 to
• convert ColumnStorage from a proxy to local ColumnStorage when creating a new Column - done in 4a052e8

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• All code follows the
  Scala,
  Java,
• Unit tests have been written where possible.
• Are library benchmarks influenced by Buffer usage?
  • benchmark for 1827145 is executed at

[JaroslavTulach]

• With 6655b7b the computation of Mean is as fast in dual JVM mode as in single JVM

- we have the solution, @jdunkerley - now there is time to design the system properly! - data were captured with following command

sbt:enso> runEngineDistribution 
  --vm.D=polyglot.enso.classLoading=Standard.Generic_JDBC:guest,hosted 
  --run /home/devel/enso-projects/SQLite/03-GenericConnect 
  --profiling-path /tmp/better.npss

[JaroslavTulach]

There are performance regressions when running stdlib benchmarks. For example:

use

sbt:enso> std-benchmarks/benchOnly Column_Arithmetic_1000000.Plus_Nothing

to run such a benchmark. Should be faster with b084696 - update on Nov 21: Yes, the enormous regression is gone, but still we have 2-3x slowdown mostly in Column_Arithmetic_1000000 benchmarks:

Slowdown is very likely coming from LongIterator.bgv. Time to speed it up!

[JaroslavTulach]

Slowdown is very likely coming from LongIterator.bgv. Time to speed it up!

The graph on left is the new LongBuffer.wrap version. The graph on right is the current long[] version. As can be seen, the LongBuffer is doing more operations as the code is more generic. It needs to check limit, it has concept of offset. It always reads hb array again (not sure why, that doesn't seem necessary to me). In any case, with these additional operations we just have to expect some slowdown.

[JaroslavTulach]

Works Fast!

• rawAddress and rawCapacity introduced by 4a052e8
• with these changes we get the Dual JVM benchmark computing mean on a table loaded by Generic_JDBC driver #14357 on par:

sbt:std-benchmarks> benchOnly mean
[info] Benchmark                     Mode  Cnt   Score   Error  Units
[info] Dual_JVM_Generic_JDBC.mean    avgt       33,393          ms/op
[info] Single_JVM_Generic_JDBC.mean  avgt       36,639          ms/op

• the next step is to ensure the format of data at rawAddress() matches Arrow format as used by Arrow language #8512 & co.
  • to be continued at...

Appendix: A Vision that Failed

• in one of the previous prototypes there was rawAddress and rawValidityAddress
  • in the process of rewriting the goal shifted to unify these two into one rawAddress and getSize()
  • however then it turned out that getSize() can be different than capacity of the buffer
• hence we are back to two values rawAddress, rawCapacity and also getSize()
• it might have been simpler to stick with the two rawAddressandrawValidityAddress` addresses...

[JaroslavTulach]

Tested for Compatibility with Arrow (and Arrow Language)

• ca62140 generates LongStorage by LongBuilder
• and reads it via ArrowLanguage expecting the same result
• not only that guarantees our format is Arrow compatible
• but it also ensures that whatever formats are generated by our storage Java code
• are also supported by ArrowLanguage
• e.g. we have all the pieces we need to drop the Java code and use ArrowLanguage when the time comes

[JaroslavTulach]

• Basic compatibility achieved at 89955a0
• more work remaining as aad18a7 demonstrates