The time to market for a flagship CPU is four to five years (from initial architecture design, to volume production). For a chip with a new ISA, it is longer (the article said Merced took six years, but it actually took over seven years). In other words, I don't see how they think they will get this out by 2001.
Since they are simply making the IA-32 architecture 64 bit instead of developing a new architecture, they will be hampered by the IA-32 instruction set (e.g. all of the different funny modes, space for obsolete instructions, difficulty of instruction decode, etc.) They have an opportunity (in theory) to make a new (and good) architecture, but they are choosing to use the most backwards and difficult one available. TRUE, this is good for backwards compatibility, however, IA-64 is also backwards compatible AND has a different architecture.
The reason this architecture will fail is that all the software makers have done ports to IA-64. I am especially talking about the non-x86 commercial Unix's. Porting things like HP-UX, Irix, AIX, and Tru64 makes as much sense as porting those to IA-32. In the more PC type market it is viable, but only just: again, it depends on support from software makers, and I really don't see why they would all want to go out and support ANOTHER architecture which is totally unproven. It also depends on support from VAR's: could you imagine IBM or HP using an AMD chip in their high profit margin workstations?
Finally, I have the following to offer: If AMD was smart, they would license an existing 64 bit architecture (say, Alpha), and then engineer a die which would put that together with their IA-32 bit stuff. This would actually be a serious threat to Intel (but what AMD has now is a joke). It would have the advantage of have existing 64 bit operating systems and it would also be quicker to market (it might be cheaper also, depending on the licesing costs).
Firstly, there are not 5 patches to Windows NT, there are 5 Service Packs. These are a combination of a large number of smaller fixes rolled togeather. There are a large number of "Hot fixes" also, which usually just fix one, or a number of smaller bugs, and are later rolled into the next service pack.
Yeah, but all of the Linux patches all fix more than one thing also.
Secondly, Free software certianly does have a testing phsae. This is what all the "unstable" release versions are all about. With free software however you are free to disregard the warnings if you wish.
I understand this but my point was, it has no FORMAL test methodology. The methodology is "throw it out to the beta testers", rather than first testing it.
You are ignoring the differences between stable and unstable release tracks incorporated into almost every kind of free software in active development.
No. Linux kernel 2.2 has *12* patches. 2.2 is (supposedly) the "stable" branch. 12 patches to a stable branch in less than a year???? And this is somehow "more stable" than Windows NT which had had five in the course of five years?? Please explain, I must be missing something.
And if you see some obvious improvements to be made in some package you work with, then send in a patch.
Look, I'm a full time EE and I work upteen hours every week. If you think I have time to fart around with buggy, unreliable software like Linux and its ilk and submit my patches you are dead wrong.
Anybody who read The Cathedral and Bazaar (most people here, I'm assuming), know that the entire PREMISE of the free software industry is "release early, release often" -- which means that free software uses the attitude described in this article, only on steroids.
I find it scary that people think this is limited to commercial software. The article mentions that there are 5 patches for NT 4.0 -- there are 12 for the Linux 2.2 kernel, and that is just for the kernel (in many cases, the packages distributed on top of that have patches also, there are probably thousands of patches and updates collectively to every packages distributed in Red Hat 6.0, for example), AND Linux 2.2 has been around for less than 1/4 as long as Windows NT 4.0.
Feee software usually doesn't have formal testing either. Instead of a dedicated testing team like most commercial software has, the testing philosophy is to release it and for users to test it. Not good preventive treatment obviously. Nobody is going to test if the new SCSI driver is going to wipe off your hard drive - it's left for the beta testers to find this.
I can think of five or six showtopper bugs off the top of my head in Red Hat 6.0 that would have prevented the release from cooming close to shipping out the door had it been a serious commercial system, but it was released anyways.
I have also looked at the source code for many free projects such as GCC and GIMP and noticed that the code quality was quite low. For example, malloc() calls were usually unchecked (especially in GIMP). I have worked on commercial projects before, and checking malloc() is rule #1 -- if you happen to run out of memory while using GIMP, it'll blow up, where as commercial systems will simply fail to complete the current operations. If such a high profile package is of such low code quality, I expect the lesser profile packages are considerably more buggy.
AMD shoots itself in foot with pre-announcement
on
K8 Details
·
· Score: 3
A year and a half ago, all we heard was "K7 is going to put Intel out of business. They are going to be for sale signs on all of Intel's fabs and they stock is going to tumble".
A year and a half later AMD losses are at an all time high, K7 hasn't made any dent in sales, and I can't even see one at Best Buy.
This is largely due to the pre-announcement effect: everybody heard about K7 and delays purchases of AMD chips(when they would have bought a K6).
Now they announce the K8 when the K7 is barely ready for production. This is going to have the same effect. Consumers are going to say, "Why should I buy K7 now when K8 is coming out Really Soon Now?" They'll probably just buy Intel.
Willamette/Foster will be out by the time K8 is. What has the world heard about that? Very little. Almost no details have been made public.
Intel never makes the details of a processor public to the industry until it it ready for VOLUME production. Often their published figures are lower than expected, so the compeititors feel comfortable and slack off, then they grab the crown from out of nowhere (P6 is the prime example, and Willlamette/Foster will do the same).
This is the reason Intel is more successful than AMD - they don't preannounce, so they can sell chips they can fab in volume NOW, and not tell customers "don't buy what we have now just wait a little while longer and we'll have this whiz-bang part" (OK, they didn't do this with Merced, but they have with everything else)
Re:not much info about the chip
on
K8 Details
·
· Score: 1
Coppermine? 700 and 733? WTF? That's slow man. When ya have parts being tested at 900Mhz and 1 Ghz already (ie, we're STILL talking.25u and non-copper)
You are making the very common mistake of comparing production parts to prototype parts. The 700 and 733 Coppermines are PRODUCTION. Intel has managed to fab them at high yields, and they are bug free.
The 900 Mhz and 1 GHz K7 parts are PROTOTYPES. They may have various bugs, and they are probably not able to fab them at high yields. They may get one or two working parts per die. They are NOT parts which are ready for production and are NOT parts which can be fabbed in quantity.
I have no doubt that Intel is testing parts at those frequencies also (they demoed a 1 GHz Coppermine at the beginning of the year). Intel is a very private company and doesn't announce their parts until they are ready for production, so you don't hear about them until they are ready for production.
Also, your comment about K7 being 0.25 is wrong: the shipping K7 uses a hybrid 0.18/0.25 process, where the transistors are 0.18 and the lines are 0.25. This means the full 0.18 shrink of K7 will have a much lower boost than a full 0.25 to 0.18 transition (e.g. Katmai -> Coppermine). AMD advertises it as 0.25, probably to mislead people into thinking that the 0.18 shrink is going to gain them so much, and that the current part is just a preview.
Third, while Coppermine is debuting at only 700/733 those are the first parts. K7 debuted at 500/550/600 but that doesn't mean only those parts will be available for the future.
Coppermine is a river, and all the IA-32 chips designed in Oregon are named after rivers.
Some of the more clueless people around here think that calling it Coppermine is false advertising. Coppermine is an internal name for the project (it will be marketed as Pentium III), so there's no "advertising" involved.
Furthermore, the Coppermine project was started (and named) long before IBM had announced that they were using copper. It's not like Intel could have known that at that time that copper would be the latest buzzword in the industry when the part came out. It's 100% coincidence.
Why does Petreley feel the need to spread FUD about 64 bit Windows? He says "Microsoft was making such poor progress with 64-bit NT". What are the details? What problems specific to 64 bit could Windows be having? He uses "facts" like this, which contain absolutely no details whatsoever, and it makes it sound like it is just something he heard off of a rumor mill, and it also makes him sound like he has very minimal system design experience of his own. Undetailed, ungrounded FUD like this is regularly passed around and it sounds clearly unbased in reality, and intended just be a more feel-good juice to appease the Microsoft-hating crowd rather than to make any sort of intelligent journalism.
Slashdot Mirror
The time to market for a flagship CPU is four to five years (from initial architecture design, to volume production). For a chip with a new ISA, it is longer (the article said Merced took six years, but it actually took over seven years). In other words, I don't see how they think they will get this out by 2001.
Since they are simply making the IA-32 architecture 64 bit instead of developing a new architecture, they will be hampered by the IA-32 instruction set (e.g. all of the different funny modes, space for obsolete instructions, difficulty of instruction decode, etc.) They have an opportunity (in theory) to make a new (and good) architecture, but they are choosing to use the most backwards and difficult one available. TRUE, this is good for backwards compatibility, however, IA-64 is also backwards compatible AND has a different architecture.
The reason this architecture will fail is that all the software makers have done ports to IA-64. I am especially talking about the non-x86 commercial Unix's. Porting things like HP-UX, Irix, AIX, and Tru64 makes as much sense as porting those to IA-32. In the more PC type market it is viable, but only just: again, it depends on support from software makers, and I really don't see why they would all want to go out and support ANOTHER architecture which is totally unproven. It also depends on support from VAR's: could you imagine IBM or HP using an AMD chip in their high profit margin workstations?
Finally, I have the following to offer: If AMD was smart, they would license an existing 64 bit architecture (say, Alpha), and then engineer a die which would put that together with their IA-32 bit stuff. This would actually be a serious threat to Intel (but what AMD has now is a joke). It would have the advantage of have existing 64 bit operating systems and it would also be quicker to market (it might be cheaper also, depending on the licesing costs).
Firstly, there are not 5 patches to Windows NT, there are 5 Service Packs. These are a combination of a large number of smaller fixes rolled togeather. There are a large number of "Hot fixes" also, which usually just fix one, or a number of smaller bugs, and are later rolled into the next service pack.
Yeah, but all of the Linux patches all fix more than one thing also.
Secondly, Free software certianly does have a testing phsae. This is what all the "unstable" release versions are all about. With free software however you are free to disregard the warnings if you wish.
I understand this but my point was, it has no FORMAL test methodology. The methodology is "throw it out to the beta testers", rather than first testing it.
You are ignoring the differences between stable and unstable release tracks incorporated into almost every kind of free software in active development.
No. Linux kernel 2.2 has *12* patches. 2.2 is (supposedly) the "stable" branch. 12 patches to a stable branch in less than a year???? And this is somehow "more stable" than Windows NT which had had five in the course of five years?? Please explain, I must be missing something.
And if you see some obvious improvements to be made in some package you work with, then send in a patch.
Look, I'm a full time EE and I work upteen hours every week. If you think I have time to fart around with buggy, unreliable software like Linux and its ilk and submit my patches you are dead wrong.
If it's not source, it's not software
Keep chanting the slogans...
Anybody who read The Cathedral and Bazaar (most people here, I'm assuming), know that the entire PREMISE of the free software industry is "release early, release often" -- which means that free software uses the attitude described in this article, only on steroids.
I find it scary that people think this is limited to commercial software. The article mentions that there are 5 patches for NT 4.0 -- there are 12 for the Linux 2.2 kernel, and that is just for the kernel (in many cases, the packages distributed on top of that have patches also, there are probably thousands of patches and updates collectively to every packages distributed in Red Hat 6.0, for example), AND Linux 2.2 has been around for less than 1/4 as long as Windows NT 4.0.
Feee software usually doesn't have formal testing either. Instead of a dedicated testing team like most commercial software has, the testing philosophy is to release it and for users to test it. Not good preventive treatment obviously. Nobody is going to test if the new SCSI driver is going to wipe off your hard drive - it's left for the beta testers to find this.
I can think of five or six showtopper bugs off the top of my head in Red Hat 6.0 that would have prevented the release from cooming close to shipping out the door had it been a serious commercial system, but it was released anyways.
I have also looked at the source code for many free projects such as GCC and GIMP and noticed that the code quality was quite low. For example, malloc() calls were usually unchecked (especially in GIMP). I have worked on commercial projects before, and checking malloc() is rule #1 -- if you happen to run out of memory while using GIMP, it'll blow up, where as commercial systems will simply fail to complete the current operations. If such a high profile package is of such low code quality, I expect the lesser profile packages are considerably more buggy.
A year and a half ago, all we heard was "K7 is going to put Intel out of business. They are going to be for sale signs on all of Intel's fabs and they stock is going to tumble".
A year and a half later AMD losses are at an all time high, K7 hasn't made any dent in sales, and I can't even see one at Best Buy.
This is largely due to the pre-announcement effect: everybody heard about K7 and delays purchases of AMD chips(when they would have bought a K6).
Now they announce the K8 when the K7 is barely ready for production. This is going to have the same effect. Consumers are going to say, "Why should I buy K7 now when K8 is coming out Really Soon Now?" They'll probably just buy Intel.
Willamette/Foster will be out by the time K8 is. What has the world heard about that? Very little. Almost no details have been made public.
Intel never makes the details of a processor public to the industry until it it ready for VOLUME production. Often their published figures are lower than expected, so the compeititors feel comfortable and slack off, then they grab the crown from out of nowhere (P6 is the prime example, and Willlamette/Foster will do the same).
This is the reason Intel is more successful than AMD - they don't preannounce, so they can sell chips they can fab in volume NOW, and not tell customers "don't buy what we have now just wait a little while longer and we'll have this whiz-bang part" (OK, they didn't do this with Merced, but they have with everything else)
You are making the very common mistake of comparing production parts to prototype parts. The 700 and 733 Coppermines are PRODUCTION. Intel has managed to fab them at high yields, and they are bug free.
The 900 Mhz and 1 GHz K7 parts are PROTOTYPES. They may have various bugs, and they are probably not able to fab them at high yields. They may get one or two working parts per die. They are NOT parts which are ready for production and are NOT parts which can be fabbed in quantity.
I have no doubt that Intel is testing parts at those frequencies also (they demoed a 1 GHz Coppermine at the beginning of the year). Intel is a very private company and doesn't announce their parts until they are ready for production, so you don't hear about them until they are ready for production.
Also, your comment about K7 being 0.25 is wrong: the shipping K7 uses a hybrid 0.18/0.25 process, where the transistors are 0.18 and the lines are 0.25. This means the full 0.18 shrink of K7 will have a much lower boost than a full 0.25 to 0.18 transition (e.g. Katmai -> Coppermine). AMD advertises it as 0.25, probably to mislead people into thinking that the 0.18 shrink is going to gain them so much, and that the current part is just a preview.
Third, while Coppermine is debuting at only 700/733 those are the first parts. K7 debuted at 500/550/600 but that doesn't mean only those parts will be available for the future.
Coppermine is a river, and all the IA-32 chips designed in Oregon are named after rivers.
Some of the more clueless people around here think that calling it Coppermine is false advertising. Coppermine is an internal name for the project (it will be marketed as Pentium III), so there's no "advertising" involved.
Furthermore, the Coppermine project was started (and named) long before IBM had announced that they were using copper. It's not like Intel could have known that at that time that copper would be the latest buzzword in the industry when the part came out. It's 100% coincidence.
Why does Petreley feel the need to spread FUD about 64 bit Windows? He says "Microsoft was making such poor progress with 64-bit NT". What are the details? What problems specific to 64 bit could Windows be having? He uses "facts" like this, which contain absolutely no details whatsoever, and it makes it sound like it is just something he heard off of a rumor mill, and it also makes him sound like he has very minimal system design experience of his own. Undetailed, ungrounded FUD like this is regularly passed around and it sounds clearly unbased in reality, and intended just be a more feel-good juice to appease the Microsoft-hating crowd rather than to make any sort of intelligent journalism.