From owner-freebsd-chat@FreeBSD.ORG Sat Apr 22 15:33:18 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 97A0E16A402 for ; Sat, 22 Apr 2006 15:33:18 +0000 (UTC) (envelope-from dugger@hotlz.com) Received: from www.hotlz.com (freedom.hotlz.com [209.20.218.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 467FE43D45 for ; Sat, 22 Apr 2006 15:33:18 +0000 (GMT) (envelope-from dugger@hotlz.com) Received: from [172.27.240.45] (henry.local.hotlz.com [172.27.240.45]) by www.hotlz.com (8.13.3/8.13.3) with ESMTP id k3MFX1EB022819; Sat, 22 Apr 2006 08:33:02 -0700 (PDT) (envelope-from dugger@hotlz.com) Message-ID: <444A4CAD.7080901@hotlz.com> Date: Sat, 22 Apr 2006 08:33:01 -0700 From: Don Dugger User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-chat@freebsd.org References: <200604221511.k3MFBxa2003218@mist.nodomain> In-Reply-To: <200604221511.k3MFBxa2003218@mist.nodomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dan Strick 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:33:18 -0000 Not that it matters a great deal but I didn't write that. Don ;^) Dan Strick wrote: >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 >_______________________________________________ >freebsd-chat@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-chat >To unsubscribe, send any mail to "freebsd-chat-unsubscribe@freebsd.org" > >