To David Gerrard. The "See Also: AMD64" line at the top of the introduction was put there to emphasize that the main technical article would be AMD64, and that EM64T would only be an article about the history of Intel's EM64T in relation to AMD64. So it was not superfluous, it was deliberate.
Also I don't believe the bottom paragraph linking to articles that said that Intel's Nocona has performance problems is something that belongs in an encyclopedia. First of all, as of this moment Intel has not released any hardware with EM64T in it yet, everything is still in pre-release. Secondly, performance problems in a particular instance of hardware are a fleeting incident in an architecture that is expected to be around over several generations.
-- ykhan 16:58, 2004 May 2 (UTC)
Is there a reference for this last paragraph, that Intel 'copied' the technology from AMD. That is rubbish/hype and a contrast to earlier statements of the article. This is not a 'new' technology, its an extension which means the direction was already deturmined. When AMD64 was 'developed' there wasn't any 'latitude' its IA-32 x2 with a few other items added. Indeeded calling it a technology is a little far fetched.
Is this really true? It makes the article sound really bias aganst Intel. Although I wouldnt be supprised if Intel did copy AMD64 technology but I havent seen any actual proof that they did. Performance issues are also a bias sounding thing, but we'll know when actual benchmarks are to be seen, unless they already exist and I havent gone over them yet.
Until the issue dealing with suposed copying technology is resolved and the performance issue of EM64T vs Rivals, the neutrality of this article should be disputed. Sorry.
Thank you much better.
The Yamhill and Clackamas references within Intel are named after the Yamhill River and Clackamas River--two rivers in Oregon--and not after the Oregon counties which mostly contain them. I'll correct the main page.
Regarding copying; Intel and AMD have been copying each others' instruction sets and such for years. Much of AMD's line is a clone of Intel's stuff (including some key enabling technologies licensed to AMD by Intel); to claim that Intel is now "copying" AMD64 is not fair comment--unless one has evidence that Intel is doing anything below board. Emulating/supporting an existing instruction set is neither illegal nor immoral in the world of CPU design.
-- EngineerScotty 22:52, 2 September 2005 (UTC)
http://www.theinquirer.net/?article=20072
Quite strange saying. Intel claimed that AMD had stolen most part of AMD64 form them :)
This statement is true but misleading: the double-width compare-and-swap is primarily used in Lock-free and wait-free algorithms. —The preceding unsigned comment was added by 81.19.78.190 ( talk • contribs) 16:40, December 16, 2005 (UTC)
I'd like a source for this latest addition (especially the part claiming it's only useful for hyperthreaded processors). Given the technical definition of these instructions from Intel's own manuals, these would seem to be useful even in multi-core processors (not just hyperthreaded/SMT processors). If there's no verifiable source (or no objection) in a few days, I'll likely remove the passage. — Locke Cole • t • c 07:55, 2 January 2006 (UTC)
OK, but understand that this demand of yours is rude and irritating. It's something you should reserve for when you have consensus that the text is wrong.
The instructions are not quite 100% useless on plain SMP and dual-core. Having them is nice, and you might as well take advantage of that, but it doesn't really matter.
As evidence, see the linux-kernel mailing list (google site:lkml.org mwait) and the chunk of Linux kernel source code which I quote below:
arch/i386/kernel/process.c-276-static int __init idle_setup (char *str) arch/i386/kernel/process.c-277-{ arch/i386/kernel/process.c-278- if (!strncmp(str, "poll", 4)) { arch/i386/kernel/process.c-279- printk("using polling idle threads.\n"); arch/i386/kernel/process.c-280- pm_idle = poll_idle; arch/i386/kernel/process.c-281-#ifdef CONFIG_X86_SMP arch/i386/kernel/process.c-282- if (smp_num_siblings > 1) arch/i386/kernel/process.c-283- printk("WARNING: polling idle and HT enabled, performance may degrade.\n"); arch/i386/kernel/process.c-284-#endif arch/i386/kernel/process.c-285- } else if (!strncmp(str, "halt", 4)) { arch/i386/kernel/process.c-286- printk("using halt in idle threads.\n"); arch/i386/kernel/process.c-287- pm_idle = default_idle; arch/i386/kernel/process.c-288- }
Note the explicit check for hyperthreading (smp_num_siblings > 1) and the mention of hyperthreading (HT) in the warning message. This warning will not print on a non-hyperthread system. The warning is used because having one side of a hyperthreaded CPU poll memory will cause the other side to get fewer cycles.
This old discussion may be of interest: http://lkml.org/lkml/2004/9/12/41
24.110.60.225
AlbertCahalan
03:33, 5 January 2006 (UTC)
I see that the SSE3 page already provides a reference. I hope you ( Locke Cole) don't make such burdensome and abusive demands in the future, to me or to any other person editing wikipedia.
24.110.60.225
AlbertCahalan
03:55, 5 January 2006 (UTC)
Please take a deep breath, 24.110.60.225, and calm down. If you look again at LockeCole's original post, there was nothing rude there. He did not demand sources, just asked about the statement. In fact he was quite considerate in starting a discussion here rather than just deleting the text that seemed incorrect to him. Comments on article text which you may have written is not an attack. - R. S. Shaw 06:40, 5 January 2006 (UTC)
This article has a clear bias towards AMD and the originator will not allow changes to make it accurate. He does not know the real history here and will not allow it to be changed to reflect that and is therefore a fairly useless article as it reflects how he wishes history to be written. For example, what he doesn't seem to know or is choosing to ignore is that Intel developed the 64 bit extensions back in 97/98 and as part of a deal with Microsoft around the Itanium port of Windows Intel agreed that MS could disclose the specifications for said extensions to AMD. This story is far more complex than the author knows and his bias is evident.
It's been over 24 hours now and no answer from 143.183.121.3, so I've removed his disputed tag from the top of the article. I've only just now run a whois lookup - the IP belongs to Intel! One wonders what his motives were, and if the story had any truth to it. I mean, Intel and AMD have had some licensing deals in the past, that was how the Am386 came about. But that was a long time ago and I just cannot see this happening in the recent climate of competitiveness. And why on earth would Intel decide to run with two completely incompatible 64-bit architectures? I find that his claimed version of events just doesn't make sense. Imroy 06:17, 16 March 2006 (UTC)
Articles like this shouldn't be put in here :D Imagine if someone who is not familiar with either Intel or AMD reading this. Reading between the lines is not fun here. It's as chronical Intel fall down article as any AMD fan would write. What reverse ingeneering ? x86 is an Intel architecture and AMD were not invited to it. But they did copy as much as they can and made cpus on another's back. AMD always tried and tried and tried to achieve something here. First it was the Big Fat cpu Copy. Of course it sucked. Then it was fabric cpu overcloack, which did not suck that much, but smelled and caused overheating insted (even now you can see explosion of a modern AMD cpu at google videos, it took a part of the mainboard along with itself): by the time when Intel made 2.4 GHz P4 which could be o/cloacked up to 2.8 or 3.2 GHz (I don't remember right now) without even change of the core voltage, AMD fans were experiencing the 1.4 GHz AMD cpus fabricaly o/cloacked to 2.0 GHz (and running hot as hell). Then of course came along the time for at-home 64bit cpus. Alright. Intel showed the world a brand new 64 bit technology, made from scratch. They called it Itanium, IA-64. What AMD did then ? Hehe, no, they didn't copy. They just kept the good old Intel x86 arch but extending it with 64 registers, which meant not only 64 bit computation and almost no effort what-so-ever (again) (and comparing to the Itanium creation) but also the possibility of performing these good old Intel x86 instructions, so much used in the world at the time. While Intel of course faced the need of software for their platform. Well, what can I say ? Yes, for a first time Intel had to face with their actions all the **** AMD slowly created as the years passed by and make their own 64 extension of the x86 arch. Did they reverse ingeneered it ? Well how can you reverse ingeneer something you made 15 years ago, in the first place, from someone who had stolen it 10 years ago.—Preceding unsigned comment added by Butterfly collector ( talk • contribs) 23:17, July 8, 2006
To David Gerrard. The "See Also: AMD64" line at the top of the introduction was put there to emphasize that the main technical article would be AMD64, and that EM64T would only be an article about the history of Intel's EM64T in relation to AMD64. So it was not superfluous, it was deliberate.
Also I don't believe the bottom paragraph linking to articles that said that Intel's Nocona has performance problems is something that belongs in an encyclopedia. First of all, as of this moment Intel has not released any hardware with EM64T in it yet, everything is still in pre-release. Secondly, performance problems in a particular instance of hardware are a fleeting incident in an architecture that is expected to be around over several generations.
-- ykhan 16:58, 2004 May 2 (UTC)
Is there a reference for this last paragraph, that Intel 'copied' the technology from AMD. That is rubbish/hype and a contrast to earlier statements of the article. This is not a 'new' technology, its an extension which means the direction was already deturmined. When AMD64 was 'developed' there wasn't any 'latitude' its IA-32 x2 with a few other items added. Indeeded calling it a technology is a little far fetched.
Is this really true? It makes the article sound really bias aganst Intel. Although I wouldnt be supprised if Intel did copy AMD64 technology but I havent seen any actual proof that they did. Performance issues are also a bias sounding thing, but we'll know when actual benchmarks are to be seen, unless they already exist and I havent gone over them yet.
Until the issue dealing with suposed copying technology is resolved and the performance issue of EM64T vs Rivals, the neutrality of this article should be disputed. Sorry.
Thank you much better.
The Yamhill and Clackamas references within Intel are named after the Yamhill River and Clackamas River--two rivers in Oregon--and not after the Oregon counties which mostly contain them. I'll correct the main page.
Regarding copying; Intel and AMD have been copying each others' instruction sets and such for years. Much of AMD's line is a clone of Intel's stuff (including some key enabling technologies licensed to AMD by Intel); to claim that Intel is now "copying" AMD64 is not fair comment--unless one has evidence that Intel is doing anything below board. Emulating/supporting an existing instruction set is neither illegal nor immoral in the world of CPU design.
-- EngineerScotty 22:52, 2 September 2005 (UTC)
http://www.theinquirer.net/?article=20072
Quite strange saying. Intel claimed that AMD had stolen most part of AMD64 form them :)
This statement is true but misleading: the double-width compare-and-swap is primarily used in Lock-free and wait-free algorithms. —The preceding unsigned comment was added by 81.19.78.190 ( talk • contribs) 16:40, December 16, 2005 (UTC)
I'd like a source for this latest addition (especially the part claiming it's only useful for hyperthreaded processors). Given the technical definition of these instructions from Intel's own manuals, these would seem to be useful even in multi-core processors (not just hyperthreaded/SMT processors). If there's no verifiable source (or no objection) in a few days, I'll likely remove the passage. — Locke Cole • t • c 07:55, 2 January 2006 (UTC)
OK, but understand that this demand of yours is rude and irritating. It's something you should reserve for when you have consensus that the text is wrong.
The instructions are not quite 100% useless on plain SMP and dual-core. Having them is nice, and you might as well take advantage of that, but it doesn't really matter.
As evidence, see the linux-kernel mailing list (google site:lkml.org mwait) and the chunk of Linux kernel source code which I quote below:
arch/i386/kernel/process.c-276-static int __init idle_setup (char *str) arch/i386/kernel/process.c-277-{ arch/i386/kernel/process.c-278- if (!strncmp(str, "poll", 4)) { arch/i386/kernel/process.c-279- printk("using polling idle threads.\n"); arch/i386/kernel/process.c-280- pm_idle = poll_idle; arch/i386/kernel/process.c-281-#ifdef CONFIG_X86_SMP arch/i386/kernel/process.c-282- if (smp_num_siblings > 1) arch/i386/kernel/process.c-283- printk("WARNING: polling idle and HT enabled, performance may degrade.\n"); arch/i386/kernel/process.c-284-#endif arch/i386/kernel/process.c-285- } else if (!strncmp(str, "halt", 4)) { arch/i386/kernel/process.c-286- printk("using halt in idle threads.\n"); arch/i386/kernel/process.c-287- pm_idle = default_idle; arch/i386/kernel/process.c-288- }
Note the explicit check for hyperthreading (smp_num_siblings > 1) and the mention of hyperthreading (HT) in the warning message. This warning will not print on a non-hyperthread system. The warning is used because having one side of a hyperthreaded CPU poll memory will cause the other side to get fewer cycles.
This old discussion may be of interest: http://lkml.org/lkml/2004/9/12/41
24.110.60.225
AlbertCahalan
03:33, 5 January 2006 (UTC)
I see that the SSE3 page already provides a reference. I hope you ( Locke Cole) don't make such burdensome and abusive demands in the future, to me or to any other person editing wikipedia.
24.110.60.225
AlbertCahalan
03:55, 5 January 2006 (UTC)
Please take a deep breath, 24.110.60.225, and calm down. If you look again at LockeCole's original post, there was nothing rude there. He did not demand sources, just asked about the statement. In fact he was quite considerate in starting a discussion here rather than just deleting the text that seemed incorrect to him. Comments on article text which you may have written is not an attack. - R. S. Shaw 06:40, 5 January 2006 (UTC)
This article has a clear bias towards AMD and the originator will not allow changes to make it accurate. He does not know the real history here and will not allow it to be changed to reflect that and is therefore a fairly useless article as it reflects how he wishes history to be written. For example, what he doesn't seem to know or is choosing to ignore is that Intel developed the 64 bit extensions back in 97/98 and as part of a deal with Microsoft around the Itanium port of Windows Intel agreed that MS could disclose the specifications for said extensions to AMD. This story is far more complex than the author knows and his bias is evident.
It's been over 24 hours now and no answer from 143.183.121.3, so I've removed his disputed tag from the top of the article. I've only just now run a whois lookup - the IP belongs to Intel! One wonders what his motives were, and if the story had any truth to it. I mean, Intel and AMD have had some licensing deals in the past, that was how the Am386 came about. But that was a long time ago and I just cannot see this happening in the recent climate of competitiveness. And why on earth would Intel decide to run with two completely incompatible 64-bit architectures? I find that his claimed version of events just doesn't make sense. Imroy 06:17, 16 March 2006 (UTC)
Articles like this shouldn't be put in here :D Imagine if someone who is not familiar with either Intel or AMD reading this. Reading between the lines is not fun here. It's as chronical Intel fall down article as any AMD fan would write. What reverse ingeneering ? x86 is an Intel architecture and AMD were not invited to it. But they did copy as much as they can and made cpus on another's back. AMD always tried and tried and tried to achieve something here. First it was the Big Fat cpu Copy. Of course it sucked. Then it was fabric cpu overcloack, which did not suck that much, but smelled and caused overheating insted (even now you can see explosion of a modern AMD cpu at google videos, it took a part of the mainboard along with itself): by the time when Intel made 2.4 GHz P4 which could be o/cloacked up to 2.8 or 3.2 GHz (I don't remember right now) without even change of the core voltage, AMD fans were experiencing the 1.4 GHz AMD cpus fabricaly o/cloacked to 2.0 GHz (and running hot as hell). Then of course came along the time for at-home 64bit cpus. Alright. Intel showed the world a brand new 64 bit technology, made from scratch. They called it Itanium, IA-64. What AMD did then ? Hehe, no, they didn't copy. They just kept the good old Intel x86 arch but extending it with 64 registers, which meant not only 64 bit computation and almost no effort what-so-ever (again) (and comparing to the Itanium creation) but also the possibility of performing these good old Intel x86 instructions, so much used in the world at the time. While Intel of course faced the need of software for their platform. Well, what can I say ? Yes, for a first time Intel had to face with their actions all the **** AMD slowly created as the years passed by and make their own 64 extension of the x86 arch. Did they reverse ingeneered it ? Well how can you reverse ingeneer something you made 15 years ago, in the first place, from someone who had stolen it 10 years ago.—Preceding unsigned comment added by Butterfly collector ( talk • contribs) 23:17, July 8, 2006