Compile time constants when cross compiling for Android

[sandwichmaker]

1. I noticed that when building either a single or a multi-threaded build of OpenBLAS for android using the NDK, the build system detects the number of cores my desktop has, and uses that as the constant MAX_CPU_NUMBER. In my case 48!. which is clearly not the case. This happens in Makefile.prebuild by calling getarch.c, which tries to detect the number of cores on the machine that the library is being built upon.

2. The various cache sizes for the ARM64 platform are hard coded in cpuid_arm64.c. But a large section of these constants are not used for anything

L1_CODE_LINESIZE
L1_CODE_ASSOCIATIVE
L1_DATA_SIZE
L1_DATA_LINESIZE
L1_DATA_ASSOCIATIVE
L2_SIZE
L2_LINESIZE
L2_ASSOCIATIVE

(in fact this seems to be true for X86_64 also)

Are these constants just being declared for completeness so that one day the kernels can use this information as needed? Also are the values actually correct and constant across various ARM64 instantiations?

[sandwichmaker]

Looking closer at the code, if the build is single threaded, even though the constant MAX_CPU_NUMBER is not used, doesn't it make sense to set it to 1 to be explicit?

[martin-frbg]

I believe MAX_CPU_NUMBER is used to guess a sensible value for NUM_THREADS if that has not been set explicitly. In that sense, using the host system value is probably as good a guess as any. Not sure if setting the unused constant to 1 would really help - it might make sense to collect such tidbits of information on the wiki page that aspires to be the "Developer Manual" however.
The bunch of unused cpuid information has tricked me before, I suspect the x86 cpuid code was borrowed from another project and the unused information kept for completeness, and the equivalent
code for the other architectures then just tried to be equivalent. With just a handful of individual ARM64 chips declared in cpuid_arm64, it is probably safe to assume the values were copied from the
respective datasheets and the generic ARMV8 is a minimal configuration.

[sandwichmaker]

@martin-frbg thanks for the prompt reply.

I agree that updating the wiki is a good idea, and I would be happy to help. Let me gain a bit more familiarity and I will try and suggest some sensible changes.

That said, in the case of a single threaded build, should MAX_CPU_NUMBER be even defined?

[martin-frbg]

MAX_CPU_NUMBER is used to set NUM_BUFFERS, which can come back to bite you in many and mysterious ways (see #1141 and PR #1507 where I tried to document this in USAGE.md). This is another area of original libGoto2 code that needs careful review.

[sandwichmaker]

Oh wow, thanks for the education @martin-frbg #1141 was educational.

[martin-frbg]

If only I knew how to solve it, probably that whole buffers business needs to be taken out and rewritten.
Short-term solution might be to hardcode a "safe" minimum for NUM_BUFFERS (and try to catch overflows before they blow up the program).

[sandwichmaker]

@oon3m0oo may have some thoughts on this, since he is also thinking about how to do threading right.

[sandwichmaker]

I am going to close this issue, as this was mostly a query not necessarily a call to action and the relevant work is already happening in the threading related issues.