Fast JNI

Performance Tuning
#1

On theserverside.com

“Opinion: Do you want easy access to native code?”

“There has been talk that a group at Sun has come up with a nice clean way to slurp up a header file, and have access to the native code. It is reportedly four times faster than JNI, and without the other head-aches. There is a lot of native support in Microsoft .NET, but do you need it in Java? Or, do you think that we should stay portable?”

And on Suns bugdatabase. bug #6206832
“java should provide direct calls to native routines”…
"Classic JNI calls are too slow for some critical uses, such as graphics.

This bug entry exists to track prototyping of alternatives, specifically
the “Blackbird” project."

  • some of the other work pointing to tests on “Faster JNI” see bug #4740695

So, Sun VM guys, is there anything nice we should know? Or possibly lobby for?

#2

The vast majority of calls could be direct from the VM by simply specifying a DLL, function name, and passing in primitive arguments.

Only for those calls that take Java objects would a custom bit of JNI code need to be written.

It would have been far easier to write LWJGL using a direct method originally but we now do so many things under the hood that direct JNI probably no longer applies to us.

And I take issue with people who claim that JNI is too slow for graphics. The overhead is immeasurably small unless you’re doing it wrong in the first place.

Cas :slight_smile:

#3

Ahhh yes blackbird gets more email than anything else :slight_smile: Its quite fast, and currently only works for Solaris SPARC.

#4

[quote]Ahhh yes blackbird gets more email than anything else :slight_smile: Its quite fast, and currently only works for Solaris SPARC.
[/quote]
Please tell us more about Blackbird. :slight_smile:

I’ve done an absolute ton of JNI work (and wrote Jace because of it), so I’d like to know about any possible changes or alternatives in the pipeline.

God bless,
-Toby Reyelts

#5

[quote]And I take issue with people who claim that JNI is too slow for graphics. The overhead is immeasurably small unless you’re doing it wrong in the first place.
[/quote]
That’s probably true if you’re doing purely OpenGL-style graphics where almost all of the work is offloaded to the GL server through a coarse interface, but I wouldn’t be surprised if there are more operations in a Java2D-style API that require more back and forth between the engine and the underlying graphics system (i.e. GDI/DirectDraw).

God bless,
-Toby Reyelts

#6

Hm, dunno about that.

Cas :slight_smile:

#7

[quote]Ahhh yes blackbird gets more email than anything else :slight_smile: Its quite fast, and currently only works for Solaris SPARC.
[/quote]
Please, Azeem, don’t tease, what is “blackbird”?

#8

[quote]And I take issue with people who claim that JNI is too slow for graphics. The overhead is immeasurably small unless you’re doing it wrong in the first place.
[/quote]
Believe me, the JNI overhead for simple primitives is HUGE.

I also like to believe that we know what we’re doing =)

#9

How come I can draw a complex transparent GUI at hundreds of frames per second using GL then? Don’t tell me it’s because it’s hardware accelerated, because Swing should be hardware accelerated too if it’s just drawing 2D.

Cas :slight_smile:

#10

Try rendeirng a gazillon 1x1 lines, even with jogl, you’ll see what I’m talking about.
The overhead is much less noticeable in complex primitives.

Or, gasp, write a jni microbenchmark, and see how much do you lose because of the overhead…

#11

But that’s just it… a Swing GUI doesn’t have a gazillion 1x1 lines in it! Largely it’s just rectangles, boxes, lines, blits and a bit of text. Same as an OpenGL GUI in fact.

Swing still feels labouriously slow after all these years.

SWT is just as bad. Eclipse performance is becoming something of a joke since that new stuttering bug was introduced in 1.5.

Cas :slight_smile:

#12

[quote]But that’s just it… a Swing GUI doesn’t have a gazillion 1x1 lines in it!
[/quote]
My mapping component draws what feels like a gazillion tiny lines, points, etc… All UIs are not created equal.

God bless,
-Toby Reyelts

#13

Ah but that’s a custom component with a very specialised function. Probably be the same in GL or J2D.

Cas :slight_smile:

#14

[quote]Try rendeirng a gazillon 1x1 lines, even with jogl, you’ll see what I’m talking about.
The overhead is much less noticeable in complex primitives.
Or, gasp, write a jni microbenchmark, and see how much do you lose because of the overhead…
[/quote]
24 cycles?
I wrote it, but I should rerun it. Also the question is: server, or client?
I have reruned it. 0.5 - 0.2 sec difference for 10 million runs on computer underclocked to 1899 MHz.
This looks like around 37 - 90 cycles per JNI call for server.