Path: utzoo!attcan!uunet!wuarchive!sdd.hp.com!elroy.jpl.nasa.gov!ncar!gatech!mcnc!uvaarpa!murdoch!shamash!clc5q From: clc5q@shamash.cs.Virginia.EDU (Clark L. Coleman) Newsgroups: comp.arch Subject: Re: icache size (was Compilers taking advantage of architectural enhancements) Summary: All resources are limited and always will be Message-ID: <1990Oct24.200409.22449@murdoch.acc.Virginia.EDU> Date: 24 Oct 90 20:04:09 GMT References: <3300194@m.cs.uiuc.edu> <1990Oct12.042251.18884@cs.cmu.edu> <1990Oct12.135814.14346@zip.eecs.umich.edu> Sender: news@murdoch.acc.Virginia.EDU Reply-To: clc5q@shamash.cs.Virginia.EDU (Clark L. Coleman) Organization: University of Virginia Computer Science Department Lines: 44 In article <1990Oct12.135814.14346@zip.eecs.umich.edu> billms@zip.eecs.umich.edu (Bill Mangione-Smith) writes: >In article <1990Oct12.042251.18884@cs.cmu.edu> spot@TR4.GP.CS.CMU.EDU (Scott Draves) writes: >>shouldn't loop unrolling burn lots of registers also? when unrolling, >>which ceiling will you hit first, the number of registers, or the size >>of the I-cache? > >I don't understand why people are still consumed by code size with (most) >aggressive loop optimizations. Loop unrolling and polycyclic scheduling >do increase code size. That just isn't important anymore. Give me a 4k >icache. Thats usually 1k instructions, right? You want a 4k icache, and so do 100 other users. When every context switch eventually leads to some of your cache lines being thrown out of the cache in order to fit someone else's code in the icache, you will see an initialization transient every time the timesharing comes back around to you. If you prefer a different example, you could look at a networked workstation with only 2-3 users, but with each user running several processes. With compilers unrolling loops and otherwise gobbling up the icache, your 4k starts to look small. No problem, you say. In a short time, we will all have several times 4k in every machine. This is a variation on one of the oldest themes in computer science : it always seems that all our resource limitations are about to be solved, as semiconductor technology keeps improving so rapidly. But we just get more and more ambitious in our use of computers. Many computer programmers in the 1950's were certain that programming would be easy within a decade, because they would have more CPU and storage resources. And it would be easy today, if all we were trying to do was program the same problems as in the 1950's. Now that we have multitasking Xwindows applications chewing up gobs of resources, we find ourselves awaiting the next generation of hardware in order to leave behind our current resource limitations. Who knows what icache size we will have tomorrow; I do know that we will figure out a way to chew it up, and then some. That's the message of history. There is no excess of resources waiting around the corner that will excuse our inefficiencies in CPU usage, icache usage, memory usage, etc. ----------------------------------------------------------------------------- "We cannot talk of freedom unless we have private property." -- Gavriil Popov, Mayor of Moscow, September 11, 1990. ||| clc5q@virginia.edu