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.
> > 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.
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
-~----------~----~----~----~------~----~------~--~---
