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

[exa]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 18 July 2001 03:41 am, Farid Hajji wrote:
> Hi Eray,
>
> IIRC, we already discussed the language issues earlier. I do
> understand your suggestion and, frankly, I'm not opposed to C++ either
> (or probably even something else), but you should consider the
> following drawbacks:
>
> 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.

>
> 2. It would be a good idea to be able to cannibalize as much external
> code as possible, like e.g. kernel drivers etc., possibly in the form
> of OSKit libs or some such. The language we use must therefore provide
> seamless linking to C (at the linker level, but more often than not
> also at the API level). What does this mean for the Hurd? Actually,
> the glibc sysdeps would have to be adapted to the new runtime/uKernel
> and language in which the system is written. This would not be so
> hard, iff the kernel were monolithic: Here you've got a simple
> interface that could map to glibc's C in some more or less direct
> manner. I'm not sure that this still remains true for distributed
> multiserver systems like the Hurd.

A graceful extension to C preserves ANSI C properties including linking. This 
isn't a drawback for such an extension.

>
> 3. How many people are really fluent with, say Cilk or even something
> totally new and different? A few years ago, I implemented a small
> uKernel with message passing semantics in scheme (actually, the scheme
> engine was itself written in C) and guess what, the performance wasn't
> that bad either. _But_, it all boils down to providing an API of the
> uKernel (or whatever sits on top of it) to real-world applications.
> The toy project involved providing some minimal C-lib that ultimately
> linked into Scheme... and here the problems generally start getting
> pretty hard. "Native" Scheme applications naturally used the uKernel
> scheme API; they even enhanced it if they could present appropriate
> credentials/capabilities to do so. Best of all, Lambda-uK ran
> naturally on multiprocessors, mapping threads to function
> objects. But, really, do we expect that all real world applications be
> rewritten in scheme? ;-).
>

It doesn't matter how many people are familiar with Cilk. I could ask the 
same question as 'how many people are familiar with message passing or 
multithreaded code?'. An extension to C is very different from a language 
such as scheme which has horrible syntax IMO. Actually, a nice message 
passing language is a lot more intuitive than writing your own ugly code 
which does marshalling, message passing, etc.

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. :)

[snip]

>
> >   1) Obj-c
> >   2) Cilk
>
> Cilk is actually a good candidate, but who would be really willing to
> start learning it now? Just asking around: anyone used Cilk before?
>

It's just some additional syntax/semantics to C. One of the toy languages I'd 
say. It could never replace using MPI over C++.

However, it has a few good ideas which I think Charm project had got before 
Cilk.
   1) spawn directive
   2) some synchronization.

I would think that Objective-C together with a message passing directive 
would be a very good choice because it has a C-based object model and would 
allow asynch. mp code.

> >   3) Custom language extension, new language (like inferno?)
> >   4) Going C++ (better std lib, still message passing requires lang.
> > extension a la Charm++ which is _not_ a fantastic thing). Might be
> > feasible since we have a much better std lib now. [*]
>
> Well, message passing semantics would really be a "nice thing to
> have," but most of it could also be coded in C. Another aspect that
> could also be quite hairy, is support for languages with inherent
> concurrency.  Here, the problems shift to the runtime that will have
> to be ported to any uKernel we'd like to port the Hurd to. I'm not
> sure that this would be easier to do rather than write a portable
> pthreads library for each uKernel from scratch (but I'm no expert
> here).

Hmmm. Well you presume that the focus is SMP systems, but I definitely think 
that if one goes to extreme pains for a message passing language, he should 
be able to write the code for a parallel machine instead of a shared memory 
one. :)

About concurrent languages: it all depends on what kind of concurrency that 
is. Obj-C + message passing is concurrent all right, but without the kind of 
difficulties you speak of.

>
> > Things not to do:
> >
> >   1) Corba
> >   2) A "Component Object Model"
>
> I partly agree with you here. It may be possible to use some IDL and
> IDL stub compiler as replacement for MIG, even when porting to a
> non-mach uKernel, but that's it. The L4Ka team is experimenting with
> IDL4 (Flick) compiler to generate efficient stubs for L4Ka
> interfacing, and we could certainly use something similar, even before
> switching to L4 (any volonteers willing to replace MIG with IDL4?). I
> may be willing to consider doing some CORBA with C++ (most Hurd
> interfaces seem very well suited to CORBA, or some kind of
> "lightweight CORBA"), but cerainly not COM!
>

People are already using OSKit's COM :) That's not my concern though 

If you're using something like CORBA you should necessarily have multiple 
languages and compilers in the system. Otherwise, no need for the 
overhead/limitations. People argued that they may want to use Perl, etc. for 
writing their own extensions, but I don't think that's very relevant. If 
something like that is desired a wrapper (like CORBA) can always be hooked in.

If you want an object model and message passing, use a language that has it. 
That's all I'm saying.

> > The candidates have been ordered in order of decreasing feasibility. Many
> > people know obj-c and we have a front end in GCC. Cilk is pretty nice,
> > and used by some hackers at MIT (and elsewhere presumably). Both are
> > extensions to C, so transition is relatively easy. A custom language
> > might be perfected but takes time. Extending C++ (in a good way) is very
> > difficult.
>
> If you have sample code for some core (or non-core) OS components
> written in Obj-c, Cilk or any language you think would be better than
> C, please let us participate. The problem with such discussions is
> that they remain theoretic since no-one seems to be able to provide
> real code or at least some framework/skeleton to get started.
>

Might be nice yep. Got to see if I have time though :/ Without a compiler it 
would be hard though. Perhaps I could try to show how some hurd code would 
look in Obj-C?

> > What is the advantage of using a concurrent class based[+] (following
> > Cardelli's definition) language?
> >   * shorter/cleaner/better code
>
> 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.

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.

I didn't even say that it wil be more efficient, but it could be more 
efficient in principle. Surely more efficient than using CORBA. It would not 
be less efficient than hand-crafting the code in C.

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.

Someone else made a very similar comment to mine on advogato.org. He told 
GNOME people that C + GObject == Objective-C. There was insight in that 
statement.

> >   * portability to alternative message passing systems (change the
> > backend)
>
> As said earlier, we would probably just move the problem from porting
> a (virtual?) kernel interface library from one uKernel to another, to
> porting the backend from one uKernel to another. I've programmed for a
> 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. 

> Some L4 implementations are written in C++ (but note that they don't
> use the advanced features of C++) and they compete quite well with
> hand-crafted _assembler_ code implementations (!). I don't share the
> reluctance of most kernel hackers regarding C++. C++ may even be quite
> a natural choice for the object oriented Hurd interfaces right
> now. But we're getting here in the same religious war that
> periodically starts in the Gtk+ (and GNOME) community ;-). Actually, I
> can even understand both sides. It's often harder to interface other
> languages (like GUILE, Perl, Python etc...) to C++ than to C. This is
> an important point that we should not forget.
>

Write wisely and C++ can be a lot faster than C. :) Interfacing other 
languages should not be that difficult, many people mix C++ code with those 
scripting languages.

> > [+] Cilk is not class based IIRC, and I don't think Obj-C is
> > concurrent... :)
>
> ...at least not really; or should we even consider Ada for concurrency?
> [Yuck!...]? ;-)
>

Hell no! That's complicated now :) We do have a state-of-the-art ada compiler 
in GCC, but I wouldn't want to bet on it.

Regards,

- -- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7WW4JfAeuFodNU5wRAtieAJ95B9Oe7xP+QrvcqC2B+aHJ/ZD4bACeLW92
SUyAItr4CPBpfwZsXb1Ep3w=
=OVGO
-----END PGP SIGNATURE-----