caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Carlos Pita <cpitadev@yahoo.com.ar>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Why + vs +. but "fake" parametric polymorphism for <
Date: Thu, 12 Oct 2006 02:41:20 -0300	[thread overview]
Message-ID: <1160631680.7649.27.camel@monad> (raw)
In-Reply-To: <1160630365.7649.20.camel@monad>

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


  reply	other threads:[~2006-10-12  5:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-12  5:19 Carlos Pita
2006-10-12  5:41 ` Carlos Pita [this message]
2006-10-12  5:49   ` [Caml-list] " 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
2006-10-12  5:45 ` [Caml-list] " Jacques Garrigue
2006-10-12  5:58   ` Carlos Pita
2006-10-12  6:08     ` Jonathan Roewen
     [not found]       ` <452DF46C.802@fmf.uni-lj.si>
2006-10-12 14:26         ` Carlos Pita
2006-10-13 11:56       ` Diego Olivier FERNANDEZ PONS
2006-10-13 12:14         ` Gerd Stolpmann
2006-10-13 12:46           ` Diego Olivier FERNANDEZ PONS
2006-10-13 13:01             ` Luc Maranget
2006-10-13 13:15               ` Diego Olivier FERNANDEZ PONS
2006-10-13 13:15               ` skaller
2006-10-13 13:36                 ` Luc Maranget
2006-10-13 13:53             ` Gerd Stolpmann
2006-10-13 14:16               ` Luc Maranget

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1160631680.7649.27.camel@monad \
    --to=cpitadev@yahoo.com.ar \
    --cc=caml-list@yquem.inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).