* Why + vs +. but "fake" parametric polymorphism for <
@ 2006-10-12 5:19 Carlos Pita
2006-10-12 5:41 ` [Caml-list] " Carlos Pita
0 siblings, 1 reply; 6+ messages in thread
From: Carlos Pita @ 2006-10-12 5:19 UTC (permalink / raw)
To: caml-list
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.
Thank you in advance.
Best regards,
Carlos
__________________________________________________
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Caml-list] Why + vs +. but "fake" parametric polymorphism for <
2006-10-12 5:19 Why + vs +. but "fake" parametric polymorphism for < Carlos Pita
@ 2006-10-12 5:41 ` Carlos Pita
2006-10-12 5:49 ` Basile STARYNKEVITCH
2006-10-12 5:53 ` Jonathan Roewen
0 siblings, 2 replies; 6+ messages in thread
From: Carlos Pita @ 2006-10-12 5:41 UTC (permalink / raw)
To: caml-list
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:
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.
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.
>
> 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!
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Caml-list] Why + vs +. but "fake" parametric polymorphism for <
2006-10-12 5:41 ` [Caml-list] " Carlos Pita
@ 2006-10-12 5:49 ` Basile STARYNKEVITCH
2006-10-12 5:53 ` Jonathan Roewen
1 sibling, 0 replies; 6+ messages in thread
From: Basile STARYNKEVITCH @ 2006-10-12 5:49 UTC (permalink / raw)
To: Carlos Pita; +Cc: caml-list
Le Thu, Oct 12, 2006 at 02:41:20AM -0300, Carlos Pita écrivait/wrote:
> 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:
> addl $8, %esp
> ; If the C "greaterthan" function returned 1, jump to .L100
> [...]
>
> Pretty expensive for a simple int comparison I would say.
If you explicitly type it as an integer compare
let max (a : int) b = if a > b then a else b;;
you get much more efficient code (AMD64 linux ocaml 3.09.2 Debian/Sid)
.globl camlMaxi__max_57
camlMaxi__max_57:
.L101:
cmpq %rbx, %rax
jle .L100
ret
.align 4
.L100:
movq %rbx, %rax
ret
.text
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net
aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net
8, rue de la Faïencerie, 92340 Bourg La Reine, France
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Caml-list] Why + vs +. but "fake" parametric polymorphism for <
2006-10-12 5:41 ` [Caml-list] " Carlos Pita
2006-10-12 5:49 ` Basile STARYNKEVITCH
@ 2006-10-12 5:53 ` Jonathan Roewen
2006-10-12 6:10 ` Carlos Pita
1 sibling, 1 reply; 6+ messages in thread
From: Jonathan Roewen @ 2006-10-12 5:53 UTC (permalink / raw)
To: Carlos Pita; +Cc: caml-list
On 10/12/06, Carlos Pita <cpitadev@yahoo.com.ar> wrote:
> 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:
> addl $8, %esp
> ; If the C "greaterthan" function returned 1, jump to .L100
> [...]
>
> Pretty expensive for a simple int comparison I would say.
It is not an int comparison! max here would work on lists and probably
most other non-abstract types in expected ways.
Try:
let int_max a b : int = if a > b then a else b
ocamlopt -S <source> will help you see what it generates for yourself.
e.g.:
camlTest__int_max_57:
.L101:
cmpl %ebx, %eax
jle .L100
ret
.align 16
.L100:
movl %ebx, %eax
ret
.text
.align 16
Jonathan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Caml-list] Why + vs +. but "fake" parametric polymorphism for <
2006-10-12 5:53 ` Jonathan Roewen
@ 2006-10-12 6:10 ` Carlos Pita
0 siblings, 0 replies; 6+ messages in thread
From: Carlos Pita @ 2006-10-12 6:10 UTC (permalink / raw)
To: Jonathan Roewen; +Cc: caml-list
> > Pretty expensive for a simple int comparison I would say.
>
> It is not an int comparison!
Ok, I meant it would put much of a burden on performance in case max was
called with mere unboxed int arguments.
> Try:
>
> let int_max a b : int = if a > b then a else b
Great! It's crystal clear now. Thank you all!
__________________________________________________
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Why + vs +. but "fake" parametric polymorphism for <
@ 2006-10-12 5:18 Carlos Pita
0 siblings, 0 replies; 6+ messages in thread
From: Carlos Pita @ 2006-10-12 5:18 UTC (permalink / raw)
To: caml-list
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.
Thank you in advance.
Best regards,
Carlos
__________________________________________________
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-10-12 6:10 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-10-12 5:19 Why + vs +. but "fake" parametric polymorphism for < Carlos Pita
2006-10-12 5:41 ` [Caml-list] " Carlos Pita
2006-10-12 5:49 ` Basile STARYNKEVITCH
2006-10-12 5:53 ` Jonathan Roewen
2006-10-12 6:10 ` Carlos Pita
-- strict thread matches above, loose matches on Subject: below --
2006-10-12 5:18 Carlos Pita
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).