I could have solved that problem otherwise but I was in a rush and I knew that assembly treated references like pointers, I just did a LEA with the reference+4 and moved on with it. Later I came back and fixed it with proper C++.

i's say that's an acceptable use of assembly as a quick hack for rapid prototyping, especially given that you went back and cleaned it up later.

so it looks like there may still be some uses left for in inline assembly/machine code (above and beyond special instruction sets).

The quality of your code and software architecture impacts your performance way more than your choice of language or choice of library. BUT! If you are already an excellent programmer and already pushing things very close to the limit, then the language and library choice can add a small boost of extra performance that may come in handy for the next Modern Warfare or Crysis game.

Interesting. So the quality of code matters than the language. Thanks for the awesome info!

By way of analogy, you can think of different languages a bit like race-cars. The Python car might only have 200 horsepower, but its nimble and easy to drive. The C++ car has 500 horsepower, but it takes a lot of skill to drive and its got a lot of momentum when you can drive at those speeds. Very specialized languages like assembler or GPU compute languages might have even more horsepower, but good luck driving in anything other than a straight line -- and you've got to take a pitstop every other lap to fill your tank.

Having more power that you can't effectively use isn't going to make your lap times better. Not safely, anyways.

By way of analogy, you can think of different languages a bit like race-cars. The Python car might only have 200 horsepower, but its nimble and easy to drive. The C++ car has 500 horsepower, but it takes a lot of skill to drive and its got a lot of momentum when you can drive at those speeds. Very specialized languages like assembler or GPU compute languages might have even more horsepower, but good luck driving in anything other than a straight line -- and you've got to take a pitstop every other lap to fill your tank.

Having more power that you can't effectively use isn't going to make your lap times better. Not safely, anyways.

That's why I always used Toad and Koopa in Mario Kart. They were the slowest ones, but they never gave me problems with curving tracks. Bowser and DK were much faster, but it was always harder to get that speed, and even more so to try to keep it.

The only reason would be some cross platform variation that a standard library doesnt do the fucntion correctly or its not available.(including stuff like atomic locks for multithreading which might require much more limited use than generalized (slow) library/OpsSys functions)

You should never use low level programming for making games, if you actually want to MAKE and FINISH games! The lowest level you should go is C++, which is what everyone does. And depends on the game you want to make you should only go higher level. The only reason people use C++ is because the code runs faster than say, C#. But this is for crazy games like Crysis, Battlefield, Skyrim etc, who really need that performance. If you want to make games and finish your games, and you can achieve the result you want without writing in C++, I have no idea why you wouldn't use C#, which will save you thousands of lines of code, and XNA is a great platform.

C++ still alows assembly code imbedded doesnt it ??

Anyway, with the likes of the smartphones these days and lower than PC/platform rated CPUs there can be a need to push performance to reach a wider hardware target (players will always want more/faster and the handhelds will always lag behind the faster machines and their users expectations)

Issue they always quote - langauges with garbage collecting that isnt easily controlled is often a game buster (for certain types of games)

You should never use low level programming for making games, if you actually want to MAKE and FINISH games! The lowest level you should go is C++, which is what everyone does. And depends on the game you want to make you should only go higher level. The only reason people use C++ is because the code runs faster than say, C#. But this is for crazy games like Crysis, Battlefield, Skyrim etc, who really need that performance. If you want to make games and finish your games, and you can achieve the result you want without writing in C++, I have no idea why you wouldn't use C#, which will save you thousands of lines of code, and XNA is a great platform.

C++ still alows assembly code imbedded doesnt it ??

Anyway, with the likes of the smartphones these days and lower than PC/platform rated CPUs there can be a need to push performance to reach a wider hardware target (players will always want more/faster and the handhelds will always lag behind the faster machines and their users expectations)

Issue they always quote - langauges with garbage collecting that isnt easily controlled is often a game buster (for certain types of games)

inline assembly is not part of the C++ standard, the standard however does allow compilers to extend the language and compiler extensions that add the ability to write inline assembly are common but not all compilers support it and the syntax used to write inline assembly varies between compilers, the same goes for more important things like SIMD intrinsics, function attributes, etc (which can greatly boost performance if used well), C++ without compiler extensions is a pretty poor language to use for high performance code

If you're going to use C++ for performance reasons you have to be prepared to write compiler specific code, otherwise you won't gain much.

If you're going to use C++ for performance reasons you have to be prepared to write compiler specific code, otherwise you won't gain much.

There's a lot of performance-centric things that C++ allows you to do, without leaving the realm of standard/portable code.

Most of the optimization work I've done in recent years has been on improving memory access patterns -- how things are laid out, where they're allocated, and when they're used. This is because CPUs keep getting faster, but in relative terms, memory is getting slower and slower. C/C++ are great languages for this work. C# lets you do it somewhat, but it's incredibly un-idiomatic.

In C++03, you needed non-standard code to do some alignment tweaking, but not any more in C++11. The only other non-standard tools are the ones to mess with with vtable implementations, (but I'd never recommend doing that anyway ) and to affect the order of code/data within the final EXE (which is in most cases a silly microoptimization, like ASM programming ).