From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id EAA27166; Tue, 23 Jul 2002 04:08:41 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id EAA27112 for ; Tue, 23 Jul 2002 04:08:39 +0200 (MET DST) Received: from imo-r09.mx.aol.com (imo-r09.mx.aol.com [152.163.225.105]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g6N28c102475 for ; Tue, 23 Jul 2002 04:08:39 +0200 (MET DST) Received: from artboreb@netscape.net by imo-r09.mx.aol.com (mail_out_v32.21.) id y.1b6.102e860 (16215); Mon, 22 Jul 2002 22:08:34 -0400 (EDT) Received: from netscape.net (mow-m30.webmail.aol.com [64.12.137.7]) by air-in01.mx.aol.com (v86_r1.16) with ESMTP id MAILININ13-0722220834; Mon, 22 Jul 2002 22:08:34 -0400 Date: Mon, 22 Jul 2002 22:08:34 -0400 From: artboreb@netscape.net (Arturo Borquez) To: engstad@naughtydog.com ("Pal-Kristian Engstad") Cc: caml-list@inria.fr Subject: RE: [Caml-list] Caml productivity. Message-ID: <2BCE32EB.10F639F9.00958B05@netscape.net> X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk "Pal-Kristian Engstad" wrote: >I am also quite surprised by ocaml's speed. It's doing quite well on a lot >of platforms. And I would concur that it does quite well when compared to C >and Fortran. However, that is not quite enough. For me, it isn't enough that >the compiler is doing a decent job. I want to have the capability to make >the code even better. To do that, one needs to be able to make use of the >hardware, i.e. get down to the bare bones of your platform. Yes, it will >mean that you are giving up portability. Yes, it might be "unsafe", but then >again, why are there unsafe set and get operations for arrays in ocaml? > .... OCaml not too bad? If you want more I suggest to compile with ocamlopt with the switch -S (keep intermediate assembly source output) and take a look. Maybe you'll find the way to strip out some cpu cycles, or maybe you have a better 'faster' GC system. >Imagine that there is a special LZWC instruction that counts the number of >leading zeroes in a 64-bit word. I would love to be able to write >something >like: > >let lzc (x:int64) = inline >regs res : int32 of (** Work registers **) >lzwc res, x (** Opcodes sent to the assembler **) >return res (** result of the computation **) >let main = > Printf.printf "lzc %d = %d\n" 12 (lzc 12) > You can do such thing in OCaml calling a 'C' function, I don't see where is the problem, even more inside 'C' functions you can code inline assembler. So you can build your own critical time massive cpu crunching code that way and use OCaml on the top (where C is bad) -- Arturo Borquez __________________________________________________________________ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners