Your points about compilers being superior are somewhat flawed. In theory you are correct.. accept for the simple fact that the compilers you are talking about wither don't exist yet or simply aren't being used by the game developers.

There are actually VERY few compilers that will generate standard C++ into the fastest possible code in the case of several specific algorithm types.

The most common example is when coding SIMD instructions with an assembler. Any JPEG or MPEG codec that is halfway decent these days MUST use hand-coded assembly to get decent speed.. I'm not saying that the hand-coded assembly routines wouldbe the fastest possible.. I'm just saying there are any readily available C++ compilers that will come close. Image filtering and other similar operations that use SSE or Altivec etc. are all in the same boat. Usually the higher level language lacks the constructs to express the algorithm ina way such that the compiler can 'see' how to best use the SIMD instructions.

I'm not saying that all compilers aren't up to the job, but certianly the GNU compilers and Visual C++ can't come close. And they are quite popular.

For your standard if-then-else logic and simple expressions, sure a compiler will win most of the time... it's when the 'really clever' expression can not be written in the higher level language in the first place that they tend to trip up...

Err.. just so I contribute to the true purpose of this thread.. I vote YES too. A forum on game play discussions (how to make games more playable, enjoyable, fun, immersive, addictive, etc.0 is a good idea.

There are actually VERY few compilers that will generate standard C++ into the fastest possible code in the case of several specific algorithm types.

The most common example is when coding SIMD instructions with an assembler. Any JPEG or MPEG codec that is halfway decent these days MUST use hand-coded assembly to get decent speed.. I'm not saying that the hand-coded assembly routines wouldbe the fastest possible.. I'm just saying there are any readily available C++ compilers that will come close.

It seems I didn't make my meaning clear enough, but I was trying to make the point that for AN ENTIRE PROGRAM for the vast majority of cases it's not just really hard, but it can take more time and skill than any team of humans realistically has available, just to get results as good as a good compiler. I was replying to:

Quote

they could also make games nowadays that run twice as fast or are twice as smart, or pretty, etc. all they would have to do is write it all in assembly which would be too much effort

...I would like to see, for example, someone writing entire non-trivial OO programs in fully optimized assembler, by hand.

Or see someone doing optimal register assignment for a whole PROGRAM, bearing in mind they have to write the entire program several times, trying different tradeoffs between e.g. reducing memory accesses vs making use of the cache.

If you read my post carefully, I'm basically objecting to the claims that you can write whole programs (and we're talking computer games here, not simple stuff) in optimized assembler by hand - and that they'll be "twice as fast" as the compiled C++ version. That's just complete rubbish! In reality, a complete program is typically going to be very close in execution speed. TYPICALLY - i.e. I'm sure we could come up with another dozen particular programs, like your examples of (de)compressors, where the difference can be much greater - but these are special cases, and as you point out generally occur when the program is dominated by a particular kind of algorithm.

I wasn't trying to say "no compiled code can ever be sped up". I did say "Assembler programs are NOT faster than compiled programs". You seem to have read that as "bits of code written in Assembler are NOT faster than the same bits of code output from a compiler" - the distinction (which obviously I didn't make clear enough, sorry) is critical.

PS: there are also some crap compilers in common use, like the GNU ones last time I checked in detail, about 4 years ago (ducks and runs for cover!). Seeing GNU C++ compilers get thrashed on various benchmarks by Java 2 compilers is pretty unimpressive. Back then, the MS C++ compiler seemed about as good as I expected from a good compiler.

(at this point I'm so far off-topic, I'm actually back on topic again).

I will just point out that these days it largely doesn't matter at all if you choose assembler, C, C++, Pascal, etc.. The slowdowns in Java aren't related to generating bad code (mostly). They are caused by other 'features' of the language that the VM guys have to work around, and yet remain compatible with... like bounds checking, and garbage collection. Going between the Java heap and the native heap with data etc.

And of course fast code does not make a good game. (See how I dragged that back to being almost on topic )

I'm all for a forum on gameplay, or game mechanics, or whatever you'd like to call it. The SNR at gamedev.net is so low now it's basically not worth bothering with their forums any more. We've managed to keep it very, very high here.

Otherwise you might consider having a look at dexterity.com's forums for indies, where the SNR is even higher than it is here (!).

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