Looking at the source code for the Hotspot server vm (1.4.2), regarding 'OptoScheduling' there is a comment above this optimisation option when appled to x86 architectures:

"Peephole and CISC spilling both break the graph, and so makes the scheduler sick."

Sounds like you might break your program?

For anyone interested in what options are available in the server vm, as well as which ones are turned on and off by default, go download the community source 1.4.2 source code and look at:

c2_globals.hppc2_gloabals_i486.hpp

(Aside : Interestingly whilst looking at this source, I see no evidence to back up the claims that have been made that the vm will optimise code depending upon the type of x86 processor (AMD, Intel etc), apart from selecting SSE if available. Is this another one of those "theoretically the vm could ..." claims, where in reality it doesn't? Hmmmm....)

How fast is Java on OS X? Taking a look at the Scimark benchmarks results, I see Apple's VM consistently giving results below the 100 mark, yet other VMs like Sun and IBM give very high results.

Now I know that Scimark is a microbenchmark of sorts and the usual caveats apply, but the results are still surprising.

Is there a problem with the Apple VM, or is it something to do with the PPC architecture?

A bit late now to reply (maybe) but I think you will find the PPC architecture is better suited (more registers for example).

The problem you are seeing is probably the lack of a server VM for MacOSX. That puts it about 3x slower than it could have been. It annoys the hell out of me, all I can suggest is you lobby Apple about it (the guys at Sun/Java gaming group don't seem overly bothered, but then it's not their platform underneath). It's a crying shame, as I suspect (with proper instruction scheduling) a G5 based server VM might be one of the fastest Java based number crunching platforms out there!

Andy.

EDIT : When I get my own G5 (soon) instead of borrowing one, I will have to try some C# or J# using mono to see what the Mac platform can really do. That'll put the cat amoung the pigeons around these parts (yes I'm trolling)

...but sometimes the reason technical things don't get done have nothing to do with technology at all and let's leave it at that.

Thats what worries me...

Quote

With regard to the release of the benchmarks, benchmarks are just like salesmen: they are what you want them to be. Not slamming what you are proposing, but it is what it is. From Futuremark to DS Benchmarks, they have all been proven to have been skewed in one way or another.

Well my saleman would be demonstrating the need for structs!

Quote

At the very least, this has been a very interesting thread Glad to have you here in the community and hope you have some fun here as well

Shouldn't that be a question for Apple? In any case be sure to file a bug report with Apple about this. That's apparently something they use to prioritize their work. I know that they are getting the message with regard to the poor graphics performance in their JRE... but I'm not so sure that they have got the message with respect to needing a server VM.

Anyway.. above you quoted some 91% figure with C# and I didn't quite get what you were trying to say? Are you saying that C# was faster than C++ for that case? (and Java is slower, thus making it look that much worse?)

In any case.. enough of this talk.. why not come up with a benchmark program and we can see how it fares? The guys here can help to make sure it is coded properly and we can try our best to make it a fair test. Realistically we should track the development time and all that crap to get the whole picture.. but since right now you are only interested in execution speed, it will make things simpler if we concentrate on that.

Sure it's a question for Apple, but I'm sure Sun also know the answer (strange silence every time I ask the question though). I can't imagine the fact that Apple were going to run a server product (WebObjects) on a client VM didn't get picked up by the guys at Sun (you want to do what?!!!!). And as it's Sun thats pushing the cross-platform abilities of Java gaming, I'm asking them.

Yes, C# was fastest. Relative to C++:C# 91%C++ 100%Java ~200%

When I've got some time I'll think of a benchmark to post, I'm sure you guys will rip it to shreds Can't send any of the stuff I'm working on though.

Amazing then that most RTSs clock in around 30fps or lower. Even the mighty (and quite awesome) Dungeon Seige clocked in between 18-26FPS on high end systems. Ah! You must be thingking about the FPS crowd The fact remains that while we like to beleieve that the industry is completely speed obsessed, the fact remains that it is not. Look at the BIGGEST selling games of all time and you will see less speed intensive games than speed hooked games.

Must be that we Brits are far too obsessed with racing games

Of course it depends on what you are doing. And for my part, I'm not obsessed with the frames-per-sec (we seem to be quite happy with 24 at the cinema, but then they have motion-blurring!), but with trying to do a lot of complex maths in the tiny amount of time I have per-frame.

Anyhow Chris, a much more pertinant question: why don't Apple have a Server VM on the Mac? Seems like a daft thing for Sun and Apple to allow to happen (unless Sun is viewing the Apple X-Serve as a threat )

I also tried unformatted float arrays/native buffers. Improved things a marginally when I hit the memory wall, but killed things once the buffer is in the cache. This means coding differently based upon whether I expect the buffer to stay in the L2 cache between game loops or not :-/

Unfortunately the stuff I am working on cannot just fill a native buffer once at the start of the program - my geometry is dynamic.

And as I don't use my Vector3 class polymorphically and I turn RTTI off, the C++ data structure is exactly the same as the C struct. The Java object costs I mentioned came from the latest HotSpot VM docs.

EDIT - I just compared some code C# that uses structs to see what this out-of-cache performance is like with value-type arrays, and it turns out it takes only 91% of the time that of a really good C++ program (without assembly) to process one of my Vector3 arrays! (Falls over in shock...) The guys at Sun really need to get cracking on 'structs' or whatever they are going to call them.

Shawn - keyboards are for wimps - whats wrong with plugging bits of wire into a breadboard ?

If you folks are looking for some ready and actively maintained (does seem that way) benchmarks, you may want to give SciMark2.0 by Pozo and Miller a shot:http://http://math.nist.gov/scimark2

Both Java and C sources are available.

Fine for benchmarking linear algebra etc, but I've not found these are not always representative of 3D code, simply because large Vector arrays invariably throttle on the L2 cache-memory bottleneck. Of course the native code does this as well, but there twice as many bytes to move in Java!

First off, I hope my rather childish turn of phrase didn't drive you away in any part. As swpalmer indicated above, maybe I picked up on a tone that was intended to be there in your posts. If anything, it'd be pretty useful to have an objective C++ games developer around.

Not being from the games community as it were, I'm really interested from a hobbyist point of view about this. Is the whole the games community really obssessed with speed? I'd always assumed that first person shooters were that way oriented, but other games didn't seem so bothered.

Kev

Sorry about the tone. A side effect of the long debate I had with Jeff and frustration at the glacial speed Sun moves at. (Now how big was that Microsoft settlement Enough for a PS2 VM not to dent it too much? Perhaps a port to PS2-Linux so that anyone can play with it?)

I guess the NWN dev team didn't have to worry about speed, I should have said 'a large part of the games community'.

.. and we would rather focus on that then spit out another micro-benchmark that will be tainted one way or another in terms of getting Java more accepted in the game industry.

But just imagine what would happen if there were benchmarks that showed 3D computation in Java were indisputably on a par with the very best C compiled with the very best C compilers, especially if the benchmark code were open so that all could see the comparison was fair?

The fact is that the games community is obsessed with speed, which probably comes from too many 90 hour weeks trying to get their frame rates from 15fps to 60fps whilst not being allowed to simplify the game.

You hang around for a while and get a feel for different people's perspectives on things and try to use your best judgment. Neither Jeff nor the rest of the GTG are trying to deceive as far as I can tell.

I'm sure this is the case. But why would I want to hang around a forum that rips to shreds anyone who dares to question Java? This actually started because Jeff started a debate as to why games developers don't use Java. I just thought it would be a more interesting debate if the other point of view was put across, but things have gone way too far, and out of control.

Quote

The mere fact that Java technology is so much younger than C/C++ technology is perhaps reason to remain optimistic that Java will get better still.

Agreed. But looking at the machine code that the JVM produces I would hazard a guess that vectorisation is the next step forward for 3D code, perhaps by introducing vector and matrix intrinsic types. This would not just put the 3D code on a par with C++, but surpass it, whilst solving the operator issues without having to introduce operator overloading into Java. It would also enable a much more effective PS[2 || 3] VM later on.

Given Sun's primary markets I don't envisage them putting many resources into this without immense pressure from their users, and I don't see the numerical users working together to get what they need (witness the operator overloading debate). Hence a little challenge might make the point? Or perhaps a previous poster had the right idea, perhaps there should have a spec3D benchmark for vector performance comparison?

Quote

I get from the above that Java enforces better design practices. Which I extrapolate to a savings in development time for a complex project. (This test is far to small to realize significant savings at that level.)Of course Java has much better tools for re-working code anyway. The optimization pass may cost more in Java than it will in C/C++ I do not deny that. But I think that the other aspects of Java will have saved you more than the difference.

I meant you have to prematurely optimise your code before you know where the bottlenecks are, if you're not to end up re-doing large chunks in c++ (either that or use a crystal ball ). Maybe you're right and there would still be an overall saving, I know I couldn't live without Eclipse (even with it's new garish workbench )

