Re: Using Objective-C or x (Re: Hurd direction)

[Farid Hajji]

> > 1. We don't want to sacrify (potential) portability to non x86
> > platforms by using a language that is not very widespread (I don't
> > mean C++ or even gcc's objective C here). If the compiler of the
> > language you're suggesting is not written in C (or C++, or if it is
> > absolutely necessary Obj-C), then porting gcc alone would not be
> > enough. Did you already port a compiler including the runtime of some
> > more than trivial or small language to a completly new uKernel or
> > architecture?
> 
> I was talking about gcc frontends here but perhaps it wasn't that obvious :) 
> It's sufficient that it compiles under a portable gcc frontend. gcc frontends 
> are usually written in C.
Okay, most objections fade away when unsing gcc as a backend. That's what
I've meant but failed to make clear.

> In the real world, parallel programs are written in FORTRAN, C, C++. There is 
> usually no Java or LISP in HPC applications.
> 
> I'm personally a fan of functional PLs but certainly not the linked list 
> datatype. :)
That's just a matter of personal taste. Most FPLs bad reputation stem
IMHO from badly written and therefore slow interpreters or runtimes
and (up to some extent) poor syntax. Scheme is an exception here,
because it can naturally support parallelism, not only
programatically, but also declaratively. There exist very elegant ways
to express various forms of IPC in lisp/scheme-like syntax. We can
talk offline about it if you wish.

> If you want an object model and message passing, use a language that has it. 
> That's all I'm saying.
That's not a bad idea. As I started to read Hurd's code, I had a pretty
hard time to really understand what was going on. And I was already used
to Mach programming and therefore started immediately with the *.defs !!
At least declaratively, the Hurd's IPC semantics and whole architecture
could be certainly expressed in a more intuitive language. However, at
least the following problems remain:
  * You need a language flexible enough to express the current state of
    the Hurd (preferably without too much ugly hacks),
  * This language must have a portable compiler or, as you pointed out,
    be a frontend to gcc; and it must provide easy linking to at least
    C programs.
  * We need to find volunteers willing to convert the current sources
    to that language (including full conformance testing!!) and, even
    more importantly, core Hurd hackers must accept this new language,
    if you ever want some new work done.

Frankly, I'd prefer that we stick to C and replace MIG with an IDL
compiler, e.g. with OSKit's flick or something similar. This would
help improve the readability of the code somewhat. Using another
language (as C) may result in clearer code, but it would certainly
hinder Hurd porters at the moment.

That said, if you could come up with a language and a program
generator that would transform Hurd specs into servers and libraries
(preferably by generating C code), that would be really
impressive. But this would be in essence "just" an extention to IDL:
You won't just describe interfaces, but also specifications.  I'm
meaning here something similar to HDLs (hardware description/definition
languages used in IC-design). But this is a whole new story ;-)

A much more important issue would me IMO to retarget the Hurd, so that
it runs on an abstract virtual kernel (call it VK). If we could
concentrate our efforts in this direction, we could reap many benefits
at once:

1. We'll get rid of Mach-isms that are currently scattered all over the
   Hurd and in glibc.

2. The code would be _much_ easier to read and to understand. People
   would only need to learn the (preferably slim) VK-API to be able to
   hack on the Hurd internals. Right now, an at least medium
   understanding of Mach is necessary to follow the code in the Hurd's
   support libraries (and in glibc's sysdeps).

3. We could finally port the Hurd to other uKernels (or even to
   existing Unix-Systems) by rewriting the VK-backend. If we could
   manage to port the Hurd to a VK, a subsequent port to L4 would
   be much, _much_ more easy.

So, please, instead of donating time and efforts to recode the current
version of the Hurd to another language (as interesting as it may be),
we would be much better off by retargeting the Hurd to a VK. We could
even do this by specifying the Hurd's interfaces _and_ functionality
in a new language and write a (template-driven?) code generator to
produce C code... ;)

I'm currently thinking about ways to do exactly this kind of port. If
you're interested, please let us talk about it on l4-hurd.

> > The code may be easier to read, but I doubt that it will be more efficient.
> > Can you provide evidence of better efficiency, e.g. in form of published
> > benchmarks (mostly in papers)? The whole point to switch to, say L4, is
> > to reduce the overhead involved with IPC. Every uKernel-based system
> > uses IPC pretty heavily, and Mach is not that efficient at handling
> > (i.e. buffering) messages. Using some other language (runtime) could
> > likely _increase_ the latency even more, unless the runtime is optimized
> > for _every_ conceivable IPC form used in the Hurd now (and also in the
> > future). That objective could be tough to achieve.
> >
> I don't remember talking about a bloated runtime. That's Java.
I wasn't talking about a runtime either.

> The reason for using a compiler is that 'nothing compares to the wisdom of a 
> compiler'. A compiler has a lot of information available to it, and can 
> optimize code like nothing else can. It could optimize for the underlying 
> architecture: single proc, smp, shared-nothing MIMD. You could also make it 
> support multiple message passing semantics, but it would be best to keep it 
> simple. You could implement optimizations that people do, for instance stuff 
> like burst-transfers. There is a particular parallel code that should be 
> mentioned in this context (which is not a compiler): PetSC.
No, you've missed the point about L4 vs. Mach. The problem is not with
using poor optimizations or even a runtime, but within the Mach kernel
itself. Even if you compiled Mach, glibc and the Hurd with -O6, you
_still_ encounter a big performance hit, because Mach's IPC path is
slow. So what, may you ask? Well, IPC is a very frequently used
resource in _every_ kernelized system; the Hurd is no exception
here. If we want to get better performance, we need IPC that is faster
by at least one degree of magnitude. Optimizing Mach's IPC path is
unlikely to get us near this (many people tried this for more than a
decade). L4 is currently the uKernel[-architecture?] that is the most
promising w.r.t. IPC performance and this is the reason we are trying
to port the Hurd to it.

> The catch is that it wouldn't be just easier to read but easier to 
> write/share your code, and expose the architecture in the code.
Yes, agreed.

> > very long time, and all my intuition screams at me, that porting the
> > backend could be much more difficult than to just change a library. I
> > may be wrong in some special cases, please convice me that your
> > solution would be better.
> I think that's a matter of ./configure switches. But yes, it could be thought 
> of as porting the interface to system calls. Depends on how the code is 
> written. 
If it were just ./configure switches, that would be a dream ;-). uKernels
differ substantially and porting a language runtime or backend would be
nearly as hard as rewriting the (low-level) OS itself. Sure, as long as
the Hurd is not ported to VK (if this ever happens), you could still
argue that it wouldn't matter wether the language backend or hundreds of
functions need to be modified. But I would very much prefer that we opt
for the VK-approach rather than moving OS-specific stuff in some compiler
backend. Yes, that's pretty conservative, but also IMO pragmatic.

Regards,

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | farid.hajji@ob.kamp.net
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.