Why C for operating systems
in [General Programming]
|
From: Malcolm McLean on 7 Dec 2009 11:48 "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message news: > Of course, you can implement any algorithm in Lisp. > What would make you think that it cannot be done in Lisp? > That's virtually the definition of a general-purpose programming language. Judy trees aren't really an algorithm, though. They're a way of packing a search tree to minimise cache misses. Inherently, you need control of the the way the bits are laid out in memory, and they only make sense on processors with certain memory-access characteristics (which happen to be the current ones used in servers and PCs).
From: Patricia Shanahan on 7 Dec 2009 12:06 BGB / cr88192 wrote: > "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message > news:871vj7hc8l.fsf(a)galatea.local... >> "Malcolm McLean" <regniztar(a)btinternet.com> writes: >> >>> "Bill Cunningham" <nospam(a)nspam.invalid> wrote in message news: >>>> One reason why I am so attracted to C and not just markup languages >>>> scripts and java is that C is for designing OS's. What exactley is it >>>> about C that makes it good to right operating systems? >>>> >>> It's very close to assembler. With a few exceptions, all C constructs >>> compile to a few machine language instructions. So it's easy in C to keep >>> control of how much time your program is taking to execute. >>> Since operating systems have to be efficient, this is very valuable. >> Actually, this closeness prevents the compiler to implement most >> optimization algorithms that high llevel programming language >> compilers can implement, which leads to less efficient code, as soon >> as you get out of the microbenchmark. >> > > this is why it matters that people have to know what they are doing... > > if someone writes stupid code and it performs poorly, it is their fault, not > the compiler's... The problem is not necessarily stupid code, but code that was very, very clever for a hardware implementation that the programmer thoroughly understood, but that no longer exists. Patricia
From: Chris M. Thomasson on 7 Dec 2009 13:45 "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message news:87ein6epj5.fsf(a)galatea.local... > "Chris M. Thomasson" <no(a)spam.invalid> writes: >>> (And yes, in some lisp programs, buffers are preallocated, and reused >>> like you describe it, but often a generational garbage collector can >>> be as efficient as this manual memory management). >> >> IMVHO, the more pressure you can take of the GC the better, and manual >> memory management can help you do just that. >> >> ;^) > > On the other hand, the more pressure you can take of the mind of the > programmers, the better, and automatic resource management (not only > memory) can help the programmer do just that. Okay, I agree. IMHO, it is nice to know that one can improve performance in GC environment with some good ol' manual management. > Which isn't to say that lisp programmers are not concerned eventually > by performance, but when it occurs, they have had a working program > for a longer time than C programmers, and therefore have had more time > to work on the slow parts and finding good solution to improve the > performance of the application, globally. > > > "Premature optimization is the source of all evils." D.E.Knuth > > "C is premature optimization." P.J.Bourguignon ;-) :^)
From: BGB / cr88192 on 7 Dec 2009 14:12 "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message news:87ein6epj5.fsf(a)galatea.local... > "Chris M. Thomasson" <no(a)spam.invalid> writes: >>> (And yes, in some lisp programs, buffers are preallocated, and reused >>> like you describe it, but often a generational garbage collector can >>> be as efficient as this manual memory management). >> >> IMVHO, the more pressure you can take of the GC the better, and manual >> memory management can help you do just that. >> >> ;^) > > On the other hand, the more pressure you can take of the mind of the > programmers, the better, and automatic resource management (not only > memory) can help the programmer do just that. > I typically use a hybrid style, where I use GC for "most" data, and switch to a more manual style in places where I know what I am doing... > > Which isn't to say that lisp programmers are not concerned eventually > by performance, but when it occurs, they have had a working program > for a longer time than C programmers, and therefore have had more time > to work on the slow parts and finding good solution to improve the > performance of the application, globally. > my experience has been the reverse: my HLL code has tended to be very brittle and unmaintainable in the long term; my C codebase has been one of the most stable parts of the codebase, with many parts of the codebase being around or >1 decade old and still working... > > "Premature optimization is the source of all evils." D.E.Knuth > > "C is premature optimization." P.J.Bourguignon ;-) > not all C use is premature optimization. only that it gives a good deal of control for when it is needed... it is like C vs ASM: in general, if a person only uses ASM, the net speed will be lower since to much mental energy is spent just making it all work; C then allows more speed and flexibility, in the average case, leaving one to fall back to ASM primarily for micro-optimization (rarely done in my experience, but either way). higher-level languages, often, tend to be much slower in the average case... note that I am confining consideration mostly to those HLL's people might actually use...
From: Pascal J. Bourguignon on 7 Dec 2009 14:22
"[Jongware]" <sorry(a)no.spam.net> writes: > Bill Cunningham wrote: >> One reason why I am so attracted to C and not just markup >> languages scripts and java is that C is for designing OS's. [...] > > As I recently converted to Mac OS -- how does Objective-C fit in this? > From what I've seen it gives the programmer back what he looses with > plain C -- an abstraction away from low-level stuff ("how do I create > a new window for my app, insert it in the Windows menu, and allow > tabbing through that set of windows?"). > Its KVC/KVO typing is so powerful that I shudder to introduce my own > sloppy programming style :-) Indeed. Basically, Objective-C = C + Smalltalk. When you program in Objective-C, you will most of the time work at the level of the Smalltalk side, dealing only with objects and sending message around. This object system is entirely dynamic: you can create or load new methods at run-time, you can create new classes at run-time, all dispatch is dynamic, you can catch unknown message to process them as you want (ie. you can trivially implement proxies, etc). But you still have C at the tip of the finger at all time, so if you need to implement a fast loop, you can fall back to C data structures and C functions. So, compared to C, or to C++, Objective-C is a very nice OO language. Even more so nowadays that Apple provides frameworks (GUI libraries) compatible with a garbage collector, so that you can activate the garbage collector instead of doing the (semi-) manual (refcount-based) memory management of OpenStep. It is to be noted that NeXT Computer Inc. implemented drivers in NeXTstep in Objective-C, publishing the IOKit which allowed to mere programmers to write NeXTstep drivers easily (eg. subclassing an existing generic driver to implement a device specific one). I've not followed closely the evolution with Apple, it seems that they have dropped the IOKit. (They dropped a lot of goodies from NeXT, and put back in slowly only a few of them in the successive versions of MacOSX). But once upon a time I wrote a video chip driver with the IOKit in Objective-C. It is to be noted that the significant Objective-C runtime didn't prevent this code to run in kernel space... -- __Pascal Bourguignon__ |