Short field handlers are absent in NativeExecutor about jvm-driver HOT 20 CLOSED

Hi, I did a performance test today between your implementation and the none boxing/unboxing implementation.

Your implementation.

Benchmark                             Mode  Cnt      Score     Error   Units
NativeExecutorBench.get01_primitive  thrpt    5   6443.048 ± 349.801  ops/ms
NativeExecutorBench.get02_object     thrpt    5  17465.356 ± 203.896  ops/ms
NativeExecutorBench.set01_primitive  thrpt    5   6551.346 ± 109.559  ops/ms
NativeExecutorBench.set02_object     thrpt    5  20479.006 ± 224.800  ops/ms

The none boxing/unboxing implementation.

Benchmark                                      Mode  Cnt      Score     Error   Units
NativeExecutorBench.get01_primitive           thrpt    5  32597.013 ± 459.114  ops/ms
NativeExecutorBench.get02_primitive_directly  thrpt    5  35214.925 ± 789.498  ops/ms
NativeExecutorBench.get03_object              thrpt    5  17177.163 ± 457.885  ops/ms
NativeExecutorBench.get04_object_directly     thrpt    5  17462.458 ± 233.682  ops/ms
NativeExecutorBench.set01_primitive           thrpt    5  23135.374 ± 176.035  ops/ms
NativeExecutorBench.set02_primitive_directly  thrpt    5  26144.575 ± 300.973  ops/ms
NativeExecutorBench.set03_object              thrpt    5  19641.708 ± 275.529  ops/ms
NativeExecutorBench.set04_object_directly     thrpt    5  20433.885 ±  81.209  ops/ms

In my optimization implementation, I moved all checks to Java, using primitive types and doing the minimum necessary operations in JNI.

Should I create a pull request to review my code?

from jvm-driver.

Thanks for reporting. I fixed the problem but I'm unable to release: I obtain this error on ubuntu x64:

org.burningwave.jvm.test.NativeDriverTest.getAndSetDirectVolatileTestOne Time elapsed: 0.012 s <<< ERROR! java.lang.UnsatisfiedLinkError: 'void org.burningwave.jvm.NativeExecutor.setShortFieldValue(java.lang.Object, java.lang.reflect.Field, java.lang.Short)' at org.burningwave.jvm.test.NativeDriverTest.getAndSetDirectVolatileTestOne(NativeDriverTest.java:38)

This is the NativeExecutor.cpp and this is the NativeExecutor.java: what i added seems correct to me, can you see if there is any error?

from jvm-driver.

The method signature seems to be incorrect.

from jvm-driver.

I found the problem: it's on the pom.xml: when the workflow is launched on ubuntu x64 it executes only the task with id compile native for aarch64 and it doesn't execute the main task and it generates only the aarch64 artifact. Is there a way to tell to maven to execute the main task and the task within the profile?

from jvm-driver.

Try to config all tasks in the profile block.

from jvm-driver.

Ok, I solved: check the progress of the release

from jvm-driver.

Ok, I will check it after release. Why using boxed types to handle primitive types? Narcissus uses the primitive types directly.

from jvm-driver.

To avoid checks and possible conversions in the JNI layer if a value received in input is of primitive type and the class field is not and vice versa. I have reanalyzed the code and I believe that the NativeExecutor is faster than Naricissus because it performs fewer checks and minimizes JNI operations

from jvm-driver.

It seems so. I will do a performance test to compare the two implementations when I have time.

from jvm-driver.

It seems so. I will do a performance test to compare the two implementations when I have time.

Ok, you're welcome. Thank you very much

from jvm-driver.

Great job, you must create a pull request, but first make sure you have updated the project because I also made some changes a few days ago. I'll wait for your pull request

from jvm-driver.

... Or I can add you as a collaborator of the project so that you can directly submit changes and also execute releases: How do you think about?

from jvm-driver.

I have created a PR Improve performance for primitive types.

from jvm-driver.

I merged and pushed your changes: I started compiling and testing native modules: here the progress

Would you like to become a collaborator on the project so that you can directly make changes and make releases?
For example, you can enrich the home page with your own tests.

from jvm-driver.

It's my pleasure! ^_^

from jvm-driver.

Ok, tests are ok. Now to release you need only to push on the main branch with the comment "Releasing new version":

On the other hand, if you are going to make changes to the native module and want to test them, you need to do the same with the comment "Generating external artifacts".

These push trigger GitHub actions that perform native module generation, testing and release.

I await your release to update Burningwave Core dependencies

from jvm-driver.

Sorry I am in trouble when pushing the new version. I will solve it tomorrow. It's too late now in China, I have to get off work.

from jvm-driver.

Don't worry, there is no rush. I will await your release. Have a good rest

from jvm-driver.

I saw you released: well done!

Feel free to improve this project as you see fit. Burningwave JVM Driver compared to Narcissus has the native module also for aarch64 which, however, must be tested. Some improvements that can be made to this project are for example:

• compile the native module for other platforms (at the moment the native module is compiled for the configurations indicated in the Overview)
• add Javadoc
• add tests for aarch64 in the github action

All this without obligation, and if you are able to make improvements to the project you are welcome :-)

from jvm-driver.

OK, I'm excited to contribute some ideas and code to this project.

from jvm-driver.