Slashdot Mirror
Reconfigurable Computers - Again?
shermNOTsherm writes "Here's a story on UniSci about research at the University of Rochester on reconfigurable computers. The idea is to dynamically adjust cache sizes on the fly to more efficiently operate. Supposedly halves power consumption, and is based on current commercial chips, not customized, so it's just a little closer to real world."
Amen, brother! Remember the mid-80s? Full-GUI multitasking micros with 1 MB of RAM that could boot in (I am not making this up) under 2 seconds. My home computer now has over 300 times the RAM, 50 times the MHz, and 9,000 times the disk storage. Yet, amazingly, it takes 100 times as long to boot, and (apart from games) delivers very little in the way of application functionality that my system of 13 years ago did not. My OS alone requires what would have been 40 hard drives and 256 times the maximum possible RAM of the computer on which Unix was invented, and cannot support two users. This is progress?
Actually, you don't want to set to zero unless it is already there - it's the act of causing a transition in a cell state which causes the noise.
Presumably, if you know that you're not using a bank of memory, you just turn off the power to that bank & let its contents dribble away through leakage w/o worrying about doing any DRAM refreshes on it.
I've worked (am working) in commercial software. Code re-use, libraries of common functions, even a rudimentary code-optimiser...all are ignored.
Generally, things go like this.
Manager: The customer has requested a new feature. Mr. Designer, can you come up with a plan.
Mr.Designer: (Thinks for three minutes) Well, we could modify module A, B and D and then write module L and T.
Manager: I'll put some people right on it.
There aren't enough engineers so a college grad is hired or someone is brought in from another project where they have been working in another language for several years.
Manager: I know you're new here, but we're in a crunch. You have two days to review our 11MB CVS code base, and the weekend to get the feature implemented.
Programmer: Sounds reasonable.
11pm on Sunday night.
Programmer: None of the stuff is coded right. None of it makes any sense. I'll just write the feature from scratch and hardcode some links into modules A and B.
The feature is written like it was a seperate program and shipped. The new guy writes his own library functions. A code optimizer is never run against it to see what's duplicated or if the 30MB of resources (mostly library icons the the Manager paid a lot to license) is ever used. No-one with an overall knowledge of how the whole code base works is ever kept around.
It doesn't matter though. The next new-hire will just continue the tradition.
Aah, change is good. -- Rafiki
Yeah, but it ain't easy. -- Simba
One problem that I suspect this particular technology will suffer from is that modern preemptive multitasking operating systems in combination with object orientated code (which suffers from poor locality, unfortunately) mean that any microcode designed to detect low levels of cache usage etc isn't going to have enough time to respond before either the OS does a context switch, or the working set of the executing task shifts.
Having said that, I firmly believe that both this technology and Transmeta's 'codemorphing' ideas will become the norm within the next few years. Now, if only they could JIT Java bytecode in microcode...
Doesn't it essentially use a small, variable speed core, that can be used to emulate x86 code. Surely at the end of the day this achieves the same effect, but in a far cleaner manner.
Despite they hype in this article it seems like they are making a lower power consumption chip by disabling extra transistors, lowering the cache size, and cutting the voltage... not exactly groundbreaking and i'm sure you'd be better using a SparcLite or ARM cpu if you wanted to achieve the same effect.
A group at Purdue have recently published some work describing dynamic cache resizing: they shrink the cache by turning off lines until it is just big enough for the current code but no bigger. They claim 62% power reduction at the cost of a 4% slowdown. For details have a look at http://www.ece.purdue.edu/~icalp.
So, it's having a chip that can turn off parts of itself when they aren't needed. Lots of processors today do that. Lots of processors change their speeds to cut power as well. They don't cut their cache sizes though, which this is proposing. It makes sense though - the cache has to be on all the time to keep from losing data, but why couldn't you get about the same effect with today's processors by making them flush their caches and power them off when going into a low power state? Of course, this technology would allow you to work at the same time, at a lower speed, but the full power on time of a microprocessor today is measured in nanoseconds - you wouldn't even notice it. Loading from memory may take a bit longer, but it's still not noticeable, except in artificial tests.
As for the speed increase aspect of it, I doubt that this tech can turn L1 and L2 caches into each other - it probably can just cut the sizes of each - so leaving them all the way on all the time would give you them best performance - and of the power saving features would at best change nothing.
Sounds like a neat idea though, but the proof will be in the implementation .
Lets face it; a lot of commercial software out there is bloatware of the finest. Recently I did a small test with some friends who also had a laptop; pentium 160Mhz, 64Mb internal memory, 4Gb harddisk, 12.x" LCD screen and running Windows 95. My laptop is a PIII 550Mhz, Win98, 6Gb hardisk and has a 14" TFT screen. Both were equiped with a PCMCIA network card. We put the laptops next to each other and booted the machines. The 95 machine was waay done while mine was just past the PCMCI initialization. And no; my machine does not have major programs which are loaded during boot; its a very plain Win98 installation, most commonly used for office applications and demonstration purposes.
Second example is something which most people experienced afaik; if you take win98 running on a PII266 Mhz and on a PIII500 Mhz you will notice some increase in performance but not as drastic as it could be. If you compare all these Windows based experiences with an environment as Linux, BeOS or OS/2 (I haven't played around with BSD myself) then you'll notice that by using environments like Windows you don't use the hardware to its full capabilities.
Offcourse I do realize that this isn't an issue in all cases. Not everyone uses Windows and in some environments the software is allready at the 'cutting edge' in which there is no more performance to gain by adjusting the software.
But if you focus on the consumers market then the remark "We'll have to rely on innovations like this to go faster" is not the issue.
Hmmm. Turn down the voltage by cutting the noise produced by unneeded circuits...
I wonder how much of this happens already (sans the voltage lowering that would actually save power) in RAM chips in systems with tons of it. If a cell hasn't been used yet, it should be set to zero, and shouldn't be producing much if any noise). Unless refresh gets in the way.
RAM isn't usually a big problem power-consumption wise, but it should be possible to turn off bits of DRAM circuits that aren't in use. The chipset should be able to signal that automagically by looking at the page tables. In power-hungry devices, any savings should help (not to mention devices that currently have heatsinks on the RAM like RDRAM and the new nVidia card). Anybody have an idea on how much page table and processor state info modern chipsets keep around?
I wonder if there are any other devices that this can be applied to...
"Time flies like an arrow; fruit flies like a banana." --Groucho Marx
Because it doesn't sell cars.
Seriously: when new cars come out, they try to sell you on the sexy things: how powerful the engine is, how fast it accelerates or handles, how luxurious the ride is, and if it's an SUV, how rugged you'll look when you drive it through old-growth pine forests - or, at least, while picking up the kids from band rehersal.
But in our rush to go faster and look better, the only time that automotive ads seriously push the economics issue is when a) they're trying to clear out old inventory and have slashed financing rates, or b) there's an energy crisis and they're selling low gas-consumption cars.
In the computer world, there's never an energy crisis, thanks to Moore's Law (or whatever). Many people who are buying computers are buying far more power than they actually need, or are ever likely to use. The only people who are really worried about computational overhead are wonks like us - professionals. Lots of folks are willing to plunk down for a 700 GHz machine on which to check e-mail and browse Sports Illustrated online.
There's an article in IEEE Computer magazine this month, about PicoRadio, a project that's intended to build pervasive ad hoc networks from small wireless nodes.
/
These 'PicoNodes' are less than 1 cubic centimetre, weigh less than 100 grams (less than most cell phones), consume less than 100 microwatts (vs. 100 milliwatts for Bluetooth). They should even be able to scavenge energy from the environment, including vibrations from people walking by...
This project relies on reconfigurable hardware, amongst other techniques, for very low power consumption. More info, including the article, is available online at the project's home page, http://bwrc.eecs.berkeley.edu/Research/Pico_Radio
So, they're basicaly turning off Cache chips when they don't need them? Not exactly groundbreaking... What Iv'e always thought would be cool would be to change the clockspeed (and as a result, the powerconsumption, heat) of a computer. I used to be able to change jumpers on my motherboard, changing the bus speed from 66 to 75 without crashing the computer, so I'm pretty sure this could be posible.
ReadThe ReflectionEngine, a cyberpunk style n
Well, that explains how Scotty and other members of the Enterprise could reconfigure sensors to detect previously unknown substances with just a few keystrokes. Not even a reboot! It all makes sense... :-)
JL
I wonder if there will be instructions on those processors that enable you to crank the n:th transistor over the top - enabling Assembler freaks all over the world to have nifty demos running at the same time as you unpack whatever cracked software you're unpacking?
See if I care.
I want my computer to be stable - this sounds like yet another source of hardware problems to me.
Mobile processors have been disabling their caches while in low-power mode for 5 or more years.
The only thing remotely new is that they are only disabling part of the cache at once, instead of the entire cache. Then again, that's probably enough for a patent these days...
Tarsnap: Online backups for the truly paranoid