Update to 0.6.0 (dropped reinterpret arrays)

[soywiz]

trafficstars

0.6.0 is almost done. I have removed some features that should be updated here. https://github.com/jtransc/jtransc/issues/87

In 0.5.x branch we were able to reinterpret arrays arbitrarily. Haxe/CPP was very slow because of that due to a poor Typed Arrays implementation (eg. Int32Array...). Other targets like AS3 had the same problem. I changed internal implementation to have faster arrays without a common buffer. I think here there are several reinterpretCast usages that should be changed to copys for now. In the future it is possible that I add this feature again but always checking that benchmarks for normal code aren't affected.

To check performance. You can set jtranscVersion in gradle.properties here: https://github.com/jtransc/jtransc-benchmark/tree/master/benchmark

And run gradlew run to have a baseline and then gradlew runhaxecpp. Due to a bug detecting the exe path, this will fail but after running it you can go to build/jtransc-haxe/program.exe/... and find the proper executable and run it to compare with the base Java execution times. In 0.6.0 performance has been improved a lot and will improve even further in future versions. C# target is already pretty fast almost matching Java base implementation even when arrays are wrapped.

[soywiz]

@SergeyLabutin

Check if this helps you:

ByteArray ba = ByteArray.allocateDirect(10000);
FloatBuffer fb = ba.asFloatBuffer();
fb.getByteBuffer().array(); // This gives you a JA_B. This won't work normally on Java, but works on JTransc because all arrays even direct are backed by byte[].

JA_B has getBytes method ( https://github.com/jtransc/jtransc/blob/aa7835634694e1e3dfc6474894414b144abde6e9/jtransc-rt/resources/hx/JA_B.hx ) . Right now it copies in haxe-cpp target. But I think I can get it working without copying. While keeping getBytes method.

[ghost]

#44 common fix, but best value: copy need delete from hx, and if all buffers save as byte will be fast copy pointer without transform. Now we fix loading but game usually have many buffers and every tick transform will get low fps when try transform for to gl buffer. I will be work in this direction, but my skill not good. I can understand this problem, but can not fast fix...

[soywiz]

I have seen that you are copying in some cases. For example int[] (JA_I). I suppose we can do optimizations for haxe-cop with #if cpp or something. Tell me exactly which operations are slow and I will try to optimize them

[ghost]

I think this issue need close. I create new ticket #59. This related with buffers, but different issue.