Re: A few micro-benchmarks for Jython 2 and two other ideas

Hi Jeff!

I'm from the OpenRefine team where we are constantly watching the future of
Jython since we use it as an expression language within OpenRefine, along
with Clojure.
We've talked on the mailing list I think in the past, perhaps not.

Anyways, I don't know how much of this you might already know, so sorry if
you do:

Regarding the microbenchmarks and your analysis...and some of the anomalies
you found...
I'm wondering if you verified that SIMD, SSE, etc. intrinsics were being
used or not sometimes?
https://www.amd.com/system/files/TechDocs/25112.PDF#G14.232935

And to see if intrinsic methods are being utilized or not and where in
compiled code, you can add:
    -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining

You might also be thought provoked with some extra information within this
JEP:
    https://bugs.openjdk.java.net/browse/JDK-8205637

Some Java JVM compilers & many of Java's robust libraries completely miss
the point of sometimes using Intrinsic functions as often as possible. For
example: SSE 4.2
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#expand=898,2862,2861,2860,2863,2864,2865&techs=SSE4_2
and the reason why Azul's Zing JVM is fast, is because it DOES use
intrinsic functions as much as possible. Kris Mok (Azul Systems) did a
great presentation of this back in 2013
https://www.slideshare.net/RednaxelaFX/green-teajug-hotspotintrinsics02232013

Thad
https://www.linkedin.com/in/thadguidry/


On Tue, Jan 5, 2021 at 5:56 PM Jeff Allen <[email protected]> wrote:

> I've been thinking about the implementation of a Jython core that would
> make proper use of dynamic language features in Java.
>
> Although peformance is secondary to correctness, one would like to avoid
> producing elegantly correct code that could only ever run like a slug.
> Numerical operations are indispensible, so I constructed JMH benchmarks
> for dispatch of unary and binary operations on int and float, when these
> are "hot code". The short version of the results is:
>
> 1. A core may be implemented (called here VSJ 2) that broadly follows
> CPython, but uses a Java method handle in place of each C pointer to
> function, and it will run at an acceptable speed. (Comparison is
> difficult between JMH and timeit, but it is fair to say VSJ 2 has "about
> the speed of CPython".)
>
> 2. Jython 2 is a lot faster than VSJ 2, almost certainly because HotSpot
> in-lines and specialises virtual calls so effectively.
>
> 3. We may use the method handles from VSJ 2 in invokedynamic call sites.
> The result is a little faster than Jython 2 in places, and significantly
> slower in others. However, there is scope for further optimisation.
>
> A longer version is here:
>
> https://the-very-slow-jython-project.readthedocs.io/en/latest/performance/_performance.html
>
> Jeff
>
> --
> Jeff Allen
>
>
>
> _______________________________________________
> Jython-dev mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>

_______________________________________________
Jython-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jython-dev