Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gotoblas_corename() showing apparently incorrect cpu identification #2660

Closed
danielwe opened this issue Jun 12, 2020 · 1 comment · Fixed by #2661
Closed

gotoblas_corename() showing apparently incorrect cpu identification #2660

danielwe opened this issue Jun 12, 2020 · 1 comment · Fixed by #2661

Comments

@danielwe
Copy link

My machine has Xeon E7 4870 processors, which use the Nehalem-based Westmere microarchitecture. However, OpenBLAS built with DYNAMIC_ARCH appears to identify them as Atom cores. The output of openblas_get_config() is:

OpenBLAS 0.3.5  USE64BITINT DYNAMIC_ARCH NO_AFFINITY Atom MAX_THREADS=32

export OPENBLAS_CORETYPE=Nehalem makes no difference

I think the actual problem is that with DYNAMIC_ARCH but not DYNAMIC_OLDER, gotoblas_ATOM is aliased to gotoblas_NEHALEM, and gotoblas_coretype() checks for gotoblas == &gotoblas_ATOM before gotoblas == &gotoblas_NEHALEM:
https://github.com/xianyi/OpenBLAS/blob/9d5079008f964d0be08708dc3785ebcf5b7bf68b/driver/others/dynamic.c#L767-L771

Seems like the solution would be one of the following:

  • Make sure that the gotoblas_<ARCH> identifiers that could be aliases are checked last in gotoblas_corename(), or
  • Disable some of the checks in gotoblas_corename() depending on compiler flags
@martin-frbg
Copy link
Collaborator

martin-frbg commented Jun 13, 2020

Option #2 looks cleaner to me (though neither will solve the "problem" with a custom DYNAMIC_LIST - which would require a nasty cascade of ifdefs that is probably not worthwile to implement)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants