Beautiful Code [41]
For the sake of simplicity, the class of multi-core architectures includes both symmetric multiprocessing (SMP) and single-chip multi-core machines. This is probably an unfair simplification, as the SMP machines usually have better memory systems. But when applied to matrix algorithms, both yield good performance results with very similar algorithmic approaches: these combine local cache reuse and independent computation with explicit control of data dependences.
The Long-Term Benefits of Beautiful Design > My Idea of Beautiful Code
15. The Long-Term Benefits of Beautiful Design
Adam Kolawa
Some algorithms for seemingly straightforward and simple mathematical equations are actually extremely difficult to implement. For instance, rounding problems can compromise accuracy, some mathematical equations can cause values to exceed the range of a floating-point value on the system, and some algorithms (notably the classic Fourier Transform) take much too long if done in a brute-force fashion. Furthermore, different sets of data work better with different algorithms. Consequently, beautiful code and beautiful mathematics are not necessarily one and the same.
The programmers who wrote the code for the CERN mathematical library recognized the difference between mathematical equations and computed solutions: the difference between theory and practice. In this chapter, I will explore the beauty in a few of the programming strategies that they used to bridge that gap.
15.1. My Idea of Beautiful Code
My idea of beautiful code stems from my belief that the ultimate purpose of code is to work. In other words, code should accurately and efficiently perform the task that it was designed to complete, in such a way that there are no ambiguities as to how it will behave.
I find beauty in code that I can trust—code that I am confident will produce results that are correct and applicable to my problem. What I am defining here as my first criterion of beautiful code is code that I can use and reuse without any shred of doubt in the code's ability to deliver results. In other words, my primary concern is not what the code looks like, but what I can do with it.
It's not that I don't appreciate the beauty in code's implementation details; I do indeed, and I will discuss criteria and examples of code's inner beauty later in this chapter. My point here is that when code satisfies my somewhat nontraditional notion of beauty in utility, it's rarely necessary to look at its implementation details. Such code promotes what I believe to be one of the most important missions in the industry: the ability to share code with others, without requiring them to analyze the code and figure out exactly how it works. Beautiful code is like a beautiful car. You rarely need to open it up to look at its mechanics. Rather, you enjoy it from the outside and trust that it will drive you where you want to go.
For code to be enjoyed in this way, it must be designed so that it's clear how it should be used, easy to understand how you can apply it to solve your own problems, and easy to verify if you are using it correctly.
The Linux Kernel Driver Model: The Benefits of Working Together > Humble Beginnings
16. The Linux Kernel Driver Model: The Benefits of Working Together
Greg Kroah-Hartman
The linux kernel driver model attempts to create a system-wide tree of all different types of devices managed by the operating system. The core data structures and code used to do this have changed over the years from a very simplistic system meant for handling a few devices to a highly scalable system that can control every different type of device that the real world needs to interact with.
As the Linux kernel has evolved over the years, handling more and more different