Quote

There is some truth to this. A comparison of just these feature with a variety of C/C++ compliers and Java VMs would be interesting and educational I think.

Agreed. And it might convince Sun to go that extra mile to vectorise it. But is anyone here interested (apart from myself) in this? I thought everyone here writes off microbenchmarks, despite Jeff talking about them in his book (yes Jeff, I have read it, albiet a long time ago).

You reminds me of a uni student that is 2 month - 2 years out of school. A lot of absolute terms, a lot of talking about expensive tools and speed. I didn't notice such demands from other game developers. You didn't answer me, what do you mean by physic engine? -_-Do you actually mean a World engine?

Do you know the macro assembler? It's more safe than inlining and more efficient. It forces you split your code to different parts, not just add inlining to some points. Have you looked at your code after few years? Still readable?Yes it will do it somehow, so you should stop worry and...How it would work on an AMD? (or 64 bit, or 128 bit)

Best idea would be, if you need graphic engine equal to Havok2, write it down. It might benefit you and the community well. Or perhaps some nice collision library would be better. (Moving points in 3D space are already done.)

Nothing personal, I didn't understand your questions, and the stuff above is just plain random. I meant inlined as in the interpetation all C++ programmers assume, i.e. as in inlined C++ methods. And although the challenge was simple, you expect me to write rules that tell you how to implement Havok?

