Is it time to stop research in Computer Architecture ?
|
From: "Andy "Krazy" Glew" on 27 Oct 2009 01:09 Bernd Paysan wrote: > Sidenote about reversible computing: Often, people use a "history" to > make storing values in memory reversible. However, creating information > is just as costly as destroying it, so creating a history has no energy > benefit over replacing old information in a memory cell. The only > energy efficient reversible memory operation is to swap memory and > register values. This has always been where I get annoyed by theorizing about reversible computation. Seems to me that you cannot do reversible computation for workloads where you are streaming inputs; where the inputs exceed any reasonable memory size. Since that is one of the most interesting classes of computation, ipso facto not that interesting. The counter argument is usually that the irreversible aspects of compuation are related to communication: e.g. on a space probe where you are beaming something back to earth. Nevertheless, I don't see why we have to go for full irreversibility, if by taking advantage of such techniuqes we can acheive a good fraction, albeit still much worse than theoretically possible.
From: Torbjorn Lindgren on 27 Oct 2009 03:53 Terje Mathisen <terje.wiig.mathisen(a)gmail.com> wrote: >On Oct 23, 1:45�pm, Mayan Moudgill <ma...(a)bestweb.net> wrote: >> Andy "Krazy" Glew wrote: >> Problem is with the standard. H.264 specifies that the frame is CABAC >> encoded. > >Not quite: > >H.264 defines two alternate encoding schemes, of which CABAC gets the >better compression, but it is fully compliant to use the other (I >don't remember the name of it) if the encoder wants to. CAVLC. Supposedly CABAC uses about 15% less bits than CAVLC, which in turn is more efficient than what's used in regular MPEG4. >However, since a decoder has to be able to handle CABAC as well, that >limits the maximum bitrate that you can support in sw. CABAC decode support is required in most profiles but not CBP, BP and XP. Most stuff is Main or High profile though, but there are devices which doesn't support MP or HP (nor CABAC).
From: Torbjorn Lindgren on 27 Oct 2009 04:35 Terje Mathisen <Terje.Mathisen(a)tmsw.no> wrote: >Andy "Krazy" Glew wrote: >> For example: divide the image up into subblocks, and run CABAC on each >> subblock in parallel. To obtain similar compression ratios you would > >This is the only silver lining: Possibly due to the fact that they were >working on PS3 at the time, Sony specified that Bluray frames are all >split into 4 independent quadrants, which means that they could >trivially split the job across four of the 7 or 8 cell cores. I'm reliably informed that it's a bit more complicated than that. Also, I'm not sure if the slices are affect the (CABAC) bit stream, my impression was that it did not but I'm no expert. Apparently for h.264 Blu-ray supports High Profile Layer 4.1, EXCEPT with at least 4 slices (special restrictions) and lower maximum bitrate (which then gives smaller VBV buffer space and VBV max instantaneous speed) than real Layer 4.1. There's also very strict limitations on distance between keyframes also. Or High Profile Layer 4.0. This does have a significatly lower max bitrate, but x264 can cram a LOT of information into that with good settings (apparently much more than very expensive h.264 encoders) and the difference is smaller than it would normally be (because Blu-ray doesn't allow full 4.1 bitrate anyway). It has the same restrictons on keyframes (they're relaxed slightly for Level 3.1 or lower). I think recent versions of x264 actually supports slices now and that the compression hit was very small, but on the other hand some of the devs thought you usually were actually better of encoding in L4.0 instead for Blu-ray on x264. But it's pretty common to see hardware decoders handle Level 4.0, but 4.1 for Blu-ray. This usually means it can handle the Blu-ray subset but not the full bitrate, but note that they usually don't care if the video is sliced or not. >This also reduced the size of each subframe, in 1080i, to 256 K pixels. :-) I'm told that they stopped decoding slices separately on the PS/3 before launch, apparently it was more efficient even on that hardware to work on multiple frames in parallel instead. Especially since they needed to handle non-sliced L4.0 anyway, though at a lower bit-rate. I don't have a PS/3 but several people say it shows high-speed L4.1 non-sliced (but otherwise Blu-ray spec'd) h.264 video without problem, but it's always possible that it works on most but not all video.
From: Robert Myers on 27 Oct 2009 05:20 On Oct 25, 5:26 pm, Bernd Paysan <bernd.pay...(a)gmx.de> wrote: > Sidenote about reversible computing: Often, people use a "history" to > make storing values in memory reversible. However, creating information > is just as costly as destroying it, so creating a history has no energy > benefit over replacing old information in a memory cell. The only > energy efficient reversible memory operation is to swap memory and > register values. > This problem does seem fundamental to me at my current level of understanding, and the history tape argument seems fundamentally flawed. Sooner or later, you must overwrite something and throw it away. When you do that, the process is no longer reversible and you incur an irreversible energy cost. If at no other time, you will incur that cost when you write your backup tape of the history to the incoherent, "classical" world. I'm sure that there are others who have thought about this much more carefully than I have, but, if there is a way around it, I'm not seeing it at the moment. Robert.
From: =?ISO-8859-1?Q?Niels_J=F8rgen_Kruse?= on 29 Oct 2009 09:59
Andy "Krazy" Glew <ag-news(a)patten-glew.net> wrote: > Heck: Willamette / Pentium 4 was brought to you by peopled who thought > OOO was a bad idea. The original concept was anti-OOO. They were > forced to implement OOO, badly, because the anti-OOO approach did not fly. News to me. I suppose NDAs have expired. -- Mvh./Regards, Niels J�rgen Kruse, Vanl�se, Denmark |