[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Mach, a but choise ?

On Mon, Dec 04, 2000 at 09:40:14PM +0100, Patrick Strasser wrote:
> > I do not think removing a few functions would make any kind of
> > difference -- if they are that slow avoid using them. 
> It would be a lot of work and break the interface/compatibility with
> other flavours of Mach, if that is a reason for the project.
> But OTOH it would ease maintenance.

We are doing fine maintaining it, thank you.

> Is actually anyone workong at
> gnumach (not only patching)?

No. Roland is working on an oskit version of gnumach.
The Hurd is a server-on-top-of-a-microkernel project, and not a microkernel
research project. We use what works for us. If you show us code which makes
it run on a different microkernel, we might use that. It's not that

> > The reason the L4
> > people claim that Mach is so slow is that it uses async ipc messages.
> > What does that mean?  I send a message to you.  Inside the message, I
> > send a reply port.  After I send the message, I wait on the reply port
> > until you send me the result.  In L4 they have (only) synchronous
> > messages based on your tid (thread id) so when you send a message, it
> > is ``easier'' to optimize.
> I remember of reading of neither the Hurd nor gnumach being profiled at
> all.

The reason is that we don't have a profile timer. This is from the tasks

  * Mach needs to provide support for task virtual timers similar
  in functionality to the Unix ITIMER_PROF and ITIMER_VIRTUAL timers.

> Could this be a reason of this legendary inefficiency of the Hurd? 

Partly. We certainly won't start random optimization without profiling
things thoroughly.


`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org

Reply to: