From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 8F2F6BC37 for ; Thu, 28 Jan 2010 18:28:04 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4CAO9XYUvRVdvakGdsb2JhbACRQIlNPQEBAQEJCQwHEwOuZ4FFhSuIQAEBAwWENwQ X-IronPort-AV: E=Sophos;i="4.49,361,1262559600"; d="scan'208";a="42652948" Received: from mail-ew0-f218.google.com ([209.85.219.218]) by mail3-smtp-sop.national.inria.fr with ESMTP; 28 Jan 2010 18:28:01 +0100 Received: by ewy10 with SMTP id 10so1018049ewy.3 for ; Thu, 28 Jan 2010 09:28:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=KzTkE4gXlSAssy8Q6SBLM6rTAxYJj+JOvD77BZD5amE=; b=nFkgYcrZnUyVQDgql2sJ0xkDfgh/xH40Hf5Q751OqKZyC7BaIbAn6NnRnIMlguX0KE ykJtIfA3qhpqtQelI343QLkn8YfEBlgymCGGBkaxfcEQWfeaEaP37RzkWfibMlzK5Qdy 8ORUbowFd5RkB+TFYtmk3xdi0gnpMJTRytsVk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QO5eyix93T4BTwPBjoEd2LUdxPOw0KkrOyRruY+WCLnctgm10R7Lv8aqcHh2XQ5fQu UA83vdSgig/5LhUsnLXrhkbz/5EY/QbpgMFkiGY0F8UryUJYLDZE/DPrJSRZRrp3ju19 ZMkwoLrXw0hvb2ASg4GnL7K2yDkdOXG5xWlns= MIME-Version: 1.0 Received: by 10.213.109.219 with SMTP id k27mr8791354ebp.37.1264699680263; Thu, 28 Jan 2010 09:28:00 -0800 (PST) In-Reply-To: <20100128134530.GD4873@const.bordeaux.inria.fr> References: <20100128125530.GS4873@const.bordeaux.inria.fr> <20100128131832.GX4873@const.bordeaux.inria.fr> <20100128134530.GD4873@const.bordeaux.inria.fr> Date: Thu, 28 Jan 2010 18:28:00 +0100 Message-ID: Subject: Re: [Caml-list] Ocaml implementation and low level details From: Konstantin Tcholokachvili To: Samuel Thibault Cc: caml-list@yquem.inria.fr Content-Type: multipart/alternative; boundary=000e0ce0af6e308fe4047e3cd760 X-Spam: no; 0.00; ocaml:01 thibault:01 thibault:01 0100,:01 ocaml:01 iirc:01 -unsafe:01 runtime:01 pointers:01 caml's:01 alignment:01 0100,:01 iirc:01 -unsafe:01 runtime:01 --000e0ce0af6e308fe4047e3cd760 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thank you for these infos, I will consider which solution fits the best wit= h my project: make a trade off, find a more suitable ML implementation or stay (sadly) with C. Konstantin Tcholokachvili 2010/1/28 Samuel Thibault > Konstantin Tcholokachvili, le Thu 28 Jan 2010 14:35:50 +0100, a =E9crit : > > > - Also need I disable Ocaml theading subsystem? (Obviously yes, b= ut > are > > there > > > some limitations?) > > > > IIRC we just needed to port it. > > > > > > OK but as there is a giant lock (as I heard), I'm afraid that the > > multithreading subsystem of my kernel will suffer from that. > > Am I correct? > > Ah, the kernel can't be running concurrently, yes. Just like Linux 2.0 > was working, actually. > > > > Are there other important considerations to take? > > > > In my memory, mostly the direct access to some kinds of memory, lik= e > the > > video memory: we faked a string with the -unsafe option to get > efficient > > direct access. > > > > So must I also make tricks to have DMA acess? > > Yes, unless you get hooks into the caml runtime to be notified of > garbage collection, to update pointers & such. > > > > Do you think that Ocaml is suitable for OS coding (I''m using C > now). > > > > It's much better for all the programmability & safety reasons. Funk > > showed that it is possible. Performance should be quite good. Now > the > > pragmatic answer would be that Linux already works quite well and h= as > > all the drivers we need, while yet another new kernel would have to > > rewrite them all. And about performance, when you see how much Linu= x > > people care about tiny details in their lock implementation etc., a > caml > > implementation wouldn't suit that. > > > > My goal isn't to have a kenel portable across many platforms but only > > to some kind of hardware. It's a hobby project. > > Ok, then you can probably start with the current funk testbed :) > > > Why caml's implementation wouldn't be suitable? Because of the giant lo= ck > as I > > mentioned before? > > Because you do not have as much control over e.g. data alignment & such > as in C. Linux people spend quite some time fine-tuning such small > details and get performance benefits. > > Samuel > --000e0ce0af6e308fe4047e3cd760 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thank you for these infos, I will consider= which solution fits the best with my project: make a trade off, find a mor= e suitable ML implementation or stay=A0 (sadly) with C.

Konsta= ntin Tcholokachvili

2010/1/28 Samuel Thibault = <samuel.thibault@inria.fr>
Konstantin Tcholokachvili, le Thu 28 Jan 2010 14:35:50 +0100, a =E9crit :
> =A0 =A0 > - Also need I disable Ocaml theading su= bsystem? (Obviously yes, but are
> =A0 =A0 there
> =A0 =A0 > some limitations?)
>
> =A0 =A0 IIRC we just needed to port it.
>
>
> OK but as there is a giant lock (as I heard), I'm afraid that the<= br> > multithreading subsystem of my kernel will suffer from that.
> Am I correct?

Ah, the kernel can't be running concurrently, yes. Just like Linu= x 2.0
was working, actually.

> =A0 =A0 > Are there other important considerations to take?
>
> =A0 =A0 In my memory, mostly the direct access to some kinds of memory= , like the
> =A0 =A0 video memory: we faked a string with the -unsafe option to get= efficient
> =A0 =A0 direct access.
>
> So must I also make tricks to have DMA acess?

Yes, unless you get hooks into the caml runtime to be notified of
garbage collection, to update pointers & such.

> =A0 =A0 > Do you think that Ocaml is suitable for OS coding (I'= 'm using C now).
>
> =A0 =A0 It's much better for all the programmability & safety = reasons. Funk
> =A0 =A0 showed that it is possible. Performance should be quite good. = =A0Now the
> =A0 =A0 pragmatic answer would be that Linux already works quite well = and has
> =A0 =A0 all the drivers we need, while yet another new kernel would ha= ve to
> =A0 =A0 rewrite them all. And about performance, when you see how much= Linux
> =A0 =A0 people care about tiny details in their lock implementation et= c., a caml
> =A0 =A0 implementation wouldn't suit that.
>
> My goal isn't to have a kenel portable across many platforms but o= nly
> to some kind of hardware. =A0It's a hobby project.

Ok, then you can probably start with the current funk testbed :)

> Why caml's implementation wouldn't be suitable? Because of the= giant lock as I
> mentioned before?

Because you do not have as much control over e.g. data alignment &= ; such
as in C. Linux people spend quite some time fine-tuning such small
details and get performance benefits.

Samuel

--000e0ce0af6e308fe4047e3cd760--