From: Mark Veltzer <mark@veltzer.org>
To: Con Kolivas <conman@kolivas.net>,
Linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [BENCHMARK] gcc3.2 v 2.95.3 (contest and linux-2.5.38)
Date: Mon, 23 Sep 2002 14:06:01 +0300 [thread overview]
Message-ID: <200209231106.g8NB63d10555@www.veltzer.org> (raw)
In-Reply-To: <1032751018.3d8e87aa99cc2@kolivas.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Monday 23 September 2002 06:16, Con Kolivas wrote:
> >
> > Ugh?? Something is _seriously_ messed up here.
>
The most important question to ask here is: What flags did you compile both
?!? I wouldn't count on the flags that were designed for gcc 2.95 to be any
good for 3.2... Could the original poster comment on this ?
Any GCC maintainers on this list to comment ? Is there any set of flags to be
passed to gcc 3.2 to replicate 2.95 behaviour ? I wouldn't rule out gcc 3.2
having a totaly different set of optimizations geared towards user space C++.
Again, any gcc maintainers comments ?!?
Since most of the code in gcc is for C++ most of the changes in gcc should
have been geared towards C++ (yes - quite a monstrous language). It seems to
me that the changes in C compilation between 2.95 and 3.2 should be minor
EXCEPT in terms of C optimization. Can anyone with assembly knowledge take
apart two identical drivers and see the better machine code produced by 2.95
as compared to 3.2 ? If so - can this be reported to the gcc folk ?
It seems to me that the difference is so huge that even user space
applications could show the difference. I suggest compiling a large C program
(emphasis on the C) in user space and doing the comparison... I would guess
that this should have been done by the gcc folk but because of the
hideousness of the C++ language I would guess that they mostly concentrated
on C++ and didn't bother to benchmark regular C optimization. This is quite
awful as the bulk of lower level open source code is in C and not C++ so this
kind of test has a lot of meaning for any distribution that is going to be
based on gcc 3.2...
If this benchmark turns out to be right then it seems to me that the only
conclusion is that the gcc folk let their interest in aesoteric features of
C++ (which has about 1/2 a billion of those) override the basic need for
strong C optimization. Yes - it now seems that the C++ language (which is
quite an abomination in terms of engineering and the KISS principle) is
actually hurting open source (which has been my conclusion for quite some
time).
Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9jvWZxlxDIcceXTgRAnxpAKDYz61RWvceqD13Z889rwtZLOaomwCggmmj
ixt6x1e+zXewlrYCCHbiN9Y=
=snOl
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2002-09-23 10:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-23 3:04 Con Kolivas
2002-09-23 3:10 ` Robert Love
2002-09-23 3:16 ` Con Kolivas
2002-09-23 11:06 ` Mark Veltzer [this message]
2002-09-23 13:56 ` Daniel Jacobowitz
2002-09-23 3:28 ` Robert Love
2002-09-23 3:41 ` Andrew Morton
2002-09-23 3:46 ` Daniel Jacobowitz
2002-09-23 3:50 ` Con Kolivas
[not found] ` <3D8E9158.4E3DE029@digeo.com>
[not found] ` <1032754853.3d8e96a520836@kolivas.net>
[not found] ` <3D8E988F.DCB3196D@digeo.com>
2002-09-23 5:13 ` Con Kolivas
2002-09-23 7:20 ` Axel H. Siebenwirth
2002-09-23 3:47 ` Robert Love
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200209231106.g8NB63d10555@www.veltzer.org \
--to=mark@veltzer.org \
--cc=conman@kolivas.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®