On May 6, 11:26 am, William Stein <wst...@gmail.com> wrote:
> On Wed, May 6, 2009 at 7:01 AM, gemili <j...@gmx.de> wrote:
<SNIP>
> Your testing thus suggests that fxsr is really important, and we
> should be explicitly checking for it and not allowing Sage to run if
> the user doesn't have it. Also, we should look to see what part(s) of
> sage actually use it.
>
> I've made a trac ticket for this:
> http://trac.sagemath.org/sage_trac/ticket/5998
No, the problem is not fxsr IMHO as it predates SSE2 (I think it has
been around 10+ years, but I cannot find a reference). The fix here is
plainly and simple to compile MPIR with the appropriate flags since as
is MPIR is build for a Nehalem and it is absolutely no surprised that
Sage blows up spectacularly on older CPUs. So far ATLAS's SSE3
instructions always caught the problem since ATLAS is loaded before
MPIR (due to load order of extensions), so once we fixed the SSE3
problem we get hit by the next one. And no, the problem in MPIR isn't
SSE instructions per se - at least my detection script did not find
anything.
And I doubt we will ever build a pre-SSE2 binary, even for x86, due to
lack of hardware. In theory you could fudge with the build system, but
the effort is in no relationship to the benefit. And performance for
some things would be disastrous. Obviously if someone wants to do it I
am happy to review patches ;). If your system is that old just used a
Sage server somewhere else. This is obviously a problem if you don't
have net or it is too expensive. But in that case you just have to do
the painful build from source.
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to
sage-support-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sage-support
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
