On Dec 11, 2007 11:03 AM, Fernando Perez <[EMAIL PROTECTED]> wrote: > On Dec 10, 2007 4:41 PM, Robert Kern <[EMAIL PROTECTED]> 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 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
