This article is a typical example of the inflamatory rhetoric thats gets thrown around on Tom's site and here on ocassion. In the title alone the author is clearly on AMD's side. While that's not bad, it should clearly be noted that this is opinion. There is not one positive comment about Intel, and AMD is made out to look like the mesiah.
Now to qualify my own remarks: I do like Intel, but on the same token I also like AMD. I like the competition the results in better, cheaper products for all. I will buy the best system I can regardless of who makes it. I think everybody would.
The article asserts that most of Intel's woes are due to AMD's abilities. This could not be further from the truth. When you really look at things, the real reason AMD is gaining momentum is due to Intel's slips. Rambus is generally badmouthed for a variety of reasons, but the best reason for it's problems is immaturity. It is a new technology that needed further reasearch. Intel implemented it too early. The resulting slip of the i820 products caused a chain reaction of slippage by slipping boards that could support the newer Coppermine processors.
AMD meanwhile released Athlon right in the middle of these slips. And it when on to success since Intel hod nothing to counter with. This is the real and only reason AMD has shot ahead. Think for a moment if Intel had shipped i820 boards on time. Rambus would have proably taken off better, and we would have had coppermine's in the summer of last year. Further, Intel would have been able to counter Athlon right away. Perhaps even take the lead. Intel's problems and AMD's current success can only be attributed to Intel's slippages, not to any "briliant" moves by AMD.
Another problem for Intel is that they were also caught in the middle of a switch to 0.18 tech. Here is where AMD's small size helped. They were able to ramp to 0.18 far quicker than Intel could.
And Itanium? The author rants about Itanium and it's VLIW instruction set, lack of direct backward comatibility, and it's immediate move to Mckinley. Come on, Crusoe also uses VLIW so he's contradictory in supporting Crusoe and bashing Itanium. Also, Itanium was never proposed as the replacement to the current IA32 line as the author implies. It is targeted exclusively at high end workstations and servers. The areas even the Xeon can't break into. Intel has been recruiting, and helping every OS vendor it can find to port over to Itanium. The list includes Sun, HP (obviously), Win NT, and even linux (trillium project). The fact that Sledgehammer is also 64-bit is somewhat irrelevant since they're aimed at different markets. As far as Mckinley superceding Merced, Intel predicted this long ago. It new early on that Merced would not have the performance of Mckinley and said it was likely that Merced would only be used for initial development, while Mckinley would ship in production machines.
The point is, let's not bash any particular company for the sake of bashing. This entire market could change tommorow. AMD is still bleeding red all over the place and hasn't made a decent profit in a while. And if media reports are correct, the Dresden plant (for all it's potential) is a HUGE cost to AMD. So much so that there were rumors they wanted to rent out production capability to make the rent, or find a partner to buy into it.
Intel and AMD are a great story of competition. But let's keep thing in perspective...
It seems to me that DEC (now Compaq) already has the claim on "code morphing". FX!32 Did the exact same thing for the Alpha line of processors. FX!32 would translate on the fly and save the resulting translation. The result was that the more you used the program, the more code got translated and native code is used. The only thing Transmeta did is to integrate it into the processor.
Based on this, it seems that Transmeta's only real advance is on the power consumption front. This is probably the x86 compatible processor with the lowest power consumption.
I wonder how long it will take DEC (Comapq) to sue for patent infringement.
The real fact is that tech support is intended to help a person through a problem. Not teach them how to use a computer. I and the other techs I have worked with all agreed that users should make an attempt to learn the basics (whether through a school, book, or other means) before coming to tech support. Those users who did not know the difference between a mouse and a keyboard (and there are many!!) should not be asking tech support. They should realize that they need training on what a computer is and how to use it. Scott Kurtz is asserting that techs are there to teach users. The reality is that techs are computer mechanics. Users come to tech support with specific problems that they cannot fix. You don't take your car to a mechanic and complain that you can't shift into "Drive" when you have manual transmission. Nor do you ask why the car won't run if you haven't put fuel in it. You should know this already. The fact is, users that ask stupid questions(ie "My cupholder is broken.", or "Where is the any key?") have no business running a computer until they learn what it is and how to use it. They should know enough to figure things out on their own and only call tech support as a last resort for difficult, non-usage based questions (ie driver problems, hardware errors, etc.). -john
Slashdot Mirror
This article is a typical example of the inflamatory rhetoric thats gets thrown around on Tom's site and here on ocassion. In the title alone the author is clearly on AMD's side. While that's not bad, it should clearly be noted that this is opinion. There is not one positive comment about Intel, and AMD is made out to look like the mesiah.
Now to qualify my own remarks: I do like Intel, but on the same token I also like AMD. I like the competition the results in better, cheaper products for all. I will buy the best system I can regardless of who makes it. I think everybody would.
The article asserts that most of Intel's woes are due to AMD's abilities. This could not be further from the truth. When you really look at things, the real reason AMD is gaining momentum is due to Intel's slips. Rambus is generally badmouthed for a variety of reasons, but the best reason for it's problems is immaturity. It is a new technology that needed further reasearch. Intel implemented it too early. The resulting slip of the i820 products caused a chain reaction of slippage by slipping boards that could support the newer Coppermine processors.
AMD meanwhile released Athlon right in the middle of these slips. And it when on to success since Intel hod nothing to counter with. This is the real and only reason AMD has shot ahead. Think for a moment if Intel had shipped i820 boards on time. Rambus would have proably taken off better, and we would have had coppermine's in the summer of last year. Further, Intel would have been able to counter Athlon right away. Perhaps even take the lead. Intel's problems and AMD's current success can only be attributed to Intel's slippages, not to any "briliant" moves by AMD.
Another problem for Intel is that they were also caught in the middle of a switch to 0.18 tech. Here is where AMD's small size helped. They were able to ramp to 0.18 far quicker than Intel could.
And Itanium? The author rants about Itanium and it's VLIW instruction set, lack of direct backward comatibility, and it's immediate move to Mckinley. Come on, Crusoe also uses VLIW so he's contradictory in supporting Crusoe and bashing Itanium. Also, Itanium was never proposed as the replacement to the current IA32 line as the author implies. It is targeted exclusively at high end workstations and servers. The areas even the Xeon can't break into. Intel has been recruiting, and helping every OS vendor it can find to port over to Itanium. The list includes Sun, HP (obviously), Win NT, and even linux (trillium project). The fact that Sledgehammer is also 64-bit is somewhat irrelevant since they're aimed at different markets. As far as Mckinley superceding Merced, Intel predicted this long ago. It new early on that Merced would not have the performance of Mckinley and said it was likely that Merced would only be used for initial development, while Mckinley would ship in production machines.
The point is, let's not bash any particular company for the sake of bashing. This entire market could change tommorow. AMD is still bleeding red all over the place and hasn't made a decent profit in a while. And if media reports are correct, the Dresden plant (for all it's potential) is a HUGE cost to AMD. So much so that there were rumors they wanted to rent out production capability to make the rent, or find a partner to buy into it.
Intel and AMD are a great story of competition. But let's keep thing in perspective...
It seems to me that DEC (now Compaq) already has the claim on "code morphing". FX!32 Did the exact same thing for the Alpha line of processors. FX!32 would translate on the fly and save the resulting translation. The result was that the more you used the program, the more code got translated and native code is used. The only thing Transmeta did is to integrate it into the processor.
Based on this, it seems that Transmeta's only real advance is on the power consumption front. This is probably the x86 compatible processor with the lowest power consumption.
I wonder how long it will take DEC (Comapq) to sue for patent infringement.
It should be interesting...
The real fact is that tech support is intended to help a person through a problem. Not teach them how to use a computer. I and the other techs I have worked with all agreed that users should make an attempt to learn the basics (whether through a school, book, or other means) before coming to tech support. Those users who did not know the difference between a mouse and a keyboard (and there are many!!) should not be asking tech support. They should realize that they need training on what a computer is and how to use it. Scott Kurtz is asserting that techs are there to teach users. The reality is that techs are computer mechanics. Users come to tech support with specific problems that they cannot fix. You don't take your car to a mechanic and complain that you can't shift into "Drive" when you have manual transmission. Nor do you ask why the car won't run if you haven't put fuel in it. You should know this already. The fact is, users that ask stupid questions(ie "My cupholder is broken.", or "Where is the any key?") have no business running a computer until they learn what it is and how to use it. They should know enough to figure things out on their own and only call tech support as a last resort for difficult, non-usage based questions (ie driver problems, hardware errors, etc.). -john