... Hey, I've got a better idea - why don't you call Havok up yourself and see if they'll open-source it to the community

I'd sack you for stating that physics only takes up 5% of the game without ever knowing what the game is and what it is doing (Sure, yours might take up 5%.)

I'd like to take a look at your game, the last time I checked the site wasn't available. I'll try again now.

EDIT: You need more bandwidth, 11k/sec is painful!

EDIT: Nice graphics and sound - I'd guess you were in your very early 30's? (No physically based modelling to speak of though - if you're game isn't doing much in the way of physics then why tell me it's only 5%?)

EDIT: Get Jeff to pull the plug on the thread then, I think you've said it all.

Interesting points, and worth explaining what I have found to be some of the problems with Java:

Quote

I don't think Jeff checked specifically the performance on the Mac VM befiore he made his response. I think he based his response on what he knows about the Win32 VM.

So which 'facts' do I choose to believe, and which do I reject

Quote

It is not fair to ignore so many factors of Java in this sort of argument. The main argument that I think jeff was trying to get across is that Java is for most games plenty fast enough. He said it was as fast as C/C++, but he did not say it was faster or slower at any particular thing. As should be evident, there will be some things you can do faster in C and some things you can do faster in Java. Jeff even mentioned this with regard to an MPEG codec where it is clear that C/C++ and SIMD hand coded loops will give you a significant boost.

Even if 'most games' were referring to AAA titles, 9/10 of those make a loss when they go to market. We have to aim higher than that if we want a return on the development costs. Remember this thread came from a blog directed at mainstream games developers, and was never intended to criticise Java for any other type of game or any other purpose.

Intel C++ will vectorise your code using SIMD and prefetching for you- no hand coding required.

Quote

If you want to go through with a contest, then you have to make the rules a bit fairer.. I think C/C++ will win anyway.. since I believe the nature of this contest will play more to C/C++ strengths that it will to Java's.

I'm interested to hear why you think this - is it that you think it will involve lots of unordered array access or something else?

Quote

But, if you say no to JNI then you must also say no to any use of assembler (inline or otherwise) in the C/C++ version.. since it not much different than using JNI.

But I can add a little inlined assembler in a few seconds, to the points that bottleneck my code. In JNI things have to be planned long before you know if you are optimising prematurely (a bad thing), otherwise it requires a huge amount of re-working the code afterwards, at which point you have lost one of the major selling points of Java: speed of development.

Quote

Of course I think the whole thing is somewhat ridiculous, since if you were doing a game in Java and you really needed a specific bit to take advantage of things like SIMD you would code some small bits in assembler/C with JNI and move on. The time you saved using Java for the rest of the game will more than make up for any time lost optimizing a small specific bit with hand coded assembler.... I think that is a large part of the point to using Java for anything. It doesn't mean put blinders on and pretend that everything in Java will be as fast a C/C++.

But in my case I have found when you have optimised all of the rest of the Java code, profiling shows the majority of the time is spent in the vector and matrix classes, and you can't optimise just these classes using JNI (as you point out below). The big limitation with JNI is it is not a fine-grained optimisation method, and this is why other vendors have tried and generally failed with things like JDirect (which Sun put a stop to) and CNI.

Quote

I have written code which runs faster in Java than what I got out of Visual C/C++ 6.0, with the exact same algorithm. I know that Java is not inherently slower than C/C++. But I also know that there are great many things that I can do in C/C++ faster than what I can get out of pure Java. As Jeff pointed out, random access into arrays is one such thing.

Visual C++ 7.0 gets a huge speed bump over 6.0 for the same reason Java 1.4.2 got it's floating point code speedup - using scalar SIMD for it's maths. And if you are targeting the Intel platform, Intel's compiler wipes the floor with Visual C++. C++ compiler performance is still improving in leaps and bounds, so Java is chasing a moving target - do you think it is fair to compare the lastest JVM with a 6 year old compiler like Visual C++ 6.0? Most comparisons seem to be made with this or GCC.

Quote

I think it was Shawn K. that did some tests with basic floating point math and found that it was faster to code the math in Java than to try to be clever and use JNI for the math intensive routines.

Anyway I partially agree with Athomas that there is no point trying to convert C/C++ users. Just make great games in Java and be happy.

Who said I was a C programmer? I'm a little more pragmatic and use at least 4 different languages (Java included), using whatever is best suited to the task.

But for sure be happy with what you are doing, and do it to the very best of your ability regardless of the language you choose to do it in

Do you ever answer anything without trying to be offensive on the way?

Kev

Kev, my last post until I hear from people taking up the challenge.

It's a direct question born of frustration. Either you did or you didn't. If you did, then you obviously didn't understand my point - I have tried to be crystal clear but obviously failed. If you didn't then where is your objectivity?

I guess you are easily offended which was not intended, but think about which of the above it was...

2/ If you really believe the assertion that I am challenging, then put up $500 and I'll get some rules up to agree between us. The only objections to rules that I will listen to are those that mean the challenge does not fit the statement I made in my open letter.

3/ Otherwise forget this thread. I am NOT interested in a religious debate, nor any of the other debates some of you guys have tried to turn this into.

I look forward to hearing fromt those of you who believe my challenge can be met.

That's just simply not true, however unimpressed you are with mac's current JVM. Doom 3 in java would probably run like a dog on the mac if it is really that slow, I'll give you that. But that's just one game in just one genre. The majority of games you *can* develop using java *and* run on the mac perfectly well, which makes java a very viable option for cross platform games development. Alien Flux being a real life example from the indie side of games development.Your challenge to jeff won't prove otherwise, whatever the outcome. When you 'win', it will prove the mac version lags behind performance wise, nothing more.

To reiterate myself for the 1000th time, Jeff has made many bold assertions about Java in his discussion with me, and I'm calling his bluff on just one of them - that cross platform Java performance on Mac and Win32 is a shining example to all of the C programmers out there.

Jeff put words into my mouth:

"I respond:

So you are conceeding the desktop argument and only arguing PS2?

Cool. 'cause thats theoretical anyway today.I'm glad to know you feel Java is the equal of C/C++ in all the environments its currently deployed "

which I never said. You assume I think performance on Win32 is up to C. He has accused me of creating 'straw men' as he calls them, and putting words into his mouth. Well here is a shining example of him doing it to me. Curiously he seems to imply that he thinks 'Java is the equal of C/C++ in all the environments its currently deployed' (to quote him). Isn't the Mac 'an environment' that java is currently deployed in?

It seems you guys are trying to swivel the discussion around from where it started, so try reading the whole blog, discussion and this thread before jumping in. This is not a discussion about the suitability of Java for 2D and simple 3D games. Maybe try reading my open letter to him, it's not very long and says everything there is to say about the subject.

Hm, so if it's common knowledge that the Mac JVM doesn't perform as well due to lack of server VM, then there's no point at all in this challenge now is there?I wouldn't put in my money, that's for sure...

So for argument's sake let's assume you proved the current Mac JVM is not as fast as the Windows, Linux and Solaris JVM's, and so cross-platform games programming has performance issue when it comes to Mac... So now what? The Mac JVM is likely to catch up, and most of Jeff's points still hold.

Err - what like that Java for gaming is cross-platform across Win32 only?

Jeffs blog was about why games developers should be using Java, and given that there are no JVM's on 80% of the target market we should take the Mac and Win32 examples on faith as how good the console versions could be. I'm not impressed with the Mac version, and as Sun licenced it to Apple they should have ensured it also demonstrated the same level of performance that other platform users get.

Would you let us finish the Linux/x86 port first? More seriously, we have other targets in mind apart from the Mac.

Then, why should Sun be to blame about poor Java performance on Macs? Apple has licensed J2SE, go tell them to speed it up. Let's compare on platforms that Sun supports (though I doubt there are many Solaris gamers out there. )

In any case, it would be more interesting to compare on Win32 and PS2, but that brings us back to the major flaw in Jeff's "Java is good for cross-platform game development" statement - the shortage of JVMs for game consoles. C++ programmers caring about portability can get CodeWarrior for Win32, Mac, Linux(multiple CPUs), PS2, GameCube, Palm OS after all...

We would consider throwing in a JET Pro license. Would that do?

Jeff finally conceded there are no console VM's, but still asserted that for desktop cross-platform, specifically Win32 and Mac, Java still matches C performance. So the challenge tests that assertion.

Perhaps I should explain to those of you who haven't done too much Physics why I chose the type of simulation.

I want it to test the performance of a physics engine. I can't ask all the entrants to write the equivalent of Havok2, so I've chosen a smaller problem that is nice and simple to code whilst still retaining all of the processing that a physics engine would have to do.

The sim would demonstrate:

Collision detection: Capsules are the simplest form of geometric shape I can think of that allows rigid body motion to be demonstrated without friction. I need to be able to put the maths into the rules! (Capsules are like cylinders with rounded ends, rather like some of the pills you take when you are ill). You can simply plug in your own CD engine at a later date if you want to progress the code, everying will still work. Believe me this simple case will still take a bit of coding as you will have to back the simulation up to find the exact time of collision, for each collision in the simulation step.

It makes more sense to run the test on Win32, which was the major desktop gaming platform last time I checked. I think Andy mentioned Win32 as an option.

Why so? JET Pro can compile any J2SE program. Classes that may not be compiled ahead-of-time will be compiled just-in-time. So JET Pro is essentially a JVM.

Hey dleskov, nice plug by the way

Although it doesn't fit in with my original challenge to Sun and their JVM, in the interests of gaining knowledge it can play on the Java side, (you will still be limited to pure Java). However the challenge was to prove that Java can match native code performance, for a physics simulation, across the primary platforms Jeff mentioned (Mac OS X and Win32), so you had better get porting your compiler.

If you do have a Mac version, and are willing to throw in $500, great.

And before anyone else gets carried away expecting to use a beta release of the JVM, forget it. You code will have to to be compatible with Apple's 1.4.2 JVM, and the latest release on the PC, which is also 1.4.2_xx. That will be in the rules.

Regardless, if someone tells me something about some thing, and I say SHOW ME and they can't show me to my approval then I just go about my business. What is the fire on your belly over this? If you want to prove something to yourself, write the app. If you want to prove it can't be done to everyone else write the app.If you don't BELIEVE it can be done, then really aren't we talking religion and not facts?

In any case, what is your goal?

Shawn, it's interesting you have questioned my motives, a question JK should have asked. I have implemented everything necessary to know what I need to know, so why indeed am I doing this?

Well, it started like this:

Jeff wrote an article suggesting positive reasons about why games developers should be using Java, and he also invited responses. I supplied a response which I hoped would encourage him and others at Sun to look at the issues that, at least from my point of view, show why games developers are not ditching C++ and adopting Java. When asked supplied reasons why I can pretty much do in C++ what he called advantages of Java, he resorted to patronising/insulting me. Quote 'The compelxity problem, which is what was identified and called "the software crisis" 25 years ago, is well recongized as a critical problem in the industry today. Maybe the right answer is to have you personally retrain the industry'. Is this the kind of professionalism you would expect of a representative of Sun to one of the developers he should be trying to win over, especially as it was only provoked by a technical discussion? I don't accept what JK asserts, and when I asked for evidence JK's response was 'lets plonk this troll'. 10/10 for developer relations so far?

I still wanted this test for three reasons:

1/ It will turn out that I am wrong and JK is telling me the truth, in which case from now on I develop any code not required on consoles in Java, and save time and development costs. However none of my research leads to this conclusion.

2/ It will turn out unequivocally that Java is not as fast as current game dev methods, in which case Sun might see the light and be motivated to really get there. Eventually I get to drop C++.

3/ The games development group in Sun isn't really serious about games development, in which case they won't want to prove to games developers what they really can do, or will ignore the results of my challenge if it does happen. In this case I resign myself to coding in C++ until someone like Microsoft do get there (and being a more pragmatic and agressive company I'm sure they will).

Actually on a higher level I also wanted to test if Jeff was running an operation genuinely aimed at wooing commercial games developers. The lack of evidence and the way he has treated me answers that, so what am I doing here? I've seen and heard enough to not want to waste my time here any longer.

FYI: The Mac does not have a server VM (a documented fact on Apples website), and so runs about 7x slower than C code. You see a similar thing when you compare the client VM to the server VM on Win32. Unless Sun/Apple have a server vm tucked away somewhere, I would say that Java is not ready to support cross platform games.

Why is this existing test not being used as the example? The code is available you can review and debate it merit here. And it is a complete set of test across several language....Please explain your reasoning for dismissing this...

Hiya Shawn, glad to finally make your acquaintance

That test was flawed in many regards:

The comparison was to GCC. Games developers use the fastest compiler available on each platform, not GCC. GCC is not comparable to Intels or IBM's optimising/vectorising/profile guided compilers.

It was no test of computational 3D geometry, i.e. 3D games coding. In my opinion the tests were the worst micro-benchmarks I have seen in quite a while.

There are many opportunities to vectorise code using SIMD, which the Intel compiler can do for you, or you can do yourself by inlining a few intrinsic functions into your vector and matrix cpp classes. Apple sped up a real application (Noble Ape) by 6x over C based scalar code just by adding a little Altivec code.

Have you seen the performance of the JVM on the Macintosh G5? If not I suggest you pop down to your lab or to Cupertino and check it out.

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