3 ms·
While I wouldn't agree that programmers need to learn machine code, I would definitely recommend that they at least learn some ASM and poke around in a few prog
by Sapient 17y ago
While I wouldn't agree that programmers need to learn machine code, I would definitely recommend that they at least learn some ASM and poke around in a few programs with a decent disassembler.
Seeing and understanding how a program actually interacts with the hardware at runtime was one of the biggest moments in my life as a programmer. The first time I successfully "cracked" a shareware program, my understanding of how computers worked increased a hundredfold.
Before multi-core processors became common, I had a major argument with another senior developer at work who completely believed that simply adding threads would speed up execution of his functions (that's what threads do right?!).
Edit: The point is, programmers don't know nearly enough about how their programs interact with the hardware they run on.
- amalcon 17y agoReally, not many people even think about what's in any level lower than the one they're working on. Case in point: I once had a C++ program in which replacing malloc() with a wrapper that rounded up all allocations over 1kb to multiples of 1kb actually increased execution speed by 20%. Those may not have been the exact numbers, but that's the general idea. Guess why. . . . The program was allocating many large objects with small variations in size. The system default malloc/free implementation would work efficiently for small objects, but would store large allocations in a linked list, bucketed by size. In the worst-case (all objects are large and of different sizes), freeing n objects would take O(n^2) time. This program came very close to that ideal. The rounding prevented that worst case by using fewer buckets. Of course, that version never saw production use. It was just used to demonstrate the nature of this particular performance problem.