caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jon Harrop <jon@ffconsultancy.com>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] OCaml and Boehm
Date: Sat, 11 Apr 2009 11:42:23 +0100	[thread overview]
Message-ID: <200904111142.23884.jon@ffconsultancy.com> (raw)
In-Reply-To: <49E066E5.8060107@starynkevitch.net>

On Saturday 11 April 2009 10:46:13 Basile STARYNKEVITCH wrote:
> Lukasz Stafiniak wrote:
> > Hi,
> >
> > Is the OCaml runtime Boehm-safe? That is, can it be run with Boehm
> > turned on and traversing OCaml's heap? (So that the OCaml heap can
> > provide roots to Boehm.) And if not, could it be patched to make it
> > Boehm-safe in this sense?
>
> Probably not. Because I am not sure of what you mean by Boehm-safe,
> since Boehm's GC is conservative and do not make much promises.

Boehm's GC breaks on various code, most notably code that "hides" pointers to 
reachable data in an indirect form. The most famous example that breaks Boehm 
is the (admittedly awful and technically illegal) pointer bump trick used in 
Numerical Recipies to bring the wonderous starting-at-one indexes of Fortran 
to the C world. Boehm fails to recognise the bumped pointers as references 
into reachable data and goes right ahead and deallocates all of your 
numerical arrays for you.

> There is a reason for all this. The major strength of Ocaml runtime is
> its robustness and its efficiency. The efficiency of Ocaml GC is of
> paramount importance (it supports very high allocation rate, which is
> out of reach for the Boehm collector; and big allocation rate is typical
> of most functional programs; the typical allocation speed within the
> Ocaml runtime is at least one or two order of magnitudes faster than
> that of GC_malloc; a typical GC_malloc is by itself a bit slower than a
> libc malloc.).

Regarding OCaml vs libc malloc, I had always assumed that but HLVM appears to 
have proven otherwise. It uses malloc and free directly with no optimization 
whatsoever yet it is now well within 2x the performance of OCaml on the 
allocation and GC intensive 10-queens benchmark.

Boehm's allocator is asymptotically slower than malloc, of course.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e


  reply	other threads:[~2009-04-11 10:35 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-10 20:13 Lukasz Stafiniak
2009-04-11  9:46 ` [Caml-list] " Basile STARYNKEVITCH
2009-04-11 10:42   ` Jon Harrop [this message]
     [not found]   ` <4a708d20904110511o7d390807r3d29400cf96d6f35@mail.gmail.com>
     [not found]     ` <49E09C2D.4080906@starynkevitch.net>
2009-04-11 14:11       ` Lukasz Stafiniak
2009-04-11 14:27         ` Jon Harrop
2009-04-11 14:40           ` Lukasz Stafiniak
2009-04-11 20:40             ` Jon Harrop
2009-04-11 15:03         ` Basile STARYNKEVITCH
2009-04-11 20:41           ` Jon Harrop
2009-04-13  9:42           ` Christoph Bauer
2009-04-13 13:15             ` Lukasz Stafiniak
2009-04-14  5:25               ` Goswin von Brederlow
2009-04-12  3:34   ` Goswin von Brederlow
2009-04-12 12:09     ` Lukasz Stafiniak
2009-04-13 17:36 ` Xavier Leroy
2009-04-11 19:17 Ed Keith
2009-04-11 20:36 ` Jon Harrop
2009-04-12  3:25   ` Goswin von Brederlow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200904111142.23884.jon@ffconsultancy.com \
    --to=jon@ffconsultancy.com \
    --cc=caml-list@yquem.inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).