lkml.org 
[lkml]   [1999]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Some very thought-provoking ideas about OS architecture.
Date
From
> 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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.956 / U:0.804 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site