What should every programmer know about hardware internals? I do not mean hardware assembly or maintenance, but rather how the hardware actually works.
+3
A:
You should know about:
- Internal memory (ROM/RAM), the differences with storage (HDD/DVD/CD). (Differences in speed and access method).
- CPU/CORE'S, what they do and what the effects are of multiple cores.
- I/O, probably not that much, depends on the programming field.
- Probably Address and Data bus. What the effect of the sizes of both are.
- Hardware Interrupts, that hardware is capable to interrupt the current program.
Gamecat
2010-09-21 21:43:52
A:
It depends on the system , you develop with, when using smalltalk or lisp I'd say none ^^ In python floating point stuff would be good. In C I would say learn everything you can find ^^
ticking
2010-09-21 21:47:37
+4
A:
That computers speak binary. More specifically, understanding floating point representation. "Why is my math coming out wrong" is probably the most duplicated question on SO.
Tesserex
2010-09-21 21:47:44
+1
A:
I have found the following link very insightful from a programmer's perspective: What every programmer should know about memory
The moral of it is: don't think you know anything about your hardware, especially from an optimization point of view.
Alexandre C.
2010-09-21 21:52:24
+2
A:
I would simply recommend to read the Programming from the Ground Up book:
This is an introductory book to programming and computer science using assembly language. It assumes the reader has never programmed before, and introduces the concepts of variables, functions, and flow control. The reason for using assembly language is to get the reader thinking in terms of how the computer actually works underneath. Knowing how the computer works from a "bare-metal" standpoint is often the difference between top-level programmers and programmers who can never quite master their art.
Old but IMO remains relevant.
Dummy00001
2010-09-21 22:00:26
+2
A:
Endianness is an important concept to understand. Unintentionally mixing up your byte order can cause hours of painful debugging.
kylan
2010-09-21 22:20:25
A:
As computers get faster, some fundamental aspects of hardware that have for decades generally been consistent are changing. While it used to be that one could estimate the performance of a piece of code by examining the machine code produced and totaling up the number of cycles required for the various instructions, new hyperthreading processors throw such computations out the window. In many cases, it's increasingly important to regard compilers and processors as evil black boxes which will munge the behavior of your code in every way they can possibly imagine that will still comply with the language specs. As a programmer who is very knowledgeable about hardware internals, this is frustrating. I can understand the need, but it's maddening that much of my knowledge is becoming less useful.
supercat
2010-09-21 22:36:16