BlitzMax and Java

I am learning Java at school and was wondering...

It appears that Java doesn't create EXE files like BlitzMax, am I right?

Anyways, is there a way to get Java and Blitz to work together, such as running Java codes/class thingys in a Blitz code.

PS: Is there any advantages of Java over Blitz?

In a very narrow sense, yes, it doesn't create EXE files. If you also mean that it doesn't produce compiled, standalone, runnable code then no, because it does do all those things.


There are always ways, but nothing very practical springs to mind. I would have expected someone to want to do it the other way around to be honest. Use some BlitzMax stuff in Java to get all the language extras that Java has, sure, but I can't really see any purpose in the opposite since BlitzMax doesn't have half of the language features Java has, and couldn't directly interface with most of the ones it does.


Java works on more platforms than Blitz. It's probably faster than Blitz. Because it's JIT compiled, it's probably going to produce more efficient code than Blitz too. The language has a lot of features BlitzMax doesn't have ( and could benefit from. ) Java is considerably more Object Oriented, with java programmers generally being very, very fond of their interfaces and templates and their design patterns. BlitzMax doesn't have interfaces or templates, and I'm not sure if it will ever have.

"It's probably faster than Blitz. Because it's JIT compiled, it's probably going to produce more efficient code than Blitz too."

wow, I never knew that! I'm going to have to research Java more seriously. There HAS to be alot of tools for game design out there in Java.

Java is pretty much universal, and any machine for which a Java framework exist can run the code, up to and including graphical calculators and some cellphones.

The execution speed realy depends on the quality of the framework on the platform you're running it on, though. Some are great, others are really slow.

"It's probably faster than Blitz. Because it's JIT compiled, it's probably going to produce more efficient code than Blitz too."

because it's JIT compiled?! please explain....

Just In Time ( JIT ) compilation means that the program is delivered to each user ( effectively ) uncompiled. The first time you run it, it is compiled, and on subsequent executions, it is not compiled again. Because it is compiled on each machine separately, it can make use of optimizations which a compile-once, run-on-many compiler cannot make use of. In short, it knows how your machine is different from my machine and it can compile differently to make best use of each or our machines.

I know what it means... I would like to see a proof of your theory that JITs have better optimizations than stand alone compilers. The main purpose of a JIT (and Java for that matter) is for a write once run anywhere application. I highly doubt you're going to find a java compiler that out performs blitz when writing a game.

Depends on your compiler. SUNs Java compiler produces bytecode, the GCC Java compiler and Excelsior JET can produce EXE files.

No. But if you know a little C, don't mind writing tons of boilerplate code, and don't mind violating the BRL License Agreement, you can use BlitzMAX .dlls with JNI.

Yes. More jobs for starters.

It isn't a theory, and has nothing to do with better compiler optimizations. It's a matter of better CPU utilization. Think of your regular program compiled for the i386 platform. Now if you happen to have an i586 or i686 platform you're screwed because your program is not aware of these extra features. The JIT compiler on the other hand is.

Another Pro of JIT is that it profiles. ie it checks which sections can be opted for your system and which not and it opts those that benefit if it.

Thats something you will never be able to do from hand. you can only opt for some specific test cases you are able to do with your machines or your game studios machines.
But you aren't god, you can't opt for 8 types of CPU and especially not 8 different pipeline lengths within the CPU, which is a seriously usefull thing.

Why do you think is C# able to be en par with C++ even thought the C++ followers still believe that their dieing language will always be faster?
Because no C++ programmer can program a single app for single core, multicore, AMD, Core Duo, Core 2 Duo and P-M as well as P4 (which has a far longer pipeline and other capabilities) optimized, even if he would do it for the rest of his life.

And the more parallelism we will get on the CPU end, the more you are in trouble without JIT compilation and a good compiler.


BM is the best proof of that. Heck it has optimation flags for P2!!! How much worse and more useless down-opt can you an app!
Set the optimation flag for P3 or even manually SSE3 and pipeline optimations and see a 150-200% gain on the math end and a few other things!

Regarding EXEs: Neither Sun Java nor Microsoft C# create real EXEs out of the box. Visual C#.NET gives you something that's called .EXE, but it actually is only a stub that starts the .NET runtime and passes the bytecode to it - which more or less is what Mac OS X does for you when you double click on a .jar archive. But as FlameDuck said, there are also Java compilers available that can create native code for you.

Writing games with Java: Have a look at Andrew Davison's book "Killer Game Programming in Java". Everything is doable in Java - and already has been done - but in the end you will find that BlitzMax makes your life significantly easier than Java ever could, especially in this domain.

But don't let anybody fool you on that "write once, run anywhere" promise. It actually only is "write once, test anywhere". Or, as id Software's John Carmack said: "Write once, run anywhere. Ha. Hahahahaha."

If your looking for future employment: Stick to Java. There are millions of extremely boring, but probably well paid Java developer jobs out there. You know, like writing another financial software module for a bank or insurance company, or yet another crappy human resources or project management software. You won't find many INTERESTING Java jobs out there (like programming robots), unless you start your own business. Being the industry's "lingua franca" is Java's curse.

Besides all that, Java is a great language if you want to write academically clean object-oriented code. That's one of the reasons why universities love to teach in Java. Java follows that whole OO-paradigma through to the bitter end, giving you basically no alternative to it. You cannot write procedural/functional code in Java - even if it would make more sense for the task at hand.

Java also strongly enforces multi-threading - with the same disclaimer: Even if it does not make real sense for the task at hand. Carefully read most network programming tutorials for Java, and you will see that they usually spawn one thread per connection -- absolute overkill and the best way to bring every server to its knees, but until Java 1.4 you did not even have a choice.

Java is not a silver bullet and has its shortcomings and flaws just like any other programming language. What makes it special, however, is its wide acceptance. Basically everybody in the business speaks or at least understands it. In that sense, it is a bit like the English language.

Regarding the JIT...

I saw an article on the net sometime ago, from an engineer who works on .NET. ( no link sorry )

From what I remember:
-the runtime looks at the size of your cpu cache
-it can emit different code depending on whether its amd or intel, and what model it is.
-there is more room for cpu specific tuning, but theres the issue of diminishing returns/harder to track customer issues resulting from extra codepaths, etc.

Also like someone mentioned, some versions of java can profile code as it runs, and optimize certain hotspots of execution...

So thats the good stuff. But rico mariani, says straight out, the current .NET JIT has to run fast, so it can't do all the analysis a good static compiler can. But it does a very good job considering. Paraphrasing him, he said think of the JIT as a fixed, but tiny overhead. ( http://blogs.msdn.com/ricom/archive/2006/08/22/713396.aspx )

At the end of the day, you still get pretty good codegen tailored to your system-- combined with fast memory allocation, and good locality of cache. End result is pretty speedy programs.

I can't speak for java, but in my somewhat limited testing , c# almost always beats b3d/b+ in a big way. Haven't bothered testing with blitzmax.

There's a decent amount of info on the web regarding JIT advantages. I think IBM's website has some good papers on it.

"It isn't a theory, and has nothing to do with better compiler optimizations. It's a matter of better CPU utilization. "

ok, I get that but I still don't see a proof. how come I haven't seen any good performing games in Java?... how come big software houses are not using it to write their non-casual games?

"Why do you think is C# able to be en par with C++ even thought the C++ followers"...

I thought that was because visual basic/c++/c# all used the same base compiler.

"BM is the best proof of that. Heck it has optimation flags for P2!"

yeah, that's because it's based (windows) off an old compiler.... that is soon to be fixed, but I'd rather compare latest visual c++ to Java... Are you guys telling me that because of the JIT compiler Java on windows will out perform a visual C++ compiled exe.... I doubt that is the case even if we used today's JIT and a 4 year old visual c++ compiler.

For the same reason you don't see them writing games in C#, Visual Basic, BlitzMax and a host of other languages which are perfectly viable for game development. Because they have vast quantities of code written in C++ and they don't want the expense ( financial as well as bugs ) of rewriting it all in another language.


In what little testing I've done, I've found C# a little bit faster than BlitzMax, but not enough to care about if you prefer to use BlitzMax, as I do. I'd probably wipe out the performance difference with my mediocre C# programming skills.

Unmanaged C++ code is completely different from the ".NET" languages like VB.NET / C++.NET / C#.NET.

Even though JIT compilers like C# and Java can perform some optimizations that C++ can't, unmanaged C++ compilers have always been able to produce much more efficient code, which means overall the resulting EXEs will be considerably faster on just about any processor.

If you really think JIT is faster than unmanaged C++, do a search for benchmarks. You'll find that C#/Java is almost always slower than C++. JIT certainly helps, but obviously not enough to make up the difference for it's lack of in-depth optimizations which C++ compilers have.

There are not many application domains left where the performance difference between C#/Java/BlitzMax and C or C++ really matters (where C++ programs usually already perform slower than C programs).

Not all parts of an application usually require the highest possible performance, but those parts that do still can be written in C and linked to the remaining application. That way the benefits of managed languages can be combined with the raw power of C. But in all honesty - when do you really need more performance than today's Java, C# or BlitzMax already give you? The only real reason to use C is when you have to go down to the system level. Just my 2 cents.

True, but the main "domain" where the performance difference does matter happens to be the games programming domain.


You need maximum performance...
1. When you're programming a game you want to run on older hardware
2. When you need fast A* algorithms, collision detection, raytracing, and practically any other game-related task
3. When you don't want to be stuck at some point of the development of your game because a certain technique you wanted to implement just won't work fast enough
Etc.


That sounds like a good method, if it's possible. I don't know much about JIT, but isn't it impossible to use unmanaged code from a managed program?

When I ( personally ) benchmarks the latest MinGW against managed C#, I found managed C# was considerably faster. Did I do something wrong or is MinGW different?

It could be that MinGW doesn't optimize as well as MS Visual C++, or you forgot to enable speed optimizations when compiling.

Personally, I'd be happy if C# really was faster than C++ because in my opinion C# is easier to use. Unfortunately from what I could tell C# is slower in most cases (but certainly not all). But if C# ever does become faster than C++, I'm certainly not going to complain :)

John, yes, you can use unmanaged code from a managed program. Java has the "Java Native Interface" and C# has "P/Invoke" - "platform invocation".

Regarding the performance: Anybody here writing Doom 4 or Quake 5 that you really need that kind of speed? Just kidding. ;-)

Why is that boring? No offense but I think you'll find said applications far more challenging than writting (say) a match-3 game. In fact with the possible exception of Naked War, I have yet to see anything presented here that comes even close to matching the complexity (never mind stability) of a financial package for a bank.

Rubbish. If you compile your C++ program for a target architecture of (say) i386, and then run it on any different processor, the C++ version will be considerably slower than a C# version.

What? The only domain where performance difference matters is in embedded devices (which is why many embedded developers are required to have at least a fundamental understanding of assembly).

The only people who need faster languages are those who need the additional speed to make up for their lack of skill.

When you program in assembly.

Of course if you enable those optimizations, your binary will no longer work on that archaic hardware you supposedly needed the extra performance for. Catch-22 eh? Your program is either slow and works on everything, or fast, and only works on the fastest CPUs. Hrmmm.

That's fine if you like to programming simply for the challenge. Many people like to program because they want to make something they like. Not all people like business software.


Did I say 386? Sorry, but I'm speaking practically here, and the fact is that C++ is faster than C# using modern compilers with somewhat modern architectures (586+).


True, embedded devices is another domain where performance is critical, but I can't understand why you disregard game programming as a optimization-worthy domain.


You don't need to go to either extreme. Assembly is extremely fast, C# is extremely easy. C++ is a very reasonable compromise where you get OOP features, inline assembly, and high optimization.


Did I say archaic hardware? I said old hardware. As in Pentium 4.


Ok, nice.


Would you mind explaining that statement?

Skill has nothing to do with your need for optimized code; if you need a fast program, you need a fast compiler. If you don't need a fast program, you don't need a fast compiler.

If you're trying to imply that I have a lack of skill because I feel the need to use C++, say the word and I'll show you some of my work in C++.


That's actually a good point - most casual game developers don't need C++ at all.

But the fact is that a few casual developers (like me) and almost all professional developers do need C++.

FlameDuck, those applications certainly do have more complexity than many games, it's just that I find that field itself extremely... tiring. It might be technically challenging, but the entire environment (bank/insurance/big corporate entity) just doesn't attract my imagination. It's just for the paycheck. Besides, I find writing communication servers more interesting. :)

