caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jon Harrop <jon@ffconsultancy.com>
To: Jan Kybic <kybic@fel.cvut.cz>, caml-list@yquem.inria.fr
Subject: Re: [Caml-list] AST versus Ocaml
Date: Wed, 4 Nov 2009 20:25:34 +0000	[thread overview]
Message-ID: <200911042025.34897.jon@ffconsultancy.com> (raw)
In-Reply-To: <87zl725ma5.fsf@fel.cvut.cz>

On Wednesday 04 November 2009 15:42:42 Jan Kybic wrote:
> >  Shivkumar Chandrasekara said:
> >I switched from OCaml to ATS for numerical computations. I did this
> >because I was thinking of switching to some low-level language anyway
> >(for efficiency). I think ATS is a good fit for OCaml types who also
> >want low-level control of memory and CPU. (You can always turn on the
> >GC in ATS and code in an OCaml-like fashion if you wish.)
>
> Thank you, that sounds very encouraging. So are you saying that if you
> turn on the GC in ATS, the performance is not so different?

I haven't found the time to give ATSLang a serious test drive but I had a 
brief conversation with Hongwei Xi about his work and goals. He is into 
systems programming, which is closely related to high performance programming 
in the context of serial code but foundations for easy parallel programming 
are missing. I don't know what the state of ATS' memory model is so things 
like non-blocking algorithms might be tricky. Another concern is that ATS' 
code gen goes via GCC and GCC is quite a sucky compiler with poor compilation 
times, poor generated code and, of course, missing features like tail calls 
requiring elaborate and usually slow and uninteroperable workarounds. ATS 
also lacks a performant REPL, a build system, DLLs and package management. I 
don't know what the state of editors/IDEs is.

Given that ATSLang uses the Boehm GC, my main concerns would be about leaks 
and crashes rather than performance. Moreover, I would note that the 
performant ATS code out there seems to go to *great* lengths to avoid the GC 
whenever possible, so I suspect it is extremely slow in the context of 
heavily allocating code or many short-lived values (much like HLVM). For 
example, binary trees:

http://shootout.alioth.debian.org/u64q/benchmark.php?test=binarytrees&lang=ats&id=2#about

OCaml:  58 LOC
C:     122 LOC
ATS:   191 LOC

My guess is that safe ATS code will be slow if it allocates much. Also, I 
don't know how well its allocator scales across multiple threads.

> > Kevin Cheung said:
> > Unfortunately, I don't have much to say about AST at the moment.  But
> > if it is as fast as it claims to be, then it might do what Jon Harrop
> > is trying to achieve with HLVM.
>
> Yes, exactly, fast Ocaml based on HLVM would be ideal. However
> HLVM+Ocaml is probably still years away...

My vision for the OCaml+HLVM combo is the ability to use HLVM from your OCaml 
projects to generate and execute high performance parallel numerical code 
on-the-fly.

Hopefully I'll be implementing HLVM's first concurrent GC soon, based upon the 
following VCGC design:

  http://doc.cat-v.org/inferno/concurrent_gc/

In the meantime, you can still use HLVM to generate serial numerical code that 
is typically 2-3x faster than the equivalent OCaml code.

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


  reply	other threads:[~2009-11-04 20:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-04 14:01 Jan Kybic
2009-11-04 14:41 ` [Caml-list] " Kevin Cheung
2009-11-04 15:42   ` Jan Kybic
2009-11-04 20:25     ` Jon Harrop [this message]
2009-11-04 22:21       ` Jan Kybic
2009-11-04 23:15         ` Jon Harrop
2009-11-06 11:48           ` [Caml-list] ATS " Jan Kybic
2009-11-06 12:11             ` Sylvain Le Gall
2009-11-06 15:38               ` [Caml-list] " Jan Kybic
2009-11-07  1:56                 ` Jacques Garrigue
2009-11-07 19:00                 ` Jon Harrop
2009-11-06 12:22             ` [Caml-list] " Mauricio Fernandez
2009-11-04 15:37 ` [Caml-list] AST " malc

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=200911042025.34897.jon@ffconsultancy.com \
    --to=jon@ffconsultancy.com \
    --cc=caml-list@yquem.inria.fr \
    --cc=kybic@fel.cvut.cz \
    /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).