Why C for operating systems
in [General Programming]
|
From: Chris M. Thomasson on 7 Dec 2009 10:12 "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message news:87my1uet77.fsf(a)galatea.local... > "Chris M. Thomasson" <no(a)spam.invalid> writes: > >> "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message >> news:87k4wzf72o.fsf(a)galatea.local... >>> "James" <no(a)spam.invalid> writes: >>> >>>> "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message >>>> news:87ws0zfxgf.fsf(a)galatea.local... >>>>> "BGB / cr88192" <cr88192(a)hotmail.com> writes: >>>>> >>>>> [... basically that GC and big runtimes is a drag to system >>>>> programming ...] >>>>> >>>>> Have a look at Modula-3. This is a language specifically designed for >>>>> system programming and specifically including a garbage collector. >>>> >>>> Garbage collected bootloader and Kernel? >>> >>> Well, if you really need to manage so much memory to write a >>> bootloader, why not. >>> >>> And for a kernel, you definitely need to manage memory, so a garbage >>> collector may indeed be quite useful. >> >> Try to convince Linus Torvalds that a full-blown GC in the Kernel >> would be better and more efficient than using the RCU algorithm. >> >> >> >> >>>> Can I really use Haskell or Modula-3 to create that? What about a >>>> garbage collected Kernel with exceptions that beats the heck out of >>>> a Kernel written in CO and assembly language? Is that possible? >>> >>> Of course. In general, the quality of the kernels and systems written >>> in other languages than C is higher. >>> >>> (Perhaps an interlude with "The Unix Haters Handbook" >>> http://simson.net/ref/ugh.pdf would be in order here ;-)) >> >> :^) >> >> >> >> >> <OT rant> >> The part where the author basically describes garbage collection as >> being a silver bullet of sorts is very amusing to me. Especially the >> part where he says one of the advantages of porting an algorithm to a >> GC environment is that a plurality of the bugs will be fixed! WOW! >> >> >> I have had mixed experiences with GC. Here is something that pisses me >> off about Java: >> >> >> http://groups.google.com/group/comp.lang.c++/msg/4c68f9617fc301e7 >> >> >> What a damn joke! IMO, you can't really beat the efficiency of clever >> manual memory management. Heck, manual memory management can even be >> highly beneficial in a 100% full GC environment. Take a scenario in >> which a thread wanted to push some data onto a queue, and this >> required an internal node to be created so the data could be linked >> into the data-structure and consumed by another thread. If this action >> occurs frequently, then a shi% load of internal nodes will be created >> and tremendous pressure will be put on the poor GC. However, if we >> used a cache of nodes and manually popped/pushed nodes to/from the >> cache, well, that would take a lot of the burden off the GC. However, >> the act of using the cache IS manual memory management in and of >> itself. >> </OT rant> >> > > You're perfectly right. But not for a general programming > environment. Manual memory management is of course useful in some > very specific cases. It should not be the default mode of operations. > For 99% of the programmers, it should not be their concern, no more > than device drivers are their concern. > > By the same token, when we consider operating systems, and again, > given the performance of today computers, it should not be a concern > for 99% of the operating system developers. Sure, you have unix and > linux where you may have good reasons to implement kernel memory > management manually. But for a lot of other kinds of operating > systems (most being yet to be invented), you don't care about manual > kernel memory management, and a garbage collector in the kernel could > be a perfectly good solution. > > Instead of writing yet another unix implementation (Linus wasn't the > first to make such a clone, let's pray he'll be amongst the lasts), > people interested in operating system writing today should try to > invent something else, and concentrate on other features than lowly > manual memory management. Fair enough. > (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. ;^)
From: Chris M. Thomasson on 7 Dec 2009 10:14 "Chris M. Thomasson" <no(a)spam.invalid> wrote in message news:lT8Tm.38575$cX4.9071(a)newsfe10.iad... > "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message > news:87r5r6etl5.fsf(a)galatea.local... >> "Chris M. Thomasson" <no(a)spam.invalid> writes: >>> I don't quite understand what you mean. I was writing about actually >>> implementing the Judy Array from scratch. Can that be done in Lisp? >> >> Of course, you can implement any algorithm in Lisp. > > > Can I dynamically allocate an object in Lisp on a specific alignment > boundary, and get a pointer to it that I can pack with a reference count > and use single-word atomic operations to mutate it? Say I want object on > 4096 byte boundary, and I want to steal bits in pointer to pack in > meta-data. For instance, how would I implement the following proxy garbage > collection algorithm in Lisp: Keep in mind that I am pretty ignorant wrt the capabilities of the Lisp programming language. Try not to flame me up too much Pascal! ouch! ;^o [...]
From: Pascal J. Bourguignon on 7 Dec 2009 11:01 "Chris M. Thomasson" <no(a)spam.invalid> writes: > "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message > news:87r5r6etl5.fsf(a)galatea.local... >> "Chris M. Thomasson" <no(a)spam.invalid> writes: >>> I don't quite understand what you mean. I was writing about actually >>> implementing the Judy Array from scratch. Can that be done in Lisp? >> >> Of course, you can implement any algorithm in Lisp. > > > Can I dynamically allocate an object in Lisp on a specific alignment > boundary, and get a pointer to it that I can pack with a reference > count and use single-word atomic operations to mutate it? Say I want > object on 4096 byte boundary, and I want to steal bits in pointer to > pack in meta-data. For instance, how would I implement the following > proxy garbage collection algorithm in Lisp: > > > http://webpages.charter.net/appcore/misc/pc_sample_c.html > http://webpages.charter.net/appcore/misc/pc_sample_h.html > > > Please excuse the crude code, it was just a quick proof-of-concept, I > did not even bother to check if `malloc()' failed. Anyway, the key > aspect of the algorithm is that it does not use double-width > compare-and-swap (DWCAS). This is a major plus because the instruction > is NOT portable to 64-bit architectures. I get around using DWCAS by > packing a reference count into pointers to `pc_deferred_t' > data-structures. The memory which makes up `pc_deferred_t' > data-structures is aligned to a sufficient enough boundary such that I > can pack a reference count [0...127] in there. Therefore, I can use > normal single-word CAS on the anchor. > > > BTW, the proxy garbage collection is a solution to memory management > in the reader/writer problem. You can use this algorithm to allow for > a number of reader threads to iterate through shared data-structures > (e.g., linked list) while writer threads are concurrently > adding/removing/deallocating items. We can move the discussion over to > comp.programming.threads' if you are interested in such algorithms... Definitely. See for example: http://darcs.informatimago.com/public/lisp/common-lisp/heap.lisp with: http://darcs.informatimago.com/public/lisp/clisp/raw-memory.lisp and: http://darcs.informatimago.com/public/lisp/clisp/raw-memory-lib.c All the pointer and bit fiddling is done in lisp in heap.lisp. This implementation of a heap with garbage collection allows me to share memory between different lisp processes (possibly running different implementations). In the case of threads, almost all the Common Lisp implementations provide threads and manage memory for them with a garbage collector. I don't think the current common Common Lisp implementation have a multi-threaded garbage collector (working in parallel with the user threads), but if it was required, this is something that would be done at the level of the implementation (you could check with the commercial implementation Scienner Common Lisp which is targetting high performance and multi-core processors, it might have a parallel garbage collector). So, to conclude here, bit fiddling is in general left to the implementation, so that the lisp programmers may concentrate on his problem solving, but if his problem concerns bit fiddling, there's no difficulty in doing that in lisp. Most lisp implementations are written in lisp anyways. -- __Pascal Bourguignon__
From: Pascal J. Bourguignon on 7 Dec 2009 11:07 "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. 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 ;-) -- __Pascal Bourguignon__
From: [Jongware] on 7 Dec 2009 11:46
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 :-) [Jw] |