Version française
Home     About     Download     Resources     Contact us    
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: -- (:)
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
.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