How useful is assembly on todays systems?

[User12]

Hello!

This is my first post - I'm very much human (although some friends seem to disagree... ::)).

I'm a reasonably decent programmer (C++), well, more precisely I can create reasonably decent applications, but I can't claim to be knowlegable of the inner workings of many things. I've read numerous times of how hand written assembly isn't desirable at all in todays development environments when compared to the advantages and disadvantages to higher level languages. I suppose this is fair enough - I can't say I know of any modern applications written in assembly other than those at grc (which aren't particularly large). But, if a major advantage to writing in assembly is to squeeze every bit of performance out of some code by using the best instructions for the job, taking extra care of data in cache lines, careful ordering of instructions etc. then isn't this advantage diluted when you consider all the processes that are running and sharing CPU time etc. even on a fresh Windows install, to the point of making any performance advantages next to none?

Thanks.

[hutch--]

Its a question that you answer by knowing the capacity of both tools, CL and ML. If CL does the job you may never need to use an assembler, if it won't you can dabble with inline code (32 bit) with CL or write a module in MASM for targetted areas that you cannot do as fast with CL.

Your question has a set of assumptions that are probably not sound, however many processes are running does not effect compiled code any worse than assembled code, if you don't believe that optimised code exists, then use even slower non C++ code, VB etc ....

Your need will determine if you get any advantage from manual assembler coding and the clock will tell you if it was worth the effort, the rest is hot air.  :P

[MichaelW]

Because of the way Windows allocates CPU time to running processes, the sharing of CPU time will not dilute the advantage of faster code.

[SteveAsm]

I've read numerous times of how hand written assembly isn't desirable at all in todays development environments when compared to the advantages and disadvantages to higher level languages.

That's merely an opinion.

I will respond with an anecdote.
Someone once told me:  "no one needs to own a gun today, (assuming one owns a gun for the purpose of hunting), because you can buy all the meat you need at the super market".

Like wise, you don't need to go fishing, either, because you can buy all the fish you can eat at the market too.
Similarly, you don't need to play sports either, because you can watch all the sports you want on tv.

Some things people do for the enjoyment of it.
I enjoy fishing.
Among other things, I also enjoy coding in Assembler.

[ninjarider]

i think it comes down to companies wanting things done faster, as far as production time. that and with computer technology these days companies dont care how fast their code is because theres faster processors to keep up with a little inefficeint code. they dont care how big the progam is because theres bigger hard drives. when you do some research on the x86 class and find the v and u pipline and that different instructions can be read on different pipelines in the processor making it so that a single core can actually process two commands at the same time if you can write your code right (can't always be done). things that i doubt c and c++ could do.

[dedndave]

i think it's primarily a maintainability issue
the guy that writes the code today may not be here tomorrow
they want to be able to hire the next guy to step in and pick up with minimal effort
or, perhaps, they have several programmers working on different pieces of a project

i write in assembler because i like to
fewer road blocks - smaller code - and you get some mental push-ups   :P

[vanjast]

Gee.. this subject is flavour of the month!!

I do a fair amount of embedded assembly and some PC assembly, mainly because I require precise control (maybe we're control freaks here).
I use VB to just test a concept, but sometimes this doesn't work as Asm would.

It's all about what you're comfortable with... I prefer structured labels, tabs, short code instructions and comments...... to loads of indentations that fall off the edge of the page and it's related structures.... I can read asm better as I have registers in my head.. :bg

[User12]

Thank you everybody for the replies - I really will have to take some time to learn assembly and so the CPU, doesn't feel right not knowing the inner workings of something I'm using...

[vanjast]

There you go... this is what it's all about.. you'll do well  :U

[clive]

Computers and compilers are certainly a lot better keeping track of the timing nuances and interplay of various structures/logic within the CPU. This is a least the VTune model used by Intel which models how the execution units interact with branch prediction, pipeline bubbles, interlocks, caching, etc. This however usually ends up with code tailored to a very specific core, and potentially multiple solutions to the problem, with the appropriate one chosen at run-time.

With a lot of instructions dropping to cycle or sub-cycle throughput, a lot of optimization comes for actually understanding the algorithm and appropriate ways to tackle it, this is something that a compiler is never going to be good at doing. The best the compiler can do is recognize fragments, patterns or templates. The programmer hopefully has a much higher and broader grasp of the problem.

Wasn't this whole "the compiler will figure it out" the undoing of the Itanium? There was a lot of promise, but then a failure to deliver, because extracting parallelism from serialized programming languages is hard.

The problem there was the large instruction widths, where multiple operations could be combined, and lack of hardware interlocking of resources where a given register was off-limits until it's load or operation was complete. Even if you used the assembler, a post processing tool would look for pairing opportunities, and avert/identify pipeline hazards.

Compilers generally foster a level of laziness, and it's usually that which provides the astute coder with the most opportunity.

[hutch--]

There is something I should have mentioned that is often overlooked these days, with the choice of tools you have available, put your effort where you get something back for it, having the fastest MessageBoxA() on the planet would probably be a waste of development time. The rough 90/10 rule still applies, 90% of code does not matter in speed terms where the 10% that does matter is often not fast enough. If you know what you are doing with your code you should be able to isolate task based hot spots and provide a high speed alternative to it and here an assembler may be the tool if in fact you have the right algorithm in the first place.

The other comment is don't get caught with "inner loop" theory, when written correctly, assembler code does outer loops just as well along with interdependent loops, crossfire loops and any other variation you can dream up. If you are going to write algorithms in assembler or at least parts of larger more complex algorithms, think of them in terms of block components rather than just hot spots in a compiler. Where you get stung with the compiler hot spot approach is in the overhead preserving registers to call a small number of instructions and the loss of the compiler's internal optimisation around the inline assembler code.

You get the best results by writing your assembler code as a separate module and linking it into the C/C++ application.

[vanjast]

Another point to consider is that ..

If C/C++ were the defining dev languages.. there would be no place for assembler.
The continued existence of Asm and associated IDEs is an indication that the above theory is not working.
Even Msoft provides a Asm 'compiler'/'linker' in it's latest platforms... a telling story no doubt.
Also maybe Bill Gates will never forget his origins.. :green2

[SteveAsm]

Even Msoft provides a Asm 'compiler'/'linker' in it's latest platforms... a telling story no doubt.

I wish the good folks at MSDN would provide a forum for MASM.
They have forums there for just about everything else they build.
I've stated as much to them in their questionaires.

[Magnum]

They wouldn't make as much money on their other programming languages that they sell.   :bg