[Caml-list] native vs bytecode

[Ben Aurel]

hi
As I try to acquire more knowledge about Ocaml I made a bit of an
unpleseant discovery today. I always was fascinated by the execution
performance of Ocaml. But now I've learned, that this is only true for
native binaries and I'm a little confused now:

- is it possible to dynamically load native libraries into a native program?

- is it possible to dynamically load bytecode libraries into a native program?

- is it possible to dynamically load native libraries into a bytecode program?

- is it possible to dynamically load bytecode libraries into a bytecode program?

- Are there any performance test that shows how bytecode programs
stack up agains dynamic languages like ruby, perl and python?

thanks
ben

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

[Alain Frisch]

Ben Aurel wrote:
> - is it possible to dynamically load bytecode libraries into a bytecode program?

Yes:
http://caml.inria.fr/pub/docs/manual-ocaml/manual041.html

> - is it possible to dynamically load native libraries into a native program?

This will be possible in the next release of OCaml (3.11). The API is
the same as for bytecode (Dynlink module), although the model is a
little bit different (specific linking phase to produce dynlinkable units).

> - is it possible to dynamically load bytecode libraries into a native program?
> - is it possible to dynamically load native libraries into a bytecode
program?

No.

-- Alain

[Peng Zang]

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

What do you mean by "dynamically load"?

You cannot mix native and bytecode generally speaking.

I don't know of any speed comparisons of OCaml bytecode. You can always
compile to native code, which is faster, so I don't understand why you would
want to run anything large with bytecode.

Peng

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFImgUCfIRcEFL/JewRAnvkAJ4/55GKZjoZF40z2J7LDOvChKZQ+gCbBbws
gGAKM/WB1OFovWdowvrjQxk=
=xX5E
-----END PGP SIGNATURE-----

[Richard Jones]

On Wed, Aug 06, 2008 at 03:58:22PM -0400, Ben Aurel wrote:
> As I try to acquire more knowledge about Ocaml

Ben, your invitation to ocaml_beginners has now been approved so these
sorts of questions should go to that list. There are many of the same
people, and we provide lots of help very quickly, but it keeps
beginners questions out of the way of the experts on this list.

> I made a bit of an unpleseant discovery today. I always was
> fascinated by the execution performance of Ocaml. But now I've
> learned, that this is only true for native binaries and I'm a little
> confused now:

OCaml really is very fast, _when_ you want it to be.

As with all programming, avoid premature optimizations, profile your
code to find out where it's spending its time, and rewrite those parts
that take the most time.

I rarely if ever use the bytecode compiler these days, since there is
no significant advantage to using it. When I really need speed (after
profiling my program with gprof), I do the following steps in order
until the program is fast enough:

(1) Try to use more suitable data structures (eg. turning assoc-lists
into hash tables or maps).

(2) Rewrite critical functions to be tail recursive.

(3) Rewrite match expressions so that the common case has its own
match pattern and is written more efficiently.

(4) Look at memory usage of data structures and try to minimize.

(5) Turn lists into arrays and rewrite functional stuff using
for-loops.

(6) Turn to C (or even assembly) for critical inner functions.

With this strategy, OCaml programs at Red Hat are performing as well
as C code, and about an order of magnitude faster & an order of
magnitude lower memory usage than programs written in Python, which is
the main language used around here.

When you consider the environmental consequences of running many
virtualized machines in a data centre, order of magnitude reductions
in processor and RAM usage are *significant* (ie. muchos $$$).

> - is it possible to dynamically load native libraries into a native
> program?

Yes, in OCaml 3.11 Dynlink can do this.

> - is it possible to dynamically load bytecode libraries into a
> native program?

Not as far as I'm aware.

> - is it possible to dynamically load native libraries into a
> bytecode program?

Again, I don't think this is possible.

> - is it possible to dynamically load bytecode libraries into a
> bytecode program?

Yes, use the Dynlink module.

> - Are there any performance test that shows how bytecode programs
> stack up agains dynamic languages like ruby, perl and python?

If you look for the "Great Language Shootout" you'll find something.

Rich.

--
Richard Jones
Red Hat

[Mauricio Fernandez]

On Wed, Aug 06, 2008 at 03:58:22PM -0400, Ben Aurel wrote:

> hi
> As I try to acquire more knowledge about Ocaml I made a bit of an
> unpleseant discovery today. I always was fascinated by the execution
> performance of Ocaml. But now I've learned, that this is only true for
> native binaries and I'm a little confused now:
>
> - is it possible to dynamically load native libraries into a native program?
>
> - is it possible to dynamically load bytecode libraries into a native program?
>
> - is it possible to dynamically load native libraries into a bytecode program?
>
> - is it possible to dynamically load bytecode libraries into a bytecode program?

This has already been addressed by Alain Frisch. I'd only add to his answer
that OCaml 3.11 is being released soon (probably later this month):

http://groups.google.com/group/fa.caml/tree/browse_frm/thread/15126f960406e056/531fda06c1da700e?rnum=1&_done=%2Fgroup%2Ffa.caml%2Fbrowse_frm%2Fthread%2F15126f960406e056%3F#doc_e038a89c482c0c68

> - Are there any performance test that shows how bytecode programs
> stack up agains dynamic languages like ruby, perl and python?

