Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Gripes with array
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-09-12 (16:07)
From: Basile Starynkevitch [local] <basile.starynkevitch@i...>
Subject: Re: [Caml-list] Gripes with array
On Sun, Sep 12, 2004 at 04:33:38PM +0100, Jon Harrop wrote:
> Having said that, it might be possible to abstract the array lookup and 
> replace it with a clever function to work out where the "i"th element really 
> is. Then you could give Array.init a continuation. Hmm...
> > >  Could you add a memset to String.create though? :-)
> >
> > String.make
> I meant for safety reasons - either don't export String.create or make it 
> safe, e.g. "let create n = make n '\000'".
> > > An array_init2 function which specialises the array type but uses an
> > > external
> > > "f" function betters the time taken by Array.init by ~36% (perhaps not
> > > significantly different):
> >
> > That's from getting rid of the float/non-float test.  Nothing to do with
> > the cost of initializing twice.
> Yes. Optimising that would be much more productive. Am I right in thinking 
> that ocamlopt doesn't hoist the test out of the loop?

> Such optimisations would be best done at run-time, e.g. by Basile's
> JIT. Where is he? ;-)

I'm here (not for very long, I'm going back in a few days to CEA
working on other things, probably unrelated to Ocaml).

However, this optimisation is not for OcamlJIT, which is an
unoptimizing JIT. The main requirement of OcamlJIT was full
compatibility with Ocamlrun without touching a single line in the
ocaml/**/*.ml* sources (the ** is zsh notation) of Ocaml (actually, I
had to cheat for the toplevel where I added a single line, now
incorporated in 3.08).

Of course, one could dream of substantially change the bytecode
instruction set (for better JIT translation). But it won't be
compatible with Ocaml.

If you ask me, the one feature I would have liked in the bytecode
instruction set, is to add a LABEL bytecode, followed by a useless
word (used by ocamljit to store a pointer to machine code), and to
change the bytecode generator so that every closure had its code
pointer pointing to this LABEL bytecode.

But the rule of the OcamlJIT game was to leave Ocaml as much as
possible unchanged.

BTW, I would be delighted to have feedback of people using OcamlJit
with Ocaml 3.08.


Basile STARYNKEVITCH -- basile dot starynkevitch at inria dot fr
other email : basile at starynkevitch dot net
Project - for a few days --- all opinions are only mine 

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: