Beautiful Code [213]
END IF
END IF
*
* Compute multipliers
*
CALL SSCAL( KM, ONE / AB( KV+1, JJ ), AB( KV+2, JJ ),
$ 1 )
*
.
.
.
Continue direct solution
.
.
.
170 CONTINUE
180 CONTINUE
END IF
*
RETURN
*
* End of SGBTRF
*
END
Again, the subroutine starts with argument verification and then proceeds to the problem solution. This is followed by an optimization check, which looks at the problem size to determine whether it can be solved in the "cache" arrays WORK13 and WORK31, or whether it needs to be sent to a lower level for more complicated operations. This is an excellent example of code that is built realistically, for a computer with inherent limitations. The work array can be adjusted for the standard memory of the computer that is solving the problem; in problems with a small enough size, this can prevent performance penalties from possible paging. Problems above that size are so large that that the performance penalty cannot be avoided.
15.4.3. Beauty in Flow
The previous problem solution provides a step-by-step representation of the algorithm. Reading this code is almost like reading a book, since it is so easy to follow. The parts of the problem that are common to other algorithms are reused, and the parts that would complicate the code are passed to subroutines. The result is a very clear, understandable flow.
Each step in the flow corresponds to the mathematical expression. At each step, the code describes what a lower system is expected to do and calls that lower system. The main routine, which is a driver routine, branches into lower routines, each of which branches into more lower routines, and so on. This flow is represented in Figure 15-1.
This is an excellent example of how to apply the "divide and conquer" principle to code design. Every time you move to a lower step, there is a smaller problem to conquer, and you can focus on well-defined circumstances that make the code smaller and better focused. If the problem fits in the computer's memory, the algorithm will solve it directly, as I discussed previously. If not, it goes to the next level of subroutines, and so on.
Figure 15-1. Logical subdivision of tasks into subroutines
As a result, very computation-intensive routines can be written in assembly language and then optimized for the architecture. Another benefit of this design is that many people can work on the code simultaneously because each subroutine is independent and so well defined.
The Long-Term Benefits of Beautiful Design > Conclusion
15.5. Conclusion
In sum, I believe that beautiful code must be short, explicit, frugal, and written with consideration for reality. However, I think that the true test of beauty—for code as well as art—is whether the work stands the test of time. Lots of code has been written over the years, but little of it was still in use even several years after it was written. That the CERN library code is still in use more than 30 years after it was written confirms that it is truly beautiful.
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 types of devices,[*] the core of the kernel has had to change and evolve in order to come up with easier and more manageable ways to handle the range of device types.
[*] Linux now supports more different types of devices and processors than any other operating system ever has in the history of computing.
Almost all devices consist of two different portions: