2009/1/19 mabshoff <michael.absh...@mathematik.uni-dortmund.de>: > > > > On Jan 18, 8:24 pm, Bill Hart <goodwillh...@googlemail.com> wrote: >> 2009/1/19 mabshoff <michael.absh...@mathematik.uni-dortmund.de>: > > <SNIP> > >> >> Basically we can do a similar sort of thing for Moller's ngcd >> >> function. It's relatively straightforward - should be only about half >> >> a page of code. Might make a nice project for someone. I originally >> >> volunteered to do it, but at present haven't found time to get it >> >> done. >> >> > Ok. Hopefully someone will attach this problem soon. I don't think >> > this will have too much of an impact on most people's code and the >> > benefit of having eMPIRe in for the cost of a slower xgcd is well >> > worth it. >> >> It's not as great an issue for xgcd as it is for gcd, if I understand >> correctly. > > Ok. > >> > Given the rather disruptive work on --enable-fat I am curious what the >> > timeframe for the official release will look like? >> >> Do you have any further info on the leak in t-locale. I have tried to >> replicate it, but without success so far. Can you give me a list of >> things to type to replicate it. > > Yes, it will be a day since I have to finish 3.3.alpha0, but then I > will do that. > >> Other than that, the only thing holding up the release is the bug(s) >> in /mpn/x86_64/fat/fat_entry.asm. > > Ok. Has the "make dist" issue been fixed? Last time I tried it was > broken, but that was around svn1555.
No, it hasn't been fixed. I forgot about this issue. We need to get you set up with a trac account so you can make tickets. Otherwise we are always reliant on my memory. > >> > I have no problem >> > shipping a more current svn revision since it is trivial to do wide >> > testing and I assume if we do not use --enable-fat in Sage the code in >> > question does not impact stability/compilation. >> >> It shouldn't affect a normal build. I've been pretty careful to avoid >> touching general code where possible. > > Famous last words :) > >> > Once the K10 code is >> > in I have thought of using --enable-fat per default in Sage on x86 >> > based CPUs, especially since I have thought about making an SSE2 >> > binary of Sage since the Sage binaries build on boxen required SSE3 or >> > more. >> >> For binaries this is a good idea. It is a bad idea when building Sage >> from source, for performance reasons. > > Sure, this would be strictly for binaries. My plan is to use objdump > to find all the code that uses advanced SSE instructions on sage.math > and then fiddle with the build system until only up to SSE2 > instructions are used. Then I would introduce a special > SAGE_BINARY_DIST mode to build Sage limiting the optimization. > >> The K10 code will go in the next release, not the first release. I am >> certainly looking forward to getting it out the door, but we should >> get a solid first release without it first. > > Yes, I think that is extremely important. We can always do a couple > bug fix releases in the meantime should the next big one take some > time. I think we'd be pushing for a very quick release of this code. I need to look it over and we need to do some really solid testing. But then we should get it out the door. > > But we should make a list of build platforms with a list of build > targets, i.e. static only, dynamic only, C++, --enable-fat and so on > we should test before pressing the button. Sage itself should be > pretty good at catching correctness regression and I am sure people > will point out speed regressions, too. We also have a framework that > hunts for speed regressions and one potential small project for SD12 > is to write the last missing bits to automatically compare the speed > of some small set of micro benchmarks. That test would be run for each > Sage platform we build on during testing and adding a known profile > from the last release and compare it against an updated release (where > I could drop in some new svn snapshot of eMPIRe) would give us speed > regression testing on a wide set of platforms and compilers. > >> >> >> > Anyway, it is a pleasure watching the ongoing discussion about fixing >> > technical problems in the open on mpir-devel, so keep up the great >> > work :) >> >> Great. >> >> Bill. > > Cheers, > > Michael > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
