From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id BE570BC88 for ; Mon, 7 Feb 2005 07:16:06 +0100 (CET) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j176G6BX023572 for ; Mon, 7 Feb 2005 07:16:06 +0100 Received: by rproxy.gmail.com with SMTP id a41so1179611rng for ; Sun, 06 Feb 2005 22:16:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=nOVKjyYYOAo6RpjCBi7V0xU73Iv+aaK+MSG0OUbEYG1JLJ+YXoEzRssaA/Q9ZM9oR1GGT/5LauWdkGu+5l3Lny6T3UG48RhzxTzPeVAzhQvcuGRfqFW8V7ZEDxwdbNpRceYmVkWwV3DK+C6MXAyPAftBlKa8bSlAMa59gzBIxCw= Received: by 10.38.13.63 with SMTP id 63mr208819rnm; Sun, 06 Feb 2005 22:16:05 -0800 (PST) Received: by 10.38.86.80 with HTTP; Sun, 6 Feb 2005 22:16:05 -0800 (PST) Message-ID: <877e9a17050206221653d14456@mail.gmail.com> Date: Mon, 7 Feb 2005 01:16:05 -0500 From: Michael Walter Reply-To: Michael Walter To: Brian Hurt Subject: Re: [Caml-list] The boon of static type checking Cc: skaller , Jon , caml-list@yquem.inria.fr In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1107741266.6363.362.camel@pelican.wigram> X-Miltered: at nez-perce with ID 420707A6.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 wrote:01 ocamlopt:01 gcc:01 ocaml:01 gcc:01 ocaml:01 imho:01 garbage:01 garbage:01 subsystems:01 unboxing:01 reuse:01 optimising:01 inlining:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_BY_IP autolearn=disabled version=3.0.2 X-Spam-Level: On Sun, 6 Feb 2005 23:34:02 -0600 (CST), Brian Hurt wrote: > Probably a bad idea, but I've got to jump in here. > > Full disclosure: I *hate* C++. Mainly because I've actually written real > programs in it. The next time I have to use C++ in any sort of serious > way I'm registering c++sucks.com and starting a website to catalog all the > different ways C++ sucks. Feel free to stop reading at this point. :-) > ... > > g++ seems to generate better > > code than ocamlopt for similar simple problems > > (see Alioth for quantitative evidence given silly > > set of sample 'problems') > > Yep. And, conservatively, 10 times as much effort has gone into the gcc > optimizer as the Ocaml optimizer. Possibly 100 times. For, according to > Alioth, about a 10% improvement. It's only with gcc 3.x that C++ managed > to beat Ocaml on performance. More effort having gone into gcc and better performance of gcc are arguments pro gcc, right? ;-) > > IMHO the single major inefficiency in C++ is also a source > > of efficiency -- lack of a garbage collector. > > It's a source of efficiency on the small scale- it's easy to write a 1,000 > line program with hand allocation. Rather harder to write a 10,000 line > program, and a major bitch to write a 100,000 line program without garbage > collection. Personally I like it that in C++ you actually have the choice to use appropriate garbage collection schemes when you desire to do (yep, multiple kind of GCs for different subsystems/data/... is a win). Makes it easier with > 1,000,000 line programs :-) > > OTOH Ocaml has a massive inefficiency C++ does not, > > namely boxing, and ocaml tools currently do not > > seem to be very good at unboxing. > > This is also a big efficiency for Ocaml, for two reasons. First, it > encourages code reuse. Second, Ocaml only needs one implementation of a > function for all types. C++'s template system, to unbox everything, > duplicates code like crazy- generally, a new implementation for every > type. Very true. Technically this would not be very difficult in C++, though. There's a certain trade off you have to make for either way. > > Again, C++ provides inline functions which > > provide a way Ocaml does not have so easily > > for optimising. > > Don't assume that inlining is optimization. Actually, it generally isn't. > Having actually timed it on modern hardware, a function call costs like > 2-3 clock cycles these days. Plus 1-2 clock cycles per argument. This is > compared to the 10-30 clock cycles a mispredicted branch costs, the 20+ > clock cycles an L1 cache miss/L2 cache hit costs, and the 100-350+ clock > cycles of an L2 cache miss/memory fetch. Inlining for very small functions generally is an optimization. > What little inlining is a good idea can be done by the compiler, Yep, usually the "inline when appropriate" compiler switch + something like__forceinline for very small functions (for paranoia reasons) seems to be the way to go in my experience. Michael