On Dec 11, 2007 11:03 AM, Fernando Perez <fperez.net@gmail.com> wrote:
> On Dec 10, 2007 4:41 PM, Robert Kern <robert.kern@gmail.com> wrote:
>> > The current situation is untenable. I will gladly accept a slow BLAS for an
> > official binary that won't segfault anywhere. We can look for a faster BLAS later.
>> Just to add a note to this: John Hunter and I just finished teaching a
> python workshop here in Boulder, and one attendee had a recurring
> all-out crash on WinXP. Eventually John was able to track it to a bad
> BLAS call, but the death was an 'illegal instruction'. We then noticed
> that this was on an older Pentium III laptop, and I'd be willing to
> bet that the problem is an ATLAS compiled with SSE2 support. The PIII
> chip only has plain SSE, not SSE2, and that's the kind of crash I've
> seen when accidentally running code compiled in my office machine (a
> P4) on my laptop (a similarly old PIII).
>> It may very well be that it's OK to ship binaries with ATLAS, but just
> to build them without any fancy instruction support (no SSE, SSE2 or
> anything else of that kind, just plain x87 code).
>The problem is that this is non trivial, and unsupported. I tried to
do it, asked the main author of ATLAS, but building an ATLAS which
does not use any instruction set present on the CPU used for build is
too difficult, and not a priority for the main author of ATLAS. The
build system of ATLAS being extremely complex (code is generated by C
programs themselves compiled on the fly by other C softwares), I gave
up on the idea of doing it by myself.
But anyway, honestly, this is kind of stupid: ATLAS needs to be
compiled with the same CPU it is run for for good performances. For
example, if the L1 cache is of different size, ATLAS performances are
already not so good. So if you are not event using SSE/SSE2...
David