Greg_Nearfield
Newcomer
Hey what do you think would happen if all next gen console games were programed in ASM.
Who still here loves assembler?
- Thread starter Greg_Nearfield
- Start date
Greg_Nearfield said:
They'd never get finished.
Thew largest all assembeler game I've ever worked on (and I've written a few) is maybe 150,000 lines and that takes real planning and discipline. My current project is close to 2 million lines of C++ code, with 30+ engineers, it just wouldn't be viable.
Besides there is little if any benefit to coding the majority of an application in assembler on a modern processor. Excecution time is dominated by cache misses in all but a small percentage (by volume) of the code.
We do still write assember where it makes sense.
What ERP said about large scale use.
Anyway, writting ASM code is fun - maintaining it, is not.
Even when you write heavily documented code and take care to make it readable, you'll be hard pressed to instantly grasp the flow of large asm program if you haven't looked at it in months.
And anyone that's done hand-unrolling of loops and scheduling optimizations by hand can tell you that optimized code is pretty much impossible to maintain - you have to re-do the "optimization-pass" for almost any kind of change.
Going halfway (by using intrinsics or one-line-asm macros) can be similarly rewarding but keeps the code a lot easier to read since you still get to do control logic etc. in highlevel language, and a good compiler can do the more time consuming optimization passes for you.
Anyway, writting ASM code is fun - maintaining it, is not.
Even when you write heavily documented code and take care to make it readable, you'll be hard pressed to instantly grasp the flow of large asm program if you haven't looked at it in months.
And anyone that's done hand-unrolling of loops and scheduling optimizations by hand can tell you that optimized code is pretty much impossible to maintain - you have to re-do the "optimization-pass" for almost any kind of change.
Going halfway (by using intrinsics or one-line-asm macros) can be similarly rewarding but keeps the code a lot easier to read since you still get to do control logic etc. in highlevel language, and a good compiler can do the more time consuming optimization passes for you.
ditto as the previous posters.
as much as i enjoy coding in assemby, i use it only as a last resort in any projects that are expected to have some maintainability. oth, i often spend time reading through the assembly listings output by the compilers i use, but that's because i'm a paranoid sceptic suffering from advanced compilerophobia.
as much as i enjoy coding in assemby, i use it only as a last resort in any projects that are expected to have some maintainability. oth, i often spend time reading through the assembly listings output by the compilers i use, but that's because i'm a paranoid sceptic suffering from advanced compilerophobia.
arjan de lumens
Veteran
Writing assembly code may occasionally be useful to wring out the last bits of performance when you are otherwise unable to reach a lofty performance target, but it has serious problems:
As a general rule, you should do this kind of assembly or "assembly-in-C" type optimization only AFTER you have performed full profiling of your program and identified hotspots that really need extra attention AND cannot be readily resolved in any other way. If you have a large routine that makes up 20% of your program, but your program spends only 0.01% of its time in that routine, optimizing the routine for any other parameter than readability/maintainability is sheer idiocy (unless perhaps if you are allowed inordinately large amounts of development time for your program and have run out of other optimization opportunities).
- You need a profound understanding of your target's instruction set AND its scheduling rules AND a general understanding of both high-level algorithmic efficiency combined with a highly trained capability to identify and exploit low-level optimization opportunities. An inexperienced or otherwise less-than-stellar assembly programmer will often produce code of much worse performance than a C/C++ programmer of similar experience.
- Assembly code tends to be bug-prone, difficult to debug/maintain, difficult to interface with other languages, and difficult to port; also, naively transferring code from one (even binary-compatible) processor to another tends to break the scheduling rule assumptions that were used to make the assembly code 'optimal' for the first processor.
As a general rule, you should do this kind of assembly or "assembly-in-C" type optimization only AFTER you have performed full profiling of your program and identified hotspots that really need extra attention AND cannot be readily resolved in any other way. If you have a large routine that makes up 20% of your program, but your program spends only 0.01% of its time in that routine, optimizing the routine for any other parameter than readability/maintainability is sheer idiocy (unless perhaps if you are allowed inordinately large amounts of development time for your program and have run out of other optimization opportunities).
[quote="darkblu]i often spend time reading through the assembly listings output by the compilers i use, but that's because i'm a paranoid sceptic suffering from advanced compilerophobia.[/quote]
If you work on a novel hw platform or with immature/new compiler (or worse, a combination of the two), I would call it common sense rather then a phobia.
But yea, prolonged exposure to such cases will probably make it a medical condition.
If you work on a novel hw platform or with immature/new compiler (or worse, a combination of the two), I would call it common sense rather then a phobia.
But yea, prolonged exposure to such cases will probably make it a medical condition.
I think ERP is right on the money, although I've always shied away from using intrinsics, as they seemed to be (at least at the time of the first MMX processors) very compiler specific.
I've often found (again in my wavelet image compression (which I am properly documenting at the moment and then re-releasing under the zlib-license. If anyone wants to get in touch for what sort of interfaces they'd like to see, do that.)) that removing beautifully handcrafted assembly and doing higher-level optimizations in C instead yielded faster code in the end.
An acquaintance of mine wrote a DX7 RTS game ("Thandor") completely in assembly. Even the assembler used was written by him...
It's nothing I would even want to do, but he managed, so kudos to him. But you definitely need a masochist-streak to attempt something like that...
I've often found (again in my wavelet image compression (which I am properly documenting at the moment and then re-releasing under the zlib-license. If anyone wants to get in touch for what sort of interfaces they'd like to see, do that.)) that removing beautifully handcrafted assembly and doing higher-level optimizations in C instead yielded faster code in the end.
An acquaintance of mine wrote a DX7 RTS game ("Thandor") completely in assembly. Even the assembler used was written by him...
It's nothing I would even want to do, but he managed, so kudos to him. But you definitely need a masochist-streak to attempt something like that...
MrWibble said:
MrWibble has a point though.
If you want to wring the new consoles for what they are worth, the compilers are likely to need some manual help in places, given the architectures.
arjan de lumens makes some good points from a general computation perspective, but I question just how relevant portability concerns are for console game code anyway. For scientific code - sure. But if we are discussing for instance a PS3 game - it's a fixed platform, and the finished product is very unlikely to be ported over decades worth of new architectures if indeed ported at all.
Similar threads
