Article View: comp.os.linux.hardware
Article #861Re: P4 vs Athlon for Linux latexing, is gcc-2.95 responsible?
From: G. Hugh Song
Date: Sun, 16 Jun 2002 12:50
Date: Sun, 16 Jun 2002 12:50
93 lines
5711 bytes
5711 bytes
Robert Myers wrote: > Oh, geez, here we go again. > > ----- Original Message ----- > From: "Hugh" <hugh@nospam.com> > Newsgroups: > comp.os.linux.hardware,gnu.gcc,comp.sys.ibm.pc.hardware.chips,comp.text.tex > Sent: Saturday, June 15, 2002 11:05 AM > Subject: P4 vs Athlon for Linux latexing, is gcc-2.95 responsible? > > > >>The following is my general finding so far: >> >>Special features of Pentium 4 cpu is not generally utilized >>by gcc-2.95.** which is used for most Linux distributions rpms. >>Latexing a big document with Zeon Pentium 4 at 1.7GHz (52 sec) is actually >>even slower than Pentium III running at 700MHz giving 35 sec. >> >>On Athlon at 1.6GHz, it gives 16 sec. The best. >> >>Is my understanding for the reason of slow speed with P4 correct? >>gcc-2.95. If I do obtain te-latex.src.rpm and then compile it >>with gcc-3.1, would I get much faster binary under Pentium 4? >> > > An even more interesting question would be whether Intel's own compiler, > icc, which for Linux is available free for personal use, would give better > results. If anybody should be able to write a compiler to exploit the > strengths of the P4 and to minimize its weaknesses, it should be Intel. At > least up until gcc 3.0, icc generally beat the pants off gcc. Even RedHat, > which isn't known for being conservative about new releases, has yet to > bless and release a distribution of gcc 3.0, and if RedHat isn't ready to go > there, neither am I. > > >>The problem with Pentium 4 is not just limited with Latex. >>I in fact hate Pentium 4, because I simply believed in >>their high SPEC rating, and bought a bunch of Pentium 4 Xeon >>duals only to find out that the even the Fortran speed >>(with their Intel compiler) is in fact dismal. >> > > In my still very brief study of the situation, I have found that Intel's own > compiler makes very conservative assumptions about possible vector (array) > dependence in loops and will often fail to vectorize loops that can, in > fact, be vectorized if you modify the code to make it explicit that a vector > dependency is not possible. > > Without SSE2, which requires that loops be vectorized, a 1.7GHz P2 is a very > weak foating point performer, as many have noted, and as you have confirmed > for yourself. If I take naive code compiled with icc, my overclocked > Celeron running at 1.5MHz will beat a 1.7GHz P4 every time. > > If you're using a Fortran compiler, it almost certainly means you're doing > scientific computation, and that almost certainly means you have code full > of loops using pointers (arrays) that are just dying to be vectorized. If > you're using single precision, SSE2 is worth a factor of four in throughput; > for single precision it's worth a factor of two, generally with lower > instruction latencies. > > The fact that you have dual Xeon's is not likely to help much unless you > have specifically written software to exploit the availability of more than > one processor. You may find it worthwhile to explore Intel's math kernel, > also free for personal use. > > The design decisions behind the P4 seem mostly to have been driven by the > need to get multi-media performance, at which the processor excels. It is > probably possible to turn the P4 into a decent number-cruncher, but not > without some work. A processor that requires special code to get decent > performance is not especially attractive, and if the P4 weren't an Intel > product, no one would be using it. As it is, the future of high-performance > personal computing looks like it belongs to the P4 for the forseeable > future, so we might as well get used to it. > > > My three-year old Compaq-alpha based 21264 duals beat P4 all the time. Oh, my! Had compaq sold its Alpha to AMD, we would certainly have had a much better chance of using a dual true 64-bit 21364 (EV7) by now. For scientists like me, the way the CPU industry is turning its wheel is something to damn about. Which linux distributors make their RPMs with gcc-3.1? Thanks. Hugh >
Technical Details
Message-ID:
<3D0C8986.5090104@nospam.com>Path:
arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.dacom.co.kr!nntp.kreonet.re.kr!news.kreonet.re.kr!not-for-mailReferences:
<3D0B57CB.5060406@nospam.com> <cVYO8.93284$pw3.4355@sccrnsc03>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f9e16,ea3300a83f1f851c X-Google-Attributes: gidf9e16,public X-Google-Thread: 102b32,ea3300a83f1f851c X-Google-Attributes: gid102b32,public X-Google-Thread: 1045b9,ea3300a83f1f851c X-Google-Attributes: gid1045b9,public X-Google-Thread: f65d0,ea3300a83f1f851c X-Google-Attributes: gidf65d0,public X-Google-Thread: 1094ba,b32aa620bb2987b1,start X-Google-Attributes: gid1094ba,public X-Google-ArrivalTime: 2002-06-16 05:50:01 PST Path: arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.dacom.co.kr!nntp.kreonet.re.kr!news.kreonet.re.kr!not-for-mail From: "G. Hugh Song" <ghsong@nospam.com> Newsgroups: comp.os.linux.hardware,gnu.gcc,comp.sys.ibm.pc.hardware.chips,comp.text.tex,comp.lang.fortran Subject: Re: P4 vs Athlon for Linux latexing, is gcc-2.95 responsible? Date: Sun, 16 Jun 2002 21:50:14 +0900 Organization: Korea Research Environment Open Network Lines: 95 Message-ID: <3D0C8986.5090104@nospam.com> References: <3D0B57CB.5060406@nospam.com> <cVYO8.93284$pw3.4355@sccrnsc03> NNTP-Posting-Host: bellini.kjist.ac.kr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.kreonet.re.kr 1024231822 22110 203.237.41.6 (16 Jun 2002 12:50:22 GMT) X-Complaints-To: usenet@news.kreonet.re.kr NNTP-Posting-Date: Sun, 16 Jun 2002 12:50:22 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607 X-Accept-Language: ko, en-us