Comment by Macha | Hacker News Reader

Comment by Macha | Hacker News Reader

Part of the reason why there are so few low level programmers is that it's quite complicated to actually find information on it:

* Lots of college courses, especially of the Java school variety simply do not cover anything remotely near low level code.

* For people looking to learn themselves, there are far fewer books and websites with resources than for other subjects. If I walk into my local book shop, there are books on Java, C++, C#, PHP (lots of PHP), Flash and Python. Then a few language agnostic books like Code Complete and Design Patterns (Stuff like this is lacking in quantity, but at least it's there). None on anything low level. There isn't even a x86 assembly for dummies type book there. The internet has free books for other languages too (Dive Into Python, Why's Poignant Guide to Ruby, etc..) and plenty of free resources on good functional programming or good OOP. For assembly, all I keep running into is a wikibook, which I'm rather skeptical about as they tend to pretty poor in my experience.

And then, once you've gone through the initial learning phase, how are you going to get any experience? For 95%+ of projects, it's a case of YAGNI. There aren't any interesting open source projects coded in assembly today. Maybe a few Linux drivers, but that's something that would need a lot of domain knowledge on top of low level knowledge to understand.

All you need is an assembler (a language with a built-in assembler helps with the learning curve) and the processor manual (ideally the processor manual's assembler syntax will match your assembler's syntax; this is not the case for e.g. the defaults in GNU as and Intel x86 or x64). Build a timing loop (timing instructions like rdtsc are right there in the manual) and get to profiling instructions. Read up, and find out about the hidden performance models behind the various instructions (and rework your timing loop to reset these things where possible); read up on caches, branch prediction, register renaming etc., then play around, try to reproduce the positive and negative sides of these optimizations and develop intuitions etc.

I don't think there's a better - or easier - way.

A timing loop will tell you how fast it runs on your particular configuration, but not how fast you can expect it to run in the general case. For that, you need to get very intimate with the processor manuals, especially optimization guides. Also, a good profiler, like Intels VTune, is great for getting low level performance data such as cache misses.

Also, doing what you suggest on a number of combinations of hardware would be useful, so you can compare various processor architectures.

> Lots of college courses, especially of the Java school variety simply do not cover anything remotely near low level code.

That's probably true for CS courses, but a lot of courses in my computer engineering undergrad years touched low-level stuff. The most relevant are the real-time systems, microprocessor architecture, and configurable processors courses. We had to unroll loops, reorder instructions according to data dependencies, and otherwise optimize assembly routines on paper during exams (based on a description of the architecture and the number of cycles for each instruction). Having learned that it's rather easy to pick up a book on whatever processor interests you and start writing.

http://x86asm.net/

Reply on news.ycombinator.com