Physics performance challenge to J.Kesselman...

[dleskov]

[quote]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.
[/quote]
There is no point for Java users do that, indeed. We are not talking religion or MLM here. But it makes much sense for Java vendors, led by Sun, so it is apparently Jeff’s job, and part of my job too.

I would sign under the paragraphs of your post regarding the use of C++ and Java together as appropriate.

Still I think a community-developed Java Game Benchmark Suite would be a good thing, even if it only allows you to compare different Java implementations and/or hardware. Perhaps it could be built as SPEC JVM98, which is a collection of real life programs. Board game, collision detection, map generation, audio/video codec, AI, scripting, you name it.

[andyl]

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.
[/quote]
So which ‘facts’ do I choose to believe, and which do I reject ???

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.

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?

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.

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.

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.

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

[princec]

Hi Andyl,

I’m one of the normally prolific posters on this forum, and generally regarded to be a Java advocate, despite the fact that most things I say are scathingly critical, offensive, or upsetting, and often specially formulated to wind Jeff up.

My only concrete qualification to comment here is that I hold the dubious distinction here of being someone who has, from start to finish, written a complete commercial Java game that runs on the three desktop platforms.

I have this to say about the whole issue (rather than the whole thread which is about 50% noise):

1. Jeff’s job is to evangelise Java without any bloody money. If he’d actually been given a sensible Microsoft-sized budget I’m sure he’d give me some of it to help him further evangelise Java Don’t yell at Jeff when he doesn’t come up with the cash, moan at Chris Melissinos to hassle the Board for more cash!

2. I’ve been tinkering with Java for many years now and I can say that it’s gotten much, much, much faster than it used to be but the state of play - right now, straight face - is that with the 1.5 server VM on Windows you’re going to get around 80-100% of the speed of a MSVC++ framerate. With the client VM expect around 50%-100%, typically lower. The Java evangelists like to dispute my lower figures, but they’re basically wrong and I don’t care what they think. And this solves your whole thread doesn’t it! Just forget what Jeff says about raw compute performance and be happy that Java code is going to get within about 80% of the performance of C++.

3. But the next point is the bit that really pisses off C++ developers and it’s where no-one ever manages to see eye-to-eye, and why the whole situation looks like children arguing over their dads’ relative merits: It simply DOES NOT matter if Java’s throughput is 50% of C++ in this physics collision detection test. If I hired you to make a technical decision for me and you based your decision on this benchmark I’d sack you and ask for the money back, too. Why is this? Because in a real game where it actually counts, you a) won’t have 30,000 capsules to perform collision detection on, you’ll probably have about 50, and they won’t be capsule shaped and b) you’ve got a lot of other stuff to deal with. Your physics collision detection might be around 5% of your total CPU time.

4. And here’s a funny thing: floating point performance literally doubled in the latest release of the JDK. Crazy stuff. Annoying too, because I discovered that floating point was too slow in Alien Flux so I wrote the whole damned game in fixed point, only to have the problem evaporate

In a roundabout way, what I’m trying to say is, the whole discussion is a waste of bandwidth. We know Java is slower than C++ (only by a factor of 2, tops, in the worst bits, but mostly it’s hardly worth bothering over the difference), and we also know it’s Jeff’s job to evangelise it, not point out its weak areas.

There’s no need to go convincing yourself that the Java version is faster or as fast as C++ in physics calculations - it’s easily fast enough and it’s a very, very small part of a game development project.

Cas

btw, regarding Mac performance: I don’t see any appreciable difference in framerates in Alien Flux on MacOS, ergo, it’s about the same speed as the Windows and Linux x86 implementations.

[andyl]

Cas,

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? ;D (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.

[princec]

[quote]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%.)
[/quote]
Correct answer But even without the benefit of a profiler I’d say that you’re more likely to hit fillrate and memory bandwidth bottlenecks than CPU ones - most games do.

[quote]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!
[/quote]
Sorry I seem to get totally shit bandwidth from theplanet for some reason. Normally I get about 30k/sec out of it, but as soon as someone else starts downloading it’s half that, etc…

[quote]EDIT: Nice graphics and sound - I’d guess you were in your very early 30’s?
[/quote]
Turned 31 at Easter (however did you guess :P), grew up surrounded by Minters and Braybrooks, and plan to write more of the same Can’t get enough of that old school gameplay.

[quote](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%?)
[/quote]
Shot in the dark - but based on some empirical observations of the distribution of PC CPU speeds and graphics cards. If your game’s going to run on a 500MHz CPU then the physics had better be pretty lightweight. If it’s going to work on a 2GHz CPU then you’re chopping off a fairly big chunk of the market. Etc.

