[mpir-devel] Re: Release candidate 2

2009-03-25 Thread Bill Hart
Actually, perhaps you wouldn't notice it on the bench at all. You might notice it for things like mpz_get_ui which are inlined in gmp.h. Bill. 2009/3/25 Bill Hart : > The short answer is I don't know whether it causes a performance > deficit. I also don't have a workaround at present. > > Howeve

[mpir-devel] Re: Release candidate 2

2009-03-25 Thread Bill Hart
The short answer is I don't know whether it causes a performance deficit. I also don't have a workaround at present. However this is a long standing issue, for which we have a ticket. Obviously we've focused very much on the low hanging fruit performance wise. *If* it makes any difference, you w

[mpir-devel] Re: Release candidate 2

2009-03-25 Thread Jeff Gilchrist
I just tried compiling it on a brand new MacBook Pro (Core2) and it works fine (make + make check) but I did see this in the output: checking for inline... inline configure: WARNING: mpir.h doesnt recognise compiler "inline", inlines will be unavailable So I'm not sure if that is a problem, will

[mpir-devel] Re: make bench

2009-03-25 Thread Jason Moxham
On Wednesday 25 March 2009 17:12:11 Bill Hart wrote: > That's a function of our growing arsenal of machines to test on, and > the (unspecified) machines which sage developers test on. > > The reason for specifying a moving wall dependent on some measurable > metric is that: > > 1) It doesn't depen

[mpir-devel] Re: make bench

2009-03-25 Thread Bill Hart
That's a function of our growing arsenal of machines to test on, and the (unspecified) machines which sage developers test on. The reason for specifying a moving wall dependent on some measurable metric is that: 1) It doesn't depend on us (what we test on does) 2) It gives a rationale for retir

[mpir-devel] Re: make bench

2009-03-25 Thread Jason Moxham
How about we cut out the cpu's that haven't been tested for x years say. If we are going to rewrite/reorganize the mpn layer , then only the modern cpus and C version will be tested anyway. On Wednesday 25 March 2009 16:38:28 Bill Hart wrote: > One thing we could do is remove support for chips

[mpir-devel] Re: make bench

2009-03-25 Thread Bill Hart
One thing we could do is remove support for chips with a "rolling wall". If the manufacturing date for that architecture is more than 10, 15 or 20 years ago, say, we could remove support for it. Funnily enough, this may not cut much out. The Intel 80386 for example ceased to be made in September

[mpir-devel] Re: mpir-1.0 fails on x86-Darwin-tiger

2009-03-25 Thread Bill Hart
Hi Mariah, thanks for tracking this down for us. The patch is actually available online at the link you gave. Perhaps the GMP server was having temporary difficulties when you tried to access it from them again. Given that this may affect the build on other architectures, I am inclined to make a

[mpir-devel] Re: Release candidate 2

2009-03-25 Thread Bill Hart
There's been no word on the result of further testing in Sage, at this point. I strongly suspect there will be no further candidates and this will be final, but it seems logical to have the Sage developers test it as part of their release cycle as the number of systems that it then gets tested on

[mpir-devel] Re: Release candidate 2

2009-03-25 Thread Jeff Gilchrist
Just wondering what the status of 1.0.0 is. Are the changes people have been talking about recently going to be rolled into 1.0.0 so we will have an rc3 or will rc2 stay the same and become the official 1.0.0? Jeff. --~--~-~--~~~---~--~~ You received this message