Ah yes, but then I will patent the process of soaking the paper in ordinary bleach and then drying it, thus rendering the paper white and the ink blue. Muahaha.
And NOW look at those Goths. They just lurk around, wearing black, with their piercings and dyed hair and smoking those damned clove cigarettes! Turning their backs on centuries of glorious slaughter and pillage! Now they just play depressing music and work at Starbucks.
Still I have yet to get penis enlargement mailings in my mailbox.
Apart from the Playboy magazines, you mean?
The problem with overcooling async logic
on
Clockless Computing
·
· Score: 2, Interesting
The problem with slapping active cooling on an asynchronous chip is that the chip will *stop* working if it gets too cold, just like if it gets too hot.
Here's why:
There are two main aspects to consider in an asynchronous chip, gate delay (the time for a gate to open/close) and propagation delay (the time it takes for a signal to go from one gate to the next).
Asynchronous logic works by carefully arranging the length and geometry of the wiretraces between gates, so that the signals coming from those traces all hit their target gate (nearly) simultaneously.
The problem is that gate delays are affected by temperature differently than propagation delays. They both get faster with cooling, and slower with heating, but they do so nonlinearly, and at *different rates*. And asynchronous logic requires those rates to be carefully matched. Change the rates too much, and the chip breaks.
Synchronous logic doesn't have this problem (as much), because the whole point of latching everything between clock cycles is to give the slower signals time to catch up to the faster ones, and to force them all to wait up until everybody is ready (at which point the clock releases the latch, and the next cycle starts). But this has the downside of the extra wiring, circuitry, and power required to run all the clock lines and latches.
Are you scared that there's stuff in your body
that all of humanity, in all of history, still
hasn't figured out? Empirically trying things and evolving better
methods has worked for the past umpteen million
years, it's kind of odd to start complaining
about it now.
With a bit of elbow grease, you can play DiabloII under WINE, with quite adequate performance. Can't use battle.net though- only single-player. You also have to download a game crack, since the CD authentication doesn't work properly. Yes, I bought a legal copy.
Back in the day, the copy protection of games used to take the form of a booklet full of codes, which the user would have to refer to at certain points in the game to be able to continue. These booklets were printed with black ink on dark red paper, which made them pretty photocopy-proof.
Until you bleached the booklet. Which left clearly readable (and photocopyable) text. The text was actually *easier* to read afterwards, due to the better contrast.
Not that I'm suggesting that anybody bleach their SDMI-enabled hardware (although now that I think of it, it seems like a pretty good idea to me).
There is also significant cost in terms of minimum die size for a given pin count. A chip simply has to be at least a certain size to fit a certain number of pins. That's fine if you wind up using all of that silicon, but you could theoretically wind up with a bunch of extra (and expensive) space if your processor logic doesn't need all the silicon that it *has* to have because of its pinout.
This was actually the driving force behind that Micron DDR chipset with 8MB of on-chipset cache a few months ago. Their chip's logic took up only a small fraction of the die size which was necessary for the number of pins the die had, so they filled up the rest of the space with (effectively free) cache. But I can bet you that they'd rather have made the die smaller instead, except that wasn't an option.
Now, if you're proposing to double/quadruple datapath width, you're talking a significant increase in pincount, and thus a significant increase in die size, even if the chip doesn't need to be much more complex. You could possibly take advantage, as Micron did, of the sudden increase in available real estate, but the bottom line is that the chip will be more expensive and the motherboard will be more expensive as a direct result of widening the datapath.
The short answer to #2 is that each layer of associativity (2-way, 4-way, 8-way, etc) introduces a *theoretical minimum* of one gate delay to the cache logic, and actually it's more. Also there are diminishing returns involved. There's a similar problem with just making larger caches, where each successive doubling of cache size has a consequence of slowing the responsiveness of the cache, because of a similar added-gates-to-critical-path problems. Size and associativity both increase latency. Optimal cache design takes into account how much latency can be afforded, then balances both the associativity and cache size to maximize the cache hit rate as much as possible, in as many different circumstances as possible.
The short answer to #3 is that the odds of reusing instructions is much higher than reusing data. memcpy is the ultimate example of this, where you have a tight loop doing nothing but reading and writing huge swathes of data. If your instruction cache is separate from your data cache, your instructions will never be bumped out by the reams of data that they are processing.
The short answer to #4 is that it distracts the slower caches too much. They should be available to handle whatever glacial tasks they already have queued up (like writing back dirty cache lines, etc) rather than waste their time doing lookups before they're *sure* that they need to.
I don't have any short answers to the other questions.
The methane produced from those organic products had better be *very* pure. Fuel cells are notorious for handling impurities poorly- impurities bind to the catalytic surfaces of the fuel cell and degrade its performance.
However, Angband also has Ben Harrison, who did an extensive rewrite of the game making it an extremely easy framework to hack around. I've done my own hacking on the Angband source, and it was *so* easy to find and change little parts of the code, and then *see* results. I guess the point that I'm trying to get across here is "low barrier to entry"- I'm a fairly experienced programmer, but I didn't *need* to be in order to play with the Angband code.
It also reminds me of a best-of-usenet post I saw once, where somebody thought a little bit about the scene from _Fellowship_of_the_Ring_ where they throw the One Ring into the fireplace and it's still cool to the touch when they pull it out. They theorized that the *real* reason that Sauron wanted the One Ring back was to use it as a heatsink for the main MordorNet CPU...
This is actually less secure than you think. DRAM has memory too- if a given RAM cell is used to continuously store the same bit for long periods of time, if power is removed and then restored, it will tend to return to that state on powerup, rather than powering up randomly to either 0 or 1.
This is a known problem for battery-backed RAM crypto key storage systems- attackers can make statistical guesses about the bits of the key which was stored in the BBRAM (before the attacker got hold of it) by repeatedly powering up the BBRAM and reading the result.
If you keep the same data in the same place in your ramdisk for extended periods of time, and then shut the power off when the FBI comes a'knockin, the FBI could theoretically take the RAM out of your computer, put it into a test bed to see how it powers up, and then analyze the results to recover some fraction of your data. You can partially avoid this problem if you shuffle the RAM disk around on a frequent basis.
The amount of petroleum which is used for plastic is an amazingly insignificantly small fraction of the amount of petroleum which is distilled and then set on fire. So when we've depleted oil reserves to such a point that it is no longer economically viable to extract petroleum for fuel, those tiny, insignificant (on the scale of the fuel industry) dregs which remain would still be enough to make a whole *lot* of plastic.
Actually, I disagree. The article's author is doing an excellent job of pointing out how focussed people can get about trivial issues.
I personally eat meat. I wear leather. I even buy consumer products made in third-world countries by malnourished wage-slave labor. But I'm okay with all of that, because I'm a callous, insensitive, arrogant prick. However, I agree with the author, in feeling that people who condemn fictional violence and then go home and have a nice juicy steak are somewhat lacking in a sense of proportion.
They solve the problem by mounting the flywheels on gimbals. When you turn the car, the gimbals allow the flywheel to maintain its axis without jerking the car around. This was described in the Scientific American article referenced above. I read it ages ago, but remember it because it was so cool!
They also use the wheel's own momentum to power the electromagnets used to suspend the flywheel in its chamber, which I thought was rather elegant.
BGAs are pretty much permanent installations. I believe that there are clamshell sockets available for this kind of thing though. Bigger and bulkier, but you can just open up the socket and replace the chip if you need to.
Overall, BGAs aren't all they are cracked up to be. The production processes are very finicky. It's hard to get all the solder balls to form acceptable welds, and the welds aren't particularly durable in any case. Flexing a board with a BGA chip can very easily loosen or break a solder connection, causing intermittent or permanent failure, respectively.
Wouldn't a patent cross-license imply that *all* Linux code used in OpenLinux would be immune to patent infringement? I don't know if the GPL would permit the inclusion of patent-encumbered code without an accompanying explicit no-fee license, since to do otherwise would be restricting the recipient's ability to further redistribute the code. And if MSFT's patent agreement *prohibited* such redistribution, then such a patent agreement would therefore be utterly worthless except when applied to proprietary Caldera code.
This is an extremely naive position. A computer could easily detect your above text as being the clear text (or one of a small number of potential clear texts) simply by virtue of all the characters being 7-bit ASCII (i.e. highest-order bit is always zero). For a message of n bytes, there is only a 1 in 2^n chance that a given key will result in a legal 7-bit ascii message. Your string was 84 characters long, so if you were using a 128 bit key, you could expect about 2^44 potential plaintexts, which would be much simpler to brute force. And this is using a very naive plaintext recognition method- a more sophisticated method would also, say, put more weight on the occurrence of whitespace, and require a certain minimum number of whitespace characters to qualify.
A better method might be to compress the text first, but then you are vulnerable to attacks on the formatting used by the compression method (looking at the headers, symbol tables, etc).
No, quantum bits can be any probabilistic combination of 0 and 1. You could have a qubit which was 50% 0 and 50% 1, or 90% 0 and 10% 1, or any other such combination. There's an infinite number of possible qubit values.
Slashdot Mirror
Ah yes, but then I will patent the process of soaking the paper in ordinary bleach and then drying it, thus rendering the paper white and the ink blue. Muahaha.
Yes, this really does work.
And NOW look at those Goths. They just lurk around, wearing black, with their piercings and dyed hair and smoking those damned clove cigarettes! Turning their backs on centuries of glorious slaughter and pillage! Now they just play depressing music and work at Starbucks.
Another fine culturual heritage down the drain.
Pop up a dialog:
"It looks like you are trying to hack into this system. Would you like me to start the Hacking Wizard for you?"
Still I have yet to get penis enlargement mailings in my mailbox.
Apart from the Playboy magazines, you mean?
The problem with slapping active cooling on an asynchronous chip is that the chip will *stop* working if it gets too cold, just like if it gets too hot.
Here's why:
There are two main aspects to consider in an asynchronous chip, gate delay (the time for a gate to open/close) and propagation delay (the time it takes for a signal to go from one gate to the next).
Asynchronous logic works by carefully arranging the length and geometry of the wiretraces between gates, so that the signals coming from those traces all hit their target gate (nearly) simultaneously.
The problem is that gate delays are affected by temperature differently than propagation delays. They both get faster with cooling, and slower with heating, but they do so nonlinearly, and at *different rates*. And asynchronous logic requires those rates to be carefully matched. Change the rates too much, and the chip breaks.
Synchronous logic doesn't have this problem (as much), because the whole point of latching everything between clock cycles is to give the slower signals time to catch up to the faster ones, and to force them all to wait up until everybody is ready (at which point the clock releases the latch, and the next cycle starts). But this has the downside of the extra wiring, circuitry, and power required to run all the clock lines and latches.
Are you scared that there's stuff in your body that all of humanity, in all of history, still hasn't figured out? Empirically trying things and evolving better methods has worked for the past umpteen million years, it's kind of odd to start complaining about it now.
Before Iridium went under, an Iridium phone with a fully charged battery would be tops on my list. Just let me make a quick phone call...
Round it off with a crate of MREs and a crate of bottled water and I'm good to go until the rescue team shows up.
With a bit of elbow grease, you can play DiabloII under WINE, with quite adequate performance. Can't use battle.net though- only single-player. You also have to download a game crack, since the CD authentication doesn't work properly. Yes, I bought a legal copy.
Back in the day, the copy protection of games used to take the form of a booklet full of codes, which the user would have to refer to at certain points in the game to be able to continue. These booklets were printed with black ink on dark red paper, which made them pretty photocopy-proof.
Until you bleached the booklet. Which left clearly readable (and photocopyable) text. The text was actually *easier* to read afterwards, due to the better contrast.
Not that I'm suggesting that anybody bleach their SDMI-enabled hardware (although now that I think of it, it seems like a pretty good idea to me).
There is also significant cost in terms of minimum die size for a given pin count. A chip simply has to be at least a certain size to fit a certain number of pins. That's fine if you wind up using all of that silicon, but you could theoretically wind up with a bunch of extra (and expensive) space if your processor logic doesn't need all the silicon that it *has* to have because of its pinout.
This was actually the driving force behind that Micron DDR chipset with 8MB of on-chipset cache a few months ago. Their chip's logic took up only a small fraction of the die size which was necessary for the number of pins the die had, so they filled up the rest of the space with (effectively free) cache. But I can bet you that they'd rather have made the die smaller instead, except that wasn't an option.
Now, if you're proposing to double/quadruple datapath width, you're talking a significant increase in pincount, and thus a significant increase in die size, even if the chip doesn't need to be much more complex. You could possibly take advantage, as Micron did, of the sudden increase in available real estate, but the bottom line is that the chip will be more expensive and the motherboard will be more expensive as a direct result of widening the datapath.
johnthomas
The short answer to #2 is that each layer of associativity (2-way, 4-way, 8-way, etc) introduces a *theoretical minimum* of one gate delay to the cache logic, and actually it's more. Also there are diminishing returns involved. There's a similar problem with just making larger caches, where each successive doubling of cache size has a consequence of slowing the responsiveness of the cache, because of a similar added-gates-to-critical-path problems. Size and associativity both increase latency. Optimal cache design takes into account how much latency can be afforded, then balances both the associativity and cache size to maximize the cache hit rate as much as possible, in as many different circumstances as possible.
The short answer to #3 is that the odds of reusing instructions is much higher than reusing data. memcpy is the ultimate example of this, where you have a tight loop doing nothing but reading and writing huge swathes of data. If your instruction cache is separate from your data cache, your instructions will never be bumped out by the reams of data that they are processing.
The short answer to #4 is that it distracts the slower caches too much. They should be available to handle whatever glacial tasks they already have queued up (like writing back dirty cache lines, etc) rather than waste their time doing lookups before they're *sure* that they need to.
I don't have any short answers to the other questions.
The methane produced from those organic products had better be *very* pure. Fuel cells are notorious for handling impurities poorly- impurities bind to the catalytic surfaces of the fuel cell and degrade its performance.
However, Angband also has Ben Harrison, who did an extensive rewrite of the game making it an extremely easy framework to hack around. I've done my own hacking on the Angband source, and it was *so* easy to find and change little parts of the code, and then *see* results. I guess the point that I'm trying to get across here is "low barrier to entry"- I'm a fairly experienced programmer, but I didn't *need* to be in order to play with the Angband code.
It also reminds me of a best-of-usenet post I saw once, where somebody thought a little bit about the scene from _Fellowship_of_the_Ring_ where they throw the One Ring into the fireplace and it's still cool to the touch when they pull it out. They theorized that the *real* reason that Sauron wanted the One Ring back was to use it as a heatsink for the main MordorNet CPU...
This is actually less secure than you think. DRAM has memory too- if a given RAM cell is used to continuously store the same bit for long periods of time, if power is removed and then restored, it will tend to return to that state on powerup, rather than powering up randomly to either 0 or 1.
This is a known problem for battery-backed RAM crypto key storage systems- attackers can make statistical guesses about the bits of the key which was stored in the BBRAM (before the attacker got hold of it) by repeatedly powering up the BBRAM and reading the result.
If you keep the same data in the same place in your ramdisk for extended periods of time, and then shut the power off when the FBI comes a'knockin, the FBI could theoretically take the RAM out of your computer, put it into a test bed to see how it powers up, and then analyze the results to recover some fraction of your data. You can partially avoid this problem if you shuffle the RAM disk around on a frequent basis.
The amount of petroleum which is used for plastic is an amazingly insignificantly small fraction of the amount of petroleum which is distilled and then set on fire. So when we've depleted oil reserves to such a point that it is no longer economically viable to extract petroleum for fuel, those tiny, insignificant (on the scale of the fuel industry) dregs which remain would still be enough to make a whole *lot* of plastic.
Actually, I disagree. The article's author is doing an excellent job of pointing out how focussed people can get about trivial issues.
I personally eat meat. I wear leather. I even buy consumer products made in third-world countries by malnourished wage-slave labor. But I'm okay with all of that, because I'm a callous, insensitive, arrogant prick. However, I agree with the author, in feeling that people who condemn fictional violence and then go home and have a nice juicy steak are somewhat lacking in a sense of proportion.
They solve the problem by mounting the flywheels on gimbals. When you turn the car, the gimbals allow the flywheel to maintain its axis without jerking the car around. This was described in the Scientific American article referenced above. I read it ages ago, but remember it because it was so cool!
They also use the wheel's own momentum to power the electromagnets used to suspend the flywheel in its chamber, which I thought was rather elegant.
The reason that Mattel has classified these pages as nudity is because they are all pointing out how the Emperor isn't wearing any clothes...
BGAs are pretty much permanent installations. I believe that there are clamshell sockets available for this kind of thing though. Bigger and bulkier, but you can just open up the socket and replace the chip if you need to.
Overall, BGAs aren't all they are cracked up to be. The production processes are very finicky. It's hard to get all the solder balls to form acceptable welds, and the welds aren't particularly durable in any case. Flexing a board with a BGA chip can very easily loosen or break a solder connection, causing intermittent or permanent failure, respectively.
Wouldn't a patent cross-license imply that *all* Linux code used in OpenLinux would be immune to patent infringement? I don't know if the GPL would permit the inclusion of patent-encumbered code without an accompanying explicit no-fee license, since to do otherwise would be restricting the recipient's ability to further redistribute the code. And if MSFT's patent agreement *prohibited* such redistribution, then such a patent agreement would therefore be utterly worthless except when applied to proprietary Caldera code.
This is an extremely naive position. A computer could easily detect your above text as being the clear text (or one of a small number of potential clear texts) simply by virtue of all the characters being 7-bit ASCII (i.e. highest-order bit is always zero). For a message of n bytes, there is only a 1 in 2^n chance that a given key will result in a legal 7-bit ascii message. Your string was 84 characters long, so if you were using a 128 bit key, you could expect about 2^44 potential plaintexts, which would be much simpler to brute force. And this is using a very naive plaintext recognition method- a more sophisticated method would also, say, put more weight on the occurrence of whitespace, and require a certain minimum number of whitespace characters to qualify.
A better method might be to compress the text first, but then you are vulnerable to attacks on the formatting used by the compression method (looking at the headers, symbol tables, etc).
No, quantum bits can be any probabilistic combination of 0 and 1. You could have a qubit which was 50% 0 and 50% 1, or 90% 0 and 10% 1, or any other such combination. There's an infinite number of possible qubit values.
If they were really calling them "wizzards", then they would probably be infringing on Rincewind's copyright...
Will the URL contain 00 or 100? Slash runs on Perl, you know.
John Flanagan