Messages in this thread | | | Subject | Re: Some very thought-provoking ideas about OS architecture. | Date | Sun, 20 Jun 1999 17:48:38 +0100 (BST) | From | Alan Cox <> |
| |
> For the *exact same* reasons that automatic memory management with > garbage collection is preferable to slinging your own buffers. Perl > and Python and Tcl are on the rise because, outside the kernel, accepting > all that complexity and the potential for buffer overruns just doesn't > make any damn sense with clocks and memory as cheap as they are now.
But would you write your kernel in perl - no. Thats the issue.
> Remember, the name of the game in OS design is really to optimize for > least complexity overhead for the *application programmer* and *user*.
If you want windows yes maybe. The role of the OS core is
o To make the common very efficient o To make the uncommon possible and if possible efficient
nothing nothing nothing about making life cute for visual basic programmers.
If you put automatic garbage collection in the kernel for example then every application is forced to pay the cost of this, even things like webservers using hand tuned static buffers for speed and cache optimisation.
If you shovel it into libraries and tools your web server goes like smoke and you can still write python apps.
> and a file system with explicit I/O) then that's fine. But in fact I > think Shapiro makes strong arguments that an object store, done > properly, is *more* efficient.
I don't think so. Nobody has ever demonstrated a working object store based OS handling a real evil job load. When Shapiro can run innd under a full load faster than a conventional OS can, and can network share the article objects to 16 front end servers, then I'll be more convinced.
> > And that is demonstrably the right way up. If you put a "lazy programmer" > > system at the bottom of an environment you prevent the smart programmer doing > > smart things. If your bottom layer is fundamentally ignorant of programmer > > provided clues you cripple the smart. > > If that's true, why is Perl a success?
Because perl doesnt cripple the smart. People routinely rewrite perl programs into C when they become performance issues. Most of them time the performance issue is programming rate not program execution rate. If the claims of the EROS people were correct the Corel java office would not have failed.
> types and garbage collection. And the answer is the same: there comes > a point where the value of the optimization you can do with hints no > longer pays for the complexity overhead of having to do the storage > management yourself.
You miss the most important point of this
The situation you are describing does *not* occur on a global system space scale. Performance critical applications are written in high performance languages. Other stuff is often written in tools like python.
The "conventional" model of memory allocation requires address space and page allocation services. page protection services help. The object based model needs address and page allocation services and really wants page protection services.
So they share a common underlying set of needs. Should the OS provide conventional model, object model, or the underlying service both needs. The answer is obvious and its precisely want unix does supply.
Alan
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |