Author: Eugene Nalimov
Date: 14:37:11 09/17/01
Go up one level in this thread
CPU developers have to pay a price for large number of registers. I.e. slower clock speed. Or stalls when program tries to simultaneously access even- and odd-numbered registers. Or larger code, i.e. less efficient I-cache. Or slower access to L1 D-cache, as registers-to-cache ports became harder to layout. Etc. As everything, CPU is compromise -- you slow down this part and hope that resulting speedup in that part will give you a total gain. And now dumb compiler cannot efficiently use large number of registers; it uses only part of them. I.e. CPU with large number of registers becomes crippled version of CPU with less registers. So, in theory at least, for dumb compiler CPU with less registers can be faster than one with large number of those. Eugene On September 17, 2001 at 14:36:10, Robert Hyatt wrote: >On September 16, 2001 at 18:07:01, Eugene Nalimov wrote: > >>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 >> > > >OK... but I suspect this is all a semantic issue. IE I can't imagine that a >compiler would do _worse_ with twice as many registers. I can imagine that it >would produce code that might not be as efficient as it could be, but I could >not imagine that doubling the registers would result in a _slower_ executable. >Maybe the result won't run as fast as expected after doubling the number of >registers. But I can't see how it could possibly run slower than not changing >the number of registers at all...
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.