This comment is way over the top. It's also wrong.
Whoever you are, you read the first page, skimmed the rest, then posted a rant at slashdot. How typical.
At any rate, Nate most certainly did go into the layer 7 stuff--opening up the payload and using that capability to reassemble individual email messages and so on. You just missed it because you were skimming in anticipation of composing that great smack-down post where you display your glorious knowledge of DPI for all of slashdot.
At any rate, instead of giving out reading suggestions, why don't you go back and actually RTFA, chief.
Maybe you should do more than just skim the article and post an ill-informed flame. In the article, I blame the problems specifically on the complexity of dealing with programmer-managed memory hierarchy, and I give some of my reasoning.
As for your specific comments about the classes of problems that do or don't map well onto a GPU, I've covered those issues in previous posts on the topic. The post you're trying to criticize wasn't about the kinds of problems that you can and can't solve efficiently with GPUs--it was about the vendor-supplied tools for programming them.
Ok, cracks about my (in)famous lack of humility aside, you have a great point. This article took me a week from concept to execution, and over half that time was spent making the diagrams. Ultimately, I did a little over two days of basic technical research for this (including email correspondence with security experts in this area). I am not an infosec expert and I don't pretend to be--I'm just good at digesting tech info and turning it into a form that a non-specialist audience can grasp.
There are many Slashdot readers who could get up to speed on how to really steal an election in about half a day (or less) using publicly available documentation. The hardware isn't that complex at all, and the vulnerabilities in Windows (for the GEMS server) and WinCE (for the machine) are very well-known.
What I've described here is very, very low-hanging fruit for anyone with real security expertise.
"Hoisting of loads from an unknown address is now performed more speculatively than it used to be, at the cost of some complexity in the retirement unit."
I think you mean, "hoisting of loads above a/store to/ an unknown address." If you're going to pretend to school little old clueless me about the complexities of memory reordering and retirement then at least learn the difference between a load and a store.
It's not true that the article is partially paid-only. None of Ars Technica's content is paid only, either partially or wholly. You can pay for a PDF of it, but you get the HTML content for free.
There was some Wired bashing in the related Ars thread that I didn't really agree with, and it looks like that theme has been picked up by the slashdot poster. Just to clarify before this degenerates into a pile-on, this article was intended as sardonic, tongue-in-cheek humor. It wasn't intended as a slam on Wired or as a slam on any of the engineers whose hard work I ridiculed mercilessly. If it was a slam on anything, it was a slam on The Future, which has never really been all that it's cracked up to be.
Ok, this appears to be a hasty mistake on my part. The author has emailed me and shown that these two links were posted in the same thread in the Beyond3D message board, which he frequents. He also claims to have put other links in the post, which were then edited out by the/. guys. I'll give him the benefit of the doubt, and I apologize for jumping to conclusions and calling him a putz.
(P.S. I know this was sort of unprofessional behavior on my part, but this kind of thing happens all the time and every now and then it gets to you and you fly off the handle a bit. Sometimes, we embedd little joke codes in the URL, if the linked sites CMS permits it. So if you see a link with NO_YUO at the end or something, then you know where it came from.)
If you're going to rip the links out of one of my Ars news posts and submit them to slashdot (in the same order in which I linked them, no less), then at least credit your source.
Tim O'Reilly posted a clarification to this story in the Ars discussion thread attached to the post. He's the one who asked the original question about the Mac port, and the answer he heard was much more equivocal and less certain than what Reuters is reporting. Be sure and check the post again to get the update.
Believe it or not, our article web pages are statically served. It may be low-tech, but it's cheap, scalable (for our volume of output), and the server can take a licking and keep on ticking. So the server doesn't even bat an eye at the Slashdot crowd. Now when a major Mac article comes out and the entire online Mac community is trying to load the page at the same time... well, that's the one time when we're maybe thankful for Apple's small market share:0)
The news on the front page, on the other hand, is served dynamically by a CMS.
...you guys will link up my new Prescott article that went live this morning!
(Looking back at this post with the preview function, I'm thinking, "is this a troll, flamebait, informative, funny, all four, or none of the above?" I post, you decide.)
Actually, Alcibiades is more like Ahmad Chalibi. How so? Because as you didn't mention, the reason that the Syracuse expidition was so disastrous was that Alcibiades tipped off the Spartans in advance.
While Alcibiades was sailing toward Syracuse, he and a group of his young cohorts were found guilty (by trial in absentia) of impiety when it was found that they'd been getting drunk and running around cutting the penises off the local shrines of Hermes (no joke). So a ship was sent to fetch Alcibiades and bring him back for punishment.
On his way back, Alcibiades bribed the ship's captain to take him to Sparta instead, where he told the Athenian's plans to the Spartans and gave the Spartans the edge.
Ok, maybe he's not quite like Chalabi, but he's certainly a little worse than Cheney and co. (at least I hope he is). Not that I'm taking up for those clowns...
"Multiple times while reviewing the Efficion architecture the article's author suggests that the tradeoff of additional storage required for Transmeta's code-morphing approach will easily balance out the power savings from making a simpler CPU."
I neither suggest nor imply anything this simplistic. In fact, I go to great pains to show how complicated the whole power picture is for Efficeon.
"This belies a deep misunderstanding of power consumption in digital systems, as readily evidences by the fact that modern non-Transmeta processers dissipate multiple tens of Watts of power (often nearly 100W) and a full complement of memory (4G, in modern machines) dissipates a few Watts at most."
Er... you do realize, don't you, that comparing Efficeon to a 100W processor is not only unfair, but it's stupid and I didn't do it anywhere in the article. A more appropriate comparison is Centrino, which approaches Efficeon in MIPS/Watt without any help at all from any kind of CMS software. I think that you might be the one who needs to learn a bit more about digital systems.
"Also in the article, the author suggests that processors spend most of their time wating on loads, and then argues that since the code-morphing approach means more instruction fetches, the Efficion processor will be spending disproportionatly more time on loads. Then, after this assertion, he admits that he does not know *where* the translated Efficion code is held. Might it be in one-cycle-accessible L1 cache? "
No, it is most certainly all not stored in L1. TM claimed that the original CMS software that came with Crusoe took up about 16MB of RAM, and that this was paged in from a flash module on boot. What I'm not 100% certain of are the exact specs for Efficeon, but I've assumed in this article that they're similar. This is a reasonable assumption, especially given the fact that the new version of CMS contains significant enhancements and is unlikely to be smaller. In fact, it's much more likely to be larger than the original 16MB CMS footprint, especially given that DRAM modules have increased in speed and decreased in cost/MB, which gives TM more headroom and flexibility to increase the code size a bit.
"That point is conveniently sidestepped. He does not understand under what circumstances the profiling takes place, although he regurgitates the sales pitch nicely. He argues that transistors hold the translated code (trying to argue against the transistors-for-software tradeoff) but then does not realize that transistors in memory do not equate transistors in logic (neither in power, as they are not cycled as frequently, nor in speed characteristics)."
Of course I know that transistors in memory are not the same as transistors on the CPU. My point though is that they're still not "free" in terms of power draw, and that it also costs power to both page CMS into RAM and to move it from RAM to the L1. And even having pointed that out, I still don't claim that this cancells out all the power saving advantages of TM's approach.
As far as relying on the sales pitch for info on CMS's profiling, well, TM doesn't exactly release the source for CMS, nor do they provide a detailed user manual for it avialable to the public. As their core technology, details about CMS are highly guarded and the only information that either you or I will likely ever have access to about it is whatever they put in the sales pitch. So I, like everyone else, must draw inferences from their presentations and do the best I can.
Anyway, if you don't like the article, that's fine. But being a hater about it just makes you look lame.
Actually, Ars can handle a thorough slashdotting without even blinking, due to the fact that we serve static HTML--no CMS, database, etc. for the articles.
The problem isn't slashdot, but the fact that the entire Mac community shows up to read major OS X articles like this. So when you add in the slashdot crowd, which normally doesn't even cause the server to flinch (we haven't choked due to the/. effect since about early 1999), with almost all of the Mac users and Mac watchers on the 'net, then the server starts to choke.
I should've been more clear on this point. My real problem with the current G4e situation, aside from the 167 SDR FSB, is the fact that it's a shared bus topology, which is just ridiculous. To my knowledge, there's nothing stopping Apple from putting out a chipset that gives each G4e a dedicated FSB (even if it's still 167MHz SDR) to the chipset.
As far as the low MHz and SDR situation, I've also never been totally convinced that Apple wasn't partially to blame for this either, unless they just have zero clout with Moto SPS.
Ok, I went back and looked at the docs and I think you can in fact disable one of the cores, so this is probably a single-core benchmark, WITH A 32 MB L3 CACHE AND 8GB RAM!!!!
I am aware that the SPEC benchmarks aren't multithreaded. My point is that these benchmarks are for whole systems--the memory subsystem, the FSB, the caches (the 970 has no L3, unlike the Power4) etc.--and not CPUs in isolation, and certainly not CPU cores in isolation.
Anyway, I'm not going to argue this anymore. Real-world benchmarks will bear me out soon enough.
Ok, 'round we go again. There was a big discussion of this on Ars a while back, so I feel like I'm repeating myself. Power4 is multiple dual-core chips stacked together in a single four-chip module to form an 8-way SMP server, so saying that there's only 1 CPU enabled means that there's only 1 two-CPU core enabled. It's impossible to disable the second CPU on a two-CPU Power4 core.
As to whether I know anything about SPEC, read this article:
http://arstechnica.com/cpu/2q99/benchmarking-1.h tm l
In short, taking Power4 benchmarks made on an IBM eServer and claiming that they apply to the 970 is just stupid.
Hey slick, why don't you bother to learn something about Power4 before posting flames? That "1 CPU" model is actually a single-chip SMP device, so there are two Power4 cores there. The 970 is a single Power4 core. Sheesh! Gotta love those clued-out Mac flamers.
Slashdot Mirror
This comment is way over the top. It's also wrong.
Whoever you are, you read the first page, skimmed the rest, then posted a rant at slashdot. How typical.
At any rate, Nate most certainly did go into the layer 7 stuff--opening up the payload and using that capability to reassemble individual email messages and so on. You just missed it because you were skimming in anticipation of composing that great smack-down post where you display your glorious knowledge of DPI for all of slashdot.
At any rate, instead of giving out reading suggestions, why don't you go back and actually RTFA, chief.
Maybe you should do more than just skim the article and post an ill-informed flame. In the article, I blame the problems specifically on the complexity of dealing with programmer-managed memory hierarchy, and I give some of my reasoning.
As for your specific comments about the classes of problems that do or don't map well onto a GPU, I've covered those issues in previous posts on the topic. The post you're trying to criticize wasn't about the kinds of problems that you can and can't solve efficiently with GPUs--it was about the vendor-supplied tools for programming them.
This is a fantastic idea. Look for news on this front tomorrow.
Ok, cracks about my (in)famous lack of humility aside, you have a great point. This article took me a week from concept to execution, and over half that time was spent making the diagrams. Ultimately, I did a little over two days of basic technical research for this (including email correspondence with security experts in this area). I am not an infosec expert and I don't pretend to be--I'm just good at digesting tech info and turning it into a form that a non-specialist audience can grasp.
There are many Slashdot readers who could get up to speed on how to really steal an election in about half a day (or less) using publicly available documentation. The hardware isn't that complex at all, and the vulnerabilities in Windows (for the GEMS server) and WinCE (for the machine) are very well-known.
What I've described here is very, very low-hanging fruit for anyone with real security expertise.
"Hoisting of loads from an unknown address is now performed more speculatively than it used to be, at the cost of some complexity in the retirement unit."
/store to/ an unknown address." If you're going to pretend to school little old clueless me about the complexities of memory reordering and retirement then at least learn the difference between a load and a store.
I think you mean, "hoisting of loads above a
Stay gold, Pony Boy... stay gold.
It's not true that the article is partially paid-only. None of Ars Technica's content is paid only, either partially or wholly. You can pay for a PDF of it, but you get the HTML content for free.
There was some Wired bashing in the related Ars thread that I didn't really agree with, and it looks like that theme has been picked up by the slashdot poster. Just to clarify before this degenerates into a pile-on, this article was intended as sardonic, tongue-in-cheek humor. It wasn't intended as a slam on Wired or as a slam on any of the engineers whose hard work I ridiculed mercilessly. If it was a slam on anything, it was a slam on The Future, which has never really been all that it's cracked up to be.
Ok, this appears to be a hasty mistake on my part. The author has emailed me and shown that these two links were posted in the same thread in the Beyond3D message board, which he frequents. He also claims to have put other links in the post, which were then edited out by the /. guys. I'll give him the benefit of the doubt, and I apologize for jumping to conclusions and calling him a putz.
(P.S. I know this was sort of unprofessional behavior on my part, but this kind of thing happens all the time and every now and then it gets to you and you fly off the handle a bit. Sometimes, we embedd little joke codes in the URL, if the linked sites CMS permits it. So if you see a link with NO_YUO at the end or something, then you know where it came from.)
If you're going to rip the links out of one of my Ars news posts and submit them to slashdot (in the same order in which I linked them, no less), then at least credit your source.
Actually, I was crossing the Alps and got stranded, and had to eat my elephants to survive.
Tim O'Reilly posted a clarification to this story in the Ars discussion thread attached to the post. He's the one who asked the original question about the Mac port, and the answer he heard was much more equivocal and less certain than what Reuters is reporting. Be sure and check the post again to get the update.
Believe it or not, our article web pages are statically served. It may be low-tech, but it's cheap, scalable (for our volume of output), and the server can take a licking and keep on ticking. So the server doesn't even bat an eye at the Slashdot crowd. Now when a major Mac article comes out and the entire online Mac community is trying to load the page at the same time... well, that's the one time when we're maybe thankful for Apple's small market share :0)
The news on the front page, on the other hand, is served dynamically by a CMS.
...you guys will link up my new Prescott article that went live this morning!
(Looking back at this post with the preview function, I'm thinking, "is this a troll, flamebait, informative, funny, all four, or none of the above?" I post, you decide.)
Actually, Alcibiades is more like Ahmad Chalibi. How so? Because as you didn't mention, the reason that the Syracuse expidition was so disastrous was that Alcibiades tipped off the Spartans in advance.
While Alcibiades was sailing toward Syracuse, he and a group of his young cohorts were found guilty (by trial in absentia) of impiety when it was found that they'd been getting drunk and running around cutting the penises off the local shrines of Hermes (no joke). So a ship was sent to fetch Alcibiades and bring him back for punishment.
On his way back, Alcibiades bribed the ship's captain to take him to Sparta instead, where he told the Athenian's plans to the Spartans and gave the Spartans the edge.
Ok, maybe he's not quite like Chalabi, but he's certainly a little worse than Cheney and co. (at least I hope he is). Not that I'm taking up for those clowns...
...were supposed to go under the "Funny" category with the big foot icon. Am I missing something? (Don't answer; it's rhetorical.)
How do you know I'm not black?
"Multiple times while reviewing the Efficion architecture the article's author suggests that the tradeoff of additional storage required for Transmeta's code-morphing approach will easily balance out the power savings from making a simpler CPU."
I neither suggest nor imply anything this simplistic. In fact, I go to great pains to show how complicated the whole power picture is for Efficeon.
"This belies a deep misunderstanding of power consumption in digital systems, as readily evidences by the fact that modern non-Transmeta processers dissipate multiple tens of Watts of power (often nearly 100W) and a full complement of memory (4G, in modern machines) dissipates a few Watts at most."
Er... you do realize, don't you, that comparing Efficeon to a 100W processor is not only unfair, but it's stupid and I didn't do it anywhere in the article. A more appropriate comparison is Centrino, which approaches Efficeon in MIPS/Watt without any help at all from any kind of CMS software. I think that you might be the one who needs to learn a bit more about digital systems.
"Also in the article, the author suggests that processors spend most of their time wating on loads, and then argues that since the code-morphing approach means more instruction fetches, the Efficion processor will be spending disproportionatly more time on loads. Then, after this assertion, he admits that he does not know *where* the translated Efficion code is held. Might it be in one-cycle-accessible L1 cache? "
No, it is most certainly all not stored in L1. TM claimed that the original CMS software that came with Crusoe took up about 16MB of RAM, and that this was paged in from a flash module on boot. What I'm not 100% certain of are the exact specs for Efficeon, but I've assumed in this article that they're similar. This is a reasonable assumption, especially given the fact that the new version of CMS contains significant enhancements and is unlikely to be smaller. In fact, it's much more likely to be larger than the original 16MB CMS footprint, especially given that DRAM modules have increased in speed and decreased in cost/MB, which gives TM more headroom and flexibility to increase the code size a bit.
"That point is conveniently sidestepped. He does not understand under what circumstances the profiling takes place, although he regurgitates the sales pitch nicely. He argues that transistors hold the translated code (trying to argue against the transistors-for-software tradeoff) but then does not realize that transistors in memory do not equate transistors in logic (neither in power, as they are not cycled as frequently, nor in speed characteristics)."
Of course I know that transistors in memory are not the same as transistors on the CPU. My point though is that they're still not "free" in terms of power draw, and that it also costs power to both page CMS into RAM and to move it from RAM to the L1. And even having pointed that out, I still don't claim that this cancells out all the power saving advantages of TM's approach.
As far as relying on the sales pitch for info on CMS's profiling, well, TM doesn't exactly release the source for CMS, nor do they provide a detailed user manual for it avialable to the public. As their core technology, details about CMS are highly guarded and the only information that either you or I will likely ever have access to about it is whatever they put in the sales pitch. So I, like everyone else, must draw inferences from their presentations and do the best I can.
Anyway, if you don't like the article, that's fine. But being a hater about it just makes you look lame.
Actually, Ars can handle a thorough slashdotting without even blinking, due to the fact that we serve static HTML--no CMS, database, etc. for the articles.
/. effect since about early 1999), with almost all of the Mac users and Mac watchers on the 'net, then the server starts to choke.
The problem isn't slashdot, but the fact that the entire Mac community shows up to read major OS X articles like this. So when you add in the slashdot crowd, which normally doesn't even cause the server to flinch (we haven't choked due to the
I was out of town when this interview as posted,but here's my question a little bit late:
Georgy, will you marry me?
I should've been more clear on this point. My real problem with the current G4e situation, aside from the 167 SDR FSB, is the fact that it's a shared bus topology, which is just ridiculous. To my knowledge, there's nothing stopping Apple from putting out a chipset that gives each G4e a dedicated FSB (even if it's still 167MHz SDR) to the chipset.
As far as the low MHz and SDR situation, I've also never been totally convinced that Apple wasn't partially to blame for this either, unless they just have zero clout with Moto SPS.
Ok, I went back and looked at the docs and I think you can in fact disable one of the cores, so this is probably a single-core benchmark, WITH A 32 MB L3 CACHE AND 8GB RAM!!!!
(The 970 has no L3.)
That is all.
I am aware that the SPEC benchmarks aren't multithreaded. My point is that these benchmarks are for whole systems--the memory subsystem, the FSB, the caches (the 970 has no L3, unlike the Power4) etc.--and not CPUs in isolation, and certainly not CPU cores in isolation.
Anyway, I'm not going to argue this anymore. Real-world benchmarks will bear me out soon enough.
Ok, 'round we go again. There was a big discussion of this on Ars a while back, so I feel like I'm repeating myself. Power4 is multiple dual-core chips stacked together in a single four-chip module to form an 8-way SMP server, so saying that there's only 1 CPU enabled means that there's only 1 two-CPU core enabled. It's impossible to disable the second CPU on a two-CPU Power4 core.
h tm l
As to whether I know anything about SPEC, read this article:
http://arstechnica.com/cpu/2q99/benchmarking-1.
In short, taking Power4 benchmarks made on an IBM eServer and claiming that they apply to the 970 is just stupid.
Hey slick, why don't you bother to learn something about Power4 before posting flames? That "1 CPU" model is actually a single-chip SMP device, so there are two Power4 cores there. The 970 is a single Power4 core. Sheesh! Gotta love those clued-out Mac flamers.