Does anyone even know what MASM is anymore ?

[rjk44]

I've been wading through some of the Forums here and it strikes me that Games software houses are, (and have been for some time by the look of it), churning out top end games, (I don't "game" btw), which require ridiculously expensive high-spec. hardware to run them properly. I suspect that somebody, somewhere is scrimping on assembler. Someone, somewhere, is, in as many words, saying, ."..that routine would take far too long to debug in assembler, so when we release it - ....recommended hardware specs. will be 73.8ghz 100 core cpu, 112,500gb's RAM, 142 SLI / Ti graphics card (each with 50gb of DDR55 RAM), and advice that before firing up the game, one must notify one's local power generating company that a significant extra load will be coming online within the next few minutes - so you may want to cut in a couple extra mains power generating stations

During the 80's/90's John Campbell, who programmed exclusively in assembler, marketed "Masterfile PC" (a database prog.) which could sort thousands of records in just seconds flat on an IBM PC compatible | 8086 - 8mhz cpu | 640kb RAM | two 5 1/4" floppy drives, and no hard disk !

So there we are, machine code routines are obviously being called during gameplay but, one wonders if the software house game writers even know what they are ?

regards, Richard

 

[KingFatty]

I wonder what the affect would be on development costs and times if games were programmed in assembly.

Like would Grand Theft Auto V cost about 4 trillion dollars to program in assembly, and take about 50 years time to finish it?

 

[cytg111]

as allready stated, cost <> benefit. When hardware stagnates, or for other reasons are kept static, for some time then focus shifts to software optimizations including hand optimized assembly for critical paths.

 

[Phynaz]

It's not the 80's anymore. Compilers are very, very good today. I doubt that the majority of programmers could produce faster code than a modern compiler.

 

[rjk44]

I wonder what the affect would be on development costs and times if games were programmed in assembly. Like would Grand Theft Auto V cost about 4 trillion dollars to program in assembly, and take about 50 years time to finish it?

