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] Does Caml have slow arithmetics ?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Alex Baretta <alex@b...>
Subject: Re: [Caml-list] Does Caml have slow arithmetics ?
Luc Maranget wrote:
> In fact you need 7 arguments or more in the callee to
> trigger the unoptimized behavior on a pentium (just checked this time).

This is a fair amount of arguments, but still...

>>What?! Is this true? This effectively means that I cannot count on 
>>tail-call elimination in general?
> Do not take it that bad. In practice, it does not matter much I guess.
> I guess that any ocamlopt back-end passes at least the first six argument in
> registers (and six is a lot).
> Besides stack grow is a less severe issue in native code than it is in
> byte code.  At least in Unix, the process stack may grow to important sizes.

The trouble is that I have always considered idiomatically correct the 
use of tail-recursion in exchange for loops. Often, the main loop of my 
code is actually a non-terminating recursion.

I really think that the lack of full tail-call optimization in ocamlopt 
is BAD! I feel very strongly about this because it is a completely 
unexpected behavior in a proper functional language like Ocaml.

I'll have to verify that nowhere in my code do I use functions with more 
than seven arguments. If need be, I'll have to compact the arguments 
into tuples or records so as to stay within the tail-call optimization 
limit. Yet, although this is feasible and probably will have a minimal 
impact on my code, I still believe that ocamlopt should do anything it 
can to perform proper tail-call optimization all the time.


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