If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#21
|
|||
|
|||
Rob Stow wrote:
CJT wrote: Rob Stow wrote: Bill Davidsen wrote: keith wrote: On Wed, 17 Aug 2005 12:48:25 -0700, YKhan wrote: http://www.macworld.com/news/2005/08...core/index.php I simply found it an admission of how far (and for how long) their technological head is (and has been) up their corporate ass. Nine months in development isn't that big of a deal, given that the "cores" are already there. Years? Please! They don't simulate/verify in multi-processor environments? *Amazing*! If these cores are the desktop versions rather than Xeon, they were not planned to be used in SMP, much less in dual core. I'd be interested to get your spin on why they *would* test the desktop chip SMP. Here's a more interesting question: Intel built the D/C chips on P4 rather than P-M, presumably so they could offer the ht model at a huge premium. Given the low power and far better performance of the P-M in terms of work/watt and work/clock, why not a dual core Pentium-M? Then when the better P4 D/C chip is ready they could offer that? Just curious as to the logic for the decision if anyone has any insight. Probably has something to do with the fact that AMD64 is the hottest thing right now. Intel just tacked two AMD64-capable cores together in a MCP, and voila: a cheap AMD64-capable multi-chip package that they could delude the masses into thinking of as a competitor to AMD's dual-core chips. Doing the same thing with the P-M is supposed to eventually happen. Sort of. Apparently the next generation will be dual-core and redesigned from the ground up instead of evolved from the P3. Still haven't heard if it will be AMD64-capable. I think AMD has finally managed to tarnish "Intel Inside." Finally ? Where have you been hiding for the last 4 or 5 years ? AMD has had the better CPUs for desktops and 2-way servers and workstations since the Athlon XP and MP transitioned from 0.18 to 0.13 microns. Even before then the Athlon XP and MP outperformed the P4 and Xeon - but also ran pretty danged hot. The only CPU market Intel has held the technological edge in for the past 4 or 5 years has been the mobile market, where the Pentium M has been king and looks like it will reign for a while longer. While I tend to agree with you, the perception among the masses has been different, IMHO. But being "the hottest thing right now" changes that. -- The e-mail address in our reply-to line is reversed in an attempt to minimize spam. Our true address is of the form . |
#22
|
|||
|
|||
"Robert Redelmeier" wrote in message
m... In comp.sys.ibm.pc.hardware.chips Terje Mathisen wrote: There are several reasons why engineers are very poor at lying: -) "I'm an engineer, my credibility is my main capital." -) "Salesmen, la[w]yers, PHBs and several other types that I really don't like do it, so I want to distance myself from them." -) It is just so inelegant. :-( If I absolutely _have_ to lie, it must be by omission: I'll still tell the truth and nothing but the truth (as I understand it, of course), but unless you ask me specific questions about those parts I'm skipping, I might not tell you all of the truth. So how do you answer when your wife asks: "Does this dress make me look fat?" "Of course it doesn't dear!" (Well, maybe pleasing plump, chubby ... but not "fat" of course.) The concept of a "duty of truth" is a practical justification. One really should not lie (even by omission) when one owes information to someone, and they may be reasonably expected to rely upon it. For example, I have no trouble lying to a saleman saying "I'm busy" rather than telling him "Your product is grossly overpriced, I'm insulted you think I'm so stupid as to fall for it, and I find you obnoxious." The latter may be entirely true, but it is valuable information (feedback) the saleman has not earned. A certain amount of lying also eases social interactions. See the Jim Carrey movie "Liar, liar". Of course, you may claim that engineers are poor at social interactions -- ... Hank http://home.earthlink.net/~horedson http://home.earthlink.net/~w0rli |
#23
|
|||
|
|||
Bill Davidsen wrote:
Here's a more interesting question: Intel built the D/C chips on P4 rather than P-M, presumably so they could offer the ht model at a huge premium. Given the low power and far better performance of the P-M in terms of work/watt and work/clock, why not a dual core Pentium-M? Then when the better P4 D/C chip is ready they could offer that? I can't see Intel even having worried about whether it had HT or not. They just wanted a dual-core in working condition, HT or no HT. The fact that they were able to get some HT-enabled DC processors out of it is a bonus as far as they are concerned. Regarding why P4 instead of P-M? My assumption is that P-M is too complicated to simply join together side-by-side to get a dual core. I think P-4 is a major hack job anyways, dual-core or no dual-core. They mentioned that they layed out the circuit patterns of the P4 on a computer, and let the computer take care of rearranging it. Whereas the P4 may have had a lot of places free to attach communications lines between the cores, and if they don't, all they have to do is have the computer relayout the design so that places to put comm lines appear in convenient locations. Yousuf Khan |
#24
|
|||
|
|||
Robert Redelmeier wrote:
In comp.sys.ibm.pc.hardware.chips Terje Mathisen wrote: If I absolutely _have_ to lie, it must be by omission: I'll still tell the truth and nothing but the truth (as I understand it, of course), but unless you ask me specific questions about those parts I'm skipping, I might not tell you all of the truth. So how do you answer when your wife asks: "Does this dress make me look fat?" "I think that other one is even nicer." The concept of a "duty of truth" is a practical justification. One really should not lie (even by omission) when one owes information to someone, and they may be reasonably expected to rely upon it. Sure. For example, I have no trouble lying to a saleman saying "I'm busy" rather than telling him "Your product is grossly overpriced, I'm insulted you think I'm so stupid as to fall for it, and I find you obnoxious." The latter may be entirely true, but it is valuable information (feedback) the saleman has not earned. :-) Terje -- - "almost all programming can be viewed as an exercise in caching" |
#25
|
|||
|
|||
In article ,
Terje Mathisen wrote: Robert Redelmeier wrote: For example, I have no trouble lying to a saleman saying "I'm busy" rather than telling him "Your product is grossly overpriced, I'm insulted you think I'm so stupid as to fall for it, and I find you obnoxious." The latter may be entirely true, but it is valuable information (feedback) the saleman has not earned. :-) Hmm. I have no difficulty in telling him the former, though I would leave out the remark about his obnoxiousness as unprofessional. I have several times told salesmen and even technical staff that their product would be cancelled, on the grounds that it would fail in testing, including once when it had a shipment dated of under 6 months off. I told them I had seen it attempted N times before, it had failed every time for fundamental reasons, and I didn't care how senior the executive was who had told them it would succeed THIS time - he didn't know what he was rabbiting on about and I did. I may have used those words :-) That particular product was virtual shared memory, as a platform to run arbitrary SMP programs on a distributed memory system. Regards, Nick Maclaren. |
#26
|
|||
|
|||
keith wrote:
On Thu, 18 Aug 2005 09:59:19 -0700, icerq4a wrote: keith skrev: On Wed, 17 Aug 2005 12:48:25 -0700, YKhan wrote: http://www.macworld.com/news/2005/08...core/index.php I simply found it an admission of how far (and for how long) their technological head is (and has been) up their corporate ass. Nine months in development isn't that big of a deal, given that the "cores" are already there. Years? Please! They don't simulate/verify in multi-processor environments? *Amazing*! The only amazing thing here is that you don't seem to understand the article and appear to know nothing about microprocessor development. Uh, right. Since that's (microprocessor development) what I do for a living, I suggest that *you* read the article again. This time you might try reading for comprehension. Intel blew it big time, as did you. Mudslinging apart, the admission is not new. It is a long time ago that Intel top brass talked about a sudden 90 degree right turn. What is new, is that we now know that Intel wanted to be able to match cores with the same performance per watt in a package. Without that ability, you have to disable the core that runs, but not well enough. Or waste a good core. We now know that that package is cheaper for Intel than disabling a core. -- Mvh./Regards, Niels Jørgen Kruse, Vanløse, Denmark |
#27
|
|||
|
|||
keith wrote:
On Fri, 19 Aug 2005 15:28:58 +0000, Bill Davidsen wrote: keith wrote: On Wed, 17 Aug 2005 12:48:25 -0700, YKhan wrote: http://www.macworld.com/news/2005/08...core/index.php I simply found it an admission of how far (and for how long) their technological head is (and has been) up their corporate ass. Nine months in development isn't that big of a deal, given that the "cores" are already there. Years? Please! They don't simulate/verify in multi-processor environments? *Amazing*! If these cores are the desktop versions rather than Xeon, they were not planned to be used in SMP, much less in dual core. I'd be interested to get your spin on why they *would* test the desktop chip SMP. Spin? Like to load them words, eh? One reason to do SMP testing is that it's "easy" to test cache coherence with two processors. Two processors can bang the caches pretty hard against each other. Do you really think Intel has no SMP verification capabilities? Do they not "borrow" tools from one organization to another? There's more here than meets the eye. Someone dropped the ball, big time! I'm a bit confused. You are talking "verification", but the article talks about "testing tools and processes". I thought "verification" meant determining the correctness of the design, but "testing" often refers to the part of the manufacturing process that tries to determine whether a newly manufactured chip conforms to the design. In those senses, verification of an SMP design should include simulation of multiple processors. Testing should apply to each chip separately, because if you put two or more chips together and the result fails, you only know that one of a set of chips is bad, not which one it is. Are you using the words that way? If not, could you define "verification" and "testing"? Patricia |
#28
|
|||
|
|||
On Thu, 18 Aug 2005 09:59:19 -0700, icerq4a wrote:
keith skrev: On Wed, 17 Aug 2005 12:48:25 -0700, YKhan wrote: http://www.macworld.com/news/2005/08...core/index.php I simply found it an admission of how far (and for how long) their technological head is (and has been) up their corporate ass. Nine months in development isn't that big of a deal, given that the "cores" are already there. Years? Please! They don't simulate/verify in multi-processor environments? *Amazing*! The only amazing thing here is that you don't seem to understand the article and appear to know nothing about microprocessor development. Uh, right. Since that's (microprocessor development) what I do for a living, I suggest that *you* read the article again. This time you might try reading for comprehension. Intel blew it big time, as did you. -- Keith |
#29
|
|||
|
|||
On Fri, 19 Aug 2005 15:28:58 +0000, Bill Davidsen wrote:
keith wrote: On Wed, 17 Aug 2005 12:48:25 -0700, YKhan wrote: http://www.macworld.com/news/2005/08...core/index.php I simply found it an admission of how far (and for how long) their technological head is (and has been) up their corporate ass. Nine months in development isn't that big of a deal, given that the "cores" are already there. Years? Please! They don't simulate/verify in multi-processor environments? *Amazing*! If these cores are the desktop versions rather than Xeon, they were not planned to be used in SMP, much less in dual core. I'd be interested to get your spin on why they *would* test the desktop chip SMP. Spin? Like to load them words, eh? One reason to do SMP testing is that it's "easy" to test cache coherence with two processors. Two processors can bang the caches pretty hard against each other. Do you really think Intel has no SMP verification capabilities? Do they not "borrow" tools from one organization to another? There's more here than meets the eye. Someone dropped the ball, big time! Here's a more interesting question: Intel built the D/C chips on P4 rather than P-M, presumably so they could offer the ht model at a huge premium. Given the low power and far better performance of the P-M in terms of work/watt and work/clock, why not a dual core Pentium-M? Then when the better P4 D/C chip is ready they could offer that? Absolutely. ...which makes the SMP verification issue even more strange. Just curious as to the logic for the decision if anyone has any insight. Search me. I've given up trying to explain Intel's moves; too bizare. -- Keith |
#30
|
|||
|
|||
On Sun, 21 Aug 2005 17:19:16 +0000, Patricia Shanahan wrote:
keith wrote: On Fri, 19 Aug 2005 15:28:58 +0000, Bill Davidsen wrote: keith wrote: On Wed, 17 Aug 2005 12:48:25 -0700, YKhan wrote: http://www.macworld.com/news/2005/08...core/index.php I simply found it an admission of how far (and for how long) their technological head is (and has been) up their corporate ass. Nine months in development isn't that big of a deal, given that the "cores" are already there. Years? Please! They don't simulate/verify in multi-processor environments? *Amazing*! If these cores are the desktop versions rather than Xeon, they were not planned to be used in SMP, much less in dual core. I'd be interested to get your spin on why they *would* test the desktop chip SMP. Spin? Like to load them words, eh? One reason to do SMP testing is that it's "easy" to test cache coherence with two processors. Two processors can bang the caches pretty hard against each other. Do you really think Intel has no SMP verification capabilities? Do they not "borrow" tools from one organization to another? There's more here than meets the eye. Someone dropped the ball, big time! I'm a bit confused. You are talking "verification", but the article talks about "testing tools and processes". I don't think so. "Testing" is a function of ATE widgets. There comparatively little development needed to "test" a dual-core processor. Verification was what the article was referring to. I thought "verification" meant determining the correctness of the design, but "testing" often refers to the part of the manufacturing process that tries to determine whether a newly manufactured chip conforms to the design. Fine, if you want to skin the onion that thin. Why should it take that much work to "test" a dual core processor? In those senses, verification of an SMP design should include simulation of multiple processors. Testing should apply to each chip separately, because if you put two or more chips together and the result fails, you only know that one of a set of chips is bad, not which one it is. One doesn't "test" multiple processors. One tests products. If one has it together, the "tests" fall out of the verification suites (more or less). Are you using the words that way? If not, could you define "verification" and "testing"? I won't argue much with your definitions, just that they're normally confused. "Verification" includes both simulation and engineering "test" (we have both "verification" and "hardware verification" groups). Manufacturing test is something else. Once the design is shown to work, making sure the one shipped to the customer works is induction. ;-) -- Keith |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
AMD upgrade to which dual core processor | www.interfacebus.com | General | 5 | August 14th 05 11:26 AM |
FS printers/parts trays, printheads -- oki fujitsu dl3700 dl3800 hp genicom epson ibm dec jetdirect laserjet lexmark qms okidata microline 320 ml320 393 tally printronix tektronix qms toshiba zebra otc ibm intermec 7755 boul st laurent montreal ca | cisco | Printers | 2 | May 22nd 05 02:05 AM |
Games that take advantage of 64 bit and/or dual core CPUs? | boe | AMD x86-64 Processors | 1 | April 21st 05 11:47 PM |
FS PRINTER PARTS trays fusers drums printheads -- oki fujitsu hp genicom epson ibm dec jetdirect laserjet lexnmark qms okidata ml320 mannesmann tally printonix tektronix qms toshiba zebra otc ibm lexmark intermec dec compaq montreal canada toronto o | [email protected] | Printers | 1 | March 15th 05 05:50 AM |
Dual Core Processors & MoBo | k_yhz | General | 2 | January 5th 05 08:43 PM |