[Caml-list] Does Caml have slow arithmetics ?

[Caml-list] Does Caml have slow arithmetics ?

[Diego Olivier Fernandez Pons]

    Bonjour,

Does the Caml integer/pointer bit trick make arithmetics slower (with
respect to 'pure' 32 bit arithmetics) because of some mask/shift
intermediate operations or is it just the same ?

Actually I haven't seen any significative performance difference with
respect to a similar C++ code I have done, what I wasn't expecting.
That is why I am asking.


        Diego Olivier


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[Richard Jones]

On Wed, Jul 07, 2004 at 08:45:51AM +0200, Diego Olivier Fernandez Pons wrote:
>     Bonjour,
> 
> Does the Caml integer/pointer bit trick make arithmetics slower (with
> respect to 'pure' 32 bit arithmetics) because of some mask/shift
> intermediate operations or is it just the same ?

There's hardly any penalty because the code generator does lots
of tricks.  See:

http://www.merjis.com/developers/ocaml_tutorial/ch11/

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
http://www.YouUnlimited.co.uk/ - management courses

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[Basile Starynkevitch [local]]

On Wed, Jul 07, 2004 at 08:45:51AM +0200, Diego Olivier Fernandez Pons wrote:

> Does the Caml integer/pointer bit trick make arithmetics slower (with
> respect to 'pure' 32 bit arithmetics) because of some mask/shift
> intermediate operations or is it just the same ?

In principle yes, because int values are represented as tagged
(31bits) ints (with the LSB set to 1). So conversion is a shift
followed by an addition (or viceversa).

However, ocamlopt does do many optimisations (eg avoiding tagging &
untagging the same value, etc...). Also, on modern processors, simple
ALU operations are extremly fast, faster than most accesses to memory.


> Actually I haven't seen any significative performance difference with
> respect to a similar C++ code I have done, what I wasn't expecting.
> That is why I am asking.

In practice, real code do memory allocation, pattern matching,
etc.. On this, Ocaml excels (and perform probably better than C or
C++); more generally, Ocaml is good for real non-trivial programs.

But for toy programs, arithmetic is a bit faster with C than with
Ocamlopt. On my slow PentiumIII 1GHz, I've tested (the running time is
in comments at end of each example, the Ocaml compiler[s] are the
latest CVS, ie almost future 3.08)

################################################################
(* file eml.ml *)
let slowmul x y = 
  let rec muloop x y p =
    if (y>0) then muloop x (y-1) (p+x) else p
  in 
  if y<0 then muloop (-x) (-y) 0
  else muloop x y 0
;;

let main () = 
  let s = ref 0 in
  for i = 0 to 2000 do
    if (i mod 64 = 0) then Printf.printf "i=%d\n%!" i;
    for j = 0 to 3000 do 
      s := !s  + slowmul i j
    done
  done;
  Printf.printf "s=%d\n%!" !s
in main ();;
(* time ./eml (compiled with ocamlopt -inline 9) is 25.360 total *)
################################################################
// file em.c
#include <stdio.h>
int slowmul(int x, int y) {
  int p=0;
  if (y<0) { x= -x; y= -y; };
  while (y>0) {p+=x; y--;};
  return p;
}

int main() {
  int s=0, i, j;
  for (i=0; i<=2000; i++) {
    if (i%64 == 0) printf("i=%d\n", i);
    for (j=0; j<=3000; j++) 
      s += slowmul(i,j);
  };
  printf("s=%d\n", s);
  return 0;
}
// time ./em (compiled with gcc-3.3 -O3) is 19.095 sec
################################################################

As you can see on this simple test, Ocamlopt produce a program 1.32
times slower than gcc, and if you have a glance at the generated
assembly, you see some tagging stuff appearing.