Because what's the point of optimizing broken software? Practically every game released these days have glaring mistakes, so obvious there's no way no-one had noticed. The conclusion must then be that companies (I'm thinking publishers mostly) intentionally release broken or incomplete games.

Let's take my favorite example of Obsidian. Their two last games KOTOR2 and NWN2. Now apart from the fact that KOTOR2 has several engine related bugs that where fixed by Bioware in the first game (like the Dantoonie is unplayable bug) their last patch permanently breaks the game by introducing new bugs. Now with NWN2 of course there is definitely an argument for optimization, because it looked worse, and played worse than any contemporary game. However what does it matter that they could have made the game run at a reasonable framerate, when the game is broken in the first place?

Well you get objects. But saying that C++ is an object oriented language (when it's perfectly feasible to write a complete program in C++ without using a single object) is a bit of a stretch. It would be fairer to say that C++ is a pointer oriented language. I still haven't seen any measurable speed difference between C++ and C# tho'.

Well you're entitled to your opinion. Generally I find that if you need a faster program you need a faster algorithm. Or faster hardware. Both are probably a lot cheaper than C++. Did you know that the total cost of software systems in their life span is split roughly 50/50 on original development and maintenance? Except in C++ where it becomes 20/80. I find it alarming and significant that C++ programs are that much more expensive to maintain.

No I'll take your word for it. I generally find that people who are that defensive of their programming language of choice, are excellent programmers. I had this exact same discussion 15 years ago when I switched from 68K assembly to C. I had it six or so years ago when I switched from C to Blitz. I had it again 3 years ago when I switched from Blitz to Java. Lastly I had it last month when I switched from Java to Python, and I'm sure this isn't the last I've heard of it.

Oh. That must be why they're switching to Python and Lua. Because they need C++. The only people who NEED C++ are the people writing the Python/Lua/Ruby/Tcl/Perl/whatever bindings for their 3rd party commercial engine, providing SWIG doesn't do it all for them.

Well to each his own I guess. :o>

What do you mean by "switching" to Python and Lua? Are you saying that game engine programmers are dropping C++ and moving to these scripting languages? That sounds insane to me, but if this is true, I'd like to verify (any sort of reference?).

If, on the other hand, you're referring to the high-level game code being done in a scripting language, that's perfectly normal practice.

I guess when I say "game programming", I really mean "game engine programming". Almost every modern game uses scripts (and other external data files) in one way or another, but that doesn't change the fact that the game engine code needs to be coded in C++ for performance.


Well of course you should always use an optimal algorithm. I'm talking about a case where you can't optimize the algorithm any more, and it's just up to the compiler/hardware to provide you with the computational power you need.

And the "upgrade your hardware" argument doesn't prove anything. Sure, you can tell your users "You all have to upgrade to a 3.0 GHz or more in order to get over 2 FPS since I was lazy and used VB 6 instead of C++ to develop my game", but what does that prove in favor of your argument?


The definition of object-oriented is:

For example:

C++ supports object-oriented features. C++ is an object oriented language

C does not support object-oriented features. C is not an object oriented language.

Java supports object-oriented features. Java is an object oriented language.

Etc.


Pointers are a feature of C++. References are a feature of C++. OOP is a feature of C++. Non OOP functions are supported in C++. Non OOP variables are supported in C++.

I'm not sure what point you're trying to make, but saying C++ is not an OOP language because it supports procedural functions and pointers, is like saying your car doesn't have an engine because you can put it in neutral and push it down the road if you want.


There will always be bugs in software, and there will always be programmers who introduce bugs into software. No matter what language you use, this will always be the case.


Here's one of many benchmarks you can find on the internet:
http://www.mobydisk.com/softdev/techinfo/speedtest/index.html

Notice how the speed of the C++ code increases with more modern compilers - hopefully the same will be true with C# and it will one day exceed C++'s efficiency (unfortunately this is not the case currently).


And here's another:
http://www.burnap.net/stories/table2.html

Notice how the slowest 3 languages are C#, Java, and Managed C++

Its already been said that the .net jit is a compromise between code performance and length of time the jit has to compile. The user wants a responsive program, so the jit can't be as thourough as a compiler which can chew on the code for as long as needed.

Also, code security and safety is part of the ideals of .net. So you're getting things like array bounds checking, and other safety nets involved here with these benchmarks.

But none of that invalidates the promise or benefits of using a JIT. MS has said in many places, they can squeeze more performance out of it. As the common denominator for cpu power rises, expect them to crank up the aggressiveness of the jit.

Its pretty cool that programs you write today, can get faster tommorrow, with no intervention on your part.

As far as benchmarks go, I've seen ones for and against managed code. There's no black and white rule of what will be faster. I think right now, generally a good optimizing c++ compiler will win more often than not, especially when it comes to harcore number crunching-- but the fact that c# can duke it out, and even come out ahead says alot about the .net runtime.

( Also, at a quick glance of the first benchmark john j. linked to, there's a few items making me a little suspect. Like using DateTime.Now for timing, not accounting for framework spin up/jit times, etc - haven't tested though. I doubt it would make up for all the difference... )

Here's a couple of .net benchmarks that always stick out to me.

axiom vs ogre - c# port of ogre.. this benchmark was done against the 1.1 framework. I'd like to see 2.0 as it got a performance boost...
http://realmforgewiki.castlegobs.nl/index.php/Ogre_vs._Axiom_Comparision

chinese / english dictionary - 1 guy writing it in c++, other guy porting to c#.
http://blogs.msdn.com/ricom/archive/2005/05/10/performance-quiz-6-chinese-english-dictionary-reader.aspx

c# version was ahead by the 2nd step, with no real effort other than the porting involved.
Sure the c++ managed to beat the c# version in the end, but required more iterations of code, and saying goodbye to the built in library functions, and rolling his own.



I think what Tim Sweeney says about the next mainstream game programming languages is quite interesting:



http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf

I find this remark of Tim also interesting:

"Memory model - Garbage collection should be the only option."

I also liked this one:

"Exception Model - The Java/C# 'exceptions everywhere' model should be wholly abandoned."

True, that is very nice. Maybe someday Microsoft will have a JIT Game optimization mode, where it can be just as optimized as C++ (less bounds checks, etc). And provided they don't make it Vista-exclusive, I'd be happy to switch to C# in that case. I would however be a little cautious when switching to a language based on promises made (BltizMax, for example).


So would I, but:

I basically came to the same conclusion when researching C# vs. C++; C++ is considerably faster with calculations and arrays.

With a simple game without intensive and complex mathematical calculations like a simple tank game or maybe even an RTS, C# would work just fine. In other words a 10% performance loss is OK with a 10% increase in productivity.

However, with more complex game engines, you get into more advanced features like scripting engines, pathfinding, raytracing, and dynamic paging and dynamic vertex buffer batching. In some cases you need thousands of terrain height checks to be performed per second, and thousands of vertices uploaded to the video card in real-time. In this case, that 10% increase in productivity may come at a 50% performance loss.

The Axiom benchmark actually reinforces what I'm saying. Notice how the CPU-intensive "Smoke", "ParticleFX", and "Skeletal Animation" demos all run faster in C++, while all-GPU demos "Fresnel", "Dot3Bump", etc. run faster in C#.

Yeah, but isn't it still interesting that the guy who wrote the Unreal 3 engine said that he would accept a 10% performance loss for a gain in productivity? I mean, how much more bleeding edge than the Unreal 3 engine can it get? And if Sweeney thinks that he can sacrifice some performance, then I don't think smaller projects than Unreal will have a problem with that.

But his talk actually was about what a next generation language should be like, and what he thinks what features it should offer specifically for game development. He also was not talking about supporting old hardware; instead he predicted that in 2009 machines with 20 CPU cores and 80 hardware threads would be the targeted gaming platform, so he talked about the challenges that game developers would face in that scenario.

Telling the customer to upgrade his computer has always been cheaper than profiling the own code. Just ask Microsoft about it. ;-)

Well I don't think anybody's arguing that a 10% productivity gain isn't worth a 10% performance loss; my point is that for 10% more productivity, you can lose 50% performance where it really matters (buffers, arrays, math, etc.) in game technology.

> instead he predicted that in 2009 machines with 20 CPU cores and 80 hardware threads would be the targeted gaming


I think he is a couple years too optimistic. Those machines will be starting to release about then. I may be wrong but I've seen a slowdown in the rate of adoption among game developers - it used to be a new video card was required every 6 months to a year, lately I've been getting 2 years service out of each one.

Here's an interesting article about:
http://www.acm.org/ubiquity/views/v7i24_fallacy.html


I know this post is a little late, but this article seems to describe FlameDuck's software engineering style so perfectly I just had to post it.

Okay I'll just reply to his incorrect assumptions.

#4 Yes it has. If anything the step up from a 1997 computer t(what was that? 200Mhz Pentiums?) to 3Ghz quad core processors with up to 12 ALU's in parallel per core, is a much, much bigger step up than going from an 87 era CPU (like say the 8080) to the Pentium (which was more or less the same processor, just clocked at a higher speed). Of course I wouldn't expect someone who relies on his compiler to do his optimizations for him to be aware of this.

#5 And it's true to. The least Mr. Hyde (is life too weird or what?) could do was provide evidence as to how he thinks one should profile a SOA driven multithreaded application, with hundreds of concurrent users, all wanting to do different things. Yes I'm aware that in your cute little Unix-like commandline tool, or pong game, you can fairly accurately profile the bottlenecks, but in any serious application, the complexity is too high to do so effectively.

#6 It's not something I believe. It's something I can prove. For the same price of one software engineers day, you can buy the most ridiculously overpowered PC you can imagine. I know you think customers pay for anything you ell them to, but In reality, nobody wants to pay extra for something that's already "good enough". If user's time is so valuable - why don't they want to pay to optimize? Or even document? Nobody is going to pay an extra 100.000 USD for a piece of software that works, to maybe get a performance boost, when they can get new hardware for 2.000 USD that will guarantee it!

#8 This one is brilliant. Doesn't mister Hyde realize that poor (much the same as great) is highly subjective? Also he seems to be of the (wrong) opinion that optimization is somehow different to finding a better algorithm. He acts like optimization is something you can have done automatically by some fairy god mother.

Let me just eliminate this myth once and for all. Unless you have an intimate understanding of how your compiler (regardless of language) translates your source code into binary code, and likewise have an intimate understanding of all your build targets (including hardware and operating system quirks) there is no way you can effectively optimize a program. Why? Because there is no way of telling which concrete optimization is going to affect performance on different targets. You just tightened up a loop so it can fit inside your cache? Cool.. Here's Brians computer with half the cache. Back to the drawing board. You just rearranged the order of a complex mathematical expression to eliminate as many expensive instructions as possible? Oh, what's that? The expression can no longer be processed in parallel on a multiple ALU CPU? Bummer.

The idea that there are some kind of magical optimizations that always work, and that programmers are just too lazy or stupid to implement them is so ignorant it can only be ascribed to higher education. You have to have at least a Masters to say something that stupid.

For the record, I never said "you should never optimize". I said "you should never optimize unless you have to". Now call me elitist but I'd wager that any well-written Python software (isn't it all) will outperform any poorly written C++ program. I'd wager that hiring someone to write well-written Python programs is several orders of magnitude easier and less expensive then hiring a C++ programmer to do the same (because let's face it, C++ is so anti-compact that even it's inventor doesn't expect anyone to ever understand it all, and the vast majority of C++ programmers are hacks anyway).

