Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

philscott

Should I be learning assembly language...

This topic is 5813 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have just about got the basic 8086 instruction set learned and have an overview of the FPU instructions as described in the Intel manuals, and I've found a few benefits from it already just by being able to read a program's disassembly. I was thinking that learning assembler was going to be important for code optimisation, especially for someone hoping to get into 3D graphics. Can anyone in the industry give me an idea of how much assembler is actually relied upon nowadays? Can a good assembly language programmer beat the Intel compiler (I don't know if AMD have their own). And as for the SSE2 extensions, Intel reckon that you will often end up with faster code if you use their Vectoriser than if you work direct with the SSE2 instruction set, and that you will end up with pretty fast code if you work with their Vector classes. So even for working with the SSE2 instructions, is it worth knowing the SSE2 instruction set? When needing to optimise a section of code, are you going to get better results by reading the Optimisation manuals and knowing how to provide the right C for the compiler, or is assembler still called upon for the parts of the program that need the heaviest optimisation? Thanks [edited by - philscott on November 20, 2002 4:46:09 AM] [edited by - philscott on November 20, 2002 4:46:37 AM]

Share this post


Link to post
Share on other sites
Advertisement
Frankly, using assembly in very well-written code will generally get you next to nowhere. There''s a limit to just how fast you can get code to perform, no matter how assembly optimized, and if your C/C++ code is written properly and fully optimized, chances are the compiler will compile it to closely match that limit.

I''ve learned through personal experience that, to quote what many people on this board say, assembly isn''t a magic optimization bullet that''ll magically speed up all your functions. However, in some cases, you can optimize some stuff to save yourself a few dozen clock cycles here and there. For instance, a blitter of some kind that allows you to plot translucent sprites on the screen is somewhat needy and might benifit slightly from assembly optimization IF you know what you''re doing.

Here''s one thing to keep in mind: just because rearranging your code to swap out a mov or two might seem better, if you end up saturating your registers to do it you won''t be able to take advantage of parallelism and thus, even though your program may be shorter, it''ll take longer to execute. There''s a lot of stuff like this to keep in mind and the compiler may seem to do some strange stuff sometimes, but it often compiles to take advantage of stuff like this.

Basically, don''t bother optimizing in assembly uselessly. Just optimize speed-critical sections of your program if you really want an extra frame per second or two. And I recommand keeping a C/C++ version and an assembly version of functions to test them both and see which would perform fastest (over, say, a few thousand calls to the function). You''ll notice there isn''t that much of a difference in most cases.

Share this post


Link to post
Share on other sites
Is the gap then closing between the speed of code produced by a compiler and that produced by a good assembly programmer?

Looking at the amount of things you have to take into consideration to make effective optimisations with assembler, it looks like there are a lot of places where you could go wrong where a compiler would not. I''m not going to be applying for a job in the games industry till about 2006, and I''m wondering that, if the future of assembler is looking a bit bleak, is it worth the effort learning it when I could be spending the time improving skills in other areas.

Share this post


Link to post
Share on other sites
Performance gained through assembly language is only as good as your algorithm. You should be concerned more with using most efficient algorithm in a first place. I dont suggest going in and replacing every line of code with ASM equivalent. You only wanna do that on parts of program that are executed frequently, like blitting subroutine or something. Before you even start rewriting some portion of code in assembly, question yourself, can I really do this better than a compiler? If you''re certain that ASM will speed up a portion of your code, always setup a benchmark. Run the optimized subroutine say 100,000 times, and measure how many milliseconds it takes to execute that. Then run the original version to see if anything is gained. Optimize only parts that need optimization and are used freqently. With pretty good compilers out there don''t expect major performance boost either. The system will operate no faster than the slowest component which. If you''re doing programming for DOS then I say go ahead with extensive ASM optimization on things like loops, fills, but at the same time don''t re-invent what''s already been done. In Windows environment the performance gain may be lesser in general since Windows is programmed with API which are coded in C so cramming loads of ASM code will not buy you much. It''s important to optimize but don''t reinvent the wheel over one clock cycle.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
It can''t hurt.

If you know assembly well enough to sometimes beat a compiler, then you will much more able to write better code in the first place. By understanding assembly, and what makes code fast/slow and then seeing asm output of a compiler you learn an enormous amount about writing good code in the first place.

While maybe asm is becoming less common, if you understand and can program well in asm then you will be much more able to analyze a critical loop, check the compiler''s code, and then determine if you yourself can do something better.

But of course, always benchmark to make sure.

Cheers.

Share this post


Link to post
Share on other sites
Speaking from my personal experience, sure if your algos are slow they won''t be much faster in asm either. However, if you can get the code where 60% of the time is spent to be 40% faster it will buy you quite a bit of time. Even though no compiler will ever get nearly as good as good assembly programmer, the compilers code will probably be faster then bad asm code. I also think that any programmer should learn asm, it will make them better programmers even in high level languages. But you should not bother wasting time coding everything in asm. Only where it matters. First profile your code to find out where most the critical parts are, then start optimizing the innerloops of the critical parts ( ) in asm.

Share this post


Link to post
Share on other sites
Heh, and the post above my first one say the exact same thing. Note to self: Next time read all posts.

Share this post


Link to post
Share on other sites
Thanks for the replies.

I''m working in windows so surely things like blitters are provided in hardware through DirectX. My question came up after scanning through optimisation manuals and reading replies on the forum and realising how many seemingly obscure rules you would need to know in order to write good assembler. By the looks of things, Intel''s compiler, which is designed to optimise for the P4, would know those rules and be able to work with them far more faultlessly than a human could. And their benchmarks reckon that, while a routine using the SSE2 extensions written in pure assembler will significantly outperform standard C code, it will not out perform code optimised with their Vectoriser (whatever the hell that is)

None of the replies have made mention of what I am specifically referring to, so I''d still like a bit more help answering my question. I''ve read a number of replies on this forum saying how assembly language can regularly beat compiled code, but they don''t say which compiler they use. The code produced by MSVC standard edition is absolutely appauling and very easy to beat, but with optimisation options provided by the professional edition it can make optimisations that would often be impractical for a human to imitate (like converting constant multiplications to shifts and using the esp register to reference stack parameters instead of the ebp register). And this is only the microsoft compiler which doesn''t specifically target the latest processors.

I''ve learnt the 8086 basic instruction set and it has been a help to me, but on top of that there are the MMX, SSE and SSE2 instructions to learn and then all the optimisation rules on top of that. I don''t want to become proficient in their usage, even if its just with the intention of optimising that essential algorithm, if keeping up to date with the next generation chipsets is going to turn out more trouble than it''s worth, and then to find that compilers are going to end up closing the gap so much that speed differences are negligible anyway.

Thanks again.




Share this post


Link to post
Share on other sites
Well, question yourself what you want to do with your code: do you want it to be fast or compatible?

Learning MMX and SSE and all is great and can make for much more performant code, but you''ll be alienating processors not compatible with those. You could use some chipset-specific code to take advantage of something only, say, intel processors can do (say, some architecture related means of arranging the order in which you access registers; I dunno ^^ but it might perform slower on an AMD or plain fail to perform, so you''d need more code, etc...

C/C++, however, is generally compiled to execute on any computer so long as it runs the appropriate OS (and that it isn''t TOO old; let''s try running a 3D demo on a 8086 boys and girls :D) However you can''t micro-optimize sections of code and wouldn''t benifit from sparing a few cycles here and there. As dumb as it may seem, sparing a handfull of cycles in a tight loop executed many, many times every frame can have an actual effect on execution in some cases.

No matter how good a compiler gets, there''s always a case or two where you could optimize where the compiler cannot. At least not until they get AI. Regardless of the compiler there''s always something you could do in certain cases. A compiler isn''t god; it can''t, for instance, keep a common result in a register to avoid having to reload it every time it is used. It''ll translate your code the same way you wrote it while trying to translate each statement as well as possible. At least that''s how MSVC works: it handles every statement/line individually and produces assembly output independant of other statements. Registers aren''t reused. Dunno how other compilers work...

Basically, a good algorithm is a much better optimization than rewriting a bad algorithm in assembly.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!