Saturday, June 12, 2004

Why Bother Learning Assembly Language?

A very interesting Slashdot discussion is going on about the pros and cons of learning assembly language. Although I'm familiar with more than one assembly language myself, including Motorola 68000, DEC Alpha and (yuck!) Intel x86, I'm personally of the opinion that unless one is working in a field like game development or numerical computing where top performance is the utmost prioirity, messing about with assembly is mostly a waste of time, and performance improvements are better obtained by focusing on algorithms, i/O and program architecture. Even the most carefully hand-optimized piece of assembly code that happens to use an O(n2) algorithm like bubble sort will eventually be outperformed by a piece of Perl or VB6 code that uses an O(n log n) alternative like merge sort.

For numerical computation, game development or anywhere else where access to the SIMD functionality included in most modern-day CPUs is vital, intimate knowledge of assembly-language will continue to be vital, as it will be for those who have to work at the systems level, e.g. low-level driver writers and the like. For the vast majority of programmers outside these fields, knowledge of assembly language is only important insofar as it is difficult to do binary-level debugging without it, as is often necessary when source-code is not available. Fiddling about with register instructions and so forth is a massive drain of developer time and energy which can be put to more profitable uses, and the worst thing of all is that in most cases, the hand-tweaked code people come up with will actually turn out to be slower than what they'd have obtained had they left the optimizing to a decent compiler.

My own two bits of advice to those concerned about performance; don't bother programming with code execution speed foremost in mind, other than to avoid gross inefficiencies where possible. Write clean, maintainable, future-oriented code, and see whether it performs acceptably before going the extra step - you'll be surprised how rarely the speed of code execution is actually an issue these days, with network I/O usually being the main holdup. If greater speed does turn out to be of the essence, the first thing to do is profile, profile, profile, and only after identifying the most critical hotspots should you bother looking for optimizations; even then, you'll likely find that you can either obtain the desired improvements by modifying the algorithm you're using or by rethinking some design considerations, or you can essentially "outsource" the problem by relying on pretuned 3rd party libraries like ATLAS or the AMD Core Math Library. I know that I relied heavily on the Compaq Math libraries back when I was writing high-performance routines for the Alpha 21264.


Post a Comment

<< Home