Look, I don't know how to break it to you, but not every C++ programmer is as good as you. I present to you as evidence practically every piece of software ever written. Let's take Microsoft as an example shall we? Microsoft is the major corporation in the world with the highest average IQ. Now when you think of all the hordes of morons in front-line support, that leaves a handful of super geniuses left to develop their software, and almost without exception it's all written in C++, and also almost without exception it is not marginally the least bugged, never mind best performing. I mean having SQL Server manager crash when you double click on a table name? How the hell did no-one find that one? Having Outlook do whatever the hell it does when it starts up, that hangs the entire fucking system for what fells like an eternity? Great performance? I don't think so.

Listen. Once (like 5 years ago - if that) I was just like you (I programmed in Assembly until 2002 - because I lived under the illusion that it was the fastest). All idealistic and thinking the customers deserve the best of the best. Bollocks! The customers deserve what they're willing to pay for, and if they don't care about performance, neither do I. In that respect, the customer is always right. I will write the software to specification and to the best of my abilities, and to date, that's all worked out wonderfully. But if they aren't willing to pay for the time I spend optimizing, well hey - there's no such thing as a free lunch.

Possible, but that C++ program would have to written extremely poorly, almost to the point of being written intentionally to run slow.


And I never said "you should always optimize". I said "you should always optimize if you need to". For modern applications, you don't need to optimize much. For simple games, you don't need to optimize much. For complex games that make full use of your PC's power, you do.


Well that's wonderful from the software developer's perspective. Unfortunately most users can't always afford top-end PCs.


Who says they don't? If given a choice between a game that runs and plays great for $50, and a game that runs and plays horrible for $10, I'd choose the $50 game. But maybe that's just me.


As with most of your responses to the articles, it seems to me that you are totally misunderstanding. Here's the original point again:

The point made here is that (regardless of programming language) many developers fail to optimize portions of their code that they normally should "instinctually" know will be a bottleneck. In no way does this reference profiling your code, in fact, it's referring to the opposite.


You seem to think the word "optimize" automatically means CPU-level optimizations. It is useless and impractical to perform CPU-level optimizations unless you're using assembly, as you put it, "...there is no way you can effectively optimize a program" in this way.

A compiler-level optimization isn't useless though. For example, comparing the speed difference between an identical C++ and Python program, will demonstrate this point well.

Algorithm-level optimization is obviously the most important kind of optimization, but you seem to be making the incorrect assumption that C++ programmers use bad/buggy algorithms, while Python/C# programmers use perfect/100%-bug-free algorithms. Either that or you strongly believe that there's some evil nature to the C++ language that inherently introduces bugs into your software.

True, C++ can result in more low-level bugs if you don't know what you're doing, but every programmer should know that it's the logic bugs that really cause problems. And not even the most modern high-level language can prevent logic bugs.

For example in one part of my engine dynamically adding trees to the optimization system would sometimes result in those trees not being displayed. It turns out that this bug was basically a simple +/- mismatch and the wrong vertex buffer page was being marked for update. Whether I used C++ or Python to implement this, the same thing would have happened.

P.S. From the BRL terms and conditions:

