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] Efficency of varient types
Date: Sat, 26 Nov 2005 01:18:43 +0000	[thread overview]
Message-ID: <200511260118.44430.jon@ffconsultancy.com> (raw)
In-Reply-To: <c62c8d860511251553k782c574cg37fa1116d6fc3064@mail.gmail.com>

On Friday 25 November 2005 23:53, Michael D. Adams wrote:
> I am working on a program that translates code from scheme into ocaml.
>  (Later I will try python into ocaml.)  Because it is a dynamicly
> typed language, the most natural translation would make everything a
> function of a large variant type like:
>
> type value = Int of int
>
>   | Char of char
>   | String of string

Yes, exactly.

> However the point of my project is to translate into *efficient* ocaml
> code so I would like to avoid the ten times slow down that I've seen
> with variant types.

This is the main reason why dynamically typed languages are typically much 
slower than statically typed languages.

Look at my ray tracer comparison:

  http://www.ffconsultancy.com/free/ray_tracer/languages.html

Adding type declarations makes the Lisp implementation much faster because, 
without them and without static typing, the Lisp compiler (SBCL) resorts to 
boxing almost everything as you have done.

The Stalin-compiled Scheme implementation is vastly faster than the 
SBCL-compiled Lisp implementation for many reasons. One of the most important 
reasons is that Stalin is a whole-program optimising compiler and spends a 
significant part of its 10 minute compile time removing as much boxing as 
possible.

> Is there is a way to make program 2 as fast as program 1?  (Still
> keeping the variant type of course.)

No.

Transforming from version 2 to version 1 (unboxing) is exactly what the 
optimisers in the compilers of dynamically typed languages are doing.

> Why is program 2 so slow?  Is it the cost of heap allocation?  The GC?
> Having to access memory instead of registers?  Constructor matching?

All of the above.

> One trick that I've thought of would be to push some of the tag
> information into the pointer.  For example an Int would be represented
> exactly like an int (i.e. an odd address), but a String would be
> represented as a pointer to a block (i.e. an even address).  I could
> hack around with the Obj module (indeed some experiments with that
> show very good performance), but it would be nice if there were a
> cleaner way such as a way to annotate constructors so OCaml tries to
> avoid using blocks for them.  (Stuffing tags into pointers is very
> common in the Scheme world.)

You would probably be better off trying to apply the unboxing optimisations 
(e.g. that Stalin does).

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists


  parent reply	other threads:[~2005-11-26  1:23 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-25 23:53 Michael D. Adams
2005-11-26  0:31 ` [Caml-list] " Nicolas Cannasse
2005-11-26  1:22   ` Brian Hurt
2005-11-26  9:39     ` Nicolas Cannasse
2005-11-28  0:17     ` Obj or not Obj Christophe Raffalli
2005-11-28  8:41       ` [Caml-list] " Nicolas Cannasse
2005-11-28  9:27         ` Christophe Raffalli
2005-11-28  9:33         ` skaller
2005-11-28  8:43       ` Alain Frisch
2005-11-26  2:54   ` [Caml-list] Efficency of varient types skaller
2005-11-27  5:06   ` Michael D. Adams
2005-11-27  5:45     ` Brian Hurt
2005-11-27 10:02       ` Nicolas Cannasse
2005-11-27 15:35       ` Michael D. Adams
2005-11-27 18:08         ` Brian Hurt
2005-12-02 15:07           ` Michael D. Adams
2005-11-26  1:18 ` Jon Harrop [this message]
2005-11-27 14:57 ` Lukasz Stafiniak
2005-11-27 15:47   ` Lukasz Stafiniak
2005-11-28  8:14   ` Christophe Raffalli
2005-11-28  7:24 ` David Baelde
2005-11-28  7:49   ` Jacques Garrigue
2005-11-28 10:01     ` Jon Harrop
2005-11-28 10:26       ` Luc Maranget
2005-11-28  7:53   ` Ville-Pertti Keinonen
2005-12-01 17:05 ` Stefan Monnier
2005-12-02 15:07   ` [Caml-list] " Michael D. Adams

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=200511260118.44430.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).