For completeness, the above eml.ml program bytecompiled by ocamlc to
eml.byte is run in 381.5 seconds -more than 6 minutes- by my
ocamljitrun (see http://cristal.inria.fr/~starynke/ocamljit.html) and
in 1780 seconds (yes, more than 29 minutes, almost half an hour!) by
the standard ocamlrun interpreter.

Regards.
-- 
Basile STARYNKEVITCH -- basile dot starynkevitch at inria dot fr
Project cristal.inria.fr - phone +33 1 3963 5197 - mobile 6 8501 2359
http://cristal.inria.fr/~starynke --- all opinions are only mine 

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[Diego Olivier Fernandez Pons]

    Bonjour

> In principle yes, because int values are represented as tagged
> (31bits) ints (with the LSB set to 1). So conversion is a shift
> followed by an addition (or viceversa).

Subsidiary question : why LSB instead of MSB ? I thought it would be
simpler to let the computations silently overflow and correct when
necessary the tag bit.

        Diego Olivier


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[Basile Starynkevitch [local]]

On Wed, Jul 07, 2004 at 02:32:56PM +0200, Diego Olivier Fernandez Pons wrote:

(I, Basile Starynkevitch, replied:)

> > In principle yes, because int values are represented as tagged
> > (31bits) ints (with the LSB set to 1). So conversion is a shift
> > followed by an addition (or viceversa).
> 
> Subsidiary question : why LSB instead of MSB ? I thought it would be
> simpler to let the computations silently overflow and correct when
> necessary the tag bit.


I cannot answer for sure, since I did not made the choice, but I see
some reasons for it.

values which are nontagged integers are pointers to blocks. For
obvious reasons, you want to access the block's field as quickly as
possible, so the pointer is in fact a machine pointer to the block
(with perhaps a constant offset).

using the MSB as a tag bit would require that every Ocaml value is in
some restricted address range (like e g [0 ... 2^30] on 32 bits
machine). And having the heap always inside this range is not doable
without tricky system hacks (on Linux, mmap MAP_NORESERVE very early
in the Ocaml startup)

More simply, Ocaml's GC (IIRC) allocates memory (in big chunks) with
malloc, not mmap. Hence, it has no idea of what the memory address is,
and what is its MSB.

All above is an educated guess (from reading the code and some
discussions with Xavier L. & Damien D.) - I may be grossly wrong.

I did read many GC related papers, and all the tagging schemes I
remember having read about (for some suitably short integers) uses the
LSB, not the MSB. So, it is probably a well established habit.

If you want to start a functional language implementation from
scratch, you might (as Xavier Leroy told me) consider tagging integers
with a 0 LSB, and having GC-ed pointers with a 1 LSB. Hence, ordinary
C pointers (outside your heap) are handled as integers and remain
untouched by the GC. This insight is Xavier's, not mine!

(Old dinosaurs like me also remember the tagged-add machine
instruction on the Sparc, which had the tags of int in the two lowest
bits of the word).

This is the first time I'm hearing about tagging integer in the MSB,
and I have no more convincing arguments - maybe it is just a habit
(and maybe 64 bits processors might change it - since they won't fill
their address space for a long time).

-- 
Basile STARYNKEVITCH -- basile dot starynkevitch at inria dot fr
Project cristal.inria.fr - phone +33 1 3963 5197 - mobile 6 8501 2359
http://cristal.inria.fr/~starynke --- all opinions are only mine 

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[Olivier Pérès]

Basile Starynkevitch [local] wrote:
> If you want to start a functional language implementation from
> scratch, you might (as Xavier Leroy told me) consider tagging integers
> with a 0 LSB, and having GC-ed pointers with a 1 LSB. Hence, ordinary
> C pointers (outside your heap) are handled as integers and remain
> untouched by the GC. This insight is Xavier's, not mine!

    But there is no way to be sure that a pointer you got from C is 
word-aligned. Consider, for example, a smart user sending you a string 
with the first character chopped off : this pointer has an odd LSB. And 
C hackers like to do that kind of things. Xavier Leroy obviously knows 
this, so I must have missed something.

    Olivier.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[David Brown]

On Wed, Jul 07, 2004 at 05:09:32PM +0200, Olivier P?r?s wrote:

>    But there is no way to be sure that a pointer you got from C is 
> word-aligned. Consider, for example, a smart user sending you a string 
> with the first character chopped off : this pointer has an odd LSB. And 
> C hackers like to do that kind of things. Xavier Leroy obviously knows 
> this, so I must have missed something.

The only pointers that ocaml "cares" about (in the sense of the GC or
polymorphic compare) are those that are allocated on the ocaml heap.
These values will always be aligned.  Whenever the gc or friends sees a
pointer, it checks a bitmap of pages to determine if this pointer was
ocaml allocated.  If not, it ignores it completely.

Dave

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[Olivier Pérès]

David Brown wrote:
> 
> The only pointers that ocaml "cares" about (in the sense of the GC or
> polymorphic compare) are those that are allocated on the ocaml heap.

    Sure, but the reason given above to zero-tag integers was to have C 
pointers "look" like integers to the GC. However, C pointers are not 
necessarily aligned and thus may mislead the GC into trying to 
garbage-collect them.

    Olivier.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[David Brown]

On Wed, Jul 07, 2004 at 07:43:13PM +0200, Olivier P?r?s wrote:
> David Brown wrote:
> >
> >The only pointers that ocaml "cares" about (in the sense of the GC or
> >polymorphic compare) are those that are allocated on the ocaml heap.
> 
>    Sure, but the reason given above to zero-tag integers was to have C 
> pointers "look" like integers to the GC. However, C pointers are not 
> necessarily aligned and thus may mislead the GC into trying to 
> garbage-collect them.

No.  Aligned C pointers look like pointers to the GC.  It uses a bitmap
to distinguish between C pointers and ocaml heap managed pointers.
Misaligned pointers are the ones that will look like integers to the GC.

Dave

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[Olivier Pérès]

David Brown wrote:
> No.  Aligned C pointers look like pointers to the GC.  It uses a bitmap
> to distinguish between C pointers and ocaml heap managed pointers.
> Misaligned pointers are the ones that will look like integers to the GC.

    Once again, you are not talking about the same thing as I am. In the 
suggested new system, aligned C pointers would look like (0-tagged) Caml 
integers and thus the GC would not even consider collecting them, which 
is good. However, the check whether a (1-tagged) pointer was allocated 
by Caml would remain necessary, because C pointers can have their LSB 
set, even if it is seldom so. Therefore I wonder whether this would be 
useful at all. It was not my intention to say this three times, so I'm 
stopping there so as not to pollute the list.

    Olivier.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[Richard Jones]

On Wed, Jul 07, 2004 at 02:32:56PM +0200, Diego Olivier Fernandez Pons wrote:
> Subsidiary question : why LSB instead of MSB ? I thought it would be
> simpler to let the computations silently overflow and correct when
> necessary the tag bit.

I don't know, but the current representation allows simplifications of
some common mathematical operations.  You don't need to worry about
the tag bit at all.

Addition (a + b)
----------------

let r1 = 2 * a + 1	# Actual representation of 'a' in a register
let r2 = 2 * b + 1

  r1 + r2 - 1		# Addition, proof follows:
= 2 * a + 1 + 2 * b + 1 - 1
= 2 * a + 2 * b + 1
= 2 * (a + b) + 1

ocamlopt actually uses the effective address calculation unit to do
this, so it's basically a single instruction:

lea     -1(%eax, %ebx), %eax

Subtractions (a - b)
--------------------

let r1 = 2 * a + 1	# Actual representation of 'a' in a register
let r2 = 2 * b + 1

  r1 - r2 + 1		# Subtraction, proof follows:
= 2 * a + 1 - 2 * b + 1 + 1
= 2 * a - 2 * b + 1
= 2 * (a - b) + 1

ocamlopt compiles this to two instructions:

subl    %ebx, %eax
incl    %eax

Multiplication (a * b)
----------------------

let r1 = 2 * a + 1	# Actual representation of 'a' in a register
let r2 = 2 * b + 1

  (r1 - 1) * (r2 / 2) + 1
= (2 * a + 1 - 1) * b + 1	# NB: r2 / 2 = b because of integer rounding
= 2 * a * b + 1
= 2 * (a * b) + 1

ocamlopt compiles this into four instructions:

sarl    $1, %ebx
decl    %eax
imull   %ebx, %eax
incl    %eax

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
MONOLITH is an advanced framework for writing web applications in C, easier
than using Perl & Java, much faster and smaller, reusable widget-based arch,
database-backed, discussion, chat, calendaring:
http://www.annexia.org/freeware/monolith/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[David Haguenauer]

On 2004-07-07 14:32:56 Wed, Diego Olivier Fernandez Pons wrote:
> > In principle yes, because int values are represented as tagged
> > (31bits) ints (with the LSB set to 1). So conversion is a shift
> > followed by an addition (or viceversa).
> 
> Subsidiary question : why LSB instead of MSB ? I thought it would be
> simpler to let the computations silently overflow and correct when
> necessary the tag bit.

Xavier Leroy's report about the ZINC experiment gives a good
rationale:

    4.2.1 Unallocated objects

    The only kind of unallocated (unboxed) objects is small
    integers. As the heap contains only 32-bit words, all pointers in
    the heap are 32-bit aligned, so their low-order bits are always
    00. Integers are therefore encoded with a 1 as low-order bit:
    [...]

(http://pauillac.inria.fr/~xleroy/publi/ZINC.ps.gz)

-- 
David Haguenauer

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[Brian Hurt]

On Wed, 7 Jul 2004, Diego Olivier Fernandez Pons wrote:

> Subsidiary question : why LSB instead of MSB ? I thought it would be
> simpler to let the computations silently overflow and correct when
> necessary the tag bit.

Because everything is a word and word aligned, so pointers always point to
a word aligned address- which means that the low 2 (on 32-bit machines) or
3 (on 64-bit machines) bits are always zero for pointers.  So if we set 
the low bit of unboxed values, the garbage collector can simply walk 
through memory, looking at every word.  If the low bit is set, then it's 
an unboxed integer type and not a point.  If the low bit is clear, it's a 
pointer.  This speeds up the garbage collector, making the overall program 
faster.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[Evgeny Chukreev]

On Wed, 7 Jul 2004 11:13:08 +0200
    Basile Starynkevitch <basile.starynkevitch@inria.fr> wrote:

BSl> In practice, real code do memory allocation, pattern matching,
BSl> etc.. On this, Ocaml excels (and perform probably better than C or
BSl> C++); more generally, Ocaml is good for real non-trivial programs.

Do developers plan to add new kinds of optimization in a near future?


Trivial example:

let f a b =
    let a, b = a, b in
        a + b

let g a b =
    a + b


Compiled in:

Test__f_57:
.L100:
        movl    %eax, %ecx
.L101:  movl    young_ptr, %eax
        subl    $12, %eax
        movl    %eax, young_ptr
        cmpl    young_limit, %eax
        jb      .L102
        leal    4(%eax), %eax
        movl    $2048, -4(%eax)
        movl    %ecx, (%eax)
        movl    %ebx, 4(%eax)
        movl    4(%eax), %ebx
        movl    (%eax), %eax
        lea     -1(%eax, %ebx), %eax
        ret
.L102:  call    caml_call_gc
.L103:  jmp     .L101

Test__g_62:
.L104:
        lea     -1(%eax, %ebx), %eax
        ret


--
... WBR, Evgeny ...

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[Xavier Leroy]

> Do developers plan to add new kinds of optimization in a near future?
> 
> Trivial example:
> 
> let f a b =
>     let a, b = a, b in
>         a + b
> 
> let g a b =
>     a + b

The main purpose of OCaml's compiler optimizations is to avoid
introducing inefficiencies while compiling.  In other terms, the main
objective is to generate good machine code from good source code.
In this respect, optimizations of redundant tagging operations is
crucial, since this aspect of execution is not apparent in the source
code.  Other examples include register allocation and instruction
selection, which are not under the programmer's control

On the other hand, reducing inefficiencies already present in the
source code isn't a priority.  In your "f" function, you asked for the
construction of a pair, and you get that pair construction in
ocamlopt's output.  If you didn't want the pair to be constructed, why
did you write "f" this way?

- Xavier Leroy

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[Evgeny Chukreev]

On Wed, 7 Jul 2004 16:58:03 +0200
    Xavier Leroy <Xavier.Leroy@inria.fr> wrote:

> On the other hand, reducing inefficiencies already present in the
> source code isn't a priority.  In your "f" function, you asked for the
> construction of a pair, and you get that pair construction in
> ocamlopt's output.  If you didn't want the pair to be constructed, why
> did you write "f" this way?

This example was reduced version of:


let g a b =
    a*b, a+b


let f a b =
    let x, y = g a b in
    ...

with inlining we got:

let f a b =
    let x, y = a*b, a+b in
    ...

so pair will be constructed...
There is no way to return >1 values at once without contstructing
memory block and then decomposing it. Yes, I could do this as in C:

let g a b r1 r2 =
    r1 := a*b;
    r2 := a+b

let f a b =
    let x = ref 0 in
    let y = ref 0 in
        g a b x y;
        ...

but it's not best choice. Many of my functions return >1 values, so it's
not empty talking.

-- 
... WBR, Evgeny ...

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[skaller]

On Thu, 2004-07-08 at 00:58, Xavier Leroy wrote:

> On the other hand, reducing inefficiencies already present in the
> source code isn't a priority.  

Of course that argument fails totally in one important
case -- Q: if you wanted a loop why didn't you use one?
A: tail-rec functional code is considered cute :)

I'm sure there are other cases .. would not:

let x = 1 in
let y = 1 in
let z = 1 in ...

be optimised into a single closure, not 3?
Or do i really have to write:

let x = 1 and y = 1 and z = 1 in ..

What's efficient depends on what's optimised which
depends on what idioms are considered 'cute' looking :)

BTW: there is another answer to the question Xavier asked:

Q: why did you write the code that way ..?
A: I didn't, it was generated..

which suggests sometimes there is a reason to optimise
'silly' looking code.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[David Brown]

On Thu, Jul 08, 2004 at 05:16:19AM +1000, skaller wrote:
> On Thu, 2004-07-08 at 00:58, Xavier Leroy wrote:
> 
> > On the other hand, reducing inefficiencies already present in the
> > source code isn't a priority.  
> 
> Of course that argument fails totally in one important
> case -- Q: if you wanted a loop why didn't you use one?
> A: tail-rec functional code is considered cute :)

In some functional languages (Scheme, specifically), tail recursion is
required to be implemented iteratively.  It is a common enough idiom,
and easy enough to implement, that it is generally done in functional
languages.  In fact, gcc does it in C, with enough optimization.

Dave

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[skaller]

On Thu, 2004-07-08 at 13:44, David Brown wrote:
> > Of course that argument fails totally in one important
> > case -- Q: if you wanted a loop why didn't you use one?
> > A: tail-rec functional code is considered cute :)
> 
> In some functional languages (Scheme, specifically), tail recursion is
> required to be implemented iteratively.  It is a common enough idiom,
> and easy enough to implement, that it is generally done in functional
> languages.  In fact, gcc does it in C, with enough optimization.

I'm aware of this, my point is that Xavier's argument
that complex code generates inefficient code 
"what else do you expect?" is a bit weak.

Whether you expect tail-rec optimisation or not
depends on your knowledge of compiler implementation
details.

Felix for example has a functional subsystem which
one could argue is "more functional" than Ocaml's
since side effects are not permitted .. but it happens
to generate C at the moment -- and I admit I myself
have no idea whether tail calls in functions are
optimised or not, or how to actually organise the generated
C so as to encourage a compiler .. perhaps gcc, perhaps MSVC ..
to actually perform the optimisation. Procedure calls ARE
tail-rec optimised by Felix (guarranteed!) but the calling
mechanism is quite different to that used for functions.

Even experts are often surprised by generated code complexity.
In C++ for example, the close connection between source
and generated code is lost in some cases, particularly
constructor calls: the cost of instantiating a class with
virtual bases and functions derived from others can be
extremely high and is silently hidden .. and C++ experts 
often miss the disparity between source and generated code.

Note I'm not disputing Xaviers orientation here: I basically
agree, I merely wish to point out that the argument isn't
quite as strong as one might think. Higher level optimisations
are also important IMHO. Chosing which ones to actually do
is of course very hard :)

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[Andreas Rossberg]

David Brown wrote:
> 
> In some functional languages (Scheme, specifically), tail recursion is
> required to be implemented iteratively.  It is a common enough idiom,
> and easy enough to implement, that it is generally done in functional
> languages.  In fact, gcc does it in C, with enough optimization.

The latter is, to a certain extent, a myth.

First, you have to distinguish between simple tail *recursion*, and the 
much more general concept of tail *call*. I believe Scheme requires to 
fully optimize the latter, and so it is done by all decent FPL 
implementations. GCC does not do that, already falling short of mutually 
recursive functions, IIRC.

Second, a C compiler can only optimize tail recursion under limited 
circumstances, because generally the C language semantics prevent it 
(once more due to pointers, particularly C allowing - and its libraries 
relying on - taking the address of local variables). Last time I heard 
of it, it was said that GCC is having a hard time doing anything 
practically usefull at all.

- Andreas

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

Let's get rid of those possible thingies!  -- TB

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[Marcin 'Qrczak' Kowalczyk]

W liście z czw, 08-07-2004, godz. 11:51 +0200, Andreas Rossberg napisał
(a):

> First, you have to distinguish between simple tail *recursion*, and the 
> much more general concept of tail *call*. I believe Scheme requires to 
> fully optimize the latter, and so it is done by all decent FPL 
> implementations. GCC does not do that, already falling short of mutually 
> recursive functions, IIRC.

GCC sometimes does optimize non-recursive tail calls too.

> (once more due to pointers, particularly C allowing - and its libraries 
> relying on - taking the address of local variables).

Another problem is that with the default calling convention the caller
pops the arguments, so it's impossible to optimize a tail call to a
function which has more arguments than the caller.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[David Brown]

On Thu, Jul 08, 2004 at 11:51:10AM +0200, Andreas Rossberg wrote:
> David Brown wrote:
> >
> >In some functional languages (Scheme, specifically), tail recursion is
> >required to be implemented iteratively.  It is a common enough idiom,
> >and easy enough to implement, that it is generally done in functional
> >languages.  In fact, gcc does it in C, with enough optimization.
> 
> The latter is, to a certain extent, a myth.

> First, you have to distinguish between simple tail *recursion*, and the 
> much more general concept of tail *call*. I believe Scheme requires to 
> fully optimize the latter, and so it is done by all decent FPL 
> implementations. GCC does not do that, already falling short of mutually 
> recursive functions, IIRC.

I just tested it, and gcc did tail call of two, (simple) mutually
recursive functions.  If they aren't simple enough, it doesn't.

> Second, a C compiler can only optimize tail recursion under limited 
> circumstances, because generally the C language semantics prevent it 
> (once more due to pointers, particularly C allowing - and its libraries 
> relying on - taking the address of local variables). Last time I heard 
> of it, it was said that GCC is having a hard time doing anything 
> practically usefull at all.

C is certainly going to limit the cases where tail-call elimination can
be done.  It also isn't very obvious where it can, so it isn't useful to
depend on.

Many ocaml programs depend on tail-call elimination, although I don't
believe anything in the docs requires it to be done.

Dave

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[Luc Maranget]

> On Thu, Jul 08, 2004 at 11:51:10AM +0200, Andreas Rossberg wrote:
> 
> Many ocaml programs depend on tail-call elimination, although I don't
> believe anything in the docs requires it to be done.
> 

Well, when programming in caml, I use the following rules (which I hope to be
accurate!)

+ ocamlc does perform tail call elimation
+ ocamlopt does it less often. Namely, calls in tail position
  become real tail calls when all their arguments are passed in registers.
  (This does not apply to self-tail calls which are always optimized)

  On pentiums/x86/IA32 this means that tail calls are performed when the callee
  has four arguments or less (if I remember well).


--Luc

> Dave
> 

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[Alex Baretta]

Luc Maranget wrote:
>>On Thu, Jul 08, 2004 at 11:51:10AM +0200, Andreas Rossberg wrote:
>>
>>Many ocaml programs depend on tail-call elimination, although I don't
>>believe anything in the docs requires it to be done.
>>
> 
> 
> Well, when programming in caml, I use the following rules (which I hope to be
> accurate!)
> 
> + ocamlc does perform tail call elimation
> + ocamlopt does it less often. Namely, calls in tail position
>   become real tail calls when all their arguments are passed in registers.
>   (This does not apply to self-tail calls which are always optimized)
> 


What?! Is this true? This effectively means that I cannot count on 
tail-call elimination in general?

Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[Luc Maranget]

> > + ocamlc does perform tail call elimation
> > + ocamlopt does it less often. Namely, calls in tail position
> >   become real tail calls when all their arguments are passed in registers.
> >   (This does not apply to self-tail calls which are always optimized)
> > 
> 
Oups sorry...

In fact you need 7 arguments or more in the callee to
trigger the unoptimized behavior on a pentium (just checked this time).


> 
> 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.


--Luc

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[Alex Baretta]

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.

Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[Markus Mottl]

On Fri, 09 Jul 2004, Alex Baretta wrote:
> 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.

I disagree here, because this would lead to inefficiencies.  Throwing
things on the stack is still much more efficient than heap allocation.
Since the OCaml-compiler can never rule out potential recursion (think
of references containing functions, etc.), it would always have to use
heap allocation with functions having more than six parameters.

I do have some functions that take more than six parameters, but none of
them is recursive.  It would be pointless to make calling these functions
less efficient, only because IA-32 sucks.

Regards,
Markus

-- 
Markus Mottl          http://www.oefai.at/~markus          markus@oefai.at

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[Norman Ramsey]

 >  + ocamlc does perform tail call elimation
 >  + ocamlopt does it less often. Namely, calls in tail position
 >    become real tail calls when all their arguments are passed in register s.
 >    (This does not apply to self-tail calls which are always optimized)
 > 
 > In fact you need 7 arguments or more in the callee to
 > trigger the unoptimized behavior on a pentium (just checked this time)...
 > 
 > Do not take it that bad. In practice, it does not matter much I guess.

Hmm.  Guess I'm shooting myself in the foot with this code (and lots
more like it):

let rec decl r imps exports lbls ks consts types regs archs data d k = match d with
  | A.DeclAt(x,r)   -> decl r imps exports lbls ks consts types regs archs data x k
  | A.Typedef d     -> k imps exports lbls ks consts ((r,d) :: types) regs archs data
  | A.Import (t,ii) -> k ((r,t,ii)::imps) exports lbls ks consts types regs archs data
  | A.Export (t,ee) -> k imps ((r,t,ee)::exports) lbls ks consts types regs archs data
  | A.Const d       -> k imps exports lbls ks ((r,d) :: consts)  types regs archs data
  | A.Registers rs  -> k imps exports lbls ks consts types ((r, rs) :: regs) archs data
  | A.Target    t   -> k imps exports lbls ks consts types regs ((r, t) :: archs) data
  | A.Pragma        -> k imps exports lbls ks consts types regs archs data

It's a wee bit depressing---I had hoped to treat a function call as a
goto while avoiding unbounded stack growth or unnecessary heap
allocation...


Norman

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[Luc Maranget]

>  >  + ocamlc does perform tail call elimation
>  >  + ocamlopt does it less often. Namely, calls in tail position
>  >    become real tail calls when all their arguments are passed in register s.
>  >    (This does not apply to self-tail calls which are always optimized)
>  > 
>  > In fact you need 7 arguments or more in the callee to
>  > trigger the unoptimized behavior on a pentium (just checked this time)...
>  > 
>  > Do not take it that bad. In practice, it does not matter much I guess.
> 
> Hmm.  Guess I'm shooting myself in the foot with this code (and lots
> more like it):
> 
> let rec decl r imps exports lbls ks consts types regs archs data d k = match d with
>   | A.DeclAt(x,r)   -> decl r imps exports lbls ks consts types regs archs data x k
>   | A.Typedef d     -> k imps exports lbls ks consts ((r,d) :: types) regs archs data
...
> 
> It's a wee bit depressing---I had hoped to treat a function call as a
> goto while avoiding unbounded stack growth or unnecessary heap
> allocation...

