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 RAA28596; Fri, 18 Jun 2004 17:33:18 +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 RAA28585 for ; Fri, 18 Jun 2004 17:33:17 +0200 (MET DST) Received: from herd.plethora.net (herd.plethora.net [205.166.146.1]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i5IFXFSH017894 for ; Fri, 18 Jun 2004 17:33:16 +0200 Received: from bhurt.plethora.net (bhurt.plethora.net [205.166.146.49]) by herd.plethora.net (8.11.6/8.10.1) with ESMTP id i5IFX6i10985; Fri, 18 Jun 2004 10:33:06 -0500 (CDT) Date: Fri, 18 Jun 2004 10:38:45 -0500 (CDT) From: Brian Hurt X-X-Sender: bhurt@localhost.localdomain To: Ville-Pertti Keinonen cc: Ocaml Mailing List Subject: Re: [Caml-list] Great Programming Language Shootout Revived In-Reply-To: <06D9583C-C0FD-11D8-8AC7-000393863F70@exomi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Miltered: at concorde with ID 40D30B3B.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 shootout:01 shootout:01 misleading:01 implemented:01 fibonacci:01 slower:01 unroll:01 unrolling:01 unrolling:01 doable:01 compiler:01 compiler:01 anyhow:01 debug:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Fri, 18 Jun 2004, Ville-Pertti Keinonen wrote: > Anyhow, the shootout seems, like most benchmarks, to be misleading and > arbitrary. The language features compared are not really equivalent. > E.g. C, C++ and Ada should be approximately the same in performance for > code that doesn't compare their libraries or exception models. Despite > doing things like disabling array index checks, it seems some of the > Ada benchmarks don't even use types equivalent to the C versions. I agree. Even worse, the majority exercise only small amounts of the language. The tests array accesses, exception handling, method calls, nested loops, object instantiations, and string concatenation all explicitly test specific operations- with no regard for how often those options are actually implemented. Take, for example, exception handling. The C version of this code uses setjmp()/longjmp(). Two functions which are rarely actually used in C code- the standard language pattern is to return an error code instead. And other tests- notably ackerman's function and fibonacci numbers, are mainly dependent upon a similiarly small set of features (mainly speed of function calls). "Artificial" doesn't begin to cover it. As a side note, there is a reason why C++ is slower than C, even if you're compiling the exact same code. C++ functions need to be able to handle exceptions and unroll the stack, even if the function itself doesn't throw or catch exceptions. Even if unrolling the stack is a no-op, the function generally needs to be able to both be handed off from another function's stack unrolling, and hand off to another function's stack unrolling. To remove this cost, the compiler needs to do a full program analysis, and basically detect "wait- you could compile this code with a C compiler, so I will compile this code with a C compiler!" While this may be doable in theory, it's not going to happen in the real world. Which raises another point. Many languages, and C++ and Ocaml both qualify, have "preferred" styles of programming, even if they admit other styles. For example, Ocaml "prefers" functional programming, it's the default style, even as it allows imperitive and OO programming constructs. C++ "prefers" a template/OO style of coding, even as it admits C as (basically) a proper subset. If I were to sit down and start writting an application in Ocaml, 99% or more of it would be in a functional style. How fast Ocaml is in imperitive or OO would not likely be all that important to the overall performance of my application. Likewise, were I to write an application in C++, it's use templates, classes, virtual methods, etc. If I wanted to write the application in C, I'd write it in C, not C++ and not Ocaml. Even if they involve a performance hit, they have other advantages (easier to write/debug code in, easier to use more advanced data structures, etc.). This then raises the question of how much performance am I sacrificing for this increased power at the high level? Plus there's the whole efficiency in the small vr.s efficiency in the large issue I mentioned earlier. The GPLS measures almost entirely efficiency in the small. Which isn't necessarily bad, just that it doesn't necessarily map to larger projects. -- "Usenet is like a herd of performing elephants with diarrhea -- massive, difficult to redirect, awe-inspiring, entertaining, and a source of mind-boggling amounts of excrement when you least expect it." - Gene Spafford Brian ------------------- 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