If, many years go, ((more focus had been retained on assembler, (which would obviously have impacted on profits but, not significantly), when the divergence really got going towards high level programming languages), we wouldn't be on the never ending trek for more powerful hardware

regards, Richard

 

[BonzaiDuck]

I used to teach a class in assembly language; after so many years, what memory I have of it is so deficient that I'd have to take my own class, or pick up the textbook and start from scratch.

But what most of the posters say here is true. Programmers today have access to comprehensive libraries that can be utilized with higher level languages. The cost and time of doing things at a level just above machine language would, indeed, result in games nobody could afford -- no matter how many gamers were lining up to buy.

 

[zir_blazer]

Lurking the FASM (Flat Assembler) forum and an interview with John Carmack about the Doom engine, claims are mostly that good hand made ASM code can be like 10% faster that very good code in a high level language like C (Which is itself rather low level). However, point is, these days you're not comparing ASM vs C like during the 90's, you're comparing ASM vs things like Java and a lot of other abstraction layers that EATS performance in exchange for cross platform development, code reusability, portability, faster development times and all those things that the companies that pays the programmers prefer these days.
But yes, there is a point: The faster Hardware is, the more lazy programmers can be. Go look for the ASM scene and their famous demos, you will see what "magic" is in the Software world. But taking advantage of ASM performance and hand made optimization requires geniuses that both know how to write good code and how to take full advantage of the Hardware potential, the regular programmers are merely codemonkeys that just try to get things working and ready to go commercial before deadlines.

Also, compilers are NOT perfect, they are complex behemoths, and such high complexity adds for realistic chances of compiler-induced bugs. For example, you may read things like GCC -o3 optimizations for the Linux Kernel, since at several points it presented issues (Check here, there were a few better links with more hard data about that matter). On ASM, the assembler mostly just translates directly to machine code what you wrote. You get the exact, documented behavior you want.

 

[rjk44]

The cost and time of doing things at a level just above machine language would, indeed, result in games nobody could afford -- no matter how many gamers were lining up to buy.

I really do understand that but, the end result, (from what I can see of it), is people keep ending up with fairly newish hardware, that was VERY expensive to buy, and which rapidly depreciates in value, and is simply not up to playing that latest game !

regards, Richard

 

[VirtualLarry]

I used to code games on PC (mostly hobby, some professional) in both C / C++ / and x86 ASM. It really is a bit of a lost art. But now with auto-vectorization in compilers, and smarter loop unrolling, I really do wonder how much better a real pro ASM programmer would do with certain code sequences than a really good compiler.

Edit: Oh, and if studios aren't even going to patch the C source code for threading, such that a console port designed to start the main thread on physical core number 3, won't even run on a dual-core PC (that is still largely sufficiently fast enough to run the game), then they certainly won't pay for the extra development time that ASM hand-tuning would require.

 

[rjk44]

Edit: Oh, and if studios aren't even going to patch the C source code for threading, such that a console port designed to start the main thread on physical core number 3, won't even run on a dual-core PC (that is still largely sufficiently fast enough to run the game), then they certainly won't pay for the extra development time that ASM hand-tuning would require.

That's a little like saying that, "It's not good enough that Creative aren't paying a small team of people to write drivers for my old Audigy 2 soundcard so that it works in Windows 8.1 , so that I didn't have to patch it myself " !

regards, Richard

 

[zir_blazer]

That's a little like saying that, "It's not good enough that Creative aren't paying a small team of people to write drivers for my old Audigy 2 soundcard so that it works in Windows 8.1 , so that I didn't have to patch it myself " !

This is an entirely different example and not even related to ASM itself, you should instead say thanks to propietary Drivers. Not only you pay for the Hardware part, but also the Software that its needed to make it work. For whatever its mainstream at that time it may be fine, but if they decide to not maintain or update their Drivers to work on newer OSes (Which is rather common), you're screwed.
If Drivers were open source, you could leave the mainteinance job to someone else, since every now and then someone voluntarily picks up a Driver and fixes it so it can be used in newer OSes. Heck, if you wanted it really that bad, you could even try to put a bounty for a port of the Driver and try to catch a programmer-for-hire. Without the source code, your only choice is the ridiculous harder reverse engineering (Which is where ASM may come to play).

 

[Schmide]

In a highly pipelined architecture a few tics here and there mean less and less compared true penalties incurred by poor memory and critical section management. The middle ground of intrinsics has kind of put the nail in the coffin for true low level languages. This is not to say instruction level programming is dead, it's just moved into the shader and compute level coding.

 

[VirtualLarry]

That's a little like saying that, "It's not good enough that Creative aren't paying a small team of people to write drivers for my old Audigy 2 soundcard so that it works in Windows 8.1 , so that I didn't have to patch it myself " !

regards, Richard

No, it's a trivial source-code change. It should have basic error-checking, such that it doesn't try to schedule threads on logical CPUs that don't actually exist in the system.

 

[videogames101]

A productive programmer is one who doesn't have to worry about assembly. This is why higher level languages exist, and btw those languages and abstractions are enabled by faster hardware.

Each layer is programmed at the necessary level of complexity, and not having to worry about whats underneath you is a key. How far should we go down? Should programmers have to know which ALU path is fastest? Determine that from circuit schematics? Abstraction is fundamental.

 

[NTMBK]

I really enjoy that you complain about the amount of VRAM that your game requires, as this has nothing to do with whether a game was written in assembly. Frankly, if they wrote the memory management system in assembly, then it will probably be a bug-ridden mess which uses your GPU memory inefficiently. Better to write it in C/C++ and actually make the logic clear and understandable, easier to debug, and still damn fast.

Hot sections of engine code are likely to still be written in either assembly or intrinsics, especially if it is something which can be vectorized with SSE. But higher level logic will be written in a compiled language such as C++, because developer productivity is an absolute nightmare in assembly/intrinsics.

Let me put it this way- would you rather have a game which ran 25% faster, or a game with 3X as much content in it? That is the sort of choice you would have to make if you wanted to write the damn thing in ASM. New games require a lot of resources because they are really, really graphically intensive. If it bothers you so much, just turn down a couple of settings and get on with your life.

 

[cytg111]

A productive programmer is one who doesn't have to worry about assembly. This is why higher level languages exist, and btw those languages and abstractions are enabled by faster hardware.

Each layer is programmed at the necessary level of complexity, and not having to worry about whats underneath you is a key. How far should we go down? Should programmers have to know which ALU path is fastest? Determine that from circuit schematics? Abstraction is fundamental.

I'd add that the productive programmer do understand the lower levels, having a firm understanding of how the machine works, what your code is translated into, will guide you to produce more efficient c/c++.

edit : on the subject, and motivated from the same source as the OP, i started a project once(never finished) to create a small-as-possible gui enabled IRC client, using C-ish C++ (c89) and nothing but CreateWindowEx - just for the hell of it. I bet you could get such a, well featured, sucker down at ~10-20kb.

 

[Hulk]

I've been wading through some of the Forums here and it strikes me that Games software houses are, (and have been for some time by the look of it), churning out top end games, (I don't "game" btw), which require ridiculously expensive high-spec. hardware to run them properly. I suspect that somebody, somewhere is scrimping on assembler. Someone, somewhere, is, in as many words, saying, ."..that routine would take far too long to debug in assembler, so when we release it - ....recommended hardware specs. will be 73.8ghz 100 core cpu, 112,500gb's RAM, 142 SLI / Ti graphics card (each with 50gb of DDR55 RAM), and advice that before firing up the game, one must notify one's local power generating company that a significant extra load will be coming online within the next few minutes - so you may want to cut in a couple extra mains power generating stations

During the 80's/90's John Campbell, who programmed exclusively in assembler, marketed "Masterfile PC" (a database prog.) which could sort thousands of records in just seconds flat on an IBM PC compatible | 8086 - 8mhz cpu | 640kb RAM | two 5 1/4" floppy drives, and no hard disk !

So there we are, machine code routines are obviously being called during gameplay but, one wonders if the software house game writers even know what they are ?

regards, Richard

I used a handed coded assembly program in the early '90's by Bob Lentini called SAW, Software Audio Workshop. It easily fit on one floppy and was the only program available that could easily record and edit multichannel audio with good eq and other effects. Also have done some assembly on my old Atari 800 back in the day I wonder how good today's compilers really are compared to a really smart person with assembly. Not for the whole application but only the routines that are continually called.

 

[knutinh]

... I wonder how good today's compilers really are compared to a really smart person with assembly. Not for the whole application but only the routines that are continually called.

Everything should be coded at the highest abstraction level possible, given the expected functionality and performance requirements.

Usually that means a high-level language, abstract libraries that lets you produce a lot of platform-independent, relatively bug-free functionality per man-hour. Sometimes that means dipping your toes in low-level stuff because that is the only way to get acceptable calculation times for a particular problem and a particular hardware platform.

The roof is the limit when it comes to "how large can the speedup potentially be" for a cherry-picked function. If you average over a wider set of functions, the speedup tends to be less. Compilers might not beat (skilled, motivated) humans in a single hot-spot but they beat us by being able to do their thing over and over for all parts of the code, for ever new platforms etc.

I think that the knowledge about assembly and the self-confidence of beating the compiler at least once in a life is a good thing for programmers. I don't think it makes much sense to move to assembly permanently for anyone but very specialized ones; the world "needs" (is willing to pay for) ever more software complexity, and having 90% of us being software developers would not be sustainable.

-k

 

[sm625]

Today's software is so far from ASM its not even funny. We are literally decades behind in software optimization. It would take the average programmer dozens of megabytes in code and RAM just to emulate the original super mario bros, even though that cartridge was like 64 KB or some crazy small number and the system only had 2KB of RAM. It has become so bad that it actually takes billions of instructions just to render a simple web page, once all the data has been downloaded. There is simply no excuse for that. What's even worse is when a very simple dialog box has noticable lag.

 

[cytg111]

and having 90% of us being software developers would not be sustainable.

- I think you are dead wrong on that one.. but the endgame is too far off to make any bets on it yet .

 

[xthetenth]

- I think you are dead wrong on that one.. but the endgame is too far off to make any bets on it yet .

Well it'd be interesting if we tried to get 90% of people hand-coding assembly that can beat modern compilers, that's for certain.

 

[Exophase]

Assembly has its place still sometimes, but there's usually a lot of other things that need consideration when optimizing code.

For example, maybe your compiler isn't as good at auto-vectorizing some forms of code for some archs as you are, but your code likely first needs to be designed at a high level with that sort of vectorization in mind.

 

[Gryz]

If you want to make a program run faster, it's a waste of time to look at assembler code. As Zir blazer says, you might gain a 10% speedup. If you're lucky. And if you're really good at assembler and hardware architecture. And then in a few months, when a new CPU is released, your speedup-gain might be completely lost.

If you want to make a program run faster, then look at the algorithms you use. Time versus space trade off is a good one to start, and that should always be considered. What data-structures do you use (array vs list vs tree vs hash-table) ? This is where you can gain true speedups.

Not messing around with assembler.

I'll go so far to say: thinking that programming in assembler will speed up your programs, is a sign that someone is a true amateur.


Also, the cost of hardware is peanuts. Compared to the eighties and nineties. Even if you build the most expensive gaming-PC you can think of.

 

[Arachnotronic]

If you want to make a program run faster, then look at the algorithms you use. Time versus space trade off is a good one to start, and that should always be considered. What data-structures do you use (array vs list vs tree vs hash-table) ? This is where you can gain true speedups.

This is a really good point and one that CS DS&A courses (correctly, IMO) try to drill into students' heads.

 

[jhu]

Today's software is so far from ASM its not even funny. We are literally decades behind in software optimization.

Hyperbole much?

It would take the average programmer dozens of megabytes in code and RAM just to emulate the original super mario bros, even though that cartridge was like 64 KB or some crazy small number and the system only had 2KB of RAM.

So, you know how to emulate an NES in less code?

It has become so bad that it actually takes billions of instructions just to render a simple web page, once all the data has been downloaded. There is simply no excuse for that. What's even worse is when a very simple dialog box has noticable lag.

Really? Have you looked into it? Also, are you able to implement the entire html5 specification in less space with maintainable code and bug free?