[mpir-devel] Re: eMPIRe-svn1523 vs. Sage 3.2.3

2009-01-03 Thread mabshoff
Ok, I did valgrind all the tests and aside from one tiny issue t- locale I found no problems in all 109 or so tests I found. Time to catch some sleep :) Cheers, Michael t-locale is a C++ issue, but I haven't looked at the sources yet or even build with debug info so I could start poking around

[mpir-devel] Re: eMPIRe-svn1523 vs. Sage 3.2.3

2009-01-03 Thread mabshoff
On Jan 3, 7:00 pm, ja...@njkfrudils.plus.com wrote: > On Sunday 04 January 2009 02:52:55 mabshoff wrote: Hi Jason, > > Can you write a test and check it in? I am not sure if anyone added > > one yet. > > the above from current svn of mpir trunk at tests/mpz/t-perfpow.c Ok, please excuse my du

[mpir-devel] Re: eMPIRe-svn1523 vs. Sage 3.2.3

2009-01-03 Thread jason
On Sunday 04 January 2009 02:52:55 mabshoff wrote: > On Jan 3, 6:48 pm, ja...@njkfrudils.plus.com wrote: > > On Sunday 04 January 2009 01:56:15 mabshoff wrote: > > Hi Jason, > > > > So while the results are correct we either have an unfixed memory leak > > > either in Sage and/or eMPIRe. I have pl

[mpir-devel] Re: eMPIRe-svn1523 vs. Sage 3.2.3

2009-01-03 Thread mabshoff
On Jan 3, 6:48 pm, ja...@njkfrudils.plus.com wrote: > On Sunday 04 January 2009 01:56:15 mabshoff wrote: Hi Jason, > > So while the results are correct we either have an unfixed memory leak > > either in Sage and/or eMPIRe. I have planned to do some valgrinding on > > eMPIRe as well as Sage+eM

[mpir-devel] Re: eMPIRe-svn1523 vs. Sage 3.2.3

