From owner-freebsd-chat@FreeBSD.ORG Sat Apr 22 15:12:02 2006 Return-Path: X-Original-To: freebsd-chat@freebsd.org Delivered-To: freebsd-chat@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16A5216A50B for ; Sat, 22 Apr 2006 15:12:02 +0000 (UTC) (envelope-from strick@covad.net) Received: from mail874.megamailservers.com (mail874.carrierinternetsolutions.com [69.49.106.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D86E43D46 for ; Sat, 22 Apr 2006 15:12:01 +0000 (GMT) (envelope-from strick@covad.net) X-POP-User: strick.covad.net Received: from mist.nodomain (h-67-101-151-109.snfccasy.dynamic.covad.net [67.101.151.109]) by mail874.megamailservers.com (8.13.6/8.12.9) with ESMTP id k3MFBxiJ002409 for ; Sat, 22 Apr 2006 11:12:00 -0400 Received: from mist.nodomain (localhost [127.0.0.1]) by mist.nodomain (8.13.3/8.13.3) with ESMTP id k3MFBxs3003219; Sat, 22 Apr 2006 08:11:59 -0700 (PDT) (envelope-from dan@mist.nodomain) Received: (from dan@localhost) by mist.nodomain (8.13.3/8.13.3/Submit) id k3MFBxa2003218; Sat, 22 Apr 2006 08:11:59 -0700 (PDT) (envelope-from dan) Date: Sat, 22 Apr 2006 08:11:59 -0700 (PDT) From: Dan Strick Message-Id: <200604221511.k3MFBxa2003218@mist.nodomain> To: freebsd-chat@freebsd.org Cc: dan@mist.nodomain Subject: Re: Why is not more FreeBSD software written in C++? X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2006 15:12:02 -0000 On Friday 21 Apr 2006 09:20, Don Dugger wrote: > > The example above is not exactly a realworld example. Even if you stick > to plain C, a repeated putchar(' ') is 1-2 orders of magnitude slower > than aggregating those characters and write()'ing them every few dozen > chars. > This might seem obvious, but is it really true? I wrote a program that tries it both ways with the output redirected to /dev/null and discovered that filling a 24 character buffer and doing a write() takes about 11 times as much cpu time as 24 putchar()s. Perhaps a buffer larger than a "few dozen chars" would be useful. There must be a moral here somewhere. :-) Don continued: > > I'm not sure that I/O routine efficiency is really that relevant. I can't > think of any program I use whose I/O routines are CPU bound. Ok, I guess > if we look at really weak or embedded devices, say, those Soekris > net4501 boards, I/O CPU efficiency will make a difference. > I wrote in my original message that I first noticed the iostream performance problem when I compared the run time of a C program rewritten in C++ to the run time of the original C program. The C++ version ran about 5.5 times slower. It was a very "real world" program that performed some simple matrix computations and pretty-printed the results. Most of the effort apparently went into the pretty-printing. This must have exaggerated the performance problem. The C program did a lot of stuff like: char buf[...]; sprintf (buf, "...", ...); /* format output */ do_something_with (buf); The equivalent iostream idiom is: ostringstream bos; bos.str (""); bos << ... ; // format output string s = bos.str(); // extract string from ostringstream do_something_with (s.c_str()); // extract characters from string This turns out to be a performance nightmare for various reasons apparently involving the implementation of strings and iostreams. The problem is not just with ostringstreams. printf ("...", ...); generally runs many times faster than cout << ... << ...; The problem is not just with formatted output. putchar (c); also runs many times faster than cout.put (c); I don't know why. It just does. Perhaps in-line functions are not always an efficient alternative to preprocessor macros. I am not claiming that strings and iostreams are bad. I am observing that some reasonable programs that use these facilities will run very slowly and I am suggesting that it is not always obvious which programs these are. I am also expressing disappointment because I want the decision to use any feature of C++ or its standard library to be a no-brainer. Dan Strick