No offense, but I don't want you to get banned or anything over this conversation.

John J., just this one because it immediately caught my eye:

"..the speed difference between an IDENTICAL C++ and Python program.."

Writing an IDENTICAL program in Python and C++ already implies that you a) did not take real advantage of either programming language and therefor b) wrote extremely poor code. You can solve one and the same problem in both languages, but to optimally solve it in each language, you would have to write two completely different programs. Therefor, you just cannot compare an identical implementation; one language would automatically lose.

Why do so many programs converted to Python just suck at their performance? Because they are no real Python programs, but programs written by Java or C++ or whatever-language programmers who still think in their old language. With a highly dynamic language like Python, that simply won't work (well).

On the other hand, if you'd program in C++ like you would program in Python (provided that you implemented your own dynamic runtime that works similar to what Python does), you would soon discover that C++ wouldn't be one bit faster than Python is. Probably slower, because your code wouldn't be as mature and optimized as the Python interpreter.

You cannot treat all languages in the same way. You need to adjust your coding style to the philosphy and the features of the language that you are using when you want to write optimal code.

If you'd ask a very good C++ programmer and a very good Python programmer to solve the same issue, you would discover that the Python programmer would be ready MUCH sooner than the C++ programmer (and therefor be MUCH cheaper) and you would also discover that his program would be more than fast enough for every user out there. Naturally, you have stay in domains that both languages can technically solve; nobody would write a 3D engine Python, but obviously Python is used in robotics, the "one laptop per child" project and also as a scripting language in Civilization IV.

For most applications, the highest possible performance just does not matter at all. And FlameDuck was right: It -is- cheaper to spend a few more bucks on a fast workstation or server than pay the programmers to make the software faster. I don't think he was talking about games here, but probably rather about enterprise grade software.

Another important issue is readability and maintainability of code, especially when we are talking about software that will be used for a couple of decades, like most enterprise software: What do you think how readable your optimized C++ code will be for a new developer in 20 years from now? Even the most verbose C++ code is not half as readable as ANY Python or COBOL code.

Concerning the bugs: Most C++ bugs actually come from memory management problems. Does buffer overflow ring a bell and the myriad of security problems in Windows and web browsers resulting from exactly those memory management problems?

Anyway. The reality out there is that it usually is cheaper to just aim for a faster target system than to pay the programmers to profile their code. Memory and CPU cycles are cheap, man hours aren't.

Of course I didn't mean "IDENTICAL" literally - naturally there's translation involved. I should have said "logically identical" or "procedurally identical".


Exactly. But I'm not talking about applications, I'm talking about games.


Very readable. Just like good Python code looks hard to read to me, I'd imagine how good C++ code might be hard to read for you.

Then they certainly can't afford to buy optimized software either. How much do you think it would have cost to halve the minimum requirements for (say) Half-life 2. Another 10 million? Think they would've gotten another million or so sales (or however many they would have had to sell to break even) from doing that? I doubt it. I think most people figured that since they didn't absolutely need it, they'd wait, and buy it when there was a compelling reason to upgrade their computer anyway.

Sure. So would I. I would've bought ShadowRun sight unseen if it had run on my Computer (never mind my OS). However do you think Microsoft/Fasa can justify to their shareholders, spending another 6 months optimizing the game to get that kind of additional sales? No - of course not. Because they know (like I know) that:
a) If I was a hardcore gamer on a budget I would've bought the XBox360 version.
b) In 2 or 3 years time, I'll have a more powerful computer (and Vista) and ShadowRun will be re-released on a budget label, or bundled with my mouse or something, and I can get it then.

And I'm saying it's ludicrous to claim that programmers intentionally write rubbish code! Maybe everyone I know is just a natural born programmer (which I seriously doubt)?

Who are these mystery people you are referring to?

Depends on the target platform. On a VLIW processor, no. On a modern CISC/RISC processor 90% of all optimization is done on-die anyway, so the effect of any (real or imagined) compiler optimization is trivial at best, particularly so if the programmer is already doing "instinctive" optimizations.

Depends on the program. Since the most widely used Python interpreter is written in C, I doubt the speed difference is as profound as you suggest for any benchmark not specifically written to be favorable to C++.

Yes. And Tim Sweeney, who is probably one of the top ten C++ programmers in the world thinks so too. Did you not read the presentation linked up above? 50% of the bugs in the Unreal Engine are bugs, caused by shortcomings of C++. Yes. The use of C++ to develop software does increase "accidental" (as opposed to inherent) complexity in software, which then results in more bugs. Yes the skill of a programmer (or the application of techniques like pair-programming) can compensate for a lot of accidental complexity, but it seems somewhat of a wasted effort, when the effort could be spent further improving productivity, rather than fighting complexities inherent in the language, and instead focusing on the problem that needs solving.

Is it? I don't know that. Logic bugs are found by writing good unit tests. Good unit tests will prevent 90% logic bugs, and 100% regression bugs. The bugs that really cause problems (with C++ programs) are rogue pointers and concurrent access to shared data, and they are almost impossible to track down.

I think HL2 is optimized very well as it is. Most (popular) commercial games are (BTW, I'm reasonably certain that HL2 was created with C++).


Again, assuming that it takes 6 months more to use C++ as opposed to something like C#.


I hardly think that's an accurate statement when disabling C++ compiler optimization on my project drops it from 250 FPS to ~20 FPS on my relatively high-end PC.


Ok. Maybe I'm different, but for me it's second nature to avoid these problems - in other words, there's no effort lost.


I don't know, maybe it's just me, but a "rogue pointer" seems like a very common beginners mistake in C++ (just like forgetting your semicolons, you learn to eliminate it with time).

I'm not saying that high level languages don't reduce potential bugs, I'm saying that in some (though hardly the majority of) cases, the performance loss isn't worth it.

For example, can you imagine CryEngine 2 being coded completely in Python? That just seems ridiculous to me. Yes, the coding time would probably be reduced slightly, but not only would most of your time be spend on higher level tasks (inventing rendering techniques), but as I'm sure you know the engine would run inexcusably slow.


First of all, it's not me - it's the article I was explaining to you.

Secondly, I'm not saying programmers intentionally write bad code. I'm saying that it seems you claim that code optimizations are worthless and only waste your time.

Yep, I think Niklaus Wirth was absolutely right about C++. ;-)

I still don't understand why the industry chose C (and later C++) when there was Pascal. Or DOS when there was the Mac. Or VHS when there were BetaMax and Video 2000.

By the way, I am not a Pythonista, I only spent some days with it to find out what all that hype is about. To make it short, I did not fall in love with it, but there are some very good books about it written by people who truly love the language. I think it is hard to beat Mark Lutz' "Programming Python" or Alex Martelli's "Python in a Nutshell". Beautiful works, both of them.

Anyway, it's time to call it a day. ;-)

I doubt it. The "stolen" source code build had better performance than the final game.

Then I put it to you, that your code isn't optimized.

I wouldn't say that people who've worked on developing one of the most advanced (and probably optimized) 3D engines in existence over the last what, 15 years (?) is a beginner. By any definition of the word.

Not on the right hardware.

I don't know much about the leaked version you reference, but it's most likely that any extra performance is due to a lack of complete graphical / AI features.


Sorry, that's not true. My engine runs very fast, even compared to many commercial games.

Disabling optimizations means that a lot of the CPU and memory intensive tasks (like dynamic paging and batching) are EXTREMELY inefficient since every line of your code is compiled as it appears - nothing is optimized. I'm not saying the speed of C# or anything else is this slow; I was simply responding to this absurd statement:



Ok, maybe you're right then (assuming what you say is true). Do you have any proof of these 3D engine veterans complaining about rogue pointers and missing semicolons?


Ok, assuming Crysis could have been released months ago due to the "accelerated" development of using Python, what good would it do you? You'd have to wait 10 years until a PC powerful enough came out.

Just out of curiosity, have you ever tried implementing graphical techniques anywhere near as complex as some of the commercial games out there? If you had any idea what's going on internally in something like CryEngine 2, you'd realize how ridiculously slow it would be if implemented completely in a scripting engine.

No. Most of that is done by the CPU. The main reason your C compiler optimizations make such a huge impact, is because you're running it on a CPU that only has four general purpose registers - the compiler compensates for this by reorganizing code, so that it reuses these registers as much as possible (decreasing the chance of cache misses and necessary memory hits). If you were to write your code in an optimized way, you could get C code that runs just as fast as what the compiler optimizations does, but you don't because (surprise, surprise) it's not necessary - the compiler does it for you. Get it yet?

Yes. Read the presentation by Tim Sweeny linked by Orca earlier in this thread.

