What happened to computer architecture (and comp.arch?)
|
Prev: VMWare tools killed my Mac OS X ?
Next: Software vs hardware floating-point [was Re: What happened ...]
From: "Andy "Krazy" Glew" on 2 Oct 2009 10:15 Robert Myers wrote: > On Oct 2, 12:56 am, "Andy \"Krazy\" Glew" <ag-n...(a)patten-glew.net> > wrote: > >> That about as close as you come to a win in the "First, do no harm" contest. > > A virtual machine doesn't have to be stupid, though. Or, rather, the > user of the virtual machine doesn't have to be stupid. All the > unnecessary software cruft can be pushed off the stage like movable > scenery when it's not helpful or at least when it's extremely > harmful. That's one nice thing about virtual machines. They can > mimic reconfigurable hardware. And like reconfigurable hardware, they pay a basic cost: the circuitry that is reconfigurable has extra wires and switches. If you do that at really fine grain, it is at least 4x more expensive / 4x more slower. (I just asked an expert - he says more like 16x.) You're talking about Java / Jim Smith style virtual machines above. Binary translation and all that. The scene changes are a basic cost. Plus, the eventual substrate - what you are executing on when the curtains come up - also matters. By the way, that's been my chief quibble with binary translation VM people: they want you to add all of this hardware support for BT, and so often end up translating to a target machine, a substrate, that is a fairly conventional RISC or VLIW. This sort of VM usually doesn't make sense unless the target machine also makes sense if you don't need BT. (Not 100% true, but most present BT technology only brings value in translation a legacy ISA.) > It sounds like the proposals are too expensive no matter how they are > implemented, hard or soft. Like I said: some people are willing to pay 15% to get HardBound/SoftBound security. Some are not. So long as, when you do not need the security, you pay as close to nothing as possible - then I am happy. If you have dedicated hardware, you can't remove it, but you can clock gate it. It is an interesting proposal to consider implementing the HardBound checking logic in reconfigurable logic - so that it can actually be regained and used for something else when not needed. I'm tempted to say Tensilica style just because people may know them - although my own work in the area predated Tensilica (and was communicated to at least person who I believe subsequently became an early Tensilica employee). (God, I hate it that I have to add these caveats that will lead to ratholes, just because if I don't it might one day be quoted in court. I think that I will start providing links to a web page full of disclaimers.) Unfortunately, in general purpose CPUs, the case for reconfigurable logic has not been made. HardBound may be the first good example.
From: Mayan Moudgill on 2 Oct 2009 10:25 Andy "Krazy" Glew wrote: > Myself, I refer people to the HardBound and SoftBound papers, that > quotes a much lower than 2x performance cost. More like 1.15x. I think > that is a reasonable tradeoff. > Data point: PL.8 had dynamic checking of all array bounds. I have two numbers stuck in my head, I don't know which one is correct: 1-2% and less than 8%. This was on mid-90s hardware, but I expect the results will hold. Either way, its less that the 15% you're quoting.
From: kenney on 2 Oct 2009 12:14 In article <ha2t0s$j85$1(a)smaug.linux.pwf.cam.ac.uk>, nmm1(a)cam.ac.uk () wrote: > I.e. that a client won't get > unhappy if the real time it sees isn't continuous. Well for real time systems you would probably using a real time micro controller not a virtual machine. You would also be using a language that did not use garbage collection or anything else that resulted in unpredictable latency. Numerically controlled machine tools did not have a high level operating system for just those reasons. I believe that real time systems have different constraints compared with a word processor or a spreadsheet. For multiple processors the VM should hide form applications the fact that parts of it are running on different processors. In other words parralism is handled by the VM or the OS not by the application, something that is easier said than done especially as the number of cores increase. Ken Young
From: Jeremy Linton on 2 Oct 2009 12:57 nmm1(a)cam.ac.uk wrote: > I wrote some MPI code to enable MPI processes to synchronise their > clocks, and estimate the consistency. One of the things that it .... > Now, one thing that almost all virtual machine implementations > assume is that they can suspend a client for short but frequent > intervals, to do something else. I.e. that a client won't get > unhappy if the real time it sees isn't continuous. There are > parallel emulators that emulate real time, but let's inore them, > too. Isn't that the fundamental issue here? Given a multiprocess VM with deterministic behavior against a virtual clock. Within the granularity of that virtual clock, the algorithm would work. The problems happen when you try to map the virtual clock to a "real" clock. Aren't we just discussing "time" determinism, and the complete lack thereof in an unsynchronized virtual machine (and I guess most physical machines)? For those machines, its impossible to make any kind of judgment at _all_ with respect to a "real" clock. Especially when you consider the machine may be stopped and stored as a resumable image. Furthermore, I would assume an algorithm that fails on a VM, is likely to fail on a real machine given the right circumstances. For instance, what happens when some component on a real machine goes to sleep and takes a fairly long time to resume. Better yet, the memory region your lock is contained in, was paged to disk. Isn't this just a restatement of the idea, that given a synchronization primitive only guaranteed to make forward progress. Any application which makes assumptions about fairness, ordering, or runtime is probably broken?
From: nmm1 on 2 Oct 2009 14:09
In article <ha5bdk$e07$1(a)aioe.org>, Jeremy Linton <reply-to-list(a)nospam.org> wrote: > > Isn't that the fundamental issue here? Given a multiprocess VM with >deterministic behavior against a virtual clock. Within the granularity >of that virtual clock, the algorithm would work. You're still thinking serially :-( There are three problems, of which you considered two: the above, and the 'suspension' issue. The third is global consistency, of the form that occurs in special relativity. Regards, Nick Maclaren. |