What I  exactely meant was that ``unbounded stack growth or unnecessary heap
allocation'' may not be as bad as it may seem.

Especially as regards heap allocation, provided allocated objects are
short-lived.


--Luc

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[Markus Mottl]

On Thu, 08 Jul 2004, Alex Baretta wrote:
> Luc Maranget wrote:
> >+ ocamlopt does it less often. Namely, calls in tail position
> >  become real tail calls when all their arguments are passed in registers.
> >  (This does not apply to self-tail calls which are always optimized)
> 
> 
> What?! Is this true? This effectively means that I cannot count on 
> tail-call elimination in general?

No, you can't.  If you happen to use a register-starved architecture like
IA-32 and call an OCaml-function with more than six parameters, then you
are out of luck, because you'll have to throw things on the stack.  AFAIK,
the OCaml compiler generates closures on the heap to work around this,
but only in cases where the recursion is obvious (self-tail calls).
Hm, shouldn't be too difficult to extend this to mutual recursion?
Or does OCaml already do this?

I usually avoid recursive functions with more than six parameters for
performance reasons.  I wrap them in closures, which bind constant
parameters, or, if there are too many volatile parameters, I modify the
volatile parameters in references outside of the function.  Another (less
efficient) solution would be to use tuples to pass volatile parameters.

The ultimate solution is, of course: buy a better architecture :-)

Regards,
Markus

-- 
Markus Mottl          http://www.oefai.at/~markus          markus@oefai.at

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[skaller]

On Fri, 2004-07-09 at 01:51, Markus Mottl wrote:
>  AFAIK,
> the OCaml compiler generates closures on the heap to work around this,
> but only in cases where the recursion is obvious (self-tail calls).
> Hm, shouldn't be too difficult to extend this to mutual recursion?
> Or does OCaml already do this?

one level of inlining would achieve this 
for two functions

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] tail recursion and register poor Intel architecture

[Brandon J. Van Every]

Markus Mottl wrote:
> On Thu, 08 Jul 2004, Alex Baretta wrote:
> > Luc Maranget wrote:
> > >  + ocamlopt does it less often. Namely, calls in tail position
> > >  become real tail calls when all their arguments are
> > >  passed in registers.
> > >  (This does not apply to self-tail calls which are always
> > >  optimized)
> >
> >
> > What?! Is this true? This effectively means that I cannot count on
> > tail-call elimination in general?
>
> No, you can't.  If you happen to use a register-starved
> architecture like
> IA-32 and call an OCaml-function with more than six
> parameters, then you
> are out of luck, because you'll have to throw things on the
> stack.  AFAIK,
> the OCaml compiler generates closures on the heap to work around this,
> but only in cases where the recursion is obvious (self-tail calls).
> Hm, shouldn't be too difficult to extend this to mutual recursion?
> Or does OCaml already do this?
>
> I usually avoid recursive functions with more than six parameters for
> performance reasons.  I wrap them in closures, which bind constant
> parameters, or, if there are too many volatile parameters, I
> modify the
> volatile parameters in references outside of the function.
> Another (less
> efficient) solution would be to use tuples to pass volatile
> parameters.
>
> The ultimate solution is, of course: buy a better architecture :-)

Or implement more of what Intel's crufty architecture actually offers.
For instance, supporting SSE would provide 8 additional 32-bit FPU
registers.  One doesn't have to use use the XMM registers for vectors,
they could be used as scalars, and that's the more straightforward
benefit of SSE architecture.  SSE2 allows for 64-bit FPU registers and
also integer registers, of size 32-bit and 64-bit IIRC (but I haven't
much cared about integer code).  So, if you were willing to compile for
a Pentium III for SSE, or a Pentium4 for SSE2, the optimization problem
would be less painful.  Of course, you'd have to write the painful
support for SSE/SSE2 in the first place.  :-)

For the record, I hate Intel's architectures.  They were talking about
Merced when I was writing real code on DEC Alpha.  Alpha is dead for
marketing reasons, not technical ones.  Meanwhile, Itanium is still
handwaving.

AMD also offers more registers on their newest chips.  I'm too fazed to
remember the details right now; I do recall twice as many FPU registers.


Cheers,                         www.indiegamedesign.com
Brand*n Van Every               S*attle, WA

Praise Be to the caml-list Bayesian filter! It blesseth
my postings, it is evil crap!  evil crap!  evil crap!

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] tail recursion and register poor Intel architecture

[Brian Hurt]

On Thu, 8 Jul 2004, Brandon J. Van Every wrote:

> Or implement more of what Intel's crufty architecture actually offers.
> For instance, supporting SSE would provide 8 additional 32-bit FPU
> registers.  

If you're using the MMX/SSE[123] registers, you can not be using the x87 
registers.  In addition, to move values between these registers (or the 
x87 registers) and the normal integer registers, you have to go via 
memory- i.e. write the value out to memory and read them back in again 
into the other register.  At which point you might as well be throwing 
them on the stack.

The large print giveth, and the small print taketh away.

> One doesn't have to use use the XMM registers for vectors,
> they could be used as scalars, and that's the more straightforward
> benefit of SSE architecture.  SSE2 allows for 64-bit FPU registers and
> also integer registers, of size 32-bit and 64-bit IIRC (but I haven't
> much cared about integer code).  

SSE2 is also only available on the P4s and the Opterons/Athlon-64s (AMD is 
the current crown holder for cool code names and dorky release names, 
having taken it away from HP.  Hammers and Snakes- cool code names.  
Sempron?  Give me a break).  Those of us with older computers would like 
to keep backward compatibility.


> For the record, I hate Intel's architectures.  They were talking about
> Merced when I was writing real code on DEC Alpha.  Alpha is dead for
> marketing reasons, not technical ones.  Meanwhile, Itanium is still
> handwaving.

Yes, but now it's the desperate handwaving of people trying to flag down a 
rescue helicopter.

> 
> AMD also offers more registers on their newest chips.  I'm too fazed to
> remember the details right now; I do recall twice as many FPU registers.
> 

The new iAMD-64 architecture in 64-bit mode has 16 general purpose 
registers (of which 14 are usable as such- the stack pointer and base 
pointer are both counted as general purpose registers), and 16 fp
registers (usable as both x87 and MMX/SSE[123] registers).

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] tail recursion and register poor Intel architecture

[Brandon J. Van Every]

Brian Hurt wrote:
> On Thu, 8 Jul 2004, Brandon J. Van Every wrote:
>
> > Or implement more of what Intel's crufty architecture
> actually offers.
> > For instance, supporting SSE would provide 8 additional 32-bit FPU
> > registers.
>
> If you're using the MMX/SSE[123] registers, you can not be
> using the x87 registers.

That is true/false.  These are *not* synonymous sets of registers.  MMX
registers are incompatible with the x87 FPU as you describe, because
they're aliases/repurposings of the x87 FPU registers.  The *XMM*
registers, associated with SSE/SSE2, are entirely separate registers.
You can most certainly use the x87 FPU simultaneously with those, no
special instruction state dances required.

> In addition, to move values between these registers (or the
> x87 registers) and the normal integer registers, you have to go via
> memory- i.e. write the value out to memory and read them back
> in again into the other register.  At which point you might as well be
> throwing them on the stack.

Well, you could pass the first 6 integer arguments via the normal
registers, the first 8 floating point arguments via the x87 FPU, and the
next 8 integer or float arguments via the XMM registers.  The values
wouldn't always be interoperable, you'd have to go through memory in
various cases, but it's better than nothing getting passed in registers
at all.  In any event I think this is more useful for FPU than integer
code.

> SSE2 is also only available on the P4s and the
> Opterons/Athlon-64s

Yes I mentioned the P4 requirement.  So what?  P4s have been around for
quite some time now.  It of course would be a conditional compilation
flag, but I see no reason why one should fear a paucity of SSE2 support
nowadays.  My late model 866 MHz P-III is 4 year old technology now.  A
functional workhorse, but obsolescent.

> Those of us with older computers would like
> to keep backward compatibility.

Those of you with particularly old computers are cheap-ass bastards who
should afford buying a new one every 6 years or so.  :-)  I do believe
in buying "behind the power curve," but come on, by the time anybody
actually implements what I'm talking about the P-IIIs will be mostly
gone.


Cheers,                         www.indiegamedesign.com
Brand*n Van Every               S*attle, WA

Praise Be to the caml-list Bayesian filter! It blesseth
my postings, it is evil crap!  evil crap!  evil crap!

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] tail recursion and register poor Intel architecture

[Brian Hurt]

On Thu, 8 Jul 2004, Brandon J. Van Every wrote:

> That is true/false.  These are *not* synonymous sets of registers.  MMX
> registers are incompatible with the x87 FPU as you describe, because
> they're aliases/repurposings of the x87 FPU registers.  The *XMM*
> registers, associated with SSE/SSE2, are entirely separate registers.
> You can most certainly use the x87 FPU simultaneously with those, no
> special instruction state dances required.

Point.

> Those of you with particularly old computers are cheap-ass bastards who
> should afford buying a new one every 6 years or so.  :-)  I do believe
> in buying "behind the power curve," but come on, by the time anybody
> actually implements what I'm talking about the P-IIIs will be mostly
> gone.

The brand new cpu/motherboard I bought six months ago doesn't have SSE2.  
I'll give you a hint: 
http://www.nanosys1.com/cpu-amd-xp-220d.html

Not top of the line, I admit, but still a nice box.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] tail recursion and register poor Intel architecture

[Florian Hars]

Brandon J. Van Every wrote:
> Well, you could pass the first 6 integer arguments via the normal
> registers, the first 8 floating point arguments via the x87 FPU, and the
> next 8 integer or float arguments via the XMM registers.

But this will give you different results for your computations, depending on 
argument ordering (if you push an argument from the last x87 register to the 
first XMM register, it loses 16 bits). Not really a desirable property...
But then, floating point on computers sucks, anyway.

Yours, Florian Hars.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] tail recursion and register poor Intel architecture

[Brandon J. Van Every]

Florian Hars wrote:
> Brandon J. Van Every wrote:
> > Well, you could pass the first 6 integer arguments via the normal
> > registers, the first 8 floating point arguments via the x87
> > FPU, and the
> > next 8 integer or float arguments via the XMM registers.
>
> But this will give you different results for your
> computations, depending on
> argument ordering (if you push an argument from the last x87
> register to the first XMM register, it loses 16 bits).

You are worrying about 80-bit Intel internal precision vs. the 64-bit
IEEE storage format?  That's a little too anal for my tastes.  If you
store your results as 64-bit doubles at some point, you're going to lose
that internal precision anyways.


Cheers,                         www.indiegamedesign.com
Brand*n Van Every               S*attle, WA

Praise Be to the caml-list Bayesian filter! It blesseth
my postings, it is evil crap!  evil crap!  evil crap!

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] tail recursion and register poor Intel architecture

[skaller]

On Fri, 2004-07-09 at 09:01, Brandon J. Van Every wrote:
>  by the time anybody
> actually implements what I'm talking about the P-IIIs will be mostly
> gone.

Don't be forgetting microcontrollers!  


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] tail recursion and register poor Intel architecture

[Brandon J. Van Every]

skaller wrote:
> On Fri, 2004-07-09 at 09:01, Brandon J. Van Every wrote:
> >  by the time anybody
> > actually implements what I'm talking about the P-IIIs will be mostly
> > gone.
>
> Don't be forgetting microcontrollers!

In OCaml?


Cheers,                         www.indiegamedesign.com
Brand*n Van Every               S*attle, WA

Praise Be to the caml-list Bayesian filter! It blesseth
my postings, it is evil crap!  evil crap!  evil crap!

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] tail recursion and register poor Intel architecture

[skaller]

On Sat, 2004-07-10 at 00:45, Brandon J. Van Every wrote:
> skaller wrote:
> > On Fri, 2004-07-09 at 09:01, Brandon J. Van Every wrote:
> > >  by the time anybody
> > > actually implements what I'm talking about the P-IIIs will be mostly
> > > gone.
> >
> > Don't be forgetting microcontrollers!
> 
> In OCaml?

How about an aircraft heads-up display and instrument
unit using a PIII, and Ocaml? I can't see why you'd
not want to opt for a language where you can actually
reason the code is correct -- would you prefer your
aircraft to use a C program?

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] embedded OCaml

[Brandon J. Van Every]

skaller wrote:
> > >
> > > Don't be forgetting microcontrollers!
> >
> > In OCaml?
>
> How about an aircraft heads-up display and instrument
> unit using a PIII, and Ocaml? I can't see why you'd
> not want to opt for a language where you can actually
> reason the code is correct -- would you prefer your
> aircraft to use a C program?

That sounds like theory.  Show me an embedded device actually programmed
in OCaml.  C interfaces are important when speaking to low level
hardware, and OCaml doesn't have a particularly good one.  I'm aware of
some other research work in the ML language family regarding "typed
assembly language," such as the TILT compiler.
http://www.cs.cornell.edu/Info/People/jgm/tilt.html  OCaml doesn't
strike me as being oriented towards low-level hardware problems though.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

"The pioneer is the one with the arrows in his back."
                          - anonymous entrepreneur

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] embedded OCaml

[Alex Baretta]

Brandon J. Van Every wrote:
> skaller wrote:

>>How about an aircraft heads-up display and instrument
>>unit using a PIII, and Ocaml? I can't see why you'd
>>not want to opt for a language where you can actually
>>reason the code is correct -- would you prefer your
>>aircraft to use a C program?
> 
> 
> That sounds like theory.  Show me an embedded device actually programmed
> in OCaml.  C interfaces are important when speaking to low level
> hardware, and OCaml doesn't have a particularly good one.  I'm aware of
> some other research work in the ML language family regarding "typed
> assembly language," such as the TILT compiler.
> http://www.cs.cornell.edu/Info/People/jgm/tilt.html  OCaml doesn't
> strike me as being oriented towards low-level hardware problems though.

We are about to ship our first embedded ocaml application: an automatic 
glass cutting table. The PLC is 2Ghz Celeron with 256MB RAM, Linux 2.4 
and Ocaml 3.07+2. It's just magnificent!

We are working on a logical control framework based on Ocaml. We will 
release under the GPL when the API will have stabilized.

Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] embedded OCaml

[Brandon J. Van Every]

From: Alex Baretta
>
> We are about to ship our first embedded ocaml application: an
> automatic
> glass cutting table. The PLC is 2Ghz Celeron with 256MB RAM,
> Linux 2.4 and Ocaml 3.07+2. It's just magnificent!

Sounds interesting.  Love to hear about things that aren't theory.

> We are working on a logical control framework based on Ocaml. We will
> release under the GPL when the API will have stabilized.

How does a GPL license help anyone else in commercial industry?  Or are
you going to do one of those "GPL or you can pay us" licenses?


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

When no one else sells courage, supply and demand take hold.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] embedded OCaml

[Alex Baretta]

Brandon J. Van Every wrote:
> From: Alex Baretta
> 
>>We are about to ship our first embedded ocaml application: an
>>automatic
>>glass cutting table. The PLC is 2Ghz Celeron with 256MB RAM,
>>Linux 2.4 and Ocaml 3.07+2. It's just magnificent!
> 
> 
> Sounds interesting.  Love to hear about things that aren't theory.

Very much, commercially. Industrial control is one of the few 
applications of computing where there still is some money to earn.

>>We are working on a logical control framework based on Ocaml. We will
>>release under the GPL when the API will have stabilized.
> 
> 
> How does a GPL license help anyone else in commercial industry?  Or are
> you going to do one of those "GPL or you can pay us" licenses?

We currently develop the complete automation solution: PLC kernel, 
low-level hardware drivers, application logic. We are more than willing 
to share our technology with the Ocaml community in order to further the 
development of the core and enhance our ability to develop custom 
application logic at lightning speed.

And, BTW of benchmarking Ocaml vs. anything else, here are the figures. 
It does memory management, driver management and process management. We 
currently compile to bytecode for testing purposes because we are too 
lazy to use ocamlopt, yet the kernel runs an order of magnitude faster 
that the physical layer can handle. We spend most of our time waiting 
for IO. Typical CPU loads are under 10% on the above mentioned 2GHz 
Celeron. Typical memory usage is under 2MB.

To communicate with the UI, the PLC kernel uses a stateless 
request-response binary protocol running over a TCP connection. This 
protocol is implemented with ocaml's native marshalling. The actual UI 
application has been written in Xcaml, my company's web application server.

The PLC kernel was developed in two days and debugged in a couple more. 
The web UI required about a man week. The low level driver required a 
couple of man weeks. We believe that no other computer language would 
have given us anything close to the results we achieved with Ocaml.

The conclusion: Ocaml is a mature industrial language. It's definitely 
not plain theory.

Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] embedded OCaml

[Brandon J. Van Every]

Alex Baretta wrote:
>
> >>We are working on a logical control framework based on
> >>Ocaml. We will
> >>release under the GPL when the API will have stabilized.
> >
> > How does a GPL license help anyone else in commercial
> > industry?  Or are
> > you going to do one of those "GPL or you can pay us" licenses?
>
> We currently develop the complete automation solution: PLC kernel,
> low-level hardware drivers, application logic. We are more
> than willing
> to share our technology with the Ocaml community in order to
> further the
> development of the core and enhance our ability to develop custom
> application logic at lightning speed.

Great... again, how is a GPL license workable for others with a
commercial interest in the technology?  I am saying that license is not
workable.

> The conclusion: Ocaml is a mature industrial language. It's
> definitely not plain theory.

I think I'd say "proven in this instance" rather than "mature."
Maturity has connotations of widespread usage and ready availablility of
software and programmers.  In OCaml-land, that's certainly work
remaining to be done.  I'm encouraged that I've been able to start a ML
SIG in Seattle, and one guy actually gets paid to use OCaml at his job,
but most don't.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

When no one else sells courage, supply and demand take hold.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] embedded OCaml

[Richard Jones]

