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 UAA21394; Mon, 22 Jul 2002 20:08:37 +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 UAA21229 for ; Mon, 22 Jul 2002 20:08:35 +0200 (MET DST) Received: from slave-dog.naughtydog.com (naughtydog200.brandx.net [209.55.75.200]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g6MI8X120557 for ; Mon, 22 Jul 2002 20:08:33 +0200 (MET DST) Received: from SMTP agent by mail gateway Mon, 22 Jul 2002 11:22:43 -0800 Received: from happydog (happy-dog.naughtydog.com [10.0.0.99]) by slave-dog.naughtydog.com (SGI-8.9.3/8.9.3) with SMTP id LAA42722; Mon, 22 Jul 2002 11:22:32 -0700 (PDT) From: "Pal-Kristian Engstad" To: "William Chesters" Cc: "Caml-List@Inria.Fr" Subject: RE: [Caml-list] Caml productivity. Date: Mon, 22 Jul 2002 11:22:32 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <15673.32452.130587.498649@beertje.william.bogus> Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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? Now, I am not saying that C or C++ is inherently that much better. Even gcc's inline syntax is really awkward in practice. But I would love to see a superior system in ocaml! So, what is needed in order to support inline assembly in ocaml? Is it at all possible? 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) PKE. -----Original Message----- From: owner-caml-list@pauillac.inria.fr [mailto:owner-caml-list@pauillac.inria.fr]On Behalf Of William Chesters Sent: Saturday, July 20, 2002 8:16 AM To: caml-list@inria.fr Subject: [Caml-list] Caml productivity. Pal-Kristian Engstad writes: > Some proponents of this mailing list seem to be > convinced that Ocaml is so much more productive than > C++. I find this to be a terrible mistake. From an > industry where performance is crucial (games > programming), I find quite a few aspects of Ocaml hard > to unify with productivity. You are saying that for some tasks the superior productivity of ocaml, in terms of development time, is irrelevant because you cannot achieve the required level of performance. I (myself, personally) thought your mail contained several misconceptions about ocaml. I work with C++ in HPC, and I've played with a variety of different languages and coding idioms; I have to say that ocaml is generally quite competitive with "general purpose" C and Fortran compilers, if you write your inner loops in a Fortran style. ocaml will lose in some cases against serious Fortran compilers that do heavyweight HPC optimisations, but as far as I know very few C++ compilers have that capability (Intel's?). And for some tasks the superior performance of Fortran is irrelevant because you cannot achieve the required level of productivity :-P. ocaml also loses performances as soon as you start trying to put nice abstraction features in the inner loops. This is disappointing but not specific to ocaml: templated inner loops in C++ are fast if they only use scalars, but loops involving e.g. lightweight objects as "iterators" are not, unless you are using the KAI compiler. (Which has just been bought up and killed off by Intel, grrr. KAI was way ahead of its time; it really made it possible to write incredibly "high level" C++ and get fast code out the back. I wish all that effort had been done in a university, put into a more sensible language, and liberated so that nobody could take it away :( .) I don't agree that the lack of operator overloading is a problem, per se. If you follow the argument (passim ad nauseam in the archives) you eventually reach the conclusion that the real problem is that the compiler doesn't inline across module boundaries---and that _is_ serious. If access to machine-specific instructions is a problem, then ocaml isn't the right tool. Of course, if your uses of them occur in library routines which can naturally be written in C, then you don't have a problem. In short, ocaml is really not so bad for high performance, provided that you take care to write your inner loops in a "dumb" way and save the nice language features for the rest of the code (and you have to do that anyway, although maybe not so stringently, with C++). ------------------- 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 ------------------- 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