Aw come on, AMD hasn't done too badly. At least now they have "a portfolio of products suited to a range of needs" or something like that. That's much better than the kx naming system.
Anyhow, given the justification you already gave, these names seem good to me. Bill. 2009/3/19 Jason Moxham <ja...@njkfrudils.plus.com>: > > > A summary of the new proposed x86_64 directorys > > base directory when all we know is that it is 64bit x86 and for any code that > is common to all x86_64 chips > x86_64 > > For the AMD chips AKA Opteron=K8 Phenom=k10 > x86_64/k8 > x86_64/k8/k10 > > For the Intel core2 chips AKA merom=core2-65nm dunnington=penryn=core2-45nm > x86_64/core2 > x86_64/core2/penryn > > For the Intel atom , this has no OOO so the code is likely to be different > x86_64/atom > > For the Intel nehalem AKA i7 > x86_64/nehalem > > For the Intel netburst AKA pentium D or nocona > x86_64/netburst > x86_64/netburst/netburstlahf > > This covers all the microarchitectural differences that we take advantage of > currently. It does not cover number of cores or size of caches or irrelavent > microarchitectural differences (eg virtualization,PGE...) > > The name netburst was chosen to reflect the microarchitecture , whereas > pentium is a brand name that means lots of things , although in the 64bit > context there really is no confusion.nocona is also a possibility. > > The core2,penryn names should perhaps be changed as sometimes these can refer > to platforms and each other , but they do refer to the penryn new > instructions in the docs > > If this is OK , I can merge into trunk , we can argue about and change the > names later :) > > Jason > > Thanks to Jeff for all those benchmarks , without them I wouldn't be able to > separate the wheat from the chaff . > > No thanks at all to AMD and especially Intel for the most meaningless set of > codenames,platform names, chipset names and other marketing speak. :( > > On Thursday 19 March 2009 00:35:26 Jason Moxham wrote: >> On Tuesday 17 March 2009 18:40:30 Bill Hart wrote: >> > Jason, >> > >> > I had a look over this and it looks brilliant. This really deals with >> > a number of tickets, which is great! >> > >> > Some comments: >> > >> > The name athlon seems inconsistent with k5, k6, k62, k63, k8, k10. It >> > seems to me that Athlon and k7 are synonymous, so shouldn't we use the >> > latter? >> >> I'll change athlon to K7 >> >> > I also wonder if there is a way to distinguish intel family 15 and 22? >> > Is one lot high end Xeon as opposed to low end core2? If we can figure >> > out what the reason intel had for splitting this lot into two >> > families, we can probably be more precise about something. >> >> As far as I can tell we have for "core2" branded processors >> >> F=6 M=15 core2 65nm >> F=6 M=22 core2 65nm lowend cpu? >> F=6 M=23 Penryn 45nm >> F=6 M=29 Penryn 45nm dunnington >> >> Penryn have a faster div instruction and a faster sse shuffle (you can >> allready see it effect on the current shifting code) >> >> As far as I know there are no architectural differences for 15/22 or >> 23/29. There are differences in number cores and cache sizes , but we dont >> yet care about that. >> >> The existing mpn/generic/sumdiff_n.c code does depend on L1-cache size (a >> little bit). >> >> > Also, I'm not seeing nocona any more? We originally distinguished p4, >> > prescott and the 64 bit versions which we called nocona. I now see >> > prescott, netburst and pentium4. Admittedly nocona is a codename for a >> > certain Xeon revision (basically the Xeon for which intel introduced >> > Intel64), and it is also used by gcc to identify 64 bit p4's, so it >> > seemed convenient to Gonzalo Tornaria and I to use it to distinguish >> > 64 bit p4's. Now I think it wasn't such a good idea as some prescotts >> > are actually 64 bit. But what is the difference between pentium4 and >> > netburst? >> >> none >> >> > I suppose the other thing that worries me slightly is that we now have >> > AMD's named by core revision and Intel's named by a mixture of >> > marketing names and technologies. I'm actually not worried about that >> > as such, as it might be the best way to do it for now until the whole >> > mess clicks into place for us. >> >> It wasn't always clear what names were used for what purposes , my >> intention was that the names should correspond to the microarchitecture , >> and I only did the 64bit side , I have left the 32bit alone. >> >> Lets get the 64bit side sorted first. >> >> > But the intel chips do seem to have had internal core names as well. >> > Roughly speaking, here is a list: >> > >> > 386 -> i386 >> > 486 -> i486 >> > pentium ->p5 >> > pentiumpro ->p6 >> > pentium2 ->p6 >> > pentium3 ->p6 >> > pentiumM ->p6 >> > yonah -> p6 >> > core duo ->p6 >> > pentium4->p68 >> > netburst -> p68 >> > "nocona"->p68 >> > prescott->p68 >> > core2 -> p6 >> > itanium -> p7 (not x86) >> > nehalem -> i7 >> > atom >> > >> > It's not clear to me why we are distinguishing core2/penryn and not >> > core2 family 15 and core2 family 22. If we distinguish penryn, why not >> > conroe, allendale, wolfdale, kentsfield, yorkfield, penryn and merom? >> > I'm not suggesting we distinguish all these, as they are all core2. >> > I'm just wondering, why distinguish penryn. >> > >> > One other confusion of course is that prescott was a major reworking >> > of the previous netburst cores, which according to wikipedia made >> > people wonder why Intel didn't call it pentium5. Intel apparently >> > tried numerous core redesigns as they had initially thought clock >> > speeds of the p4 (netburst) architecture would scale to 10GHz. That's >> > one of the reasons we had distinguished pentium4 and prescott in the >> > old naming system (that and the SSE3 revision of prescott). >> > >> > Another confusion is that intel called netbust p68 whereas everyone >> > else called it p7. They called itanium p7, which is not an x86 >> > processor. >> > >> > Another confusion is that pentiumM's revived the p6 architecture, >> > being a reworking of prior pentium III's. But they were perhaps >> > sufficiently different to be considered a separate thing. >> > >> > It makes me wonder if we shouldn't use a naming system like: >> > >> > k5, k6, k7, k8, k9, k10, etc >> > >> > p5, p6, p7, i7, atom >> > >> > Of course we should distinguish prescott and core2: >> > >> > p7pres, p6core2 >> > >> > For systems where there can be confusion over non mmx and mmx, and sse >> > revisions, we could append that: >> > >> > p5, p5mmx, p6, p6sse2, p6sse3, etc >> > >> > That only leaves the lahf issue. We'd have to have p7, p7lahf, p7pres I >> > suppose. >> > >> > Of course we'd not be distinguishing pentiumpro, pentium2, pentium3, >> > etc. with this naming system, but if you think about it, we don't have >> > separate code for these anyhow, and there probably wouldn't be any >> > difference, even if someone could be bothered writing it (hardly >> > likely). They all currently get assigned to the p6 directory (I >> > think). >> > >> > I don't know if there is any ideal solution here. The one critical >> > piece of missing info now is whether it is a 32 or 64 bit chip. For >> > AMD it is trivial I think. But we'd have to have p7 and p7_64, p7pres >> > and p7pres_64 I suppose. It's not clear if there are any other >> > possible confusions. >> >> Don't see why we want to know this? >> >> > Also p7pres may be unnecessary, as they are distinguished by their >> > SSE3 revision. Could we/should we have: >> > >> > p5 (pentium), p5mmx (pentium mmx), p6 (pentium II, Celeron, Pentium >> > pro, Xeon), p6sse (pentium III, Xeon), p7 (pentium4, Xeon), p7lahf, >> > p7sse3 (prescott), p7sse3_64 (nocona), p6sse2 (pentium M, celeronM), >> > p6sse3 (yonah/core), p6core2 (core2), i7 (nehalem), atom? >> > >> > sse2 was introduced from the very first pentium4 (p7), so no need for >> > p7sse2 >> > >> > sse3 and intel64 seem to come together in Xeons, intel64 only comes >> > with chips since prescott in Celeron D and Pentium 4 chips, all >> > pentiumD's are 4 bit and have SSE3 and similarly for pentium extreme, >> > so there is no need for p7sse2_64 as it doesn't exist. >> > >> > Eventually with some work, we may be able to get rid of p7lahf. >> > Apparently the cmov instruction available on some chips but not others >> > is also used a lot in optimisation, making many things faster. I don't >> > know that we use it at all though, yet. >> > >> > (The brackets indicate what processors start with this core and are >> > not part of the proposed names.) >> > >> > Technically p6core2 is inconsistent naming. It should be p6_64. >> > >> > A final note: there may be some confusion with SSE revisions of AMD >> > chips, so we might need k8, k8sse3, etc. >> > >> > 2009/3/17 Jason Moxham <ja...@njkfrudils.plus.com>: >> > > In the svn branch x86_64-cpuid is my attempt at re-organizing the >> > > x86_64 processors. >> > > >> > > The file cpuid.c is now the only place where detection takes place , >> > > before we had config.guess and the two fat.c , they now just #inlcude >> > > "cpuid.c" >> > > >> > > cpuid.c returns the microarchitecture of the processor only , no >> > > consideration of what code will be run. >> > > >> > > in 64bit mode we have >> > > x86_64(default) core2 penryn nehalem atom netburst netburstlahf k8 k10 >> > > >> > > in 32bit mode we have >> > > i486(default) pentium pentiummmx pentiumpro pentium2 pentium3 core >> > > pentium4 prescott k5 k6 k62 k63 athlon viac3 viac32 core2 penryn >> > > nehalem atom k8 k10 >> > > >> > > I've not changed the x86 CFLAGS or asm path order for static/fat ( I >> > > hope) >> > > >> > > for non-fat builds this is the asm path search order >> > > >> > > x86_64-*-*) >> > > path_64="x86_64" ;; >> > > netburst-*-*) >> > > path_64="x86_64/netburst x86_64" ;; >> > > netburstlahf-*-*) >> > > path_64="x86_64/netburst/netburstlahf x86_64/netburst >> > > x86_64" ;; k8-*-*) >> > > path_64="x86_64/k8 x86_64" ;; >> > > k10-*-*) >> > > path_64="x86_64/k8/k10 x86_64/k8 x86_64" ;; >> > > core2-*-*) >> > > path_64="x86_64/core2 x86_64" ;; >> > > penryn-*-*) >> > > path_64="x86_64/core2/penryn x86_64/core2 x86_64" ;; >> > > nehalem-*-*) >> > > path_64="x86_64/nehalem x86_64" ;; >> > > atom-*-*) >> > > path_64="x86_64/atom x86_64" ;; >> > > >> > > there is a similar one in configure.in for 64bit cpu in 32bit OS >> > > and a similar fat path search order in fat.c >> > > >> > > I've tested on a few machines , and it all appears to work. What I will >> > > do is fake each cpu and test the paths that it uses. >> > > >> > > Jason >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-devel@googlegroups.com To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en -~----------~----~----~----~------~----~------~--~---
