LLR Version 3.8.18 released [deprecated]

[Jean Penné]

Hi All,

I uploaded today the version 3.8.18 of the LLR program.
You can find it now on my personal site :

http://jpenne.free.fr/

The 32bit Windows and Linux compressed binaries are available as usual.
The Linux 64bit binaries are also released here.
I uploaded also the complete source in a compressed file ; it may be used to
build the Mac-Intel executable and also the 64bit Windows binary.

This LLR version is linked with the Version 28.8 of George Woltman's gwnum library.

The main new feature in this version is that MULTITHREADING is now available by setting -oThreadsPerTest=<number> or -t<number> in the command line.
Thanks to Serge Batalov who showed me how simple it was to implement this!

When doing PRP tests, the Fermat test is now not strong by default, because it is time consuming...

As usual, I need help to build the 32bit Mac Intel binary, and also the 64bit Mac Intel and Windows ones.
Please, inform me if you encountered any problem while using this new version.
Best Regards,
Jean

[pepi37]

Great news!
So let test it :)

[IBethune]

Mac builds will be forthcoming soon!

[TheCount]

Readme.txt, "range beeing $b to $b" -> "range being $a to $b":

- ABC$a$b$c : Used to launch a Wieferich prime search, 
  the range beeing $b to $b and the base $c (new feature!)

I found a Version 3.8.17 Readme.txt in llr64 directory.
Does the new Multi core support cover all types of tests?

[diep]

When someone has 64 bits windows version compiled with intel c++, i would be very happy to receive it as well.

Have windows vista though - not newer.

Will start now the linux64 bits version and compare speed with what i had. Is tough under linux to compare well with previous LLR the speed (is my internet computer so other stuff runs as well like sometimes browsers).

Easier to benchmark under windows here - yet require 64 bits version for it. I do not own recent legal version of intel c++ that's why. Only freeware compilers and especially Qt on windows i'm using with GCC - which is duck slow compiler if speed is involved.

[henryzz]

Originally Posted by diep

When someone has 64 bits windows version compiled with intel c++, i would be very happy to receive it as well.

Have windows vista though - not newer.

Will start now the linux64 bits version and compare speed with what i had. Is tough under linux to compare well with previous LLR the speed (is my internet computer so other stuff runs as well like sometimes browsers).

Easier to benchmark under windows here - yet require 64 bits version for it. I do not own recent legal version of intel c++ that's why. Only freeware compilers and especially Qt on windows i'm using with GCC - which is duck slow compiler if speed is involved.

The Community edition of Visual Studio will likely compile it if someone creates a solution.

[diep]

Originally Posted by henryzz

The Community edition of Visual Studio will likely compile it if someone creates a solution.

Yeah well no finish yet of the first one it's busy with which should take 1 core 24000 seconds. It's busy at 4 cores for a while yet i see regurarly it drop to 324% cpu time instead of what i'd prefer a systematic 3.8 - 3.9.

At this box scaling well is not so easy of course as it has 2 sockets L5420 @ 2.5Ghz.

That was hard for my chessprogram as well to scale well at it, yet for chessprogram i needed hard spinlocks() of course and worked for years at that SMP code and there the speedup goes exponential (down the drain), so that's a far more complicated problem there - first getting the exponential loss limited and THEN scale well.

Yet this is about throughput rather than realtime performance. And it seems it already fails at the scaling, even though that should be not overcomplicated to establish (lot of work though to get it right).

Once it would scale reasonable well, say 3.8 - 3.9 then there would be a speedup as a result from fitting better inside the L2, as that's a whopping 8MB here, so a single transform should easily fit inside at the current 69 * 4.56M+ i'm testing at it, a batch i already run.

p.s. note i do not know how well of that linux schedules the threads onto the same socket. Usually linux scheduler is doing a very ugly bad job.

[diep]

69*2^4561333-1 is not prime. LLR Res64: 8F312539C3BB74F6 Time : 11108.595 sec.

At 4 cores.

At same box timings single core was:

69*2^4561333-1 is not prime. LLR Res64: 8F312539C3BB74F6 Time : 24485.134 sec.
69*2^4561333-1 is not prime. LLR Res64: 8F312539C3BB74F6 Time : 24619.177 sec.

Not so impressive. Let me restart it single core that version. I remember how Cilk first slowed down a program factor 50, in order to claim "good" scaling :)

[diep]

Yeah something is wrong with that threading code.

If you run it with 1 thread, it already eats systematically 101% system time and sometimes 100.7 yet always more than 100.

Running it single core should eat of course not 1% extra system time.

Beginners code.

[Batalov]

Originally Posted by TheCount

.
Does the new Multi core support cover all types of tests?

Yes.

[rebirther]

I have sent the files for 64bit win to Jean, in the meantime you can download them here

Also compiled with XP-toolset, please test it if its working.