Very low performance with opengl...

[quote]The new 1.5 starts up considerably faster than 1.4.x. Shame the server VM doesn’t.
[/quote]
Well for servers the startup time doesn’t matter, and since it’s being called the server VM…
Of course, like you, I’d welcome if SUN shipped the server VM per default with the J2SE. :slight_smile:
The ideal VM would be as fast as the server VM and start as fast as the client VM, hehe…

Class Data Sharing[quote]In J2SE 5.0, class data sharing is supported only with the Java HotSpot Client VM, and only with the serial garbage collector.
[/quote]

Can’t understand why class sharing isn’t available for server.

Have you noticed that tuning option for two phase compilation…? I wonder what that’s all about.

Cas :slight_smile:

You wouldn’t say that if you had to (re)start big servers many times a day because you were developing startup code (whinge, whinge ;)).

What? Argh! There I was, naively expecting that I’d be able to run lots of copies of server and client VMs simultaneously and see some serious RAM usage improvements (the idle RAM usage is small for the stuff I run in server JVM, and the clients often use very little RAM beyond the standard lib classes).

There’s a new 66.29 driver from nvidia works now works nicely with the openGL pipeline of Java2D. I’ve got a small sample benchmark that takes 9,7 secs (client HS) and 7,3 secs (server HD) without the openGL pipeline and 3,5 secs (client HS) and 4,4 secs (server HS) with the openGL pipeline enabled. Of course a factor of 10 would even look better, but 1/3 isn’t bad either… Especially if I compare it to the Cairo c++ version of the benchmarks which takes 20 seconds for Xlib and 10 seconds with the glitz openGL backend.

Does anyone have a clue why the openGL pipeline runs faster with the client hotspot than with server? I have the same behaviour on windows too…

I just ran the benchmark on a JRE 1.4.2_05 (on SuSE 9,2) and saw a strange result, since it took 4.2 seconds for the client VM and for the server VM. Strange that performance has degraded from 1.4 to 1.5…

[quote]There’s a new 66.29 driver from nvidia works now works nicely with the openGL pipeline of Java2D. I’ve got a small sample benchmark that takes 9,7 secs (client HS) and 7,3 secs (server HD) without the openGL pipeline and 3,5 secs (client HS) and 4,4 secs (server HS) with the openGL pipeline enabled. Of course a factor of 10 would even look better, but 1/3 isn’t bad either… Especially if I compare it to the Cairo c++ version of the benchmarks which takes 20 seconds for Xlib and 10 seconds with the glitz openGL backend.
[/quote]
Hi there,

I was also happy to read that Nvidia had addressed some of the performance and robustness issues that were affecting the OGL-based Java 2D pipeline in their 6629 drivers. I’ll test out the new drivers this week, but in the meantime, could you verify that 5073409 (crash on exit, etc) is fixed after installing the 6629 drivers? Once I’m convinced that the problems are resolved I’ll be able to close out 5073409.

Also, do you know how much faster the 6629 drivers are for your microbenchmark compared to the 5336 drivers? I suspect that they improved the glDrawPixels() issue (described in 5020009), but it would be great to hear your take on it. (For example, is the intro screen in Java2Demo faster now with the 6629 drivers?)

I’ve sent mail to our contacts at Nvidia to get some more info about what they’ve fixed specifically. As I mentioned, I’ll run some benchmarks later this week with the new drivers to see what’s improved.

Thanks,
Chris
Java 2D Team

Has anybody till now tried the new drivers?

My Laptop is at repair so I can’t check it out :frowning:

I also would be interrested about normal swing benchmarks, that do not crazy stuff like clipping and transformations, simply fills lines and text.

Any results till now?

Thanks in advance, lg Clemens

I tried them (two different Linux boxes), havent done any benchmarks, though. Things look rather good. Works much faster and stable, although I still can crash (better to say, hang) SwingSet2 and Java2D. And can see some rendering artifacts here and there. But speed is really ok, and there is no crash on exit bug anymore.

66.93 has managed to introduce atleast 1 very bizarre bug =/

I left C&C: Generals idle for about 4 minutes, came back and found my mouse cursor had stopped responding to mouse motion.
While annoying, this was no great suprise… until I realised the mouse hotspot was still active :S

I could still move the mouse about, and click stuff, its just the mouse cursor icon was not being rendered where the mouse clicks were being registered :slight_smile:

I quit Generals, expecting the issue to rectify itself, only to find Windows behaving in the exact same way :o

It took a restart to rectify the problem, and havn’t seen it happen since.

Very peculiar :S

meh, it did it again =/

Mouse cursor stops moving, but the mouse hotspot is just fine O_o

Seems the latest nvidia drivers are buggy (atleast on the GeForce 6800GT)

Strange, as I would have thought the focus of any new drivers would have been to improve performance on the latest cards (which the 6800 certainly is :S)

Maybe its just the game, as this is the 2nd time Nvidia drivers have broken C&C: Generals =/