Cas

[Jani_Laakso]

In short: “get the job done faster, cheaper or quicker”.

1. I’d say C wins this because it has huge amount of resources (free / commercial libraries) on behind it.
2. If you do not need any additional libraries (scenegraph, physics…) then Java definately wins.

Here’s the important comment:
IMHO Java is not ready for serious gaming business (except server side). This is because we do not yet have 3d renderer, 3d scenegraph, sound, physics + bunch of other tools and libraries ready. Some alternatives are coming up, but nothing is production quality (yet). This is the problem, not Java’s slowness (it’s fast enough). Still, the proof of concept is missing.

Let’s see after a year or so if Java then has any excellent gaming libraries available. If this is the case, I see no reason why Java gaming industry wouldn’t get started. Currently there’s problems with even the 3d renderer libraries (lwjgl, jogl).

Speed: assembler < C < Java, what’s the point?

I do not see much point making this kind of contest or debate. It’s the whole package that counts, hence you can’t never justify any software project with only raw execution speed.

The language itself is good but this is not sufficient alone. Community and Sun’s participation is important, jogl is a good start. Community is the “ice breaker” which acts as an critical mass.

The Java language itself simply outperforms assembler or C++. Sure it’s somewhat slower but who thinks that this is an real issue? The benefits on all other areas (except raw speed) are huge. C’s time is slowly running up while Java (and other higher level languages) are coming.

Take best parts of any technology at any given time. Don’t ever be an idealist (or evangelist) when making technological decisions for commercial products, too bad objectivity can’t be bought

There it was, my ten bucks…

[andyl]

Holy %$£*& Cas, is that memory footprint in Alien Flux really 88 meg? :o

[princec]

Runs fine in 48 or so (look at the actual physical mem usage). Most of it is graphics and sounds. I was deliberate un-clever in handling memory and let the O/S swapfile take care of it - which it does very nicely.

Cas

[NVaidya]

Since things seem to be all quiet on the western front, thought I could troll around a little here.

Firstly, is the challenge that Java should come within 0.5% of the C/C++ version ? Really ? Seriously ? Why ? The challenge could have been made much more melodramatic if the number thrown at was something like 10% - 20% :).

While you guys are bandying about how best to generate and visualize physics ( a much abused term if I may say so ) people in other domains are doing some fancy things with Java to test Java’s number crunching ability to the fullest. Check out this link from my app.:
http://www.freewebs.com/matspring/ptrackone.htm
Will have to warn you that those pics are a little too big.

Those pics show particle tracking and animation with a 100% Java + Java3D application. Typically simulations such as those entail several hundred thousand polymorphic calls to track particles in a cell-by-cell fashion thru’ as big as a million cell grid (polymorphic because the cells could be arbitrary combination of hexas, prisms, pyramids, tets etc.), as many number of Runge-Kutta4 integrations, and several times more Newton-Raphson iterations and all of them in double precision. My experience has been that the server VM on Windows generally crunches stuff twice as fast the client because of SSE2 boosts, and overall the speed of Java is comparable to a C++ code (may not be exactly be apples-to-apples comparisons but I can tell you that I’m not exactly sitting down and wailing on why the heck that I even ventured to code my application in Java - well, atleast not as of yet ).

And here’s something to follow on prince’s comment about 5% time for physics. My feeling is that he probably has a valid point. Off the top of my head I’ve seen that I could do atleast 200 thousand (conservative probably and don’t hold me to those numbers) particle track iterations in about 5 seconds. The question is would you really need this many number of calculations in a typical game, and even if Java is 50% slower than C++ how much of that will have an impact on the overall speed of the game. If you really need some hard numbers I’d be happy to produce them, but at a time of my own choice :).

Just my thoughts. And I really do not care to get myself engaged in long drawn debates simply because I need to get a project out pretty soon.

Good luck with your tryst with the Java-C++ show down. Hope something useful comes out of it once and for all. But one thing for sure. If Java turns out to be 20% slower, and if that turns out to be the reason why people may want to ditch Java, I wouldn’t call that exactly a “wise” decision.

[Raghar]

Nothing light the day as much as a nice flame war.

andyl

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?

[quote]But I can add a little inlined assembler in a few seconds, to the points that bottleneck my code.
[/quote]
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?

[quote]Intel C++ will vectorise your code using SIMD and prefetching for you- no hand coding required.
[/quote]
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.)

[andyl]

[quote]Nothing light the day as much as a nice flame war.

