Fully utilising Multi cores/Multi cpus?

Performance Tuning
#21

And there are probably more, that was just the first that I found with a quick Google search.

#22

I am back from my honeymoon which was a nice diversion from real life :slight_smile:

I have not yet had time to get back into this project but just for kicks i decided to make a native windows executable of the real time raytracer to see what the performance would be.

I was both very shocked and very disappointed! When using Excelsior Jet to make a native win32 exe there is a 33% increase in performance as compared to java 1.6 JRE. I did not think that there would be such a marked difference… infact i thought the hotspot complier would be able to perform better optimisations…

Here is the native executable (9.9 meg) and there is the jar it was compiled from.

Please let me know if you see similar results… perhaps it is just an oddity with my system?

During my holiday i have thought up some other optimisations which may help speed up the rtrt. However the first thing i will attempt is the stack based tile render discussed earlier.

#23

Try the 1.7EA JDK. I was getting 30% speed increase with my own tests.

#24

thanks for the link. It will be interesting to see if any improvment as going from JRE 1.5 to 1.6 gave about 20% increase.

#25

hmm… going from 1.6 to 1.7 seems to have only a minor increase 1-3% which could be easily be staistically insigificant

more interestingly is that on a core duo system, java 1.7 is actually slower (~27fps compared to ~30fps with jre1.6)
on the same core duo system the native exe version is running at ~41 fps

#26

I have had some free time and have implemented the tile-stack based render thread load balancing and from my tests with a core duo laptop i am achieving a high level of cpu(s) utilisation.

I would like to ask if those with two or more cpu(s)/cores could run the latest version and let me know if you achieve a high level of processor(s) utilisation? If you could list your system and the fps that would be great as well :slight_smile:

You can compare it to the version 8 in the above post which does not implement the stack based approach.

#27

What that really shows you is just how good Jet is :wink:

What about the 1.6 server VM? In days gone by I generally found the server VM to be about 30% faster than the client VM, matching Jet typically (except of course on startup time which Jet rules).

Cas :slight_smile:

#28

athlon 64 x2 4200+
3gb ram
1.6 client vm

29 fps / 88% cpu with version 8
32 fps / 99% cpu with version 10

#29

2.16 Ghz Core 2 Duo, Java 5 on Leopard (Activity Monitor reports 200% CPU if both cores are fully utilized)

33 fps, 160% CPU with version 8
33 or 36 fps, 175% CPU with version 10

Version 8 was consistent - always around 33fps.
Version 10 varied on each execution. One execution would be 33 fps, another would be 36fps. Maybe something to do with thread scheduling?

#30

AMD 64 x2 4200+
2gb ram
1.6 client vm
winxp

v8: 33fps@88%
v10: 35fps@95%

(Guess my ram is faster than Martin’s.)

edit:
1.6 server vm

v8: 46fps@85%
v10: 50fps@91%

#31

Server VM pretty much lives up to expectations then eh?

Cas :slight_smile:

#32

12.5 fps for exe
9.5 fps for jar (client jvm)

yup about 30% faster

jvm 1.6.03
cpu XP2000 1.6ghz
gpu ati x800
ram 768MO

#33

Thanks for all your testing!

That is a surprising difference between the server and client jvms. Did i read some where that sun was thinking of making a jvm in which effectively the client jvm will be as good as the server jvm and thus just the one jvm?

Hmm, 175% is not bad… still better than the previous version. There are still parts of the program which are not parallerised some of which can not ever be but some which can however it does not make sense to do so until i implement a bounding volume heirachy.

So I am aiming to achive 190% utilisation.

About the FPS per run on version 10, i have changed the fps counter to use a smoothing average. For the first 3 seconds it uses the instant fps. However after 3 seconds it uses the following formula:

avgFPS= (prevAvgFPS*2+currentFPS)/3

perhaps this is causing the difference between versions? I am not sure why it would… all it will do is be less responsive to reflect change in fps.

#34

Version8:

Client-jvm:
30fps - ~170% load

Server-jvm:
46fps - ~170% load

You should check for thread problems in your code, starting your app with -Xint gives me sometimes a wrong window-size.
Are you doing all modifications to Swing/AWT-Components on the EDT?

Core2Duo T7200 laptop, 2ghz
jdk1.7.0 build22

#35

The JFrame and components are created and setup in the constructor of sub class of JFrame. The frame and its components are never modified at any other point in the program.

A buffered image is drawn onto a back buffer of a BufferStrategy and then flipped to be viewable.

The flipping does not occur on the EDT. but i thought that it was not necessary with BufferStrategy you are determining when to “paint”… is this not the case?

#36

[quote]The JFrame and components are created and setup in the constructor of sub class of JFrame. The frame and its components are never modified at any other point in the program.
[/quote]
This could be the problem, and I guess it maybe is the root of the problem on my machine.

You create the JFrame and your components on the main-thread, not on the EDT. This is a violation of Swing’s threading rules, and it is best-practise to even do component setup in the EDT.

The rendering itself can be done by any thread, because as far as I know all Java2D-related stuff is thread-safe.

lg Clemens

#37

Really?! All these years I have been doing it incorrectly… Can you point me to an approriate example/tutorial? All the examples i have seen on the Swing Tutorial have the components set up in the main thread… e.g. http://java.sun.com/docs/books/tutorial/extra/fullscreen/example-1dot4/DisplayModeTest.java

#38

It should be completely possible to construct and assemble Swing components in any thread. What you can’t do then is diddle with them or act on events in any thread.

Cas :slight_smile:

#39

Ah, I think i know what the problem is…

In order to get the frame’s inset information, the frame has to be be set visible. I then re-size the frame based on these inset information. Is there a way of obtaining the frame’s decoration dimensions before making it visible? Failing that I will put the re-size code in a swing worker to be performed by the EDT

#40

I think you can get the decoration dimensions after you call addNofity() on the frame.