OSX10.7 (Lion)'s blas is REALLY BUGGY: Fwd: cvxopt on MacOSX 10.7

[Dima Pasechnik]

OK, guys, bad news, we will have to build Altlas on Lion!

Or wait for Apple to fix their blas...

I checked the attached C code on sqrt5, both with gcc and with cc (i.e. clang), and it's all

confirmed.

The correct output is:

nash:tmp dima$ ./test_blas 

y = 

[ 0.00  1.00  2.00  3.00  4.00  5.00  6.00  7.00 ]

y = 

[-0.50  0.50  1.50  2.50  3.50  4.50  5.50  6.50 ]

y = 

[-1.00  0.00  1.00  2.00  3.00  4.00  5.00 ]

nash:tmp dima$ ./test_cblas 

y = 

[ 0.00  1.00  2.00  3.00  4.00  5.00  6.00  7.00 ]

y = 

[-0.50  0.50  1.50  2.50  3.50  4.50  5.50  6.50 ]

y = 

[-1.00  0.00  1.00  2.00  3.00  4.00  5.00 ]

And on sqrt5 one gets:

sqrt5:tmp dima$ ./test_blas 

y = 

[ 0.00  1.00  2.00  3.00  4.00  5.00  6.00  7.00 ]

y = 

[ 0.00  1.00  2.00  3.00  4.00  5.00  6.00  7.00 ]

y = 

[-0.50  0.50  1.50  2.50  3.50  4.50  5.50 ]

sqrt5:tmp dima$ ./test_cblas 

y = 

[ 0.00  1.00  2.00  3.00  4.00  5.00  6.00  7.00 ]

y = 

[ 0.00  1.00  2.00  3.00  4.00  5.00  6.00  7.00 ]

y = 

[-0.50  0.50  1.50  2.50  3.50  4.50  5.50 ]

---------- Forwarded message ----------
From: Martin S. Andersen <martin....@ucla.edu>
Date: 6 March 2012 17:54
Subject: Re: cvxopt on MacOSX 10.7
To: dim...@gmail.com
Cc: Joachim Dahl <dahl.j...@gmail.com>, Lieven Vandenberghe <lieven.va...@gmail.com>

Dear Dima,

Thank you for your example. The example helped me pinpoint the problem and to create a simple stand-alone C program that fails to produce the correct result when linking against the native BLAS library. In your example, the result is correct when b is a vector of length 7 or less, and otherwise it is incorrect. The attached C examples replicate this problem without CVXOPT. The problem occurs both with the Fortran interface (test_blas.c) and with the CBLAS interface (test_cblas.c).

I filed a bug report with Apple in November which I have now updated. I don't know if there is a faster way to get Apple's attention? In the meantime, I am avoiding the native BLAS library in Lion.

Best,

Martin

On Mar 5, 2012, at 5:52 PM, Lieven Vandenberghe wrote:

For your information.   It is a very strange bug. 


-------- Original Message --------

Subject:	Re: cvxopt on MacOSX 10.7
Date:	Tue, 6 Mar 2012 02:12:13 +1300
From:	Dima Pasechnik <dim...@gmail.com>
To:	Lieven Vandenberghe <lieven.va...@gmail.com>

Dear Lieven,
here is a bizarre bug we get on OSX 10.7 (compiled with native lapack/blas)

from cvxopt import matrix
b=matrix([ 1.00e+00, 1.63e-01, 2.83e-01, 9.47e-01, 2.32e-01, 4.85e-01,
9.57e-01, 7.44e-01])
c=1.-b
print "b :\n", b
print "1-b:\n", c


b :
[ 1.00e+00]
[ 1.63e-01]
[ 2.83e-01]
[ 9.47e-01]
[ 2.32e-01]
[ 4.85e-01]
[ 9.57e-01]
[ 7.44e-01]

1-b:
[-1.00e+00]
[-1.63e-01]
[-2.83e-01]
[-9.47e-01]
[-2.32e-01]
[-4.85e-01]
[-9.57e-01]
[-7.44e-01]

Interestingly, shorter vector b works OK...

