I thought that I should put some of my knowledge to good work by contributing something of value. Seeing that I have recently been citing that physical knowledge of a machine is important in learning how to write good code, I thought that it might be a good idea for me to write a short series on the physical aspects of computers and how they relate to code.
Premature optimization is the root of all evil (or at least most of it) in programming.
While I agree that a programmer should focus on the functional and security aspects of the application instead of the grit of the hardware, what I am talking about is not premature optimisation. I am talking about learning good programming habits so that a programmer ends up writing code that encourages the compilers to better optimise the application.
Also, I am fully aware that with the trend of increasing complexity in our computing devices as we try to squeeze more out of them, physical limitations begin to play an increasing role in determining performance. The difference between a good app and a bad one could sometimes be down to the size of the data structure chosen to hold it.
A programme could be I/O bound, memory bound, synchronisation bound, or even algorithmically bound. In all cases, knowing the hardware limitations and how to avoid them could move the bottleneck away or even spread them out evenly so that an application does not need to be bound by any one particular aspect.
Also, note that most of the bounding limitations are imposed by hardware – either communication or computational bandwidths. So, there we go – software has physical limitations and we should learn about them – just so that we become better programmers.