I've compared some OCaml bytecode programs to their Ruby equivalents, and have
often found them to be 2 to 5 times faster _if_ you're not using expensive
stdlib functions which are implemented in OCaml in the first case and happen
to be written in C in Ruby's core classes (for instance, Array.sort vs.
Array#sort; the latter is faster unless the comparison function, or #<=>
method, isn't trivial[1]). I also compared OCaml bytecode with Ruby 1.9 using
some simple micro-benchmarks, and found basic functionality (integer
arithmetic, loops, etc.) to be about as fast (not surprising since the
underlying VMs are quite similar for such things).

Still, overall OCaml bytecode can be faster than Ruby 1.9 (which can itself be
substantially faster than 1.8 sometimes) because in the latter method
dispatching is quite expensive, in contrast to OCaml, where you're applying
known functions most of the time. This holds even in Ruby's best case (method
cache hit).

[1] this deficiency is addressed by using an external C function, the same way
Ruby does. Fortunately, there are few such cases: in the stdlib, some Array
operations (copy, sub and some other operations), the above-mentioned sort
functions, and maybe Hashtbl come to mind.

--
Mauricio Fernandez - http://eigenclass.org

[Haoyang Wang]

On Wed, Aug 6, 2008 at 12:58 PM, Ben Aurel <ben....@gmail.com> wrote:
> - is it possible to dynamically load bytecode libraries into a native program?

This could be done with the asmdynlink library by Fabrice Le Fessant.
He reimplemented the bytecode interpreter in ocaml! (Does asmdynlink
still work?)

asmdynlink is distributed as part of CDK (http://pauillac.inria.fr/cdk/).

Cheers,

Haoyang Wang
Skydeck

[Matt Gushee]

Alain Frisch wrote:

>> - is it possible to dynamically load native libraries into a native
>> program?
>
> This will be possible in the next release of OCaml (3.11).

That's great news! Do you have a rough idea of when 3.11 is coming?

--
Matt Gushee

[Ulf Wiger (TN/EAB)]

Peng Zang skrev:

> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>
> What do you mean by "dynamically load"?
>
> You cannot mix native and bytecode generally speaking.
>
> I don't know of any speed comparisons of OCaml bytecode. You can
> always compile to native code, which is faster, so I don't understand
> why you would want to run anything large with bytecode.
>
> Peng

I don't know how it is for ocaml, but in Erlang, it wouldn't be
considered strange to mix native and bytecode. The main reason
is that native code increases memory footprint compared to the
very compact bytecode. In systems with hundreds of KLOC of
code, this can make a significant difference.

There is a performance penalty when switching from native to
byte code, so one needs to try to minimize the number of
transitions in order not to cancel the effect of native
compilation.

Historically, it's been a problem that while native code
could be dynamically loaded, old code couldn't be purged
after code upgrade. I believe this problem is solved now,
or will be soon.

Again, I don't know how relevant this is to Ocaml. It was
mainly intended as an answer to the question why one would
like to mix native and bytecode.

BR,
Ulf W

[Kuba Ober]

> With this strategy, OCaml programs at Red Hat are performing as well
> as C code, and about an order of magnitude faster & an order of
> magnitude lower memory usage than programs written in Python, which is
> the main language used around here.

What does RedHat use OCaml for? That's just to satisfy my curiosity. A quick
google for ocaml at redhat did not yield much.

Cheers, Kuba

[Kuba Ober]

On Thursday 07 August 2008, Kuba Ober wrote:
> > With this strategy, OCaml programs at Red Hat are performing as well
> > as C code, and about an order of magnitude faster & an order of
> > magnitude lower memory usage than programs written in Python, which is
> > the main language used around here.
>
> What does RedHat use OCaml for? That's just to satisfy my curiosity. A
> quick google for ocaml at redhat did not yield much.

I should say that I did look at your page, so the question should rather be:
what does RedHat use Ocaml for, other than what RJ is using it for? :)

[Michael Ekstrand]

Kuba Ober <obe...@osu.edu> writes:
> On Thursday 07 August 2008, Kuba Ober wrote:
>> > With this strategy, OCaml programs at Red Hat are performing as well
>> > as C code, and about an order of magnitude faster & an order of
>> > magnitude lower memory usage than programs written in Python, which is
>> > the main language used around here.
>>
>> What does RedHat use OCaml for? That's just to satisfy my curiosity. A
>> quick google for ocaml at redhat did not yield much.
>
> I should say that I did look at your page, so the question should rather be:
> what does RedHat use Ocaml for, other than what RJ is using it for? :)

Educated guess based on the things listed on RJ's page and the packages
presently available in Fedora 9: tools for a future version of RHEL, I
would imagine :).

- Michael

--
mouse, n: A device for pointing at the xterm in which you want to type.
Confused by the strange files? I cryptographically sign my messages.
For more information see <http://www.elehack.net/resources/gpg>.

[Richard Jones]

On Wed, Aug 06, 2008 at 07:24:06PM -0600, Matt Gushee wrote:
> Alain Frisch wrote:
> >>- is it possible to dynamically load native libraries into a native
> >>program?
> >
> >This will be possible in the next release of OCaml (3.11).
>
> That's great news! Do you have a rough idea of when 3.11 is coming?

Late this month according to:

http://caml.inria.fr/pub/ml-archives/caml-list/2008/06/1e42d9e432b3bcac5cf04b249c6d746a.en.html

Rich.

--
Richard Jones
Red Hat

_______________________________________________