JOGL too slow

R

Reza Roby

Hi guys,

I've written an application that makes many OpenGL calls for rendering a
scene. (The calls are glColor3f and glVertex3f, mostly.)

when my loops make about 1,400,000 additional calls to glColor3f, render
time goes from 50 Milliseconds to 300 Milliseconds!

Straight c (gcc/linux) can do 1,400,000 glColor3f's, 20 times as fast
(same hardware.)

This suggests the jogl->OpenGL bridge is very slow.

I could be wrong, but I think not.
------------------------------------------------

My question is not JOGL specific:

Can you briefly explain how the Java->native bridge is implemented?

How that explains the JOGL slowness?

And if it can be made faster?


I chose Java for it's seamless platform independence, and fairly decent
JIT, but Java->OpenGL speed is crucial.

I am presently looking into wxWindows and wxGLCanvas as a potential
alternative.

I really appreciate any help that makes my decision easier.


PS:

I won't shy away from reading the JOGL source code, if you tell me how
it works, and what to do.
 
R

Reza Roby

Roedy said:
Is JOGL using JNI? If so, the call overhead across the blood-brain
barrier is horrible.


I'm not sure. That's what I need to find out before investing the time
to learn JNI in the first place.

I _will_ need some type of c interface, for things pure Java just cannot
handle, such as

malloc(sizeof(struct s) * 20000000);


Thanks for replying :)
 
C

Chris Uppal

Reza said:
I'm not sure. That's what I need to find out before investing the time
to learn JNI in the first place.

JNI does indeed have a significant overhead per operation. As a **very** rough
estimate, in the order of magnitude of a microsecond per method call.

So you don't want to be doing a million method calls via JNI if you don't have
a spare second or so.

However you can often improve matters by being clever about your API design.
E.g. it's hard to imagine 1M calls needing to happen in quick succession /and/
being dependent on each others' results, so you could maybe populate an array
(of some primitive type) with the parameters that define (say) 1000 calls from
Java, invoke JNI once, and then do a loop in C over the contents of the array.
That should cut the overhead by a factor approaching 1000.

-- chris
 
M

Martin Winkelbauer

Reza Roby said:
Hi guys,

I've written an application that makes many OpenGL calls for rendering a
scene. (The calls are glColor3f and glVertex3f, mostly.)

when my loops make about 1,400,000 additional calls to glColor3f, render
time goes from 50 Milliseconds to 300 Milliseconds!

Straight c (gcc/linux) can do 1,400,000 glColor3f's, 20 times as fast
(same hardware.)

This suggests the jogl->OpenGL bridge is very slow.

I could be wrong, but I think not.
------------------------------------------------

My question is not JOGL specific:

Can you briefly explain how the Java->native bridge is implemented?

How that explains the JOGL slowness?

And if it can be made faster?


I chose Java for it's seamless platform independence, and fairly decent
JIT, but Java->OpenGL speed is crucial.

I am presently looking into wxWindows and wxGLCanvas as a potential
alternative.

I really appreciate any help that makes my decision easier.


PS:

I won't shy away from reading the JOGL source code, if you tell me how
it works, and what to do.

Hello

I think you should ask this questions on:
http://www.javagaming.org/cgi-bin/JGNetForums/YaBB.cgi
(altough gaming-relatet, thats where the gurus are) :)

jogl and another java-OpenGL Bindings Package (lwjgl) have their own forums
there.

hth
Martin
 
R

Reza Roby

Chris said:
Reza Roby wrote:




JNI does indeed have a significant overhead per operation. As a **very** rough
estimate, in the order of magnitude of a microsecond per method call.

So you don't want to be doing a million method calls via JNI if you don't have
a spare second or so.

However you can often improve matters by being clever about your API design.
E.g. it's hard to imagine 1M calls needing to happen in quick succession /and/
being dependent on each others' results, so you could maybe populate an array
(of some primitive type) with the parameters that define (say) 1000 calls from
Java, invoke JNI once, and then do a loop in C over the contents of the array.
That should cut the overhead by a factor approaching 1000.


Sure. Doing this was certainly one option. I _do_ need many OpenGL
calls per second (millions.) However, I thought of doing all of them
inside a single JNI call.

My concern was this: Ideologically, one major reason for choosing Java
instead of wxWindows in the first place, was not having to produce
multi-platform binaries. Whereas I cannot avoid that, I can
substantially simplify it, by letting Java handle the system-specific
calls exclusively. Then, pure, IO-free c(JNI), can be ported with ease.

But, letting Java handle IO, is letting Java handle OpenGL, and that is
too slow. Unless of course, JOGL can submit calls in "batch mode??"

Then again, even implementing "batch mode," isn't ideal, because the
OpenGL glFlush() call, already indicates one level of caching within
OpenGL itself. Two levels, gets redundant.
 
R

Roedy Green

I _will_ need some type of c interface, for things pure Java just cannot
handle, such as

malloc(sizeof(struct s) * 20000000);

the Key to JNI is to pass as few separate parameters as possible, jump
in to C and stay there a decently long time to make the trip
worthwhile.


It is sort of like shopping in Indonesia to save money. Unless you
stay there a few weeks, the cost of airfare will far outstrip your
shopping savings.
 
R

Roedy Green

But, letting Java handle IO, is letting Java handle OpenGL, and that is
too slow. Unless of course, JOGL can submit calls in "batch mode??"

You can estimate how many calls per second overhead across the barrier
you will need.

I was repeatedly disappointed by the dismal slowness of small C
routines.

Even if JOGL does no matching, you still might cook something up with
Java to bundle up an array of work packets and send that off to C in a
one go to be dispatched.


You don't want C to call Java methods either. So you want to massage
your data into a form that C can eat directly, e.g. little-endian
arrays of bytes.
 
?

=?ISO-8859-1?Q?Daniel_Sj=F6blom?=

Roedy said:
You can estimate how many calls per second overhead across the barrier
you will need.

I was repeatedly disappointed by the dismal slowness of small C
routines.

Even if JOGL does no matching, you still might cook something up with
Java to bundle up an array of work packets and send that off to C in a
one go to be dispatched.


You don't want C to call Java methods either. So you want to massage
your data into a form that C can eat directly, e.g. little-endian
arrays of bytes.

C doesn't presume data to be big or little endian (and an array of bytes
is neither by definition). Just wanted to point this out so you don't
get screwed if you want to port your app.
 
R

Roedy Green

C doesn't presume data to be big or little endian (and an array of bytes
is neither by definition). Just wanted to point this out so you don't
get screwed if you want to port your app.

C itself just goes with the flow of the native representation both
internally and for i/o. You must know what it wants to communicate
with it.

Java does all I/O big endian, and keeps you from finding out how it
works inside big or little endian.

see http://mindprod.com/jgloss/endian.html
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top