As several people are sure to remind me, the Linux Kernel mailing list is
not the right forum for a discussion on language choice and the impact on
kernel development, but as this is not the first time I've followed this
class of argument, I'd like to make a couple of general observations that I
hope *are* relevant to the list.
First, arguments of the form "it's ok for applications, but kernels need
more control, performance, et cetera than language X provides, which is why
we use language Z" are fallacious. The end user of a computer system cares
about the *entire* performance of that system, not just the kernel.
Peformance issues exist whether the hardware is executing in 'system' mode
or not (to use an archaic term) and applications are not immune from these
considerations simply because they execute in 'user' mode (to use a related
archaic term.) The point is that performance critical sections of code need
to be treated as such, no matter where they occur, and that one person's
performance critical code may never be exercised in another person's
workload.
Second, arguments of the form "language X is slower, sloppier, harder to
control than language Z" suffer from extreme oversimplification. The most
that can be said when comparing the relative performance of two programming
languages is that the combination of programming practice and compiler
sophistication is such that typically, programs written in language Z need
more care than programs written in language X in order to reach the same
level of performance, controllability, et cetera. (For instance, in the mid
80s, I recoded a rather famous Fortran vector supercomputing benchmark into
C, and, for a particular combination of machine and compiler, was able to
actually outperform the Fortran version in many of its tests. The machine's
vendor spent far more effort on their Fortran than C compiler, and in a few
years even that machine returned to Fortran outperforming C.)
The Linux kernel is an old-style process oriented Unix clone. As such, it
is best written in C, and should probably remain in C, since its overall
structure falls into a family of kernels written in C over a period now
approaching 30 years. That is, in fact, the best reason for leaving Linux
in C: preserving the long legacy of C related optimization and the C related
programming skill set.
That is *not* an argument for not writing an operating system core in mixed
languages or even other languages. Not counting assemblers, I've worked on
operating systems in a lot of languages, including Ada, Algol, Basic, C,
C++, Forth, Fortran, Lisp, Pascal, PL/I and Smalltalk, and all of those that
were in use for any period of time reached acceptable (and often very good)
levels of performance. While C++ implementations and programming practice
are not yet anywhere as mature as those for C, I expect that within a decade
a new breed of operating system cores, which have overthrown the idea of
'kernel' without falling into the trap of 'microkernel' will begin to
arrive, written in languages that more suitably match the programming
paradigms of the application systems built on top of them.
The last, by the way, is the key to language choice for OS implementation,
in my opinion: it is best to choose the language that best resolves the
competing constrains of fitting the prevalent paradigm while having robust
implementations and mature understanding of programming practice suitable to
the language.
Marty
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:08 EST