Re:Enough speed. Where are massively parallel CPUs
on
Nanotube Transistors
·
· Score: 3
Yes you're describing branch prediction. This is universally used in all modern processors. It gives probably 2x speedup or so in general. What you're describing is a way to follow multiple branch paths when you reach a branch that is hard to predict. Actually, my PhD advisor did a paper on this before http://www-cse.ucsd.edu/users/tullsen/ISCA98.ps
I don't remember the exact numbers, but they probably saw speedups of 15% or less. As you increase the number of paths you follow simultaneously (in your massively parallel processor) the gains speedup. Hell, if you give perfect branch prediction (rendering your optimization unnecessary) you probably will only get 50% speedup maximum. That's a hell of a lot less than the 1000x you'd get from a perfect speedup. Actually, my current research involves ways to use processors similar to what you describe (but much less parallel--8 way at the most) to improve the performance of programs. But trust me, it's not as simple as just waving your hands and saying 'the xxxxx will take care of it'--we've been waiting for compilers to automatically take care of it for more than 10 years and they still aren't very good at it.
Re:Enough speed. Where are massively parallel CPUs
on
Nanotube Transistors
·
· Score: 2
What the hell? Have you ever even done parallel programming? For most programs out there it will be difficult to derive benefit from even 4 processors... much less 1000... I really don't see what gains you expect to occur from having that degree of parallelism...
Well, he did mention that the 100 was to scare off people who weren't serious about it... I mean, I probably would have requested the data if it was free and I knew about the challenge... if he had charged even $1 though, I would have considered it too much trouble...
Well, I don't see this other scheme as a ripoff at all... Even taking your example about fermat's last theorem... what do you care if someone is willing to pay to find out what the theorem is? I mean, there are entrance fees to enter into tournaments all the time... what if I had a quake tournament where the entrance fee was $5 and the winner, if he had been undefeated, would get prize money, otherwise nothing... whats really the difference between the two?
You don't seem to know what a ponzi scheme is... A ponzi scheme is something where the early investors are paid off with money paid in by the later investors. It grows and grows as new people join, and all the early people are happy... but soon, the rate of people joining slows and there isn't enough money to pay off people anymore and the whole thing collapses...
this has nothing to do with that whatsoever...
People often talk about 'the masses' doing a lot of things, but I have yet to see a significant amount of 'the masses' doing anything... especially if it looks like people from 'the masses' stand to lost by doing so... even napster at its height was not so widely in use that you could make such a claim...
People who talk about 'the masses' doing things are either
1) Elitist, and just want to refer to other people as 'the masses'
2) Want something to occur, but won't put their own neck on the line
I seriously doubt it has ever been a common occurance for someone to enforced a patent in order to prevent Bob Jones from doing something in his garage on weekends... companies don't have the luxury of breaking the law en masse even in the 'the masses' choose to...
Because MHz doesn't define speed. And IPC doesn't define quality. They are products in the same product space, so of course they will be compared. With cars, for example, you compare the ones that cost around the same amount and are targeting around the same market. That's what they're doing in the review--comparing the highest end AMD processor against the highest end Intel processor.
Re:Down to 850MHz about 99% of the time...
on
What 1.7Ghz Is Like
·
· Score: 1
Do you have any evidence to back up your claim with respect to processors? Oh of course you don't... I'll give you 10:1 odds that the thermal throttling never kicked in once... read my explanations in the recent/. article on this topic for an explanation why...
I spent two summer internships at HP working on a Java Applet that ended up being potentially useful (I don't know if anyone ever used it because I was gone by the time that would have started happening). It made heavy use of swing... Through the writing of this applet I learned the key rule of Java--if you're going to use swing, then go ahead for the initial layout of your GUI, but then reimplement every swing control you used once the look is finalzed because swing is MOTHERFUCKING SLOW. Now, maybe on a P4 etc it's reached the usability stage (and I wasn't doing anything 'extreme' with it or anything) and I do agree it is very powerful, but it was totally unusbale on a p2-350 (this was two years ago, so that wasn't too shabby of a comp).
Well, obviously I'm not looking for anyone to get ripped off... I don't know how this feature is being marketed--my main point is that I was just trying to educate people about what this feature is really for, and how it will ultimately be used in future processors:).
1) 100% cpu load gives no indication of how hot a processor is. When people do stress testing, the use GIMPS or some other floating point stress tester, not RC5. Why? Because floating point instructions generate a lot more heat than integer instructions. You could probably run GIMPS at 75% cpu load and generate more heat than RC5.
2) The amount of heat generated by a program varies over very short time periods. You could be in a tight FP loop for 10 million instructions (very small compared to a > 1 GHz processor) then move on to different code which is heavily memory limited. In this second phase, you will be generating a lot less heat than in the first.
3) Rendering is not the hottest code around--it suffers incredible numbers of long latency cache misses and TLB misses. While it may be hot, there is hotter stuff around.
4) Where did Intel promise you anything other than that the P4 can reproduce the scores on the various benchmarks they quote? Answer--they didn't
5) If you really care, just pay for a more expensive cooling solution. If this is kicking in too often, keeping the proc colder will prevent that from happening.
My question is... you think it's bad that this kicks in on common applications... how about the current case? Currently, when running certian applications, you could probably kick up the clock frequency a few hundred mhz and it wouldn't crash because that app doesn't generate a lot of heat. However, you couldn't run the proc at this elevated frequency on, say, quake. Well, to me, it looks like you're gretting screwed, since most of the time you could be running at a faster speed, and it's only in these rare cases that it would actually cause any adverse effects. Well, this can be seen as addressing that issue, but from the other direction--you start out at the highest speed, and if the processor gets too hot (so there is danger of a crash or permanent damage) you automatically slip into the slower mode.
Ok, I see let me explain...
The primary benefit is lower packaging costs in two ways... As I tried to state before (but didn't say properly), the packaging costs go up by about $1 per watt for each watt over 30... until you reach around 130W. At that point, air cooling will no longer suffice, so you have to use an alternate cooling method which costs lots more (this is always how I'e heard the rule stated--I don't knwo what the alternate method is).
So, this techinque allows manufacturers to make processors which have cheaper packaging (saving money) as well as avoiding that 130w number (saving more money). Now, I understand your criticism of the technique. If it kicks in all the time, then it's probably not worth it. But that's not what this is targeted at. As has been stated, this technique never kciks in for 99.9% of people with a properly attached HS/fan, so it's more of just an emergency mechanism (in case the fan dies etc). Now, eventually (as has been published in the literature) people expect this mechanism to be applied more aggressively, so I'll briefly discuss that (but again, I don't think this applies in this case, where it is mostly just an emergency escape mechanism).
Most applications are phase oriented... they do work for a while, then stream in a bunch of data, then more work etc. Well, as you probably know, during these data streaming periods, the processor is just sitting around doing nothing, so that would be an opportunity to cool off. Now, some applications (like the FP benchmarks from the SPEC suite) are highly highly optimized, so they spend their entire time in a small loop doing work all the time without ever pausing... Applications such as these which are constantly doing high heat operations (floating point operations generate a TON of heat) are going to trigger the mechanism. But, the majority of apps have this phased behavior where they intersperse low heat work periods between the high heat periods, and most likely, will usually avoid triggering the mechanism. Did I make the distinction clear? If you're interested, I could point you at some papers on the topic which do a better job explaining this than me (power isn't my area to be honest).
So, to restate what I said, the benefit to the consumer is lower prices due to lower packaging costs, as well as possibly a higher performance processor in the general case. I don't know *anything* about layout, but I would imagine that you could use this technique also when the heat density of certain parts of the chip were getting to high. Where you get to place different components on the chip make a huge difference in the performance, so maybe you could use this mechanism to allow you to place, say, the fp function units closer to the register file, knowing that if the heat density in that region got too high you'd invoke this technique.
I said the off the record thing because I'm sure AMD is loving the fact that people are currently treating this feature as a really bad idea right now, whether or not they think it's a good idea...
Well you can not agree all you want, but I would bet you that off the record *every* engineer from *every* microprocessor company would state that something like this (or more advanced more likely) is an inevitability in any processor... or go read the proceedinds for the past few ISCAs(International Symponsium on Computer Architecture, the most prestigious computer architecture conference) or Micro or HPCA etc and see that papers have been talking about features like this for a while, and that a large amount of the great minds in this field agree that it is important (getting an ISCA paper is a very difficult task... If this idea were total BS then it would never have been published there).
Come on people... you even made me log in to reply to this one...
This is not a bad thing, but a good thing. Power has been a problem for cpus for a while. This is, in fact, actually a quite cool feature. Generally how processors are designed is you get some guy to generate the maximum heat producing code that he can find. It doesn't do anything useful, and generally consists of lots and lots of floating point instructions. Then, you find out how much this heat this program generates when run on your processor. Now, you design your processor to be able to tolerate the heat generated by this program.
However, first of all, no program that does anything useful will ever generate as much heat as this test program. SO really, you're forced to design your processor packaging for a way overkill case just to be sure that you don't have your processor die when someone is doing legitmate work with an unoverclocked processor. It has been shown that packaging costs increase by about $1 per watt generated by a processor for every watt over $30, so you can see that developing your packaging for the worst case scenario can be quite expensive. The alternative, then, is exhibited in the P4... Build your processor packaging for less than the worst case, then use some form of thermal throttling to prevent overheating. This has two advantages 1) It lowers your packaging costs 2) It prevents processor death in the case of catastrophing failure (such as a fan dying).
I expected that people would get up in arms about this feature, but really, most of you just need to learn about the most recent research in this field to see this is actually a step in the right direction. However most people on slashdot are primed to jump on Intel at every opportunity, so they interpret this in the worst possible light.
And BTW, I'm getting my PhD in computer architecture, so I know what I'm talking about:P. There have been papers at all the major conferences for the past few years dealing with power issues, and I might work on one myself soon.
The thing I see when we talk about this $10 (and I wonder about) is, since the artists and labels are now getting royalties for our dl, does this mean we are in the clear as far as dl mp3s and not buying cds? Or is the amount of money they're getting only covering the legal idea of dl mp3s and not actually fully compensating everyone?
Yes good point... heat density is much more important than total heat... L2 cache has very low density, but all that means is that your FMACs are running really hot...
Well, I won't deny that I'm not an expert on the 386... But, probably if you lay everything out and try to make the changes to the isa that you're proposing, there is some showstopper involved... I mean, I'm sure Intel thought about whatever it is that you're suggesting...
and anyway, none of this really matters... I mean, cumine is about 70% the specint of a 21264... that's not shabby for an isa that's been around for > 20 years... of course, fp is atrocious for entirely different reasons...
anyway blah... I'm a computer architect but not an expert on 'ancient history' sorts of stuff, so maybe you're right and Intel made a blunder... wouldn't have been the first time...
Ever hear of Itanium? IA64?
also, AMD is doing sledgehammer, which, while x86 compatible, is getting kind of different from "normal" x86 procs, so I think you can consider that one too...
as far as needing to go away from x86, I don't really see the need... wilamette has a trace cache, and once you have one of those, who cares about how long the inital decode takes... you spend all your time executing instructions from the trace cache anyway...
First of all, 99% of programmers are idiots who don't know the first thing about computer architecture...
they say things like "oh, pointer access... oh if-statement... those just cost 1 unit of processing"
No they fucking don't... get rid of those damn pointers and make my job easier for a change...
that's where the important optimization etc whatever can be done... babble sorry sleep deprivation...
Well, I agree with your reasoning, but that's what Intel does at the very least(they're doing it with ony of my ideas...) so it must be a standard thing...
That's a bunch of BS... if a company only wants to protect themself and that is all, then all a company would have to do is publish the patent description in some internal conference, private to the company... at that point, the idea has been published and definitely qualifies as prior art...
biutch...
Slashdot Mirror
Yes you're describing branch prediction. This is universally used in all modern processors. It gives probably 2x speedup or so in general. What you're describing is a way to follow multiple branch paths when you reach a branch that is hard to predict. Actually, my PhD advisor did a paper on this before http://www-cse.ucsd.edu/users/tullsen/ISCA98.ps I don't remember the exact numbers, but they probably saw speedups of 15% or less. As you increase the number of paths you follow simultaneously (in your massively parallel processor) the gains speedup. Hell, if you give perfect branch prediction (rendering your optimization unnecessary) you probably will only get 50% speedup maximum. That's a hell of a lot less than the 1000x you'd get from a perfect speedup. Actually, my current research involves ways to use processors similar to what you describe (but much less parallel--8 way at the most) to improve the performance of programs. But trust me, it's not as simple as just waving your hands and saying 'the xxxxx will take care of it'--we've been waiting for compilers to automatically take care of it for more than 10 years and they still aren't very good at it.
What the hell? Have you ever even done parallel programming? For most programs out there it will be difficult to derive benefit from even 4 processors... much less 1000... I really don't see what gains you expect to occur from having that degree of parallelism...
Well, he did mention that the 100 was to scare off people who weren't serious about it... I mean, I probably would have requested the data if it was free and I knew about the challenge... if he had charged even $1 though, I would have considered it too much trouble...
Well, I don't see this other scheme as a ripoff at all... Even taking your example about fermat's last theorem... what do you care if someone is willing to pay to find out what the theorem is? I mean, there are entrance fees to enter into tournaments all the time... what if I had a quake tournament where the entrance fee was $5 and the winner, if he had been undefeated, would get prize money, otherwise nothing... whats really the difference between the two?
You don't seem to know what a ponzi scheme is... A ponzi scheme is something where the early investors are paid off with money paid in by the later investors. It grows and grows as new people join, and all the early people are happy... but soon, the rate of people joining slows and there isn't enough money to pay off people anymore and the whole thing collapses... this has nothing to do with that whatsoever...
People often talk about 'the masses' doing a lot of things, but I have yet to see a significant amount of 'the masses' doing anything... especially if it looks like people from 'the masses' stand to lost by doing so... even napster at its height was not so widely in use that you could make such a claim... People who talk about 'the masses' doing things are either 1) Elitist, and just want to refer to other people as 'the masses' 2) Want something to occur, but won't put their own neck on the line I seriously doubt it has ever been a common occurance for someone to enforced a patent in order to prevent Bob Jones from doing something in his garage on weekends... companies don't have the luxury of breaking the law en masse even in the 'the masses' choose to...
Because MHz doesn't define speed. And IPC doesn't define quality. They are products in the same product space, so of course they will be compared. With cars, for example, you compare the ones that cost around the same amount and are targeting around the same market. That's what they're doing in the review--comparing the highest end AMD processor against the highest end Intel processor.
Do you have any evidence to back up your claim with respect to processors? Oh of course you don't... I'll give you 10:1 odds that the thermal throttling never kicked in once... read my explanations in the recent /. article on this topic for an explanation why...
I spent two summer internships at HP working on a Java Applet that ended up being potentially useful (I don't know if anyone ever used it because I was gone by the time that would have started happening). It made heavy use of swing... Through the writing of this applet I learned the key rule of Java--if you're going to use swing, then go ahead for the initial layout of your GUI, but then reimplement every swing control you used once the look is finalzed because swing is MOTHERFUCKING SLOW. Now, maybe on a P4 etc it's reached the usability stage (and I wasn't doing anything 'extreme' with it or anything) and I do agree it is very powerful, but it was totally unusbale on a p2-350 (this was two years ago, so that wasn't too shabby of a comp).
Well that's really easy to say when your ass isn't on the line... it's no fun being a martyr...
Well, obviously I'm not looking for anyone to get ripped off... I don't know how this feature is being marketed--my main point is that I was just trying to educate people about what this feature is really for, and how it will ultimately be used in future processors :).
2) The amount of heat generated by a program varies over very short time periods. You could be in a tight FP loop for 10 million instructions (very small compared to a > 1 GHz processor) then move on to different code which is heavily memory limited. In this second phase, you will be generating a lot less heat than in the first.
3) Rendering is not the hottest code around--it suffers incredible numbers of long latency cache misses and TLB misses. While it may be hot, there is hotter stuff around.
4) Where did Intel promise you anything other than that the P4 can reproduce the scores on the various benchmarks they quote? Answer--they didn't
5) If you really care, just pay for a more expensive cooling solution. If this is kicking in too often, keeping the proc colder will prevent that from happening.
My question is... you think it's bad that this kicks in on common applications... how about the current case? Currently, when running certian applications, you could probably kick up the clock frequency a few hundred mhz and it wouldn't crash because that app doesn't generate a lot of heat. However, you couldn't run the proc at this elevated frequency on, say, quake. Well, to me, it looks like you're gretting screwed, since most of the time you could be running at a faster speed, and it's only in these rare cases that it would actually cause any adverse effects. Well, this can be seen as addressing that issue, but from the other direction--you start out at the highest speed, and if the processor gets too hot (so there is danger of a crash or permanent damage) you automatically slip into the slower mode.
Ok, I see let me explain... The primary benefit is lower packaging costs in two ways... As I tried to state before (but didn't say properly), the packaging costs go up by about $1 per watt for each watt over 30... until you reach around 130W. At that point, air cooling will no longer suffice, so you have to use an alternate cooling method which costs lots more (this is always how I'e heard the rule stated--I don't knwo what the alternate method is). So, this techinque allows manufacturers to make processors which have cheaper packaging (saving money) as well as avoiding that 130w number (saving more money). Now, I understand your criticism of the technique. If it kicks in all the time, then it's probably not worth it. But that's not what this is targeted at. As has been stated, this technique never kciks in for 99.9% of people with a properly attached HS/fan, so it's more of just an emergency mechanism (in case the fan dies etc). Now, eventually (as has been published in the literature) people expect this mechanism to be applied more aggressively, so I'll briefly discuss that (but again, I don't think this applies in this case, where it is mostly just an emergency escape mechanism). Most applications are phase oriented... they do work for a while, then stream in a bunch of data, then more work etc. Well, as you probably know, during these data streaming periods, the processor is just sitting around doing nothing, so that would be an opportunity to cool off. Now, some applications (like the FP benchmarks from the SPEC suite) are highly highly optimized, so they spend their entire time in a small loop doing work all the time without ever pausing... Applications such as these which are constantly doing high heat operations (floating point operations generate a TON of heat) are going to trigger the mechanism. But, the majority of apps have this phased behavior where they intersperse low heat work periods between the high heat periods, and most likely, will usually avoid triggering the mechanism. Did I make the distinction clear? If you're interested, I could point you at some papers on the topic which do a better job explaining this than me (power isn't my area to be honest). So, to restate what I said, the benefit to the consumer is lower prices due to lower packaging costs, as well as possibly a higher performance processor in the general case. I don't know *anything* about layout, but I would imagine that you could use this technique also when the heat density of certain parts of the chip were getting to high. Where you get to place different components on the chip make a huge difference in the performance, so maybe you could use this mechanism to allow you to place, say, the fp function units closer to the register file, knowing that if the heat density in that region got too high you'd invoke this technique.
I said the off the record thing because I'm sure AMD is loving the fact that people are currently treating this feature as a really bad idea right now, whether or not they think it's a good idea...
Well you can not agree all you want, but I would bet you that off the record *every* engineer from *every* microprocessor company would state that something like this (or more advanced more likely) is an inevitability in any processor... or go read the proceedinds for the past few ISCAs(International Symponsium on Computer Architecture, the most prestigious computer architecture conference) or Micro or HPCA etc and see that papers have been talking about features like this for a while, and that a large amount of the great minds in this field agree that it is important (getting an ISCA paper is a very difficult task... If this idea were total BS then it would never have been published there).
Come on people... you even made me log in to reply to this one... This is not a bad thing, but a good thing. Power has been a problem for cpus for a while. This is, in fact, actually a quite cool feature. Generally how processors are designed is you get some guy to generate the maximum heat producing code that he can find. It doesn't do anything useful, and generally consists of lots and lots of floating point instructions. Then, you find out how much this heat this program generates when run on your processor. Now, you design your processor to be able to tolerate the heat generated by this program. However, first of all, no program that does anything useful will ever generate as much heat as this test program. SO really, you're forced to design your processor packaging for a way overkill case just to be sure that you don't have your processor die when someone is doing legitmate work with an unoverclocked processor. It has been shown that packaging costs increase by about $1 per watt generated by a processor for every watt over $30, so you can see that developing your packaging for the worst case scenario can be quite expensive. The alternative, then, is exhibited in the P4... Build your processor packaging for less than the worst case, then use some form of thermal throttling to prevent overheating. This has two advantages 1) It lowers your packaging costs 2) It prevents processor death in the case of catastrophing failure (such as a fan dying). I expected that people would get up in arms about this feature, but really, most of you just need to learn about the most recent research in this field to see this is actually a step in the right direction. However most people on slashdot are primed to jump on Intel at every opportunity, so they interpret this in the worst possible light. And BTW, I'm getting my PhD in computer architecture, so I know what I'm talking about :P. There have been papers at all the major conferences for the past few years dealing with power issues, and I might work on one myself soon.
The thing I see when we talk about this $10 (and I wonder about) is, since the artists and labels are now getting royalties for our dl, does this mean we are in the clear as far as dl mp3s and not buying cds? Or is the amount of money they're getting only covering the legal idea of dl mp3s and not actually fully compensating everyone?
Yes good point... heat density is much more important than total heat... L2 cache has very low density, but all that means is that your FMACs are running really hot...
Well, I won't deny that I'm not an expert on the 386... But, probably if you lay everything out and try to make the changes to the isa that you're proposing, there is some showstopper involved... I mean, I'm sure Intel thought about whatever it is that you're suggesting... and anyway, none of this really matters... I mean, cumine is about 70% the specint of a 21264... that's not shabby for an isa that's been around for > 20 years... of course, fp is atrocious for entirely different reasons... anyway blah... I'm a computer architect but not an expert on 'ancient history' sorts of stuff, so maybe you're right and Intel made a blunder... wouldn't have been the first time...
They can be thankful that the US hasn't decided to kick their ass since 1812
Read patterson and hennesey and then get back to me... modifying your isa after the fact is not as simple as you might think...
Ever hear of Itanium? IA64? also, AMD is doing sledgehammer, which, while x86 compatible, is getting kind of different from "normal" x86 procs, so I think you can consider that one too... as far as needing to go away from x86, I don't really see the need... wilamette has a trace cache, and once you have one of those, who cares about how long the inital decode takes... you spend all your time executing instructions from the trace cache anyway...
First of all, 99% of programmers are idiots who don't know the first thing about computer architecture... they say things like "oh, pointer access... oh if-statement... those just cost 1 unit of processing" No they fucking don't... get rid of those damn pointers and make my job easier for a change... that's where the important optimization etc whatever can be done... babble sorry sleep deprivation...
Well, I agree with your reasoning, but that's what Intel does at the very least(they're doing it with ony of my ideas...) so it must be a standard thing...
That's a bunch of BS... if a company only wants to protect themself and that is all, then all a company would have to do is publish the patent description in some internal conference, private to the company... at that point, the idea has been published and definitely qualifies as prior art... biutch...