2009-01-03 Thread jason
On Sunday 04 January 2009 01:56:15 mabshoff wrote: > On Jan 3, 5:20 pm, mabshoff > dortmund.de> wrote: > > Hi, > > > > > I am now running some larger examples to see if anything pops up. > > Oops, I nearly too sage.math down with a 189GB job (not a typo) when > running this: > >time len([a f

[mpir-devel] Re: eMPIRe-svn1523 vs. Sage 3.2.3

2009-01-03 Thread Jason Martin
Excellent!! Thanks for the error checking Michael!! Jason Worth Martin Asst. Professor of Mathematics http://www.math.jmu.edu/~martin On Sat, Jan 3, 2009 at 8:56 PM, mabshoff wrote: > > > > On Jan 3, 5:20 pm, mabshoff dortmund.de> wrote: >> Hi, > > > >> I am now running some larger example

[mpir-devel] Re: K10 detection trouble

2009-01-03 Thread Jason Martin
Fair enough. I don't have any strong opinions on the matter. I should probably update the Intel code to include your popcount routine since the new Intel cores support the SSE 4.1 instruction for popcount on the xmm registers. --jason On Sat, Jan 3, 2009 at 8:02 PM, wrote: > > On Sunday 04

[mpir-devel] Re: eMPIRe-svn1523 vs. Sage 3.2.3

2009-01-03 Thread mabshoff
On Jan 3, 5:20 pm, mabshoff wrote: > Hi, > I am now running some larger examples to see if anything pops up. Oops, I nearly too sage.math down with a 189GB job (not a typo) when running this: time len([a for a in srange(10*10) if not (-a^3).is_perfect_power ()]) This might have been a

[mpir-devel] eMPIRe-svn1523 vs. Sage 3.2.3

2009-01-03 Thread mabshoff
Hi, I just created a gmp-mpir-svn1523.spkg and build Sage 3.2.3.final against it. The good new is that the segfaults I reported for svn-14XX are gone and that we are seeing 11 doctest failures: sage -t devel/sage/sage/modular/cusps.py # 1 doctests failed sage -t devel/sage/sage

[mpir-devel] Re: K10 detection trouble

2009-01-03 Thread jason
On Sunday 04 January 2009 00:57:44 ja...@njkfrudils.plus.com wrote: > On Sunday 04 January 2009 00:36:46 Jason Martin wrote: > > Alternatively, we could stop trying to identify chips by marketing > > brands and just use the values returned by CPUID. This would create a > > lot of duplicated code

[mpir-devel] Re: K10 detection trouble

2009-01-03 Thread jason
On Sunday 04 January 2009 00:36:46 Jason Martin wrote: > Alternatively, we could stop trying to identify chips by marketing > brands and just use the values returned by CPUID. This would create a > lot of duplicated code in sub-directories, but disk space is cheap. > So, would something like: > >

[mpir-devel] Re: K10 detection trouble

2009-01-03 Thread Bill Hart
That seems complicated. In order to figure out which assembly files to modify, one needs to know the CPUID of the processors one wishes to work on. Also, given that there are probably 20 odd Intel and 10 AMD family/model combinations this is a lot of directories and unnecessary duplication. I thi

[mpir-devel] Re: K10 detection trouble

2009-01-03 Thread Jason Martin
Alternatively, we could stop trying to identify chips by marketing brands and just use the values returned by CPUID. This would create a lot of duplicated code in sub-directories, but disk space is cheap. So, would something like: mpn/x86_64// work for our configuration? Jason Worth Martin Ass

[mpir-devel] Re: K10 detection trouble

2009-01-03 Thread Bill Hart
I think that features such as SSE should be tested for after testing for the main chip core. So under /mpn/x86_64/k8 you'd have directories for any features not available on all k8's. Bill. 2009/1/3 mabshoff : > > > > On Jan 3, 2:25 pm, jason wrote: >> On Jan 3, 9:00 am, "Bill Hart" wrote: > >

[mpir-devel] Re: K10 detection trouble

2009-01-03 Thread mabshoff
On Jan 3, 2:25 pm, jason wrote: > On Jan 3, 9:00 am, "Bill Hart" wrote: Hi, > > The new intel machines. And I don't know if all Dunnington's use the > > same family/system CPUID etc. So there might be mutiple CPUID's we > > need to add to config.guess. > > > Bill. > > We should change the lo

[mpir-devel] Re: K10 detection trouble

2009-01-03 Thread Bill Hart
2009/1/3 jason : > > > > On Jan 3, 9:00 am, "Bill Hart" wrote: >> The new intel machines. And I don't know if all Dunnington's use the >> same family/system CPUID etc. So there might be mutiple CPUID's we >> need to add to config.guess. >> >> Bill. > > We should change the lowest common denominat

[mpir-devel] Re: K10 detection trouble

2009-01-03 Thread jason
On Jan 3, 9:00 am, "Bill Hart" wrote: > The new intel machines. And I don't know if all Dunnington's use the > same family/system CPUID etc. So there might be mutiple CPUID's we > need to add to config.guess. > > Bill. We should change the lowest common denominator on a x86_64 system to someth

[mpir-devel] Re: K10 detection trouble

2009-01-03 Thread Bill Hart
I've now added support for Phenom in config.guess. This allows MPIR to build on the CUDA machine. Just check out the latest svn. Bill. 2009/1/3 Bill Hart : > The new intel machines. And I don't know if all Dunnington's use the > same family/system CPUID etc. So there might be mutiple CPUID's we

[mpir-devel] Re: K10 detection trouble

2009-01-03 Thread Bill Hart
The new intel machines. And I don't know if all Dunnington's use the same family/system CPUID etc. So there might be mutiple CPUID's we need to add to config.guess. Bill. On 03/01/2009, mabshoff wrote: > > > > On Jan 3, 12:15 am, "Bill Hart" wrote: > > Hi Bill, > >> I'll fix this. > > Thanks.

[mpir-devel] Re: K10 detection trouble

2009-01-03 Thread mabshoff
On Jan 3, 12:15 am, "Bill Hart" wrote: Hi Bill, > I'll fix this. Thanks. > It's just a CPUID problem. Yep, that is what I assumed. > We actually already have a > ticket for it. There are lots of new machines we should fix detection > for. Other than the new Dunnington core which machines

[mpir-devel] Re: K10 detection trouble

2009-01-03 Thread Bill Hart
I'll fix this. It's just a CPUID problem. We actually already have a ticket for it. There are lots of new machines we should fix detection for. Bill. 2009/1/3 mabshoff : > > Hi, > > the "new" Jason [I guess we need to find some terminology here :)] > just made aware of the following problem on t