Go Back > Great Internet Mersenne Prime Search > Software

Thread Tools
Old 2017-05-09, 17:15   #67
Feb 2016
! North_America

1128 Posts
Default Overcomplicated hard solution

Would it be hard for p95 to "modular" or package based. (I know nothing about kernels, how they work, but mfakto kind of "switches" kernel of different types of works. And recompiles(?) the kernel?) So the FFT implementations would sit in separated file(s). I don't know about the differences in cpu, these file not to bloat up the base folder.So imagine prime95 with no capable FFT implementation in the "base" version. You would have to place different fft implementation files in the folder.
The prime95 would work as a "slotted" program, which can use these "bases".
For the common downloadable version it would "bundle" the mainstream, latest, most common cpu fft implementations. (e.g. from the Core2 or the Nehalem up to now, excluding the Ryzen.) - so you would have a precore2.fft and postcore2.fft.
Splitting up the cpu selections, not too much - spamming full the folder.
I don't think the prime95 as a downloader would be good, but e.g. placing different .fft files into the folder would be enough.

Excuse for my technical ignorance, but i thought of something:
Final: Would it be easy to implement a system, where prime95 is "only" loading these different libraries (separated FFT implementasion per generations/cpu families in files).

You could have a current version "bundled"(zipped, already "intalled"-placed in the folder) with like the most used cpu library e.g. aftercore2.fft .
You could download the less popular cpu ffts from the website: e.g. precore2.fft prenehalem.fft aftercore2.fft ryzen.fft...) - i know nothing about the similarities, the goal would be to split it up into managable number of files. So the user could download it without the client to decide what to include.
It would be confusng to split it up too much.
Of course you could download the full version with every existing fft files already "intalled".
Prime95 would recognize the "libraries"-(these files) in the folder. Or complian about the ideal library for the current is not avialable - download the extension.
Other issues with this model: version and update difficulties. (e.g.: keeping track of these different files, and prime95 version, upgrade. A version checker (these "libraries" and itself) would be a bloat. An ftp inside prime95 would make it more confusing.
Off: i wrote this before Madpoo's post, it's a better and easier solution.
Would it be important to compress all of the versions in Windows compatible compression format? (So the built in really primitive zip program can handle it?) The majority of contribution is coming from Win AFAIK.)

Last fiddled with by thyw on 2017-05-09 at 17:18
thyw is offline   Reply With Quote
Old 2017-05-09, 19:42   #68
rudi_m's Avatar
Jul 2005

2×7×13 Posts

Originally Posted by Madpoo View Post
I don't know what's standard on Linux distros lately, but GZ is pretty weak.
The gz format is not worse than zip. Both are using the Deflate compression method. It's strong regarding decompression speed. Reading gz compressed files from HD and decompress them is usually faster than reading uncompressed files. The difference between zip and gzip is more about the container format. Zip can handle directory trees and gzip only single files. But for directories we have tar already since 1979.

BTW Something must be wrong with your test, using gzip -9 I get

6,282,049 gz -9

Originally Posted by Madpoo View Post
I didn't test XZ since I didn't really care... LOL
You should have ;) xz uses lzma like 7z:

1,664,956 xz -6
1,650,480 xz -9

The xz and gzip clients have almost the same, perfectly compatible command line interface, see

Both inherited from POSIX industry standard "compress"

That's why most tools can handle .xz, .gz and bzip2 files transparently to the user.

Please leave us UNIX users alone with toys like 7z, rar, zip and friends ;)

Last fiddled with by rudi_m on 2017-05-09 at 20:05
rudi_m is offline   Reply With Quote
Old 2017-05-10, 02:54   #69
Mark Rose
Mark Rose's Avatar
Jan 2013

55428 Posts

And gzip doesn't have the best implementation either. If you're gzipping content, look at zopfli. I implemented it on some static resources today and it should save us about 1 TB per month in bandwidth. Zopfli is too slow for API requests though.
Mark Rose is offline   Reply With Quote
Old 2017-05-23, 23:49   #70
Jayder's Avatar
Dec 2012

2·139 Posts

I'm late to the party, but I'd like to add my benchmark results if it would help. I didn't notice anybody with more than one socket submit a benchmark, so maybe my 2x 2683v3 benchmarks will be of some use.

Download link

I did more benchmarking than what was requested. If you do not feel like parsing through all of this data, I can do it for you. The file that (almost) meets the original request is titled "results-2x2683v3-allworkercombos.txt", except instead of testing only one worker and max workers, I tested all combinations of workers.

I also tested one worker with all core combinations (results-2x2683v3-oneworker-allcorecombos.txt), as well as all worker combinations with all core combinations for the 4000k FFT (results-2x2683v3-allcore+workercombos-4000k.txt) and the 32768k FFT (results-2x2683v3-allcore+workercombos-32768k.txt).
Jayder is offline   Reply With Quote

Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
29.2 benchmark help #2 (Ryzen only) Prime95 Software 10 2017-05-08 13:24
Benchmark Variances Fred Software 5 2016-04-01 18:15
LLR benchmark thread Oddball Riesel Prime Search 5 2010-08-02 00:11
Does anyone have i7 920? for Benchmark? cipher Twin Prime Search 2 2009-04-14 20:16
Benchmark Weirdness R.D. Silverman Hardware 2 2007-07-25 12:16

All times are UTC. The time now is 17:38.

Fri Nov 27 17:38:37 UTC 2020 up 78 days, 14:49, 4 users, load averages: 1.13, 1.31, 1.35

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.