Do you have any idea what goes wrong here?
(this is actually the bug responsible for failure of "acent" test in here:
http://sage.math.washington.edu/home/palmieri/misc/cvxopt-1.1.3.log)

Best,
Dima


On 28 February 2012 07:25, Lieven Vandenberghe
<lieven.va...@gmail.com> wrote:
>
> Dear Dima,
>
> I am not sure what the problem is.   I will check with Martin Andersen who
> provided the MacOSX binaries and has looked into this.
>
> Best regards,
>
> Lieven
>
>
>
>
> On 02/26/2012 04:17 AM, Dima Pasechnik wrote:
>>
>> Dear Lieven,
>> I wonder if were able to determine what caused problems with running
>> CVXOPT on MacOSX 10.7. We're going to release Sage on this platform
>> soon, so it's become
>> an issue...
>>
>> I see you're distributing pre-compiled CVXOPTs for this platform,
>> using the "non-native" BLAS/LAPACKs.
>> Do you have convincing evidence that Apple's BLAS/LAPACK is broken on OSX
>> 10.7?
>> Somehow, Apple's BLAS/LAPACK is used in other parts of Sage, and there
>> we do not seem to see problems (although perhaps we do not try hard
>> enough).
>>
>> Many thanks in advance,
>> Dima

[Jason Grout]

On 3/6/12 4:30 AM, Dima Pasechnik wrote:
> OK, guys, bad news, we will have to build Altlas on Lion!
> Or wait for Apple to fix their blas...
> I checked the attached C code on sqrt5, both with gcc and with cc (i.e.
> clang), and it's all
> confirmed.

Wow. Just wow. So should we not trust matlab or mathematica on Lion
either? I feel a "Burma Sage" coming on... [1]

For completeness, what are your test_blas/cblas programs? What
operations are the three y vectors supposed to represent?

Thanks,

Jason

[1] http://trac.sagemath.org/sage_trac/ticket/12622

[kcrisman]

On Mar 6, 9:32 am, Jason Grout <jason-s...@creativetrax.com> wrote:
> On 3/6/12 4:30 AM, Dima Pasechnik wrote:
>
> > OK, guys, bad news, we will have to build Altlas on Lion!
> > Or wait for Apple to fix their blas...
> > I checked the attached C code on sqrt5, both with gcc and with cc (i.e.
> > clang), and it's all
> > confirmed.
>
> Wow.  Just wow.  So should we not trust matlab or mathematica on Lion
> either?  I feel a "Burma Sage" coming on... [1]
>
> For completeness, what are your test_blas/cblas programs?  What
> operations are the three y vectors supposed to represent?

They were attached.

[kcrisman]

On Mar 6, 9:32 am, Jason Grout <jason-s...@creativetrax.com> wrote:

> On 3/6/12 4:30 AM, Dima Pasechnik wrote:
>
> > OK, guys, bad news, we will have to build Altlas on Lion!
> > Or wait for Apple to fix their blas...
> > I checked the attached C code on sqrt5, both with gcc and with cc (i.e.
> > clang), and it's all
> > confirmed.
>
> Wow.  Just wow.  So should we not trust matlab or mathematica on Lion
> either?  I feel a "Burma Sage" coming on... [1]
>
> For completeness, what are your test_blas/cblas programs?  What
> operations are the three y vectors supposed to represent?

I've attached them at http://trac.sagemath.org/sage_trac/ticket/12519,
where Dima links to this thread.

[Dima Pasechnik]

In gmane.comp.mathematics.sage.devel, you wrote:
> On 3/6/12 4:30 AM, Dima Pasechnik wrote:
>> OK, guys, bad news, we will have to build Altlas on Lion!
>> Or wait for Apple to fix their blas...
>> I checked the attached C code on sqrt5, both with gcc and with cc (i.e.
>> clang), and it's all
>> confirmed.
>
>
> Wow. Just wow. So should we not trust matlab or mathematica on Lion
> either?

you can't trust Apple's lapack/blas on OSX 10.6 either.
Here is a short Fortran code calling blas, which crashes on 10.6 and
10.7

http://trac.sagemath.org/sage_trac/ticket/12011#comment:31

And this has been known by Apple for years, apparently...
Have they all but abandoned anything to do with high-performance
computing?

>
> For completeness, what are your test_blas/cblas programs? What
> operations are the three y vectors supposed to represent?

http://boxen.math.washington.edu/home/dima/patches/OSX7blas_bug.tgz

that's vector arithmetic, with one operand having all the same entries.

Dima

[Dima Pasechnik]

It turns out that here Apple is not doing anything wrong. 

(after having a discussion here: https://discussions.apple.com/message/17795537)

It's improper use of BLAS by CVXOPT people that triggers errors.

The C code in question violates BLAS convention that incx=0 in these kinds of BLAS functions is illegal.

Please see p.30, 1st paragraph of Sect. 2.5.3.

http://www.netlib.org/blas/blast-forum/chapter2.pdf

There is also a description of xAXPBY function (which is a slight extension of xAXBY which you presume to be buggy) on p.47 which says  that if incx (or incy) is set to 0 then an error flag must be raised.

So this is a CVXOPT bug, as far as I can see, Apple BLAS is not guilty here.

So it seems that we can proceed without Atlas on OSX 10.7, after all...

Oh well. 

Dima

[John H Palmieri]

On Thursday, March 8, 2012 4:49:12 PM UTC-8, Dima Pasechnik wrote:

It turns out that here Apple is not doing anything wrong. 

(after having a discussion here: https://discussions.apple.com/message/17795537)

It's improper use of BLAS by CVXOPT people that triggers errors.

The C code in question violates BLAS convention that incx=0 in these kinds of BLAS functions is illegal.

Please see p.30, 1st paragraph of Sect. 2.5.3.

http://www.netlib.org/blas/blast-forum/chapter2.pdf

There is also a description of xAXPBY function (which is a slight extension of xAXBY which you presume to be buggy) on p.47 which says  that if incx (or incy) is set to 0 then an error flag must be raised.

So this is a CVXOPT bug, as far as I can see, Apple BLAS is not guilty here.

So it seems that we can proceed without Atlas on OSX 10.7, after all...

Oh well. 

Darn, I was looking forward to adding 6 hours to the Sage build time on my OS X 10.7 machines.

Any ideas on when there might be a cvxopt fix?

--
John

[François Bissey]

There is already a cvxopt-1.1.4 (sage currently ship 1.1.3) do we now if it is
also buggy?
My experience from sage-on-gentoo is that going to 1.1.4 is just a matter
of dropping a new spkg - no patch to sage are necessary.

Francois

[Dima Pasechnik]

Hi John, 

I emailed you my latest communication to them.

Hopefully it's not such a big deal.

Dima

[Dima Pasechnik]

yes, I think 1.1.4 is no different in this way. Actually, we should update our cvxopt spkg to 1.1.4.

Dima

 

Francois

[François Bissey]

On Thu, 08 Mar 2012 18:31:14 Dima Pasechnik wrote:
> yes, I think 1.1.4 is no different in this way. Actually, we should update
> our cvxopt spkg to 1.1.4.

Ok but that still mean we have a bug with the latest OS X. So we should
look for a solution of some kind. Are the cvxopt authors interested in
fixing this themselves or should someone from sage, having some
knowledge of the code, step in?

Francois

[Dima Pasechnik]

they will fix this shortly, they just confirmed.

Dima

 

Francois