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
important.
> > 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
list:
!!!
* 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.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
Reply to: