This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: i386 backend


The single most common case of gcc generating slower code than
commercial compilers remains, in the code I continue to examine, the
failure to consolidate pointers which differ by a constant known at
compile time.  That appears to be something which should be independent
of architecture, although of course it hurts the i386 much more than the
others.  But, I've seen a number of cases where gcc code is close to the
same speed as MSVC++, and icl is only about 15% faster.  Not enough
difference for many people to care.
----- Original Message -----
From: "Lee Iverson" <leei@AI.SRI.COM>
To: "David Rasmussen" <pinkfloydhomer@yahoo.com>
Cc: <dewar@gnat.com>; <gcc@gcc.gnu.org>
Sent: Monday, March 19, 2001 1:28 PM
Subject: Re: i386 backend


> In message <ELECLDHLONNAHNIBCAEIIEOFCBAA.pinkfloydhomer@yahoo.com>,
"David Rasm
> ussen" writes:
> >
> >Even if I can't be very precise in pointing out _where_ the problems
is, it
> >should still be recognized as a problem. A very simplistic way of
putting it
> >is: "Why is gcc producing slower code than MSVC++ or Intel C++?". I
know
> >that it is not always the case, but from all the different types of
programs
> >I've compiled, and all the people who I have talked to, it is almost
always
> >the case. So there is room for improvement.
>
> But that *is* the point.  You can be *much* more precise in reporting
> *where* the problem is.  If you have been serious about benchmarking
> your code in any way, then it should be clear to you what parts of
> your code are having slowdown problems.  That is what is being asked
of
> you, and frankly, it is not too much to ask since this is exactly the
> kind of analysis you should be doing anyway if you are at all worried
> about performance.
>
> The compiler developers know of many places in which the compiler can
> be improved and the vagaries of the 1386 architecture make it a
> particularly nasty test case for a general purpose compiler targeted
> at a wide variety of machine architectures.  Whether or not the
> problems you are experiencing are known or unknown, simple or complex
> is something that can only be answered if and when you do at least
> some of the work to identify specifics.
>
> ----------------------------------------------------------------------
---------
> Lee Iverson     SRI International
> leei@ai.sri.com 333 Ravenswood Ave., Menlo Park CA 94025
> http://www.ai.sri.com/~leei/ (650) 859-3307
>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]