andyl

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.)
[/quote]
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? :o

… 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

[dleskov]

[quote]While you guys are bandying about how best to generate and visualize physics ( a much abused term if I may say so ) people in other domains are doing some fancy things with Java to test Java’s number crunching ability to the fullest. Check out this link from my app.:
http://www.freewebs.com/matspring/ptrackone.htm
Will have to warn you that those pics are a little too big.
[/quote]
We plan to implement support for SSE2, etc. in future versions of our compiler and we would love to play with such a real-life Java number cruncher application then. If it is not going to be freely available, would it still be possible for us to get a copy?

[swpalmer]

[quote]So which ‘facts’ do I choose to believe, and which do I reject ???
[/quote]
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.

[quote]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.
[/quote]
I’m not sure what part of my post this was relevant to, other than to say this is a good argument for using higher level languages and tools. I.e. Java.

[quote]Intel C++ will vectorise your code using SIMD and prefetching for you- no hand coding required.
[/quote]
Sure, but Jeff nor I, or anyone that I know of has stated that Java beats any particular compiler or even that it is on par with any particular compiler. As you stated yourself Intel’s compiler creams Microsofts and MSVC 7 beats MSVC 6… though MSVC 6 is still widely used as is GCC on non-MS platforms… so I don’t see why it should be discounted entirely. The argument was about languages in general… We know that compiler technology effects the overall speed as much as CPU speed in some cases. 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.

Re: my belief that C/C++ would win your contest:[quote]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]
Many factors. One is that you set the margin of error far too narrow. Given that we still see far greater than 0.5% variance within relatively modern C/C++ compilers, why would you expect less than that between C/C++ and Java?? It makes no sense. Bounds checking is an issue, the C version won’t have the safety net that it offers and it also wont have the cost associated with it. I think it is unlikely that this style of program would be a candidate for enough bounds checks to be eliminated such that it wouldn’t be a factor in slowing down the Java a bit. Given the 0.5% margin you offer… I think it is way out… I would gladly pay a mere 0.5% for the safety of the bounds checks. Another factor is the applicability of vector instructions to the problem. Which I think the latest greatest Intel compiler will take better advantage of at this stage.

[quote]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]
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.

[quote]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]
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.

[quote]C++ compiler performance is still improving in leaps and bounds, so Java is chasing a moving target…
[/quote]
Improving for sure, but which is improving faster Java or C/C++? I think Java has more momentum at this point.

[quote]Who said I was a C programmer?
[/quote]
not me. ??? I was referning to AThomas’ argument not you specifically.

[quote]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
[/quote]
Yep, I think we all agree on that.

[andyl]

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.
[/quote]
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.
[/quote]
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.
[/quote]
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).

Andy.

[swpalmer]

[quote]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?
[/quote]
Some of us have strong opinions - but don’t let that scare you away. These forums are gold for Java game developers. We also tend to get our backs up when presented with inaccurate information that ultimately contributes to an environment that reduces the acceptance of our projects. Not saying that you have done this specifically… but I think it is part of the underlying tone of the challenge. I think we all agree that the REAL challenge is doing a real game… 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.

[quote]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).

Andy.
[/quote]
Though it seems to contradict what I wrote above, I like seeing micro-benchmarks. So long as they have the opportunity to be scrutinized by experts before they are misinterpreted by the masses. They have in the past pointed out bugs in the JVM and ultimately they contribute to a better understanding of the underlying issues. In the very least we usually end up knowing the “right” way to do things in Java to get decent performance. Though typically that just means stop trying to trick the JVM and let it do it’s job. Tricks backfire as the JVM improves, and the VM guys have stated they are working to make good code run faster, they aren’t interested in optimizing how some ugly hack gets compiled. I think that’s a valid strategy.

As far as Jeff’s book goes, heck, I paid good money for it and then a few months later it was online for free :(. I’m not sorry I did though.

[andyl]

[quote]… 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.
[/quote]
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.

Andy.

[kevglass]

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

[andyl]

[quote]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
[/quote]
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’.

[NVaidya]

dleskov wrote:

We plan to implement support for SSE2, etc. in future versions of our compiler and we would love to play with such a real-life Java number cruncher application then. If it is not going to be freely available, would it still be possible for us to get a copy?

Yes, you’d be quite welcome to use it for evaluating your compiler - can’t see any problems with that right now. I’ve tried the JET evaluation version, BTW - thought I’d made a fleeting mention of it elsewhere in the forums. Will contact you directly very soon.

[NVaidya]

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://math.nist.gov/scimark2

Both Java and C sources are available.