Mlucas version 17.1

[heliosh]

That did the job, thank you!

[Lorenzo]

Hello!) Not sure ... bu looks like something wrong with txz archive. I see here only src folder. Nothing else for compile

[ewmayer]

Originally Posted by Lorenzo

Hello!) Not sure ... bu looks like something wrong with txz archive. I see here only src folder. Nothing else for compile

Lorenzo, you need to look *inside* the src folder.

[Lorenzo]

ahhh, sorry. Just i have read instruction again. Got it how to install.

[heliosh]

Another day, another problem

mlucas -s m -cpu 0:3 resulting in an error with both, the self-compiled 17.1 as well as the raspbian precompiled 14.1-2.
It runs fine until:

NTHREADS = 4
M32156581: using FFT length 1664K = 1703936 8-byte floats.
 this gives an average   18.871941786545975 bits per digit
Using complex FFT radices        26         8        16        16        16
mers_mod_square: radix0/2 not exactly divisible by NTHREADS - This will hurt performance.
pthread_create:: Cannot allocate memory
pthread_join: : Cannot allocate memory
pthread_join: : Cannot allocate memory
pthread_join: : Cannot allocate memory
ERROR: at line 1473 of file ../src/mers_mod_square.c
Assertion failed: threadpool_init failed!

Full log: https://pastebin.com/raw/XvNsn2wD
There was plenty of free RAM at that time.

Single-threaded is running fine so far.
And a minor issue: The URL printed at startup isn't working.

[ewmayer]

Originally Posted by heliosh

Another day, another problem

mlucas -s m -cpu 0:3 resulting in an error with both, the self-compiled 17.1 as well as the raspbian precompiled 14.1-2.
It runs fine until:

NTHREADS = 4
M32156581: using FFT length 1664K = 1703936 8-byte floats.
 this gives an average   18.871941786545975 bits per digit
Using complex FFT radices        26         8        16        16        16
mers_mod_square: radix0/2 not exactly divisible by NTHREADS - This will hurt performance.
pthread_create:: Cannot allocate memory
pthread_join: : Cannot allocate memory
pthread_join: : Cannot allocate memory
pthread_join: : Cannot allocate memory
ERROR: at line 1473 of file ../src/mers_mod_square.c
Assertion failed: threadpool_init failed!

Full log: https://pastebin.com/raw/XvNsn2wD
There was plenty of free RAM at that time.

Single-threaded is running fine so far.
And a minor issue: The URL printed at startup isn't working.

I haven't seen this particlular alloc error before, but have encountered not-dissimilar errors during self-tests on some systems, apparently due to the OS not being able to properly recover memory freed up by completed tests. Does re-running just the 1664K self-test (./Mlucas -fftlen 1664 -cpu 0:3) work? If so, on your system you may simply have to complete the self-tests in this one-length-at-a-time fashion, e.g. after 1664 finishes, paste the block below into your shell:

./Mlucas -fftlen 1792 -cpu 0:3
./Mlucas -fftlen 1920 -cpu 0:3
./Mlucas -fftlen 2048 -cpu 0:3
./Mlucas -fftlen 2304 -cpu 0:3
./Mlucas -fftlen 2560 -cpu 0:3
./Mlucas -fftlen 2816 -cpu 0:3
./Mlucas -fftlen 3072 -cpu 0:3
./Mlucas -fftlen 3328 -cpu 0:3
./Mlucas -fftlen 3584 -cpu 0:3
./Mlucas -fftlen 3840 -cpu 0:3
./Mlucas -fftlen 4096 -cpu 0:3
./Mlucas -fftlen 4608 -cpu 0:3
./Mlucas -fftlen 5120 -cpu 0:3
./Mlucas -fftlen 5632 -cpu 0:3
./Mlucas -fftlen 6144 -cpu 0:3
./Mlucas -fftlen 6656 -cpu 0:3
./Mlucas -fftlen 7168 -cpu 0:3
./Mlucas -fftlen 7680 -cpu 0:3

Each should add 1 line to your mlucas.cfg file.

[heliosh]

Yep. Manually running the individual tests seems to work. Thanks again.

[ewmayer]

Originally Posted by heliosh

Yep. Manually running the individual tests seems to work. Thanks again.

Can you post your final cfg file and basic system details here? Note in single-fft-length-selftest mode the code appends a bunch of stuff to right of the usual cfg-file line as shown below, suggest stripping off the non-bolded fields of each line created via single-length-test:

      4608  msec/iter =    3.07  ROE[avg,max] = [0.238615989, 0.312500000]  radices = 144 16 32 32  0  0  0  0  0  0	10000-iteration Res mod 2^64, 2^35-1, 2^36-1 = 13BB5C9DDF0CD3D6, 15982066709, 51703797107

[heliosh]

Voilà:
https://pastebin.com/raw/tMesEMUi

It's a Raspberry Pi 3 running raspbian 32 with a steady background load of about 80% on one core that I don't want to stop right now.
mlucas was compiled with -O3 -mcpu=cortex-a53 -mfpu=neon-fp-armv8

[ewmayer]

Originally Posted by heliosh

Voilà:
https://pastebin.com/raw/tMesEMUi

It's a Raspberry Pi 3 running raspbian 32 with a steady background load of about 80% on one core that I don't want to stop right now.
mlucas was compiled with -O3 -mcpu=cortex-a53 -mfpu=neon-fp-armv8

Thanks - your 1664K timing looks highly anomalous, could you redo that one and see if you get a significantly different result on attempt 2?

[Details: 1664K uses a front-end-radix (52 or 208) based on a prime-radix-13 DFT macro, but the opcount for that is actually decently low - and the next-larger radix-13-based FFT length, 3328K, only shows a modestly worse runtime than the 2 lengths bracketing it. Also, 3328K should give a runtime >= 2x that of 1664K, but the ratio is quite a bit less than 2, again pointing to a re-do of the 1664K timing.]

Edit: Just as a point of comparison, my A53 (odroid c2) is DCing right now, 120 ms/iter @2560K using all 4 cores. So if at all possible, I urge you to switch to a 64-bit version of Raspbian and a SIMD build at your earliest convenience.

[heliosh]

Yep, this one seems more reasonable.

1664  msec/iter =  541.97  ROE[avg,max] = [0.237590681, 0.312500000]  radices = 208 16 16 16  0  0  0  0  0  0