Author: Eugene Nalimov
Date: 15:07:01 09/16/01
Go up one level in this thread
Bob, Here Vincent is right. GCC core was written in 80's with VAX and 68k as its primary targets, and it dis not contain optimizations that were unnecessary than. Developers were able to add some optimizations later, but unfortunately, to implement some optimizations correctly, total redesign is necessary, and it was not done (yet?). Look, for example, at the minutes of the IA-64 GCC IA-64 Summit (http://gcc.gnu.org/ml/gcc/2001-06/msg01634.html) for the current state of the IA-64 gcc port. Compiler is functional, but it produces *very* inefficient code. Main problem is memory disambiguation (interference information, aliases analysis). It is very hard to do it properly on GCC's program internal representation (RTL), as too much information is lost during early compilation phases. Problem affects GCC code quality on all modern CPUs, but it's *vital* for the IA-64. Vincent is right, the more registers the CPU has, the more severe is the problem -- to efficiently use large number of registers compiler must have good interference information. Small numbers of registers on x86 helps GCC there, genereated code is suboptimal due to other reasons. Eugene On September 16, 2001 at 09:54:33, Robert Hyatt wrote: >On September 15, 2001 at 23:00:40, Vincent Diepeveen wrote: > >>On September 15, 2001 at 22:38:45, Robert Hyatt wrote: >> >>>On September 15, 2001 at 19:59:15, Vincent Diepeveen wrote: >>> >>>>On September 14, 2001 at 17:51:46, Robert Hyatt wrote: >>>> >>>>>On September 14, 2001 at 15:54:40, K. Burcham wrote: >>>>> >>>>>> >>>>>> >>>>>>below is part of an artical that i read on the net. >>>>>>i know you could get real technical about 64 bit. not necessary >>>>>>but here is my question. >>>>>>if we have two processors both 1500 mhz. both same brand. but "a" >>>>>> has 32 bit 1500 mhz with 32 bit program. >>>>>>"b" has 64 bit 1500 mhz with 64 bit program. >>>>>> >>>>>>how would a kns benchtest compare with these two examples? >>>>>>so if in example "a" the kns benchtest was 1200 kns for 32 bit, >>>>>> what would the 64 bit do in a similiar benchtest. >>>>>> >>>>>> >>>>> >>>>>_if_ the 64 bit program really uses 64 bit integers, then it will be faster. >>>>>Because the 64 bit processor is doing one 64 bit operation every cycle, while >>>>>the 32 bit processor will do only one 32 bit operation every cycle. The >>>>>requirement is that the program really has to use 64 bit stuff. But if it does, >>>>>a 64 bit machine is potentially twice as fast as a 32 bit machine... >>>>>That is the driving force behind 64 bit development, in fact. >>>> >>>>But in reality the 32 bit operations go at a rate of nearly 2 a cycle and >>>>on paper can get 3 a cycle versus the 64 bits we must wait and see how >>>>many a cycle can be done :) >>> >>> >>>Vincent, please study some of the spec sheets first. The 21264 already >>>executes _four_ instructions per clock cycle. That is why the thing has a >>>256-bit wide data bus to memory. >> >>Well i haven't tested a hammer yet, so we will see, in the meantime >>try to figure out the speed of 64 bits instructions at the MMX part of >>the P4 :) >> > > > > >Please look at the _title_ of this thread: 64 bit processors. Who cares >what the P4 does in MMX hardware. Nobody would consider that a 64 bit >processor. The _real_ 64 bit processors are doing things no differently >than the 32 bit processors, except that they operate on twice as much data >at a time. > > > > >>> >>> >>>> >>>>> >>>>>> >>>>>>Hammer processors, sometimes referred to as "K8," will first be produced on an >>>>>>advanced 0.13 micron SOI process out of AMD's Dresden megafab. Unlike Intel's >>>>>>Itanium, Hammer chips will provide uncompromised performance on legacy 32-bit >>>>>>applications as well as open up the 64-bit computing "new frontier." In fact, >>>>>>Hammers are expected to be the fastest chips in the world at running 32-bit x86 >>>>>>code, while seriously challenging the fastest 64-bit processors on 64-bit code. >>>>>> >>>>> >>>>> >>>>>It is unlikely they will do both well. But there are exceptions. IE if you >>>>>use single-precision floats vs double-precision floats on an IBM RS6000, you >>>>>will find _zero_ speed difference. Because the RS6000 does all FP operations >>>>>in 64 bits. So using 32 bit numbers is somewhat slower than on a real 32 bit >>>>>machine that pumps less data around. >>>> >>>>I doubt they will do this, because 'int' should go to 32 bits integers. >>> >>>Nothing in the ANSI standard says this. Which is unfortunate, but it is a >>>way of life in the ANSI world... the standard that "isn't", really... >> >>You are of course right here, but there is a small practical problem: >>all windows applications will crash. > >I suspect any good compiler will give you the option to set the default size >for ints to either 32 or 64. > > > > >> >>Graphical coordinate system is completely 32 bits oriented. expanding it >>to 64 bits will give huge problems. >> >>No take my word, unless this is another paper processor, it will >>be 2 processors within 1 processor, because otherwise there is this >>problem... ...that all windows applications will not compile easily >>onto it! > > > >That is part of the "porting" problem. IA64 doesn't claim to maintain >compatibility with older executables. > > > >> >>> >>> >>> >>>>It would mean they need a very special compiler to run normal executables >>>>on this processor in short. >> >>>Not particularly. GCC already compiles for 64 bit machines. Alpha, MIPS, >>>SPARC, etc... >> >>It is a very poor compiler for Alpha, MIPS, SPARC etc. >> >>The more registers the bigger the problem for GCC. > >I don't know what you are talking about here. GCC has a general-purpose >register allocation algorithm that works just fine on the sparc with 32 >registers. I've written a couple of compilers over the years. I don't see >why the _same_ code wouldn't work on an 8 register machine _and_ a 32 register >machine, from the compiler's point of view. That is just an optimizer issue >that isn't hard to deal with at all. > > > > > > >> >>The speed difference on P2 processor was 7.5% in disadvantage of linux. >>At the P3 it is already more near 11%. The more registers the >>bigger the problems of gcc! > >What does that mean? P2 and P3 have the same number of registers. As I >said before, the number of registers is not something that bothers a compiler. >The more there are, the better it can optimize. > > > > >> >>Of course i hope it gets better, but there is little hope! >> >>The main thing to realize however is that a new 1.5Ghz clocked >>processor is not so impressive when there is a 40% slower >>compiler at it than a commercial equivalent would be! > >I don't think gcc will be 40% slower. It may well be 10% slower always, >but not 40%. > > > > >> >>Because all the innovations of the processor then are completely >>useless in general speaking. >> >>Of course with inline assembly and many volunteers to write new >>inline assembly for you, you will survive with crafty and be probably >>the only happy exception for this processor, but that's not very >>encouraging for others to buy it! > > >You are mixing apples and oranges. GCC for specific processors works just >fine. The intel X86 is an ugly design. Very poor register operations, very >few registers. Each new cpu model introduces new instructions. Instructions >not compatible across all versions of a processor. AMD going their own way with >new instructions. etc. I doubt IA64 will get so corrupted since it covers all >those issues in the basic design. IE this has not happened to the alpha, >the MIPS chips, the sparcs, the HP chips, etc. Only with Intel/AMD. > > > > >> >>> >>> >>>> >>>>I think this is why the IA64 hasn't reached me yet, because i need to >>>>especially compile for it. >>>> >>>>Now that's still pretty simple as i have a cross compiler at home, >>>>so we can generate IA64 bits native code at a 32 bits machine (of course >>>>not run it). >>>> >>>>However, i doubt they will be able to do that with GCC soon. >>>>I've toyed quite some with gcc and making a cross compiler >>>>is pretty hard! >>> >>>It is already done. In fact, linux for IA64 is fully functional. Which >>>means that GCC had to be finished first... >> >>Everyone told me it was possible. I toyed for months. Now i'm not worlds >>smartest linux user, because all those tens of thousands of commands which >>you have to memorize i keep forgetting, but all i manage with gcc is >>to compile it for 32 bits and for linux native! > >Get an alpha. Do ./configure. The make bootstrap. Sit back, and watch. >When it finishes you will have a compiler that works. I did one on my >21164 machine without even thinking about it. Portability is not free, >in terms of performance. > > > > >> >>Note that the gcc compiler at the 21164 didn't particularly impress me >>when compared to the DEC compiler! > >The difference is not huge, but still present. But that is true for all >vendor-supplied compilers. They only have to work on the compiler for one >architecture. GCC does 'em all. > > > > > >> >>> >>> >>>> >>>>I will of course not buy hammer but cross compiling an executable for it >>>>is no problem if i can get a compiler that can produce a hammer native >>>>executable. >>>> >>>>Knowing the problems of GCC just a little bit >>>>i doubt this will happen soon! >>>> >>>>Note i never managed to create at my own PC-linux machine a gcc version >>>>which could create executables for the alpha (with linux of course onboard). >>>> >>> >>>I have one on my alpha at the office. Works fine... >>>using the same one I use on my quad xeon in fact... >>>>So that's why i still till today do not have hard numbers on how fast/slow >>>>a 21264 for me is! >>>> >>>>>>The first desktop Hammer product, the so-called "Clawhammer," will also be only >>>>>>slightly more expensive to produce than contemporary Athlons making 64-bit >>>>>>processing a real option for the masses in the near future. >>>>>> >>>>>>kburcham
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.