On 20 May 2010 03:37, Jason Moxham <[email protected]> wrote: > On Thursday 20 May 2010 03:11:24 Bill Hart wrote: >> On 20 May 2010 02:58, Jason Moxham <[email protected]> wrote: >> > On Thursday 20 May 2010 02:11:11 Bill Hart wrote: >> >> There's a new Opteron on the block. family 16 model 8. It's an Opteron >> >> 8439 SE. We don't have it in cpuid.c yet. >> > >> > Looks like another K102 , doesn't look like any differences for us , >> > although we dont know until we test it. >> >> Passes make check once the cpuid is put in. See below for bench. This >> particular machine is 2.8GHz(owner is in cc). I didn't make tune, but >> that shouldn't be needed. >> >> Index: cpuid.c >> =================================================================== >> --- cpuid.c (revision 2928) >> +++ cpuid.c (working copy) >> @@ -120,7 +120,8 @@ >> case 16: >> if (model == 2) { CPUIS(k10);break;} >> if (model == 4) { CPUIS(k102);break;} >> - break; >> + if (model == 8) { CPUIS(k102);break;} >> + break; >> } >> } >> else if (strcmp (vendor_string, "CentaurHauls") == 0) >> >> > By the way the difference between what we call the K102 and the K10 , is >> > the "same" as the difference between early K8 and late K8's , a slight >> > difference in L1-data cache and store forwarding , which does effect some >> > functions eg copy,addadd,lshiftcom , some more than others >> > >> >> Also we currently have a symbol in the library, mpn_sqr_n and a >> >> #define in mpir.h to rename it mpn_sqr in line with gmp. But that >> >> isn't sufficient. It breaks gcc on machines where gcc has been built >> >> with dynamic libs. On the face of it this shouldn't affect anyone, but >> >> in fact it will affect lots of people. The only solution I see is to >> >> rename the library symbol. >> > >> > we can just export both names , so we are compatible with the new gmp AND >> > the old >> >> Yeah, I noticed that. >> >> Anyhow, good idea, but not in mpir.h. It has to be in the library itself. >> > I ment in the library , trying to think how you do it :) , I know how to do it > in asm , but in C ?
I don't know either, I mean without duplicating the code or incurring extra overheads. The compiler is going to inline anything efficient anyway! > >> >> Also, GMP defines mpn_copyi and mpn_copyd. On generic x86_64 machines, >> >> we don't seem to have any assembly for this. There's no fallback >> >> generic C symbol in the lib. >> > >> > we can the fallback C code that a fat build uses , with the new K102 >> > cpuid above there is no current generic x86_64 cpu :) >> >> True. >> >> >> Bill. >> >> AuthenticAMD Family 16 Model 8 Stepping 0 >> Six-Core AMD Opteron(tm) Processor 8439 SE >> Speed: 0.80 GHz (reported) > > powersave on ? , below useless Probably affects only the first timing. I think it is probably on demand. > >> Category base >> Program multiply (weight 1.00) >> 128 128 => 62415242 >> 512 512 => 14910433 >> 8192 8192 => 174206 >> 131072 131072 => 3012 >> 2097152 2097152 => 108 >> 128 128 => 57065363 >> 512 512 => 13512577 >> 8192 8192 => 120162 >> 131072 131072 => 2251 >> 2097152 2097152 => 74.3 >> 15000 10000 => 59494 >> 20000 10000 => 46812 >> 30000 10000 => 27429 >> 16777216 512 => 458 >> 16777216 262144 => 13.7 => 37401,46751 >> Program divide (weight 1.00) >> 8192 32 => 1654949 >> 8192 64 => 1526756 >> 8192 128 => 926962 >> 8192 4096 => 297892 >> 131072 65536 => 3232 >> 8388608 4194304 => 11.5 >> 8192 8064 => 8473345 >> 16777216 262144 => 4.76 => 31816,39770 >> Program divexact (weight 1.00) >> 8192 32 => 1872460 >> 8192 64 => 1853921 >> 8192 128 => 786511 >> 8192 4096 => 360487 >> 131072 65536 => 3813 >> 8388608 4194304 => 11.8 >> 8192 8064 => 14242122 >> 16777216 262144 => 7.84 => 38603,48254 >> Program gcd (weight 0.50) >> 128 128 => 2284479 >> 512 512 => 227241 >> 8192 8192 => 5964 >> 131072 131072 => 111 >> 1048576 1048576 => 6.36 => 4656, 5819 >> Program gcdext (weight 0.50) >> 128 128 => 988477 >> 512 512 => 175371 >> 8192 8192 => 4609 >> 131072 131072 => 68.3 >> 1048576 1048576 => 4.31 => 2981, 3726 >> Program root (weight 0.30) >> 128 5 => 1142240 >> 512 3 => 514009 >> 8192 11 => 158261 >> 131072 3 => 4138 >> 1048576 3 => 190 => 37396,46745 >> Program fac_ui (weight 0.20) >> 128 128 => 1588752 >> 1512 1512 => 53386 >> 15000 15000 => 1249 >> 1000010 1000010 => 4.39 >> 2123456 2123456 => 1.63 => 945, 1182 => 18481,23101 >> Category app >> Program rsa (weight 1.00) >> 512 => 24338 >> 1024 => 5200 >> 2048 => 883 => 4817, 6021 >> Program pi (weight 1.00) >> 10000 => 458 >> 100000 => 27.0 >> 1000000 => 1.61 => 27.1, 33.9 >> Program bpsw (weight 1.00) >> 1024 => 1138 >> 4096 => 32.4 >> 16384 => 0.840 => 31.4, 39.2 >> Program wagstaff (weight 1.00) >> 1024 => 2626 >> 4096 => 105 >> 16384 => 3.36 => 97.5, 122 => 141, 177 => 1617, >> 2021 > > -- > You received this message because you are subscribed to the Google Groups > "mpir-devel" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/mpir-devel?hl=en. > > -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
