Error building Sage on UM 16.04: error making OpenBLAS

[Christopher Phoenix]

I'm building Sage 7.6 on my laptop, and there was an error making openblas that directed me to the log files for that package. The log file said that detecting CPU failed, and to set TARGET explicitly. It also suggested I email this google group to explain the problem, with the relevant part of the log files. So I've attached it below.

OS: Ubuntu Mate 16.04 LTS
Sage Version: 7.6
HW: Lenovo Thinkpad 11e, 500gb HD, 4 gb ram, Intel Celeron N2940 with 4 cpu cores

Before the build, I made sure that I had all the listed dependencies and suggested packages already installed. Then I cloned the Git repo, set MAKE='make -j5 -4' and typed make. Make ran for about 45 min or more before it stopped and reported the error. I asked about this issue on sage-support earlier (https://groups.google.com/forum/#!topic/sage-support/NlRyew12xDQ).

Someone had the same issue on very similar hardware (another 11e) here: https://groups.google.com/d/msg/sage-devel/zQsZsivts0I/cblwvEkNDgAJ The log files look almost exactly the same. They reported that setting OPENBLAS_CONFIGURE="TARGET=ATOM" resolved this cpu detection issue, so I'm going to try setting this and building Sage again later today. I was a little confused since a Celeron is not an Atom afaik, I'm guessing this is a catch-all setting for lower-end processors?

Any advice will be greatly appreciated!

[Dima Pasechnik]

Indeed, OPENBLAS_CONFIGURE="TARGET=ATOM" is a catch-all x86_64 processors target.

Perhaps one can try the development version of openblas on these processors

(from https://github.com/xianyi/OpenBLAS)

[Christopher Phoenix]

Well, I have successfully built Sage on my 11e—over a period of several hours! :-) Right now I'm running the tests with ./sage --testall to make sure everything is a-ok, but cli Sage starts, as does the notebook, so it looks good so far.

Maybe I'll try building the dev version of openblas on this hardware later, but I'm not really sure what to do to test it once it does build. This was my first time building a big program from source, so I'm still getting used to it all. It would be interesting to see if this detection issue with lower-end x86-64 cpus continues in the dev version.

[John H Palmieri]

I just had the same problem with a new computer (Kaby Lake processor, apparently). Can we patch OpenBLAS to fall back to ATOM if it's x86_64 but can't detect the precise CPU? (I can't do this, but maybe someone else can.)

  John

On Friday, July 14, 2017 at 12:25:57 AM UTC-7, Dima Pasechnik wrote:

[Christopher Phoenix]

I'm pretty sure that's an issue for upstream, not the Sage devs, maybe we should ask the OpenBLAS devs? But I suspect that the problem here is that there isn't a default choice that covers all CPU types. Atom is a catch-all for many low-end X86_64 cpus (like my Celeron), but it's not the best choice for all. People on this help topic suggested using TARGET=HASWELL for Kaby Lake: https://github.com/xianyi/OpenBLAS/issues/1006

I believe there are some specific optimizations applied to each setting that help it run faster on particular CPUs. If OpenBLAS fails to detect your cpu, its probably better that make simply stops the process and asks for the user to apply the right setting instead of just falling on a default that may or may not be appropriate for your situation. Fixing it just requires setting a single env variable before the build, after all.

[Christopher Phoenix]

BTW, forgot to link this, but you can see the full list of OpenBLAS targets here: https://github.com/xianyi/OpenBLAS/blob/develop/TargetList.txt

This shows the reason why ATOM isn't the default choice. It would be bad if OpenBLAS picked that and you were actually running an AMD cpu, or if you had a 32-bit system (Atom refers to X86_64 cpus). And while I don't even know what MIPS or SPARC arch is, someone is probably building OpenBLAS on it. There's just too many possible hardware configurations for OpenBLAS to make assumptions about what you are running!

On Friday, July 21, 2017 at 10:28:00 AM UTC-7, John H Palmieri wrote:

[Aram Dermenjian]

Just as a note to humans, we are developing a fix for this as it is becoming a bigger and bigger issue. Here is the ticket:
https://trac.sagemath.org/ticket/23272

-Aram