Hi Tony,

So are you saying that OPENBLAS_CORETYPE is a shell environment variable 
that has to be set by the user?

I have been trying to figure out how to compile on my HPC.  This cluster is 
heterogeneous: some Intel, but also Opterons of at least Piledriver, 
Bulldozer, and Barcelona types.  

We're running RHEL 6.5, so we've got that binutils issue.  

After a bit of searching around, 
https://github.com/xianyi/OpenBLAS/issues/401

I see that since it is only vpermpd that throws an error, it is actually 
the flag NO_AVX2=1 that should be set in the build of OpenBlas.  So perhaps 
the patch should be changed accordingly?
https://github.com/JuliaLang/julia/issues/7482

Anyhow setting that flag "worked" for me so that I didn't have to set 
DYNAMIC_ARCH=0.

But even so, my julia executable fails to run on different architectures. 
 I've been able to build it separately for Barcelona, Bulldozer, and 
Piledriver, each running on that specific hardware, but not on any other. 
 The error I get from julia is:

"Target architecture mismatch.  Please delete or regenerate 
sys.{so,dll,dylib}."

So in order for a single binary with DYNAMIC_ARCH=1, to work on these other 
architectures, do I have to write a shell script that sets this 
OPENBLAS_CORETYPE
environment variable?

If so, what are the possible settings?

Thanks,

Jim

On Saturday, July 19, 2014 9:42:54 PM UTC-4, Tony Kelman wrote:
>
> As of the latest version of OpenBLAS, it now reports which CPU family it's 
> using the optimized kernels for in its info string. If you build for a 
> particular fixed family it appears in upper case, if it's selected 
> dynamically then it shows with just the first letter capitalized. If your 
> OpenBLAS was built with DYNAMIC_ARCH enabled, then you can actually 
> dynamically choose a different family by setting the environment variable 
> OPENBLAS_CORETYPE.
>
>
> On Saturday, July 19, 2014 7:51:59 AM UTC-7, Elliot Saba wrote:
>>
>> You can get some limited information by running versioninfo(true) at the 
>> julia prompt.  There are certain things that are recorded, and one of them 
>> is the commandline that is passed to OpenBLAS when building Julia.  I 
>> believe that is what you are referring to when talking about Sandy Bridge 
>> and Nehalem.  By default, OpenBLAS will target the highest CPU capability 
>> that your CPU advertises it is capable of; so if your CPU is capable of 
>> Sandy Bridge instructions, it will target Sandy Bridge and not Nehalem. 
>>  You can force it to target a certain architecture however, and that 
>> forcing would get recorded.
>>
>>
>> On Sat, Jul 19, 2014 at 10:45 AM, Tomas Lycken <[email protected]> 
>> wrote:
>>
>>> I decided to rebuild my Julia installation, and in the process try to 
>>> optimize the build to my machine. As a first attempt, I just added a file 
>>> Make.user to the Julia directory, with the single line "MARCH=native" in 
>>> it. No other changes to the current master.
>>>
>>> Is there any way to inspect what options were actually used when 
>>> building, other than digging around in the build scripts and try to deduce 
>>> it myself? For example, I have a SandyBridge CPU, but if I understand the 
>>> docs correctly the default arch is Nehalem. Is there a (simple) way to 
>>> check that this was taken into account in my build?
>>>
>>> // Tomas
>>>
>>
>>

Reply via email to