So you reckon that you need a PC 250.000 times more powerful than a state of the art to play Crysis written in Python? C++ maybe faster, but not nearly by 5 orders of magnitude. Like I said 10 years ago, I had this exact same discussion (except I was on the other side back then). "You'll never get C code to run as fast as assembly" I said. Guess what? I was wrong. And in 2 years, when everyone has a multi-core system (or in five years, when we'll hopefully have VLIW processors), we'll both kick back and laugh at the ludicrous dinosaurs who insist on using archaic languages. Much like we laugh at Steve Gibson now.

I understand what you're saying, but I don't think you understood me. Of course C++ is powerful enough that you can perform these optimizations yourself, but that's ridiculous and defeats the purpose of a compiler & optimizer. Again, I have to remind you that my response was in regard to this statement:

The effect of compiler optimizations are not trivial. Sorry, that's a fact.


I didn't say you'll never get Python to run as fast as C++. I said it doesn't run nearly as fast now.

Whether or not you want to gamble on possible future optimizations of a mainly script based language is your choice.


Again I think you're missing the point. Here's what I was saying:

- Python, at it's current state, is no where near C++ speed

- If PCs are >250 times faster than they are in 10 years, it's unlikely that this increase will be in GHz, but in multiple cores. Without specifically designing a game to make use of parallel processing capability, no performance is gained.

For example, a 1000 core 4 GHz computer could be said to have ~4000 GHz equivalent. But using my example, running a Python version of Crysis would only run 1.33 times faster than a quad-core 3 GHz machine since 996 cores aren't even being used.

Similarly, many old 3D games run extremely slow on my computer, even though it's relatively high-end. Can you guess why? Yes, it's because old optimization just doesn't work on new hardware in many cases. Optimizing something to run from 10 FPS to 20 FPS on a GeForce 2 may make that same program drop from 120 FPS to 25 FPS on a GeForce 7800.

The same thing applies to CPUs. Writing software on the hopes that hardware will be able to run in well enough in the future is insane, unless you have a very good idea what upcoming hardware your game will be targeting. But even in this case, it's a gamble.

Which one of the following would you prefer:

1. Develop a game in C++ in 9 months that runs great as soon as it gets published

2. Develop the same game in Python in 7 months, but be forced to wait another 12 months in order for CPU speeds to catch up enough to be able to run it at playable frame rates.

This whole (nonsense) discussion remindes of this thread on indiegamer.com:
http://forums.indiegamer.com/showthread.php?t=11645

Only there the bashing was about C++ vs Java.

Here's another thought for the flames: If "the C++ language" is faster than Python, then how come that Visual C++ is faster then MinGW C++? Can C++ be faster than C++? Can American English be faster than British English? Or can it be faster than French?

Specific platforms, tools and specific code can be faster than others. But certainly not languages.

Another thought: When multicore CPUs become the norm, C++ will quickly phase out as a popular language. Why? Because Tim Sweeney is right: It does not support multithreading well. Languages and platforms like C#.NET and Java will eat C++' lunch, and even Python will kick it around.

Still, every language has its place. People will still use C++ to maintain legacy code and they will still be using it for systems programming. But it will be - and already IS - disappearing from most other domains.

And one last thought: Is there a specific reason to discuss the merits of C++ to excess on a forum for a complete different language familiy? I mean, shouldn't we be discussing how BlitzMax code can be optimized to blow C++ code out of the water? Wouldn't that make much more sense?

Anyway. It's been an extremely draining day for me, so don't take me too serious tonight.

Exactly! It all depends on the compiler. One day Python or C# may in fact be faster than C++.

But the fact is that the top C++ compilers today are much faster than the fastest Python compiler/VM/etc.


Good point.

BlitzMax doesn't even implement optimizations many free c/c++ compilers have; loop unrolling, function inlining, dead code elimination.

Well sure. To the lazy people who write unoptimized code, compiler optimizations have a significant impact. But you can't have it both ways. The more optimized you think you're making your program, the less room there is for the compiler to fix your sloppy code.

Yes they are. The scheduler, not the compiler, determines how many cores are being used. If you wrote your engine in Python, and Python had kernel level thread support, it would scale automatically to take advantage of improved hardware. That's the advantage of JIT compiled/interpreted languages as opposed to the pre-compiled binaries, who stop working when hardware changes. Don't believe me? Play any game from 10 years ago. It's the same technology (Windows, DirectX blah, blah, blah) it just doesn't work anymore. No try the same with something written in Java. Not only will it still work, it will work better than it did 10 years ago, because it takes advantage of the fact that technology isn't static.

So you agree that optimization is a waste of time then? Good.

Every thing's a gamble. Writing your game in C++ is gambling that a year or so after your game has been released, no-one will care that it doesn't work any more.

I don't think your estimates of the time-to-market for a video game is even remotely accurate. If it took 12 months for technology to catch up, I'd spend that extra time improving on the game.

So by telling a compiler to optimize your code to make use of SIMD instructions means you're lazy and your code is sloppy? Right, its better to do it by hand and make your code even less portable.

Rendering packages, utilities and such all need far greater optimisation, and will often have some pretty extreme routines. The key is not to optimise everything, but to optimise a bottleneck which will yield a recognisable speed increase.

Often, its the entire program methodology which will speed something up, not machine code or better routines. For example there's more than one way to skin a cat? Some cat skinning techniques are much faster and aren't "optimised" either.

So instead of thinking optimisation, think "better method". The only place you need to optimise the code in a very hardcore way is if you are working with millions of bytes, say rendering and database lookup, or crunching programs.

Loop unrolling is not necessarily an optimization (it is if you have a long pipeline and no cache, it isn't if you have a short pipeline and a large cache). And the BlitzMAX compiler does eliminate dead code, but doing so is not an optimization (as dead code is never executed, it has no effect on the performance of the program).

I don't consider the use of SIMD instructions an optimization, so much as a different build target.

Since when did I become an advocate for optimizing things by hand? Have you even been following the discussion? Let me just quote myself here a couple of times, to get you up to speed:

"If you compile your C++ program for a target architecture of (say) i386, and then run it on any different processor, the C++ version will be considerably slower than a C# version." - FlameDuck
"Catch-22 eh? Your program is either slow and works on everything, or fast, and only works on the fastest CPUs. Hrmmm." - FlameDuck
"Unless you have an intimate understanding of how your compiler (regardless of language) translates your source code into binary code, and likewise have an intimate understanding of all your build targets (including hardware and operating system quirks) there is no way you can effectively optimize a program." - FlameDuck

Already tried that suggestion. They didn't buy it.

The only thing close is the Framework keyword; Blitzmax doesn't remove unused functions, loops, if statements, etc.
Any how it still fits in the definition of a compiler optimization.

You apparently don't advocate the compiler doing it, so what are you left with? Optimizing by hand or having "sloppy" code you don't want to optimize.

Azathoth is right. You seem to be changing sides often in minor subtopics to suit you're argument. First you say that micro-optimizing your code is useless and a big waste of time. I agree.

Now you switch sides saying only lazy programmers benefit from compiler optimizations, implying that non-lazy programmers micro-optimize their code (micro-optimizations are you're only alternate to compiler optimizations). You're sure about this?


I only remember a few 3D games several years ago I played that were distinctly Java-based. One was a simple RTS-style game, and actually ran fairly well. The other was a more high-tech 3D game more visually comparable to something like Far Cry. Not only did it run bad years ago, but it still runs bad now (even after upgrading my PC).

Maybe I'm not understanding this multi-core technology, but please explain to me how a game written for 4 cores (game, physics, AI, graphics) can be seamlessly scaled to 16 cores, for example.


That's not true. You're suggestion that algorithms should be improved was not disregarded. My own words were: