Slashdot Mirror
A Hardware-Software Symbiosis
Roland Piquepaille writes "We all want smaller and faster computers. Of course, this increases the complexity of the work of computer designers. But now, computer scientists from the University of Virginia are coming with a radical new idea which may revolutionize computer design. They've developed Tortola, a virtual interface that enables hardware and software to communicate and to solve problems together. This approach can be applied to get a better performance from a specific system. It also can be used in the areas of security or power consumption. And it soon could be commercialized with the help of IBM and Intel."
The thing I want to see smaller is the number of Roland's copy-pasted shill posts here.
If X is the new Y, and Y is "X is the new Y", solve for X.
"Reinventing the wheel for profit!"
I can't figure out who wrote the NoRoland grease monkey script... but I've been meaning to say thanks!
Support NYCountryLawyer RIAA vs People
A middle layer between hardware and software sounds a whole lot like an operating system - the sort of thing that "would allow software to adapt to the hardware it's running on". I can't figure out from the article what makes this thing so special.
Ita erat quando hic adveni.
That doesn't really say much. In fact, without further details it sounds like dynamic tuning in virtual machines. Which can't be the case here, as that would be reinventing what has already been inventing. (Seriously, her professor wouldn't approve a project like that, would he?)
Anyone have any more details?
Javascript + Nintendo DSi = DSiCade
Damn! That professor is Hot!!!! And she teaches Compilers!!!!
http://www.cs.virginia.edu/kim/
I don't either but there's a girl in the photo so let's keep quiet and just appreciate it.
They invented firmware
The thing I want to know is the number of the hot chick who invented this. Yowza!
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
and it is just a smarter bios
Well, something that allows software to adapt to the hardware its running on sounds to me a lot like an optimizing compiler, but only if the software is distributed in source form.
"what has already been invented"
Also, her mentor (chair of the Department of Computer Science) is female, so I should have said "her professor wouldn't approve a project like that, would she".
Javascript + Nintendo DSi = DSiCade
I was thinking the same thing, I had to read over the article several times to make sure I was not missing something. In the end, I think, she is after some uber firmware I mean we have the OS we have firmware, what else does she intend to do? Sure you could make your hardware components more programmable but the cost in terms of speed lost in operations and complexity of design far outweigh any benefit.
Doesn't that feel nice? A female approach to tackling computer design challenges; rather than the square, stodgy old patriarchal logical and hierarchical thinking we grew up with.
I remember something like this being talked about by my teacher 3 years ago. About how software could show down parts of the CPU to save power. It could also change the way the CPU worked on the fly.
"We could use the software to hide flaws in the hardware, which would allow designers to release products sooner because problems could be fixed later," translation -> Hardware companies can produce shit and if someone happens to notice a flaw we can create a patch instead of testing our products first. Will this not also open the hardware up to a virus?
I can't wait to pay £400 for a Beta CPU and then get to endure 6 months of crashing until it gets patched.
Spelling mistakes, grammatical errors, and stupid comments are intentional.
This sounds a lot like a virtual machine on top of a FPGA board. Would be neat to store a VM or OS on a seperate layer, and allow the OS to reflash the FPGA to optimize the hardware to a specific task.
I was thinking it seemed almost like what LLVM is trying to do by optimising at runtime.
Should I ask you to notice she's an intelligent, pretty, woman who's into CS? Nah.
HAD
... welcome our new Kim Hazelwood overlords.
-- www.globaltics.net
Political discussion for a new world
Actually, it specifically mentions communication, so I'd say the OP is closer to correct, though a more specific answer would be "driver"
34486853790
Connection too slow for X forwarding? Try "ssh -CX user@host"
Her homepage,
tortola and
possibly unrelated paper
Sorry, but Hardware and software do not solve problems together. That is straight from the "computers are magic"-fraction. Hardware solves problems under software control. Hardware alone can do nothing and software alone cannot run.
/. provide free advertizing to them?
Using inferface layers to get more portable and easier to use interfaces is an old and well-established technique.
There people are looking for money, right? Why does
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Although this is not a dupe, it practically is. Check this other story, New Way to Patch Defective Hardware, less than two months old. Basically, both approaches suck in the same way, they allow hardware manufacturers to be sloppy in order to rush the product out as fast as possible while allowing them to try to correct the errors that will appear later in the process. In short, they reinvented the FPGA.
Two non-stories. But makes one think, cui bono? Who is benefiting from these articles? Roland for sure, being such a click whore. But other than him, who else? Weird, very weird indeed.
How is this any different than what Transmeta has already done?
Some Links:
And a comment:
I'm not entirely thrilled with this idea of dynamically communicating between hardware and software. From what I got from TFA, the hardware would change dynamically based on feedback from the software. It seems to me that we already have plenty of trouble writing programs that work correctly when the hardware does not change... imagine trying to debug a program when the computer hardware is adapting to the changes in your code. (IOW: heisenbugs.)
Also, I've got some unease when I think about what mal-ware authors could come up with using this technology. Sure, we'll come up with something else to counteract that... but I think it'll bring up another order of magnitude's worth of challenge in this cat and mouse game we already have.
This article is an example of CCS: "Cute Chick Science". The article has about as much fluff as a popcorn kernel. I am not exactly sure to what they are referring here--FPGAs? There seem to be a number of statements that are overly categorical and seemingly not well informed such as "This middle layer would allow software to adapt to the hardware it's running on, something engineers have not been able to do in the past," and "to engineer software that can communicate between the two layers, [hardware and software]".
If there wasn't a pic of a cute professor involved, would anyone care?
120 characters isn't enough to explain it.
Also known as reconfigurable computing.
Tortola Project
Seems like an interesting research project. The research seems new (I see no published papers on Tortola, although I do see some slides and an extended abstract), so it will be interesting to see how it develops. I am very interested in seeing how an operating system would interact with Tortola.
What makes it special is that she's using Transmeta's marketing literature.
I'd recommend her to hire Linus and go head-to-head against Intel. (Or try to be bought out by them).
It's scary to think what if the Cold Fusion professors were as pretty as she is.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
Sounds more like a BIOS to me.
---- Booth was a patriot ----
How about lets not encourage companies to rush out unfinished products any more than they already do?
Isn't this a bit like trying to make water communicate with pipes?
God damn she's hot! (for a geek chick)
"I'm not entirely thrilled with this idea of dynamically communicating between hardware and software. From what I got from TFA, the hardware would change dynamically based on feedback from the software. It seems to me that we already have plenty of trouble writing programs that work correctly when the hardware does not change... imagine trying to debug a program when the computer hardware is adapting to the changes in your code. (IOW: heisenbugs [wikipedia.org].)"
I suspect that you're going to have to get use to the loss of control if you ever expect computers to evolve.
Yeah... hardware/software working together. Not exactly new. In fact, I believe it is impossible to build a useful stored-program computer without it :-)
This is the most content-free article I've ever read. It's basically a press release with an female professor thrown in to boot. Yay.
My bicyles
So, for example, if low power usage is the goal, then instead of fine-tuning the hardware for low power usage, and then also tuning the software for low power usage (e.g. getting rid of unnecessary loops, checks, etc.), the strategy would be to create specific hooks in the hardware system (accessible via the OS and/or a driver, of course) to allow this fine-tuning. Nowadays we have chips that can regulate themselves so that they don't use excessive power. But it could be even more efficient if the software were able to signal the hardware, for instance differentiating between "I'm just waking up to do a quick, boring check--no need to scale the CPU up to full power" versus "I'm about to start a complex task and would like the CPU ramped up to full power."
They claim to have some encouraging results. From one of the abstracts: Obviously the idea of having software and hardware interact is not new (that's what computers do, after all)... but the intent of this project is, apparently, to push much more aggressively into a realm where optimizations are realized by using explicit signaling between hardware and software systems. (Rather than leaving the hardware or OS to guess what hardware state is best suited to the task at hand.)
Finally, the two arch nemesis: software and hardware, will live together in symbiosis. Never before you have seen software and hardware working together.
Now this article demonstrates that what was before unthinkable, may tommorow be a commodity, and we will finally be able to run software on our hardware.
Transmeta style code morphong? Firmware? OS? VM? Microcode?
First off, it's a Roland the Plogger story, so you know it's clueless. Roland the Plogger is just regurgitating a press release.
Here's an actual paper about the thing. Even that's kind of vague. The general idea, though, seems to be to insert a layer of code-patching middleware between the application and the hardware. The middleware has access to CPU instrumentation info about cache misses, power management activity, and CPU temperature. When it detects that the program is doing things that are causing problems at the CPU level, it tries to tweak the code to make it not do so much bad stuff. See Power Virus in Wikipedia for an explaination of "bad stuff". The paper reports results on a simulated CPU with a simulated test program, not real programs on real hardware.
Some CPUs now power down sections of the CPU, like the floating point unit, when they haven't been used for a while. A program which uses the FPU periodically, but with intervals longer than the power-off timer, is apparently troublesome, because the thing keeps cycling on and off, causing voltage regulation problems. This technique patches the code to make that stop happening. That's what they've actually done so far.
Intel's interest seems to be because this was a problem with some Centrino parts. So this is something of a specialized fix. It's a software workaround for some problems with power management.
It's probably too much software machinery for that problem. On-the-fly patching of code is an iffy proposition. Some code doesn't work well when patched - game code being checked for cheats, DRM code, code being used by multiple CPUs, code being debugged, and Microsoft Vista with its "tilt bits". Making everything compatible with an on the fly patcher would take some work. A profiling tool to detect program sections that have this problem might be more useful.
It's a reasonable piece of work on an annoying problem in chip design. The real technical paper is titled "Eliminating voltage emergencies via microarchitectural voltage control feedback and dynamic optimization." (International Symposium on Low-Power Electronics and Design, August 2004). If you're really into this, see this paper on detecting the problem during chip design, from the India Institute of Technology in Madras. Intel also funded that work.
On the thermal front, back in 2000, at the Intel Developer Forum the keynote speaker after Intel's CEO spoke, discussing whether CPUs should be designed for the thermal worst case or for something between the worst case and the average case: "Now, when you design a system, what you typically want to do is make sure the thermal of the system are okay, so even at the most power-hungry application, you will contain -- so the heat of the system will be okay. So this is called thermal design power, the maximum, which is all the way to your right. A lot of people, most people design to that because something like a power virus will cause the system to operate at very, very maximum power. It doesn't do any work, but that's -- you know, occasionally, you could run into that. The other one is, probably a little more reasonable, is you don't have the power virus, but what the most -- the most power consuming application would run, and that's what you put the TDP typical."
From that talk, you can kind of see how Intel got into this hole. They knew it was a problem, though, so they put in temperature detection to slow down the CPU when it gets too hot. This prevents damage,
Does it run Linux?
Thanks for the insight. I really wish the summaries would link to project pages when they're available. I sure don't see a link to the project page from the article - and that's par for the course with news publications any more. I mean really, right under the spot with the reporter's email address would be a great place for it (besides the obvious spot somewhere within the body of TFA...)
more of the same on Twitter.
WTF is a "virtual interface"? Seems like an absolutely superfluous word adornment.
What makes it special is it's driving hits to Roland Piquepaille's blog.
This smells like trying to open the back door to Treacherous Computing to me, just by way of wrapping it up in buzzwords that'll make otherwise wary geeks accept it thinking it'll make their computers somehow go faster.
As for this work, the article summary and the article itself are severely lacking in details. Go to the project page. And yes, people have been doing dynamic translation/optimization for years (Transmeta, Dynamo from HP - which she worked on actually, - rePLAY from UIUC), but it has always been with the intent to improve performance. This work is looking at a much wider scope of problems, and using the binary translation mechanism as a part of the solution. It looks to be in somewhat early stages - not sure specifically what problems they are looking to tackle other than the "dI/dt" problem that's posted on the project page. I'm interested to see what other papers come out of this group though.
...she's hot.
"hardware and software to communicate and to solve problems together"
This is freaking slashdot - could we get something a little more technical in the summaries?
sic transit gloria mundi
Software-controlled hardware scaling already exist IIRC. They've existed in a primitive form since Intel first introduced its "Speedstep" feature on its mobile Pentiums. The OS would control the clockrate of the microprocessor based on the CPU utilization.
Embedded systems (PDA's and cell phones) have had finer and more sophisticated grades of software-controlled frequency and voltage scaling and even software-controlled sleep-states.
I'm not sure why this research project is so special. I suppose since she's trying to form a standard interface, one that both hardware and software designers can independently use (whereas before, hardware designers would have to double as software designers designing the low-level control software and giving embedded software designers a library). But see, with something as customized as microchips, I'm not really sure it's possible to come up with a standard "end-all" interface that will fit all of the features a hardware designer could use.
Then there's the problem of where this software would run. The problem with software-controlled scaling isn't that software doesn't know the workload better (as it does) but rather, how fast can it communicate that information to the hardware? There's an overhead in that communication.
Not that I'm not saying software and hardware aren't merging, but it's not going to be in the realm of new software layers IMO. More likely than not, it'll be a move towards more firmware-based microprocessors with hard-wired core designs and configurable, tile-like co-processors that can be configured using non-volatile memory on startup (and stored in configuration SRAM) much like an FPGA.
Aargh! I accidentally clicked on the link without noticing the submitter- most of Roland's trash gets tagged very quickly, why the delay with this one?
Much Madness is divinest Sense --
To a discerning Eye --
Much Sense -- the starkest Madness
FPGAs are too power-inefficient. If that's your goal you'd better keep the FPGA off for anything that isn't massively data-parallel or you've just lost any advantage you might have had... (People who claim FPGAs are power-efficient are comparing them to doing the same data-parallel computation at n-times the speed on a serial processor.)
A device to let software communicate with hardware? Cool! Why don't we call it a "computer"?
(434) MAR-RIED
Peter predicted that you would "deliberately forget" creation 2000 years ago...
The story presents an example of synergy rather than symbiosis. Just sayin'.
I'm still not amazingly impressed with what you told me... just kind of a "meh". But what bothers me is just how amazingly bad the article is:
Wow, sounds just like firmware. That or drivers, depending on your definition.
Ok, now it sounds like a compiler (and architecture-specific compiler flags), and/or drivers.
What's this? A better way of debugging hardware? Maybe even reprogrammable hardware (like having a chip fab in your box)?
Nope, not even close:
Ok, this would be roughly like simply telling Linux to emulate a math coprocessor, or to emulate the math coprocessor only for the instructions that aren't accurate, and only on a Pentium. I'm not sure, but I think they do this already.
Except, this strikes me as a truly irresponsible way of handling this, bordering on fraud. You paid for a chunk of hardware, and due to a defect, you don't have certain functionality. You can emulate that in software for a performance hit, but really, you were robbed, and you should be able to get a refund/replacement.
Let me put it another way: Suppose someone shipped a video card which didn't work. At all. And when someone pointed this out to them, they shrug and release "updated drivers" which simply run a software renderer. Would you call that progress, or would you call it fraud?
So, turns out that she actually did something cool, but with an article like that, I might never have known. I'd say that an article like that actually hurts more than it helps -- if they had thrown a few more technical terms in there, it might've confused me, but I'd at least be paying attention and looking for more.
Don't thank God, thank a doctor!
I find that CS women look just like women everywhere else on campus. The only significant difference is that there are so few of them, but both of the girls in my freshman CS course were hot enough.
Really, the stereotype of "geek" for either sex is entirely obsolete now.
Don't thank God, thank a doctor!
What is more interestin, however, is that hardware capability is getting richer. Gate arrays etc allow you you build far more intelligent hardware requiring less software control from the main CPU. That makes for more efficient processing.
Engineering is the art of compromise.
From TFA: Hazelwood already has collaborative ties with researchers at Intel and IBM that place her in an ideal position to eventually commercialize the technology her lab develops.
IBM's iSeries computers use a lot of microcode to mediate between OS and hardware, promoting both software and hardware independence. Sounds like the current project is in the same vein.
Why are you so scared of women's sexuality? I was making an insensitive joke, but you are just bitter. You need to get laid more.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
yeah... we call that embedded software engineering at my company.
Same ole' same ole. Move along.
Reinventing either the FPGA or System C. Or both
... smaller computers. I'm very happy withe the form factors beginning at Extended ATX down to picoITX/SBC. Sizes for all my needs. But faster and cheaper, especially the small SBCs and pico/miniITX/felyATX, would be nice.
I'm sure it seemed like a good idea at the time... peices of junk. My old ISA bus modem (with real hardware on it) ran circles around those PCI bus beauties.
waiting for ad.doubleclick.net
When the hardware detects a problem it signals the software. The software knows the location of the problematic code by checking a "last executed branch" register. A dynamic optimizer(software) then re-orders the code in that region and caches it to be used in future passes through that section.
The trick will be getting the dynamic optimizer light-weight enough that it doesn't induce performance hits in and of itself. Also, as an above poster noted, re-ordering code on the fly is fraught with peril. It seems this could have application in general purpose laptops, cellphones, and other non-safety critical gadgets. There should definitely be a bit in the machine control register to switch off the optimizer.
.. but the idea is so old the patent has expired.
Back in the 70s when they replaced the super successful 360 series
they used "microcode" to translate the old 360 instructions into instructions
understood by the new hardware -- and -- are still doing this today for zSeries.
This was a very good thing as the 360 instruction set and associoated tooling
was a work of art.
Old COBOL programmers never die. They just code in C.
Programs could be accelerated if computers had FPGAs as standard components.
There. Fixed that for you.
Yeah, this sounds like an idea to enhance the concept of a Hypervisor; develop functionality for better "error-handling". Initially, I thought this was a rather-impressive idea; most-likely since embedded-systems intrigue-me. ...yet after more-thought, the only way I could see this as beneficial would be to create a similar magic to the sheer-awe IBM revealed with microcode. Though the issue with insuring that this sort of implementation doesn't "hinder" performance right from the get-go, perplexes-me. In other-words, the only thing that I see when I think of such an idea, is a Vista-like microcode - gobbling up resources just to satisfy its own needs.
Obviously (per the idea), the architecture of the Hardware would be to work in-tandem with the Software - but with all of the time Commercial-Manufacturing cuts-out with "cutting-corners", I could only hope for this to "materialize".