From owner-freebsd-chat@FreeBSD.ORG Sun Apr 23 00:03:12 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 1B2A516A402 for ; Sun, 23 Apr 2006 00:03:12 +0000 (UTC) (envelope-from benlutz@datacomm.ch) Received: from maxlor.mine.nu (c-213-160-32-54.customer.ggaweb.ch [213.160.32.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 736B043D46 for ; Sun, 23 Apr 2006 00:03:11 +0000 (GMT) (envelope-from benlutz@datacomm.ch) Received: from localhost (unknown [127.0.0.1]) by maxlor.mine.nu (Postfix) with ESMTP id AB5252E0A6; Sun, 23 Apr 2006 02:03:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at atlantis.intranet Received: from maxlor.mine.nu ([127.0.0.1]) by localhost (atlantis.intranet [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sK--Q0luZpgh; Sun, 23 Apr 2006 02:03:09 +0200 (CEST) Received: from mini.intranet (mini.intranet [10.0.0.17]) by maxlor.mine.nu (Postfix) with ESMTP id 61A3E2E01B; Sun, 23 Apr 2006 02:03:09 +0200 (CEST) From: Benjamin Lutz To: freebsd-chat@freebsd.org Date: Sun, 23 Apr 2006 02:03:01 +0200 User-Agent: KMail/1.8.3 References: <200604221511.k3MFBxa2003218@mist.nodomain> In-Reply-To: <200604221511.k3MFBxa2003218@mist.nodomain> X-Face: $Ov27?7*N,h60fIEfNJdb!m,@#4T/d; 1hw|W0zvsHM(a$Yn6BYQ0^SEEXvi8>D`|V*F"=?iso-8859-1?q?=5F+R=0A?= 2@Aq>+mNb4`,'[[%z9v0Fa~]AD1}xQO3|>b.z&}l#R-_(P`?@Mz"kS; XC>Eti,i3>%@g?4f,=?iso-8859-1?q?=5Cc7=7CGh=0A?= =?iso-8859-1?q?_wb=26ky=24b2PJ=5E=5C0b83NkLsFKv=7CsmL/cI4UD=25Tu8alAD?= MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1297295.LFSzQG6KxA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200604230203.05209.benlutz@datacomm.ch> 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: Sun, 23 Apr 2006 00:03:12 -0000 --nextPart1297295.LFSzQG6KxA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 22 April 2006 17:11, 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 tim= es > 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. :-) Yes, it is really true. Since I don't know what your test is, I've created = my=20 own. test_putchar.c:=20 =2D--- #include #include int main(int argc, char** argv) { int i, j; for (i =3D 0; i < 50000; i++) { for (j =3D 0; j < 60; j++) { putchar('.'); } putchar('\n'); } return 0; } =2D--- test_write.c: =2D--- #include #include int main(int argc, char** argv) { char buf[61]; int i, j; for (i =3D 0; i < 50000; i++) { for (j =3D 0; j < 60; j++) { buf[j] =3D '.'; } buf[60] =3D '\n'; write(STDOUT_FILENO, buf, 61); } return 0; } =2D--- And for completeness' sake, two corresponding C++ iostream variants: test_iostream.cpp: =2D--- #include using namespace std; int main(int argc, char** argv) { for (int i =3D 0; i < 50000; i++) { for (int j =3D 0; j < 60; j++) { cout << '.'; } cout << '\n'; } return 0; } =2D--- test_string.cpp =2D--- #include using namespace std; int main(int argc, char** argv) { for (int i =3D 0; i < 50000; i++) { for (int j =3D 0; j < 60; j++) { cout << '.'; } cout << '\n'; } return 0; } =2D--- All files are compiled with gcc/g++ and the -O2 option. I'm running them on= a=20 Mac Mini under Linux. And the results are (I've run that command several times and picked a line= =20 that shows an average run time): $ time ./test_putchar > /dev/null =2E/test_putchar > /dev/null 0.39s user 0.00s system 97% cpu 0.397 total $ time ./test_write > /dev/null =2E/test_write > /dev/null 0.02s user 0.01s system 82% cpu 0.029 total $ time ./test_iostream > /dev/null =2E/test_iostream > /dev/null 0.94s user 0.00s system 99% cpu 0.950 total $ time ./test_string > /dev/null =2E/test_string > /dev/null 0.21s user 0.00s system 97% cpu 0.213 total That quite clearly shows that my prediction that using putchar is "1-2 orde= rs=20 of magnitude slower" is accurate. It also shows the points you and others=20 have made that iostream is slower than C's I/O mechanisms. If we take the two most sensible variants, test_write and test_iostream, an= d=20 have them write into a file, we get these numbers: $ time ./test_write > foo =2E/test_write > foo 0.01s user 0.16s system 95% cpu 0.180 total $ time ./test_string > foo =2E/test_string > foo 0.20s user 0.02s system 98% cpu 0.223 total Which is a small enough difference to be irrelevant. The large I/O performa= nce=20 advantage of the write(2) variant over the C++ string variant vanishes as=20 soon as the code actually does something remotely useful. > 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. You mentioned a pretty printer. I'm not convinced that the performance=20 drawbacks you saw were inherent in iostream. Rather it seems that the comfo= rt=20 of C++'s strings and streams led the programmer to program in a less=20 performance-conscious way. > I am also expressing disappointment because I want the=20 > decision to use any feature of C++ or its standard library to be a > no-brainer. Personally, I don't hesitate to use features of C++. As for the STL... ther= e=20 are nice alternatives that are sometimes available. When writing Qt program= s,=20 I'll use Qt's data structures only, not the STL ones, since imo Qt's data=20 structure classes are more comfortable to use. Cheers Benjamin --nextPart1297295.LFSzQG6KxA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBESsQ5gShs4qbRdeQRAlIlAJ4hGnBtg4OiW8BpCuFWVI9ujIqW9ACeJ7wu l6InmUPeDNGdO6aiIz+V8yk= =pUhW -----END PGP SIGNATURE----- --nextPart1297295.LFSzQG6KxA--