Opened 8 years ago

Closed 7 years ago

Last modified 14 months ago

#13706 closed defect (wontfix)

atlas spkg does not take the SAGE_ATLAS_ARCH variable into account when SAGE_FAT_BINARY is set to 'yes'

Reported by: tmonteil Owned by: GeorgSWeber
Priority: major Milestone: sage-duplicate/invalid/wontfix
Component: build Keywords: atlas, days43, denigration, community, management, sdl
Cc: Merged in:
Authors: Reviewers: Volker Braun
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description (last modified by tmonteil)

The spkg-install code of atlas spkg is structured as follow (from line 192):

if SAGE_FAT_BINARY == 'yes':
    arch = 'HAMMER'
elif SAGE_ATLAS_ARCH is defined:
    arch = 'SAGE_ATLAS_ARCH'

It has the effect not to take the SAGE_ATLAS_ARCH variable into account when SAGE_FAT_BINARY is set to 'yes'. I consider it as a bug, since on may want to build a fat binary for an architecture that is not HAMMER (for example, one may want to build a fat binary able to run on Pentium 3).

Attachments (1)

trac_13706-atlas_arch-tm.patch (905 bytes) - added by tmonteil 8 years ago.
proposal minimalistic patch

Download all attachments as: .zip

Change History (22)

Changed 8 years ago by tmonteil

proposal minimalistic patch

comment:1 Changed 8 years ago by tmonteil

  • Description modified (diff)

comment:2 Changed 8 years ago by tmonteil

May it be cleaner to switch the two conditions instead of replacing the 'elif' by a 'if' ? Also, why was the arch 'HAMMER' chosen by default ?

comment:3 Changed 8 years ago by vbraun

#10508 uses the new x86x87 target for building ATLAS on i386 with SAGE_FAT_BINARY, so I'm pretty sure that this has been fixed for a while now.

comment:4 Changed 8 years ago by tmonteil

As of today, this seems not to be fixed in the spkg proposed in #10508 : SAGE_FAT_BINARY default still overwrites SAGE_ATLAS_ARCH when it is set.

SAGE_FAT_BINARY is not only used for atlas, but also for (according to grep in the sage-5.4 sources) : ecm-6.3.p8 libm4ri-20120613 mpir-2.4.0.p6 polybori-0.8.2 r-2.14.0.p6 hence one may want to take advantage of it and be more precise by setting the SAGE_ATLAS_ARCH variable.

By the way, it is interesting to see that, when SAGE_FAT_BINARY=='yes' in sage-5.4, libm4ri-20120613 explicitely disables SSE2 set of instructions and atlas-3.8.4.p1 explicitely enables it.

Also, in the #10508 package, configure_base() method adds 3DNow set of instructions to some Intel architecture, which seems not to know it: https://en.wikipedia.org/wiki/3DNow!

comment:5 Changed 8 years ago by vbraun

SAGE_FAT_BINARY default still overwrites SAGE_ATLAS_ARCH when it is set.

The combination is nonsensical: You either want a binary that runs on all reasonably old hardware for distribution, or you want to specify the architecture in detail. Which one is it? I don't mind adding support for nonsensical combinations if there is demand. But the only bug here is that it requires SSE2 on i386, which is probably too much. Note that the old ATLAS (which we currently ship, and probably will for a while) doesn't have "generic" archdefs to start with so it always was a crapshot.

Also, in the #10508 package, configure_base() method adds 3DNow set of instructions to some Intel architecture, which seems not to know it: https://en.wikipedia.org/wiki/3DNow!

So? Sage will never run with only the original 8086 instruction set. For many of the processors on your web page you'll have to recompile a linux distro from source, never mind Sage.

comment:6 Changed 8 years ago by vbraun

  • Authors set to Volker Braun
  • Status changed from new to needs_review

Close as invalid since everybody seems to agree that the combination in nonsensical and the SSE2 issue is addressed at #10508.

comment:7 Changed 7 years ago by jdemeyer

  • Authors Volker Braun deleted
  • Milestone changed from sage-5.10 to sage-duplicate/invalid/wontfix
  • Reviewers set to Volker Braun
  • Status changed from needs_review to positive_review

comment:8 follow-up: Changed 7 years ago by tmonteil

  • Milestone changed from sage-duplicate/invalid/wontfix to sage-pending

