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

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 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
.L102:
[...]

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.
Regards,
Carlos

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 v.gr 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.
>
> Best regards,
> Carlos
>
>
>
>
>
>
>
> __________________________________________________
> Pregunt. Respond. Descubr.
> Todo lo que queras saber, y lo que ni imaginabas,
> est en Yahoo! Respuestas (Beta).
> Probalo ya!
> http://www.yahoo.com.ar/respuestas
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

```