Exception in thread "main" java.lang.ExceptionInInitializerError at apollo.Surface.<init>(Surface.java:59) at test.TestLevel.run(TestLevel.java:69) at test.TestLevel.main(TestLevel.java:54)Caused by: java.lang.IndexOutOfBoundsException: invalid hotSpot at sun.awt.CustomCursor.<init>(CustomCursor.java:61) at sun.awt.X11CustomCursor.<init>(X11CustomCursor.java:26) at sun.awt.X11.XCustomCursor.<init>(XCustomCursor.java:27) at sun.awt.X11.XToolkit.createCustomCursor(XToolkit.java:742) at apollo.CursorManager.createInvisibleCursor(CursorManager.java:68) at apollo.CursorManager.<clinit>(CursorManager.java:37) ... 3 more

There mere fact that both code versions actually differ is already food for thought IMO (that was not obvious from the documentation I read about 1.5).

@Mark,I do not think so, this syntax is used in lots of places in java source files. At worst it does not optimize anything but I would be surprised if it slows down the test.

@Anders,Did you wait for the warmup to finish as Jeff suggested ?

@Jeff, This kind of micro benchmarks can easily go wrong but they are interesting when they mimick the hot spots of your program (small loops called zillions of time to process audio/video data for instance).

Are you saying that the hotspot JVM is 'smart' enough to remove array bound checkings before 1.5 ? (I thought bound checkings could be only removed by a flag) It means it is able to analyze that the index is not modified inside of the loop code, that the increment is contant (maybe it _must_ be 1 in order to remove bound cheks). If so, then it is not obvious there is any gain at all, otherwise, the loops with the new syntax should be faster.

I have just downloaded 1.5 and started playing with it.I made a small test with the new enhanced loops. So far I thought it was just a syntax improvment. I did not realize it can help improve the performance of loops also. Isn't that cool or did I just wake up after everybody ?

Before 1.5, one would write (some stupid test) like this:

// array is int[]

for (int i=0, n=array.length; i<n; i++) { int p = array; p=p+p+p; }

in 1.5, it becomes:

for (int p : array) { p=p+p+p; }

There is no penalty access to the elements of the array and my first tests show it is actually faster (and yes it is a micro benchmark however it have some audio processing code with tight loops goobling most of the processing time). I wonder if the JVM also can optimize the bound checks since it 'knows' that the whole array is going to be scanned ?

Princec,You are measuring also the creation of 1000000 node objects, you should move the creation of those nodes (and the associated strings) out of the insert() loop.Also, my understanding is that the heaps remain small but yours grows to 1M nodes.Toby, Have you tried the profiler (-Xrunhprof:cpu=times) to measure the time spent in your methods ?With my Ahtlon 1.4Ghz and JVM 1.4.2-beta-b19, I get (no optimization options) :

Toby,How did you measure exactly ?1 Million times insert/extract or 1 Million times for ( int i = 0; i < ints.length; ++i )insert()while ( heap.size() > 0 )extract()?or something else ?The results seem to be pretty slow indeed. Did you try without the generics because the generics prototype may be slowing down everything ? There is nothing suspect in the code AFAIK.

When I copy the controller directory to the level I am running from, it works (and only in this case).I had no luck with -Djinput.plugins (any ":" in the path makes the program fail with class not found or something).

I don't know about you but I think it is a weird behavior and I do not see the rationale so far. Any user running a program using JInput needs to copy the controller dir to the installation dir ?

Thanks, but no luck so far. I will do more tests later.To say the least the packaging is 'creative': when I install JInput from the zip file, I getjinput.jat both under coreAPI/bin and plugin/DX8/libjutils.jar both under coreAPI/lib and plugin/DX8/libdxinput.dll is both under coreAPI/src/tests/controller and plugin/DX8/bindxinput.jar is both under coreAPI/src/tests/controller and plugin/DX8/binSo far, I did not know I needed to include the controller dir under tests or create a controller directory.I created a jinput dir in my working dir and put jutils.jar and jinput.jar in there. Then I created a controller dir under jinput and copied dxinput.jar and dxinput.dll in there.Then I tried to run my test (if it basically a wrapper around ControllerReadTest)java -cp .;./jinput;./jinput/jinput.jar;./jinput/jutils.jar;./test/classes;./classes test.testJInputSame result: no error but only 1 empty window because no controller is detected.

I have been trying to test JInput lately. I downloaded the latest lib/bin, compiled and ran the tests programs.On my config (WinXP, athlon, no joystick) I was expecting to see a mouse and keyboard in the list of controllers but I get nothing. I wrote some code also to list the controllers and I get nothing.So I tried the webstart based test at newdawnsoftware and I see my controllers.I guess I must be trying to do something stupid. Also I am confused about why there are several libs with the same name in both coreAPI and plugins (which ones should be used ?). What is the difference between these libraries.

blahblahblahh,you are right. The rendering problems occurs probably outside of the renderer. However I do not think that traversing the tree in an instable state should lead to a crash.After looking at the code involved, it looks more like a test is missing to check if the currentCellRenderer is null in javax.swing.plaf.basic.BasicTreeUI.paintRow (the check is made in other places in the same class).Maybe it is possible to the synchronize on the getTreeLock() of the tree during model updates to block any painting.

Correct me if I am wrong but accessing or inserting an element in a balanced (red-black) tree is O(log n). So, using a SortedMap is still faster than using a radix sort. The only advantage of the radix sort (or others) I can see is when basic (non object) types are managed (then again it is possible to write a class that would manage such types).

Take a look at the apollo sound library (see appropriate thread also under javasound), there are mechanisms to play sounds in parallel and optimize resource consumption of audio clips through caching.Now, the real question is no so much how many you have but how many sounds you want to play at once.

At least the good old Albert was doing something interesting while being a clerk at the patent office. Fortunalety he forgot to patent relativity Let us hope there is another Albert who is doing something valuable beside granting a patent for the 1 click buy !

As for the definition of a patent, it is nice. Maybe we should send it to these patent offices ...

PS: AndersDahlberg, we have you are name and you address ... we are coming ...

Just a few final comments on EP ... At least it is interesting to hear about somebody having a good experience with keyboard sharing. I am still doubtful that in works in average though, maybe the pairs have to be 'special' misterX, I agree with you. The only thing to remember from Extreme Programming IMO is the "test as often as you can" idea.OK.. back to the topic. I did not mean to hijack the thread. Start small ... start with easy games.

Personally, I see Extreme Programming as a new marketing buzz word and not a real work process (come on, share a keyboard among 2 people !). Sure there are a lot of guys making money with E.P. books, seminars and other blah blah. As PrinceC wrote, some people were already working like that before the marketing buzz fell from the sky.

I understand that some people may feel at ease with the do-now-rework-later kind of process but from my experience, it is more costly (at least in big projects) than a usual design-now-implement-later process.

And yes, I have been writing real programs for real customers in a real company for (too) many years.

Now, for small projects and/or less experienced people, it can make sense.

Unlike previous results, the results on the P3/NT would be enough to ban floats (or remove this platform from the targets). You did not give the version of the JVM though (upgrading could help improve the score).

Consider a game heavily using floats: it would fly on the Mac and the fast P4s (with XP) but would be implayable with a 'slow' PC with NT. Less so with integers.

"Write once run anywhere" seems really not to be an easy task as far as performance is concerned ...

I did not make myself clear. " Your results are puzzling because in the end 'we' do not know what to shoot for ".

I meant that it is not obvious from your results what to target to achieve the best speed : use floats or integers ? It depends on the platform (hardware, JVM, OS). Alias / not alias ? it all depends on the code inside of the loop AND the platform.

On Mac, the floats are somewhat slower than the ints, but all in all, the JVM/Max Os X/G4 combunation kicks butts !!!

Abuse,

micro-optimizations may be a waste of time but benchmarking them is not IMO : you are always safe with aliasing int arrays, the floats are 'usually' pretty fast (at least on the 3 config that have been tested so far).

The -server option seems to decrease dramatically the speed (unless the micro benchmark was too short for the JVM optimizations to kick in).

Geeeeee !Your results are puzzling because in the end you do not know what to shoot for.With both integers and floats, the values span (roughly) from 2 to 9 ! And the floats can be faster or slower that the ints.I note than with the new JVM, the floats 'can be' REALLY fast ... How can you be sure that the optimizations you made on your platform are relevant at all ?The only constant thing for sure is that aliased integers are always faster than non aliased.

OK, basically it is some math computation inside loops.I ran these tests several times in the same process and got the following results:

int : 5203int aliased : 4750float : 4172float aliased : 5031

The absolute values by themselves are not really important but they reveal a pattern.

First conclusion: the floats are faster that the ints on my platform (WinXP, Athlon XP, Java 1.4.2beta) !!! Incredible isn't it ?

Naively, I thought otherwise. I guess the SSE2 instructions now used by the JVM kick in to boost dramatically the float performance. It would be interesting to see the results on other platforms (SSE or no SSE). That is good news for Open GL Java ;-)

Second conclusion: aliasing is always better with ints but counter productive with floats which also was not obvious to me.

I am perfectly aware that these results should be taken with a grain of salt (if you slightly modify the code inside the loop you may end up with other conclusions).

The bottom line: it is going very difficult to optimize code since the optimization on one platform may end up decreasing perf on another platform. The only way to know is to test !

I'd be interesting in other people testing with other hardware, OS and JVM versions.

Disabling the GC is a very bad idea: if you do not create objects anyway, the gain would be small. The question is : are you sure you are not calling APIs that DO create objects. In this case, the GC is your insurance against ever increasing memory ...

Well, it is already official that Sun will show a new development tool aimed at Visual Basic programmers and the likes.We also know that this forum will be revamped.We can easily extrapolate that the JDK 1.4 will be delivered as a final version.My guess is Sun is going to show an OpenGL java library and there will be a deal announced with a company like Sony or Nokia to support java games on their platform (?).Place your bets.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org