I disagree with this positive review.

  • "everybody seems to agree that the combination in nonsensical" -> Citation needed !
  • "You either want a binary that runs on all reasonably old hardware for distribution, or you want to specify the architecture in detail" -> i want both, that is why local and global variables are made for !
  • The fact that the cross-packages SAGE_FAT_BINARY variable takes precedence over the atlas-specific variable SAGE_ATLAS_ARCH is not addressed in #10508.
  • Currently, if i want to tune atlas for a specific old architecture, and at the same time tell other packages not to use too recent sets of instructions (which is coherent), i simply can not. I still consider this as a bug. It makes all the predefined atlas architectures settings useless: if i want to specify one of them, i can not use SAGE_FAT_BINARY for the other packages, which impossible for an old architecture.

comment:9 Changed 7 years ago by vbraun

  • Milestone changed from sage-pending to sage-duplicate/invalid/wontfix

You can recompile atlas after installing sage using the atlas-config script. This allows your obscure use case without burdening the process for making binary distributions. As a plus you'll actually have a chance of getting the correct tuning values since the script can disable CPU sleep states.

#10508 addresses the issue presented here in that we don't require SSE for generic i386 builds any more.

Last edited 7 years ago by vbraun (previous) (diff)

comment:10 Changed 7 years ago by tmonteil

  • Keywords denigration community management added

Understood, i won't bother anymore about this.

comment:11 in reply to: ↑ 8 ; follow-up: Changed 7 years ago by jdemeyer

Replying to tmonteil:

  • "You either want a binary that runs on all reasonably old hardware for distribution, or you want to specify the architecture in detail" -> i want both, that is why local and global variables are made for !

I don't understand what "both" could possibly mean. How can it run on all architectures while still being optimized for one architecture? If it needs to run on all architectures, it cannot use Core2-specific instructions for example, so how could be optimized for Core2?

Currently, if i want to tune atlas for a specific old architecture, and at the same time tell other packages not to use too recent sets of instructions (which is coherent), i simply can not.

1) If the "specific old architecture" is the one you're building on, it's easy: don't set any environment variable and build as usual.

2) If the "specific old architecture" is not the one you're building on but you still don't want a generic binary: first of all, why would you want that? But this can probably be achieved by setting specific CFLAGS, although this isn't really supported.

comment:12 Changed 7 years ago by jdemeyer

  • Resolution set to wontfix
  • Status changed from positive_review to closed

No answer, closing this.

comment:13 in reply to: ↑ 11 Changed 7 years ago by leif

Replying to jdemeyer:

Replying to tmonteil:

  • "You either want a binary that runs on all reasonably old hardware for distribution, or you want to specify the architecture in detail" -> i want both, that is why local and global variables are made for !

I don't understand what "both" could possibly mean.

Well, he apparently meant he wants to specify what "reasonably old" means to him (or, more precisely, what's needed / more appropriate in his use case).

To me doesn't sound too exotic or "obscure"...

comment:14 follow-up: Changed 7 years ago by vbraun

You can (and always could) specify precisely what you want for ATLAS using SAGE_ATLAS_ARCH.

comment:15 in reply to: ↑ 14 Changed 7 years ago by leif

Replying to vbraun:

You can (and always could) specify precisely what you want for ATLAS using SAGE_ATLAS_ARCH.

... unless you also specified SAGE_FAT_BINARY=yes, which is what this ticket was all about. ;-)

comment:16 follow-up: Changed 7 years ago by vbraun

That is because SAGE_FAT_BINARY really means: give me what Sage considers to be sufficiently generic to run on a variety of old hardware.

comment:17 in reply to: ↑ 16 Changed 7 years ago by leif

Replying to vbraun:

That is because SAGE_FAT_BINARY really means: give me what Sage considers to be sufficiently generic to run on a variety of old hardware.

.. which is a misinterpretation of "fat".

comment:18 follow-up: Changed 7 years ago by vbraun

If you are complaining about the misnomer then you are quite late to the party ;-)

comment:19 in reply to: ↑ 18 Changed 7 years ago by leif

Replying to vbraun:

If you are complaining about the misnomer then you are quite late to the party ;-)

You know, je später die Gäste...

(Although that's not the first time I'm arguing that way.)

The MPIR spkg supports exactly what's meant by "fat binary", although on x86 / x86_64 only IIRC.

comment:20 Changed 7 years ago by jdemeyer

For leif, we should support the variable

SAGE_FAT_BINARY_OR_GENERIC_BINARY_DEPENDING_ON_THE_PACKAGE_AND_PROCESSOR=yes
Last edited 7 years ago by jdemeyer (previous) (diff)

comment:21 Changed 14 months ago by tmonteil

  • Keywords sdl added
Note: See TracTickets for help on using tickets.