Which SIMD flag to use for Raspberry Pi
 

Hi. I'm trying to compile the latest version of MLucas for my Raspberry Pi Model B Rev 2.

I ran all four commands to determine which SIMD type to use, but it came up empty. So which flag should I use?

Also since my Raspi is a single core would it be benificial to not compile using the "-DUSE_THREADS" flag?

I hope you can help me out :)

[QUOTE=BrainStone;471920]Hi. I'm trying to compile the latest version of MLucas for my Raspberry Pi Model B Rev 2.

I ran all four commands to determine which SIMD type to use, but it came up empty. So which flag should I use?

Also since my Raspi is a single core would it be benificial to not compile using the "-DUSE_THREADS" flag?

I hope you can help me out :)[/QUOTE]

The Rapsberry Pi B2 is ARM-v7. The SIMD code is for ARM-v8. The Raspberry Pi B2 has 4 cores.

[QUOTE=henryzz;471934]The Rapsberry Pi B2 is ARM-v7. The SIMD code is for ARM-v8. The Raspberry Pi B2 has 4 cores.[/QUOTE]

We are talking about the Raspberry Pi 1 B, not the 2 B

So it is an ARM-v6 single core processor.

Anyways, I compiled it it with [code]gcc -c -O3 -DUSE_THREADS ../src/*.c[/code] and this resulted in this error: [URL=https://gist.github.com/464437e0ab39bca04bef5e2311952cc5]https://gist.github.com/464437e0ab39bca04bef5e2311952cc5[/URL]

[QUOTE=BrainStone;471946]We are talking about the Raspberry Pi 1 B, not the 2 B

So it is an ARM-v6 single core processor.[/quote]
Yes, you should just omit -DUSE_THREADS, unless that single core is hyperthreaded, which seems unlikely. (My A53 v8 quad-core isn't.)

[quote]Anyways, I compiled it it with [code]gcc -c -O3 -DUSE_THREADS ../src/*.c[/code] and this resulted in this error: [URL=https://gist.github.com/464437e0ab39bca04bef5e2311952cc5]https://gist.github.com/464437e0ab39bca04bef5e2311952cc5[/URL][/QUOTE]

Looks like HWCAP_ASIMD is only defined as of v8 (or perhaps v7, but def. not v6). What happens if you compile (just use 'gcc -c -O3 ../src/util.c') with this hacked version of has_asimd() replacing the current one at line 1882 of util.c?
[code] int has_asimd(void)
{
unsigned long hwcaps = getauxval(AT_HWCAP);
#ifndef HWCAP_ASIMD
const unsigned long HWCAP_ASIMD = 0;
#endif
if (hwcaps & HWCAP_ASIMD) {
return 1;
}
return 0;
}
[/code]

[QUOTE=BrainStone;471946]We are talking about the Raspberry Pi 1 B, not the 2 B

So it is an ARM-v6 single core processor.

Anyways, I compiled it it with [code]gcc -c -O3 -DUSE_THREADS ../src/*.c[/code] and this resulted in this error: [URL]https://gist.github.com/464437e0ab39bca04bef5e2311952cc5[/URL][/QUOTE]
In any case, welcome to the forum. Also, thanks for a question I learned some things from. :smile:

BTW, in case it wasn't obvious, single-core v6 is going to be godawfully slow - my A53 quad, using the SIMD code on all 4 cores, is gonna need 2 months to DC a single exponent ~45 million @2304K FFT length.

Yes, I'm aware that it's going to be slow. I kinda just want to play with my Pi since I'm not using it for anything else.
Initially I was trying to use mprime and assign it only work that takes the least amount of work. But since mprime doesn't run on arm I can't use it.

Assuming I get it to work, and use the script, does it have a feature like mprime that saves the progress so it continues after reboot?

[QUOTE=BrainStone;471965]Yes, I'm aware that it's going to be slow. I kinda just want to play with my Pi since I'm not using it for anything else.
Initially I was trying to use mprime and assign it only work that takes the least amount of work. But since mprime doesn't run on arm I can't use it.

Assuming I get it to work, and use the script, does it have a feature like mprime that saves the progress so it continues after reboot?[/QUOTE]

Yes, the program saves a checkpoint file every 10000 iterations - for exponent N, you will see the following 3 files:

pN.stat - text status file, initially the FFT params being used, then 1 line added at each checkpoint;
pN,qN - pair of redundant checkpoint files, program reads these automatically on restart-from-interrupt.

A worthwhile experiment might be to make 2 binaries, one with -DUSE_THREADS, the other not. Both will be restricted to 1-thread running on your Pi and one would expect the unthreaded build to be a bit faster due to no thread-management overhead, but I have seen instances where the threaded code is faster even when running 1-threaded. The automated self-tests which will provide the answer will be sufficiently slow on your system that you should probably just run them overnight.

Did the above function hack work for you?

It's still compiling. Takes around 3 hours to do so. I'll let you know in the morning. I'll start a second compilation with the flag active though.

Ok. The compilation without threads errored with this log: [url]https://gist.github.com/a1c1a090015569b25b820b6c9707594e[/url]

[QUOTE=BrainStone;471975]It's still compiling. Takes around 3 hours to do so. I'll let you know in the morning. I'll start a second compilation with the flag active though.[/QUOTE]

That's why I suggested just recompiling util.c to see if the code patch works. Incremental recompilation, it's a beautiful thing. :)

[QUOTE=BrainStone;471976]Ok. The compilation without threads errored with this log: [url]https://gist.github.com/a1c1a090015569b25b820b6c9707594e[/url][/QUOTE]
Thanks - my bad, it's been a while since I did an unthreaded build, since that mode is now deprecated. I will need to try one locally in each of the various SIMD modes (scalar-double, SSE2, ARMv8, AVX, AVX2, AVX512) and issue a patch based on the resulting fixes.

Did your above unthreaded build attempt use the modified has_asimd() I posted? If it did and you got no errors in the compilation of util.c, that means you can go back to your original -DUSE_THREAD build (assuming you did that in a separate obj-file directory, and the resulting .o files are still around) and simply do an incremental recompile of util.c, and that should allow you link an executable. If you did your latest build in the same obj-file directory, I suggest you create a 2nd dir strictly for threaded-build obj-files, cd to that, then first make sure compilation of util.c works, then retry the all-sourcefiles compile.