On Sun, 2004-08-29 at 06:45, Basile Starynkevitch [local] wrote:
> On Sat, Aug 28, 2004 at 07:03:44PM +0200, Nicolas Cannasse wrote:

> 
> Ocaml does scan *explicitly* the C stack. Telling *explicitly* what
> are the local GC roots of C routines is the task of CAML_param &
> CAML_local macros (FWIW, my Qish GC use very similar tricks,and every
> exact GC has to do similarily.).

The Felix GC does not. You may wonder how this can
possibly work. The answer is -- the GC is called by
the driver, and the driver is not called by the 
program -- the driver *calls* the program.

So the C stack is always empty whilst executing
the driver code, hence the GC does not need to
scan the C stack.

Of course -- your proposition is technically not
contradicted in this architecture -- more precisely
it remains true 'in vaccuo' :)

> This interesting discussion triggers another interesting question:
> would Ocaml coders still use Ocaml if its implementation was (say) 3
> or 10 times slower than the current implementation?

Yes they would. John Goerzen already made that quite clear:
there are plenty of times when performance just isn't the issue.

I am assuming you have two choices -- use the fast Ocaml and
lose interoperability, or use the slow Ocaml to get it.

> Alternatively, do
> people use my OcamlJitRun program which could provide (on several
> programs) a speedup of nearly 2 on their bytecode program.

I have an application which I would like to enhance with
dynamic loading. This application does need to perform well.
I'm using ocamlopt, with bytecode as a fallback, but I 
have to mandate bytecode to use Dynlink.

A decision to do that is likely to be strongly influenced
by the existence of OcamJitRun -- there is huge difference
between a a 5 minute compile and a 15 minute compile:
5 is enough to make a cup of coffee, 15 is enough
to go out for lunch :)

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners