Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Why + vs +. but "fake" parametric polymorphism for <
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2006-10-12 (05:41)
From: Carlos Pita <cpitadev@y...>
Subject: Re: [Caml-list] Why + vs +. but "fake" parametric polymorphism for <
Umh, soon after writing my previous post I found out an interesting
chapter in the tutorial giving an exact example of asm code generated by
the compiler for comparison operator <:

# let max a b =
  if a > b then a else b;;
val max : 'a -> 'a -> 'a = <fun>

        ; Call the C "greaterthan" function (in the OCaml library).
        pushl   %ebx
        pushl   %eax
        movl    $greaterthan, %eax
        call    caml_c_call
        addl    $8, %esp
        ; If the C "greaterthan" function returned 1, jump to .L100

Pretty expensive for a simple int comparison I would say. Which is the
way to go? I bet for-loops are optimized for int arithmetic/comparisons,
aren't they?

Thank you again.

On Thu, 2006-10-12 at 02:19 -0300, Carlos Pita wrote:
> Hi all!
> I would like to implement some number crunching inner loops for dsp
> stuff with ocaml. I'm a newcomer to the language with strong
> scheme/python background and trying to come into terms with type
> inference, parametric polymorphism and structural subtyping. One thing
> than I'm pretty fond of is the difference between floating point and
> integer basic mathematical operators. I guess the compiler is able to
> generate specific and more efficient code for each case without further
> analysis. But then I found out that comparison operators offer some kind
> of adhoc polymorphism in the guise of parametric one:
> # (<);;
> - : 'a -> 'a -> bool = <fun>
> Is there any reason for this apparently inconsistent design? Would the
> generality of < be against performance if for example, say, my critical
> inner loops check against a top limit value thousands of times per
> second? I'm afraid that the implementation of such a generic operator,
> which is so different for numerical integer comparison than for
> string lexicographical comparison, would incur into some run time
> overhead. But, as I've said at the beginning, I'm just a newbie and most
> probably there is a coherent explanation for all this confusion.
> Thank you in advance.
> Best regards,
> Carlos
> __________________________________________________
> Pregunt. Respond. Descubr.
> Todo lo que queras saber, y lo que ni imaginabas,
> est en Yahoo! Respuestas (Beta).
> Probalo ya! 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> Archives:
> Beginner's list:
> Bug reports:

Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!