On Mon, Jul 12, 2004 at 11:48:23AM -0700, Brandon J. Van Every wrote:
> Great... again, how is a GPL license workable for others with a
> commercial interest in the technology?  I am saying that license is not
> workable.

The GPL works fine in situations where you don't want a company to
steal you hard work for nothing, and the LGPL works fine in
circumstances where you will allow people to link to your work but you
also don't want them to steal it.  What is your point exactly?

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
Perl4Caml lets you use any Perl library in your type-safe Objective
CAML programs. http://www.merjis.com/developers/perl4caml/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] embedded OCaml

[Alex Baretta]

Richard Jones wrote:
> On Mon, Jul 12, 2004 at 11:48:23AM -0700, Brandon J. Van Every wrote:
> 
>>Great... again, how is a GPL license workable for others with a
>>commercial interest in the technology?  I am saying that license is not
>>workable.
> 
> 
> The GPL works fine in situations where you don't want a company to
> steal you hard work for nothing, and the LGPL works fine in
> circumstances where you will allow people to link to your work but you
> also don't want them to steal it.  What is your point exactly?
> 
> Rich.
> 

We are willing to allow other companies to use our code in their 
products, so long as they are willing to release such products to the 
community for mutual benefit. Essentially, anyone interested in using 
our technology has two alternatives:
1) invest time and programming resources to improve our technology (and 
release it under the GPL or not release it at all)
2) invest money into a consulting contract with us to help them develop 
their products, whereby we would improve the core technology and 
continue to release it under the GPL.

Overall, we've been in business for 20 months now, so we are no longer a 
newborn company. Our experience is significant, I think. We've been 
living by making GPLed software. Any code we release is covered by the 
GPL. We are still climbing the Himalayas of technology, so I can't say 
we are making cartloads of money, but we are making cartloads of 
technology while maintaining a non-negative cash-flow. We consider our 
results extremely pleasing. And, let this be noted, all our code is 
either written in Ocaml or in any one of a number of DSLs whose compiler 
we have written in Ocaml.

Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] embedded OCaml

[Brandon J. Van Every]

Preface: I am not here to argue which license is best.  I am here to
argue that different licenses have different consequences, and one
should be clear what one's business and community objectives are, before
picking a particular license.

Alex Baretta wrote:
> Richard Jones wrote:
> > Brandon J. Van Every wrote:
> >
> >>Great... again, how is a GPL license workable for others with a
> >>commercial interest in the technology?  I am saying that
> >>license is not workable.
> >
> >
> > The GPL works fine in situations where you don't want a company to
> > steal you hard work for nothing,

GPL is a two-edged sword.  Let's say you want to *receive* improvements
to your GPL code from the OCaml community.  Well, you can't just take
those mods and use them any way you like.  You are stuck with GPL.  The
minute I redistribute GPL code, I've got the same rights you do.  GPL is
the seed you propagated out into the world, and it's what you're going
to get back from the world.  If you actually want commercial freedom
when you receive community improvements, they can't be GPL.  You could
license under something less restrictive; MIT is one possibility among
many.  Or you coud put a "weasel" clause in your otherwise GPL code that
says, "This is GPL for you, but since we're the authors, you agree to
let us use your derivative works in any way *we* want."  Forced
/contrib, basically.

When a community understands what your license really is - whatever it
is - that affects what people in a community are willing to do with your
code.  I'd think hard about contributing to anyone's GPL project with a
"weasel" clause.  Let alone commercial enterprises, who are almost
entirely disinterested in GPL anything, due to the legal restrictions
and exposure.

> > and the LGPL works fine in
> > circumstances where you will allow people to link to your
> > work but you
> > also don't want them to steal it.  What is your point exactly?

LGPL *2.1* does not work so fine anymore.  LGPL 2.1 is much more
restrictive than 2.0.  It says that you must leave your proprietary code
in a form that allows other people to make arbitrary changes to the LGPL
licensed library.  If I want to insert a different square rooting
function, you have to allow me to do so.  In practice, this means you
have to ship your proprietary code as a pile of *.o files that can be
linked.  In commercial practice this is totally unacceptable to the vast
majority of vendors.

GPL and LGPL are really bad news as far as commercial entities are
concerned.  You have to be pretty deeply into Communistic open source
business models to be willing to deal with 'em.  Maybe Alex envisions
such a business model and GPL is indeed the correct choice for what his
company wants to do.  But I suspect he hasn't thought seriously about
what other commercial entities want / will tolerate.  If they won't
tolerate it, then releasing code as GPL is an academic exercise, as far
as commercial growth of OCaml is concerned.  Sure you offer GPL code...
nobody commercial wants to use it, so what does that get you except some
'feel good' with open source types?  I'm sure some academics could make
some R&D use of it, and that might be totally acceptable to them.  But
it's not, generally speaking, acceptable to commercial entities.

I won't preach alternate licenses.  I'll just mention that MIT is the
simplest alternate license, and point at OCaml's own license for a more
convoluted example of open-source-with-restrictions.

> We are willing to allow other companies to use our code in their
> products, so long as they are willing to release such products to the
> community for mutual benefit. Essentially, anyone interested in using
> our technology has two alternatives:
> 1) invest time and programming resources to improve our
> technology (and
> release it under the GPL or not release it at all)
> 2) invest money into a consulting contract with us to help
> them develop
> their products, whereby we would improve the core technology and
> continue to release it under the GPL.

3) say screw this, this isn't any use to us, we'll write our own
proprietary code.

If you can upsell (2) to mutual benefit, power to you.  I have serious
doubts that anybody's going to be interested in (1).

> Overall, we've been in business for 20 months now, so we are
> no longer a
> newborn company. Our experience is significant, I think. We've been
> living by making GPLed software. Any code we release is
> covered by the
> GPL. We are still climbing the Himalayas of technology, so I
> can't say
> we are making cartloads of money, but we are making cartloads of
> technology while maintaining a non-negative cash-flow. We
> consider our
> results extremely pleasing. And, let this be noted, all our code is
> either written in Ocaml or in any one of a number of DSLs
> whose compiler we have written in Ocaml.

Growing your business, and growing OCaml commercially for embedded
applications, aren't the same goal.  They might overlap, but I strongly
suspect that a GPL license will greatly interfere with the overlap.  You
might provide other vendors with proof-of-concept, however.  Other
vendors might say, "These guys proved you can do embedded stuff in
OCaml.  Now, their licensing is pretty restrictive, it's a nasty GPL, so
we're offering our own unencumbered source for $XXXXXXXX."


Cheers,                     www.indiegamedesign.com
Brand*n Van Every           S*attle, WA

"The pioneer is the one with the arrows in his back."
                          - anonymous entrepreneur

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] embedded OCaml

[Benjamin Geer]

Brandon J. Van Every wrote:
> GPL and LGPL are really bad news as far as commercial entities are
> concerned.

This is (a) nonsense, since plenty of companies rely on the GPL in order 
to make money, and (b) off-topic for this list.  Please don't subject us 
to yet another barrage of wildly misinformed anti-GPL FUD, least of all 
on caml-list.

Ben

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] embedded OCaml

[Brandon J. Van Every]

Benjamin Geer wrote:
> Brandon J. Van Every wrote:
> > GPL and LGPL are really bad news as far as commercial entities are
> > concerned.
>
> This is (a) nonsense, since plenty of companies rely on the
> GPL in order to make money,

Let's keep this concrete.  Show me OCaml companies making GPL money in
whatever application domain, or any-other-language companies making
making GPL money in embedded controllers.  Where's the business model
here?  Show me the money.  If GPL is working anywhere in the embedded
market, why does it work?  Why does it fail?  How has it impacted the
growth of a language community?

> and (b) off-topic for this list.  Please don't subject us
> to yet another barrage of wildly misinformed anti-GPL FUD,
> least of all on caml-list.

I can see that you didn't accept my Preface, and I surmise you feel
strongly about licensing issues.  I'm not going to back down about
discussing them in Alex's specific case, however.  This is about what
will grow OCaml in the embedded marketplace, and what won't.

Instead of arguing with you, Benjamin, I'd rather ask Alex:

- why have you opted against a more traditional proprietary license, for
$XXXXXX, that gives full closed source proprietary control to the
licensee?

- why have you opted against a MIT style license?

I'm interested in understanding your choices, not berating them.


Cheers,                         www.indiegamedesign.com
Brand*n Van Every               S*attle, WA

Praise Be to the caml-list Bayesian filter! It blesseth
my postings, it is evil crap!  evil crap!  evil crap!

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] embedded OCaml

[Damien Doligez]

On Jul 13, 2004, at 10:47, Brandon J. Van Every wrote:

> Preface: I am not here to argue which license is best.

Indeed, that would be totally off-topic for this list.

> I am here to
> argue that different licenses have different consequences, and one
> should be clear what one's business and community objectives are, 
> before
> picking a particular license.

And that is also totally off-topic for this list.  Please move this
discussion elsewhere, guys.

-- Damien

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] OCaml as business model

[Brandon J. Van Every]

Damien Doligez wrote:
> Brandon J. Van Every wrote:
>
> > I am here to
> > argue that different licenses have different consequences, and one
> > should be clear what one's business and community objectives are,
> > before picking a particular license.
>
> And that is also totally off-topic for this list.  Please move this
> discussion elsewhere, guys.

You don't deal with OCaml business, marketing, and strategic growth
issues on this list?  Where would you deal with them then?

Granted, other languages often have different lists to deal with these
sorts of practical business concerns.  But OCaml hasn't evolved to that
point.

Do you think nobody on this list should discuss how to popularize OCaml,
in any particular application domain?


Cheers,                         www.indiegamedesign.com
Brand*n Van Every               S*attle, WA

Praise Be to the caml-list Bayesian filter! It blesseth
my postings, it is evil crap!  evil crap!  evil crap!

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml as business model

[Richard Jones]

I think we should set up an ocaml-advocacy list on Yahoo Groups to
deal with these and other issues.  They are definitely off-topic and
unwanted on caml-list.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
MONOLITH is an advanced framework for writing web applications in C, easier
than using Perl & Java, much faster and smaller, reusable widget-based arch,
database-backed, discussion, chat, calendaring:
http://www.annexia.org/freeware/monolith/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] OCaml as business model

[Brandon J. Van Every]

Richard Jones wrote:
> 
> I think we should set up an ocaml-advocacy list on Yahoo Groups to
> deal with these and other issues.  They are definitely off-topic and
> unwanted on caml-list.

More productively, how about caml-biz?

You know, people who want to make money.


Cheers,                     www.indiegamedesign.com
Brand*n Van Every           S*attle, WA

"The pioneer is the one with the arrows in his back."
                          - anonymous entrepreneur

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml as business model

[Damien Doligez]

On Jul 13, 2004, at 11:56, Brandon J. Van Every wrote:

> You don't deal with OCaml business, marketing, and strategic growth
> issues on this list?  Where would you deal with them then?

Here, as long as they are OCaml-specific.  When they degenerate into
general-purpose arguments about the GPL, I don't want them in my
mailbox.

-- Damien

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] OCaml as business model

[Brandon J. Van Every]

Damien Doligez wrote:
> Brandon J. Van Every wrote:
>
> > You don't deal with OCaml business, marketing, and strategic growth
> > issues on this list?  Where would you deal with them then?
>
> Here, as long as they are OCaml-specific.  When they degenerate into
> general-purpose arguments about the GPL, I don't want them in my
> mailbox.

Ok, if that is the generally accepted criteria, I will attempt to
rephrase.  I wasn't exactly terse before, and that probably gets in the
way.  Here are the questions:

- What would make OCaml more popular in the commercial embedded market?
- How does *any* language gain popularity in the commercial embedded
market?
- is community contribution terribly relevant to this market?
- under what licensing schemes did community contributions actually
occur?
- did the company feel it strengthened their product?
- did the company make money and retain control over their product?
- did community interest grow or stagnate due to choices made?

I do not know any way to answer these questions without referencing
things other than OCaml.  If you want to learn from history, you have to
look at other people's efforts, and those are not OCaml efforts.


Cheers,                     www.indiegamedesign.com
Brand*n Van Every           S*attle, WA

When no one else sells courage, supply and demand take hold.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] embedded OCaml

[I R T]

"Brandon J. Van Every" <vanevery@indiegamedesign.com> writes:

> If you can upsell (2) to mutual benefit, power to you.  I have serious
> doubts that anybody's going to be interested in (1).

Isnt this the person who spends vast amounts of energy arguing that 
the implementation of ints should be changed ?

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] embedded OCaml

[Christophe TROESTLER]

On Mon, 12 Jul 2004, Alex Baretta <alex@baretta.com> wrote:
> 
> We are about to ship our first embedded ocaml application: an
> automatic glass cutting table. The PLC is 2Ghz Celeron with 256MB
> RAM, Linux 2.4 and Ocaml 3.07+2. It's just magnificent!

Maybe you could describe it a bit more so that it could be included on
the "applications" web page if the Caml Team feels like it?

Cheers,
ChriS

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] embedded OCaml

[Alex Baretta]

Christophe TROESTLER wrote:
> On Mon, 12 Jul 2004, Alex Baretta <alex@baretta.com> wrote:
> 
>>We are about to ship our first embedded ocaml application: an
>>automatic glass cutting table. The PLC is 2Ghz Celeron with 256MB
>>RAM, Linux 2.4 and Ocaml 3.07+2. It's just magnificent!
> 
> 
> Maybe you could describe it a bit more so that it could be included on
> the "applications" web page if the Caml Team feels like it?
> 
> Cheers,
> ChriS


I am presently too busy with the final integration phase of our first 
application (plc kernel, application logic, servodrives and actuators, 
mechanics). When we ship this we'll cook up an official release.

Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Tail calls (Was Re: [Caml-list] Does Caml have slow arithmetics ?)

[brogoff]

On Thu, 8 Jul 2004, Luc Maranget wrote:

> > On Thu, Jul 08, 2004 at 11:51:10AM +0200, Andreas Rossberg wrote:
> >
> > Many ocaml programs depend on tail-call elimination, although I don't
> > believe anything in the docs requires it to be done.
> >
>
> Well, when programming in caml, I use the following rules (which I hope to be
> accurate!)
>
> + ocamlc does perform tail call elimation
> + ocamlopt does it less often. Namely, calls in tail position
>   become real tail calls when all their arguments are passed in registers.
>   (This does not apply to self-tail calls which are always optimized)

In my own code the self tail call is by far more

   let rec loop params accum =
      if finished params accum then
         result params accum
      else
        loop (update_params params) (update_accum params accum)

is by far more the most common, so much so that that idiom is "under finger".
Usually params takes up one or two arguments. Anyone have good examples
where this limitation leads to significantly "uglier" code?

The limitation you describe should be well doumented, but is not yet annoying
to me. I'll need to write some tests and check the assembly output on the
Linux machines I have access to.

More annoying is the lack of some way to get the "tail recursion modulo cons"
capability directly in the language without needing to use Obj functionality.

-- Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: Tail calls (Was Re: [Caml-list] Does Caml have slow arithmetics ?)

[Richard Jones]

This discussion of tail calls is very interesting.

I understand what Xavier is saying about ocamlopt not optimizing badly
written code.  Despite this, I have to say that ocamlopt does a
fantastic job!

However, I think there is one bit of badly written code where it would
be nice if the compiler could do a little bit more optimization,
namely functions such as:

let rec input_all_lines chan =
  try
    let line = input_line chan in
    line :: input_all_lines chan
  with
      End_of_file -> []

The reason is that (as discussed previously, so please don't repost)
the tail-recursive version of this sort of code is quite a bit more
complicated, and therefore quite a bit harder to remember.

Note that the specific input_all_lines function should be in a library
- it is in ExtLib, I think.  However I use that code /pattern/ quite
frequently, particularly when iterating over something which can throw
a Not_found or End_of_file exception and building a structure from the
result.  So I need to remember the optimized version of the pattern,
which my poor brain can't do.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
MOD_CAML lets you run type-safe Objective CAML programs inside the Apache
webserver. http://www.merjis.com/developers/mod_caml/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: Tail calls (Was Re: [Caml-list] Does Caml have slow arithmetics ?)

[Xavier Leroy]

> Many ocaml programs depend on tail-call elimination, although I don't
> believe anything in the docs requires it to be done.

Just for the record, here is the exact situation regarding tail-call
elimination in OCaml.  It is performed in any of the following
situations:

1- Compilation to bytecode (with ocamlc).
2- When the function being tail-called is the current function
   (tail recursion).
3- When the function being tail-called has no more than N arguments,
   keeping in mind that a function with free variables has one extra
   hidden argument representing its environment.

Here, N is a constant that depend on the target processor: it's 6 for
the Intel x86, and 10 or more for the other supported processors.
This constant is the number of processor registers used for parameter
passing.  The tail-call issue appears when extra parameters need to be
passed on stack.

In other words, the only case where tail-call elimination isn't
performed is: native-code compilation, more than N arguments, and the
function being tail-called is not the current function.

Before case 2 (tail call to self) was implemented, we often received
problem reports from x86 users.  Since the addition of case 2, we
haven't received any.  This makes me suspect that the lack of
tail-call elimination in the situation described above isn't that much
of a problem in practice.

Proper elimination of tail calls in ocamlopt in all cases is feasible
but requires a bit of work.  In particular, the current code
generation convention "caller deallocates stack-allocated arguments"
must be changed to "callee deallocates stack-allocated arguments".
Also, some stack manipulations are needed that would make tail-calls
slightly more expensive (in time) than regular calls.

- Xavier Leroy

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: Tail calls (Was Re: [Caml-list] Does Caml have slow arithmetics ?)

[skaller]

On Tue, 2004-07-13 at 03:07, Xavier Leroy wrote:

> 2- When the function being tail-called is the current function
>    (tail recursion).
> 3- When the function being tail-called has no more than N arguments,
>    keeping in mind that a function with free variables has one extra
>    hidden argument representing its environment.

> Proper elimination of tail calls in ocamlopt in all cases is feasible
> but requires a bit of work.

Can you comment on the effect of -inline switch and inlining in general?

If you have 

let rec f a1 a2 a3 a4 ... = 
  let g b1 b2 ... = f b2 b2 ... in
  g a1 a2 ...

we have situation where the tail call in g isn't to g
but to its parent f .. however this is an obvious candidate
for inlining, and if we inline g into the body of f,
then the tail call is to f, which is itself, which might
then be tail-call optimised .. yes?

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: Tail calls (Was Re: [Caml-list] Does Caml have slow arithmetics ?)

[Xavier Leroy]

> Can you comment on the effect of -inline switch and inlining in general?
> 
> If you have 
> 
> let rec f a1 a2 a3 a4 ... = 
>   let g b1 b2 ... = f b2 b2 ... in
>   g a1 a2 ...
> 
> we have situation where the tail call in g isn't to g
> but to its parent f .. however this is an obvious candidate
> for inlining, and if we inline g into the body of f,
> then the tail call is to f, which is itself, which might
> then be tail-call optimised .. yes?

Yes.  Tail-call elimination is performed after inlining.

- Xavier Leroy

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[Brian Hurt]

On Thu, 8 Jul 2004, Andreas Rossberg wrote:

> David Brown wrote:
> > 
> > In some functional languages (Scheme, specifically), tail recursion is
> > required to be implemented iteratively.  It is a common enough idiom,
> > and easy enough to implement, that it is generally done in functional
> > languages.  In fact, gcc does it in C, with enough optimization.
> 
> The latter is, to a certain extent, a myth.
> 
> First, you have to distinguish between simple tail *recursion*, and the 
> much more general concept of tail *call*. I believe Scheme requires to 
> fully optimize the latter, and so it is done by all decent FPL 
> implementations. GCC does not do that, already falling short of mutually 
> recursive functions, IIRC.

GCC has started optimizing tail calls in 3.x.  

I compiled:

int fib(int a, int b, int n) {
    if (n <= 1) {
        return b;
    } else {
        return fib(b, a+b, n-1);
    }
}

with gcc 3.2.2 -O2, and got:

.globl fib
        .type   fib,@function
fib:
        pushl   %ebp
        movl    %esp, %ebp
        movl    12(%ebp), %ecx
        pushl   %ebx
        movl    16(%ebp), %edx
        movl    8(%ebp), %ebx
        .p2align 2,,3
.L4:
        cmpl    $1, %edx
        jle     .L5
        leal    (%ecx,%ebx), %eax
        decl    %edx
        movl    %ecx, %ebx
        movl    %eax, %ecx
        jmp     .L4
.L5:
        movl    %ecx, %eax
        popl    %ebx
        leave
        ret

Notice that it's turned the tail call recursion into a loop.  I don't 
recall it doing this back in 2.95 or 2.96, so it's a pretty recent 
improvement, but it does now exist.

What it's limits are, I haven't determined, but it does exist.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[Alex Baretta]

skaller wrote:

> BTW: there is another answer to the question Xavier asked:
> 
> Q: why did you write the code that way ..?
> A: I didn't, it was generated..
> 
> which suggests sometimes there is a reason to optimise
> 'silly' looking code.
> 

We use a lot of generated code, but we try to preoptimize it to 
"cute-looking", if not really efficient.

Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[Jon Harrop]

On Wednesday 07 July 2004 15:58, Xavier Leroy wrote:
> ... In your "f" function, you asked for the
> construction of a pair, and you get that pair construction in
> ocamlopt's output.  If you didn't want the pair to be constructed, why
> did you write "f" this way?

Funny you should say that. I've only recently been trying my hand at such 
low-level optimisations in OCaml and, to my surprise, I'm terrible at it (no 
comments, please!).

Specifically, I recalled a post that ocamlopt doesn't do CSE. On the basis of 
this I thought that I could optimise my original code:

      let pivot = (first + last)/2 in
      let sum1=helper (scale+1) (2*entry) first pivot in
      let sum2=helper (scale+1) (2*entry+1) pivot last in
      Array.unsafe_set data2 entry (sum1 -. sum2);
      sum1 +. sum2

by performing some CSE manually, for example:

      let pivot = (first + last)/2 in
      let (sum1, sum2) =
        let scale=scale+1 and entry=2*entry in
        (helper scale entry first pivot, helper scale (entry+1) pivot last)
      in
      Array.unsafe_set data2 entry (sum1 -. sum2);
      sum1 +. sum2

I also tried applying part of the arguments to Array.set to avoid the creation 
of a pair:

      let pivot = (first + last)/2 in
      let set=Array.unsafe_set data2 entry in
      let scale=scale+1 and entry=2*entry in
      let sum1=helper scale entry first pivot in
      let sum2=helper scale (entry+1) pivot last in
      set (sum1 -. sum2);
      sum1 +. sum2

Contrary to my expectations, these revised versions are 30 and 70% slower than 
the original, respectively. In the first case, this is presumably because 
ocamlopt is building the pair which I asked for but don't want. In the second 
case, "set" appears to be very expensive to create and/or apply (forgive my 
avoiding the word "closure" - I'm still not confident that I know its precise 
meaning).

So, in order to optimise OCaml code in this much detail, I guess I need some 
quantifications of the relative costs of such "primitive" operations. Has 
anyone documented this and can anyone give me some hints?

From Evgeny Chukreev's post I'm guessing that constructing any data 
structures, even pairs, can be very costly because it invokes the GC which 
(always?) does a minor collection. Can partially applied functions be more 
efficient if they are applied many times?

(For anyone who's interested, bounds checking only slows this array-intensive 
code down by 9%)

Cheers,
Jon.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Does Caml have slow arithmetics ?

[Jacques GARRIGUE]

From: Jon Harrop <postmaster@jdh30.plus.com>

> Funny you should say that. I've only recently been trying my hand at such 
> low-level optimisations in OCaml and, to my surprise, I'm terrible at it (no 
> comments, please!).
> 
> Specifically, I recalled a post that ocamlopt doesn't do CSE. On the basis of 
> this I thought that I could optimise my original code:
> 
>       let pivot = (first + last)/2 in
>       let sum1=helper (scale+1) (2*entry) first pivot in
>       let sum2=helper (scale+1) (2*entry+1) pivot last in
>       Array.unsafe_set data2 entry (sum1 -. sum2);
>       sum1 +. sum2
> 
> by performing some CSE manually, for example:
> 
>       let pivot = (first + last)/2 in
>       let (sum1, sum2) =
>         let scale=scale+1 and entry=2*entry in
>         (helper scale entry first pivot, helper scale (entry+1) pivot last)
>       in
>       Array.unsafe_set data2 entry (sum1 -. sum2);
>       sum1 +. sum2

Interesting.
Actually, I suppose that this kind of situation could be optimized,
by working at the Clambda level. This is a bit unfortunate, as most
"non-local" optimizations are expected to be done at earlier stages,
but would be necessary to cope with inlining too.

Yet, in this example sharing the computation for scale and entry is
useless: addition and multiplication by a power of 2 cost virtually
nothing anyway.

> I also tried applying part of the arguments to Array.set to avoid
> the creation of a pair:
> 
>       let pivot = (first + last)/2 in
>       let set=Array.unsafe_set data2 entry in
>       let scale=scale+1 and entry=2*entry in
>       let sum1=helper scale entry first pivot in
>       let sum2=helper scale (entry+1) pivot last in
>       set (sum1 -. sum2);
>       sum1 +. sum2
> 
> Contrary to my expectations, these revised versions are 30 and 70%
> slower than the original, respectively.

This is a well-known behaviour, building the closure "set" is costly
for two reasons: a data structure holding it must be allocated
(causing eventually GC), and calls through a closure cost more than
direct ones (particularly if the "helper" function is known.)
In your case, there is even a 3rd reason: unsafe_set is not a real
function, but a primitive, which just generates the operations to
modify an array. By wrapping it in set, you make it a function.
And for some reason, ocamlopt does not inline set, leaving you with a
function call where there should have been none.

You may look at an abstraction of the code generated with the -cmm
option. For the above code it gives you:

(data
 int 3319
 "camlPivot__2":
 addr "caml_curry3"
 int 7
 addr "camlPivot__fun_75")

(function camlPivot__fun_75 (prim/73: addr prim/72: addr prim/71: addr)
 (if (!= (load unsigned int8 (+a prim/73 -4)) 254)
   (extcall "caml_modify" (+a (+a prim/73 (<< prim/72 1)) -2) prim/71 unit)
   (store float64u (+a (+a prim/73 (<< prim/72 2)) -4)
     (load float64u prim/71)))
 1a)

(function camlPivot__pivot_57
     (first/58: addr last/59: addr data2/60: addr entry/61: addr
      scale/62: addr helper/63: addr)
 (let
   (pivot/64 (+ (<< (/ (>>s (+ (+ first/58 last/59) -1) 1) 2) 1) 1)
    set/65 (app "caml_apply2" data2/60 entry/61 "camlPivot__2" addr)
    scale/66 (+ scale/62 2) entry/67 (+ (* 4 (>>s entry/61 1)) 1)
    sum1/68
      (app "caml_apply4" scale/66 entry/67 first/58 pivot/64 helper/63 addr)
    sum2/69
      (app "caml_apply4" scale/66 (+ entry/67 2) pivot/64 last/59 helper/63
        addr))
   (app (load set/65)
     (alloc 2301 (-f (load float64u sum1/68) (load float64u sum2/69))) set/65
     unit)
   (alloc 2301 (+f (load float64u sum1/68) (load float64u sum2/69)))))

You can even see another problem here: the function call to set requires
wrapping your float into a heap value, which introduces yet another
inneficiency.

Jacques Garrigue

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners