[QUOTE=mackerel;458270]Keep a legacy version available for those that need it, and have a more modern version looking forwards?

On Ryzen specifically, is there any significant potential advantage to be gained if its architecture was considered specifically?[/QUOTE]

Well, the x87 code is still in there. So, support seems to last forever. However, I do drop some FFT implementations as time goes by (the Pentium Pro specific versions are gone as are some Pentium 3 implementations). Next to go will be some of the Pentium 4 FFTs. There were FFTs optimized for 128KB, 256KB, 512KB, 1MB L2 caches. Perhaps some K8 versions can be deleted. Of course, those CPUs would still run, just using less than optimal FFT implementations.

On Ryzen, I have no idea if rewriting some FFT code would result in a faster version -- I do not have access to one. I suspect it wouldn't help much as it will run into memory bandwidth issues too.

[QUOTE=Prime95;458232]The test executable was 50ishMB ... we could be pushing 200MB. Deal breaker, probably not.:[/QUOTE]
If you worry about download size, you could offer a better
compression alongside the current .zip.
5.618.832 byte: p95v2810.win64.zip from download
1.302.170 byte: LZMA2 (.7z)
The 55.4MB test mprime can be brought down to 1.7MB.
With large dictionary sizes, LZMA2 needs quite a lot of
RAM for compression, but since this would be done only
once for every release it shouldn't be an issue.

Very few people have/use 7z.

Is there an option to compress the file into a self-extracting archive?

We (vaguely) remember doing this a long time ago.

:mike:

[QUOTE=Xyzzy;458359]Is there an option to compress the file into a self-extracting archive?:[/QUOTE]
Windows yes, other OS I don't know. Depends on the tool used, I guess.
Adds ~150KB for the wrapper/decompressor.

7z is widely used. Any modern decompression program supports it. Support is generally lacking on a default OS install though.

[QUOTE=mackerel;458270]Keep a legacy version available for those that need it, and have a more modern version looking forwards?[/QUOTE]
I actually quite like the idea of a legacy version (without regular updates) with the optimizations for older architectures like Pentium4, Core2, K8, etc. This could be a larger executable. And a 'main' version which optimizes for newer architectures, which has a smaller size (as that is the most downloaded version) but with a small backup FFT so it will at least work (albeit a little slower).

For instance
Legacy version: core2 and earlier.
If you're still running Core2 CPUs for GIMPS you might want to consider upgrading ;)

Main version: AVX capable CPU and newer

[QUOTE=VictordeHolland;458378]I actually quite like the idea of a legacy version (without regular updates) with the optimizations for older architectures like Pentium4, Core2, K8, etc. This could be a larger executable. And a 'main' version which optimizes for newer architectures, which has a smaller size (as that is the most downloaded version) but with a small backup FFT so it will at least work (albeit a little slower).

For instance
Legacy version: core2 and earlier.
If you're still running Core2 CPUs for GIMPS you might want to consider upgrading ;)

Main version: AVX capable CPU and newer[/QUOTE]

This seems backwards to my thinking. If you can afford a newer CPU you can afford bandwidth such that even a 200MB download isn't going to take more than an hour. Though a "just works" version on the page and optimized versions in the /gimps/ folder and linked from here in the forums would probably let those who know what they're doing get better performing versions.

prime95: you have any interest in getting donated a Ryzen board and CPU? and if so, where are you located?

I've implemented the 64-bit shared pass 1 code for AVX and FMA. The throughput benchmarks are unchanged (well, at least within the margin of error for benchmark timings).

[QUOTE=tului;458409]prime95: you have any interest in getting donated a Ryzen board and CPU? and if so, where are you located?[/QUOTE]

Thanks, but I don't have enough time to look at optimizing for Ryzen. If circumstances change, I'm sure someone can provide SSH access to a suitable machine.

[QUOTE=Mark Rose;458364]7z is widely used. Any modern decompression program supports it. Support is generally lacking on a default OS install though.[/QUOTE]

For the Linux files we could use xz (lzma) instead of gz. It's installed by default on any Linux distro since years. GNU tar is able to handle it transparently, So there is no difference for most users:

tar -xf p95-linux64.tar.gz
tar -xf p95-linux64.tar.xz

[QUOTE=J F;458361]Adds ~150KB for the wrapper/decompressor.[/QUOTE]That sounds reasonable.

:mike:

[QUOTE=rudi_m;458416]For the Linux files we could use xz (lzma) instead of gz. It's installed by default on any Linux distro since years. GNU tar is able to handle it transparently, So there is no difference for most users:

tar -xf p95-linux64.tar.gz
tar -xf p95-linux64.tar.xz[/QUOTE]

I don't know what's standard on Linux distros lately, but GZ is pretty weak. :smile:

I just did a sample using the latest P95 win64 29.1 distro and compressing in different formats (I didn't test XZ since I didn't really care... LOL)

[CODE]1,653,827 7Z (-mx)
1,681,285 7Z (no opts)
1,819,186 RAR (-m5 -ma5 -s)
1,853,317 7Z SFX
2,080,818 RAR SFX (same options as above)
3,418,869 RAR (-m1)
6,009,367 Original ZIP
6,280,227 ZIP (InfoZip highest level)
7,010,173 tar.gz
9,118,956 ZIP (InfoZip lowest level)[/CODE]

What I get out of that is that George must use something better than my crummy old InfoZip when creating the ZIP files since he squeezes another 270K out of it. And also, ZIP is still blown away by more modern compression algorithms.

Even when I used Winrar to create a zip it was still only a little smaller than what InfoZip did (6,267,250), and 7Z creating a zip was still just a little smaller than that (6,131,318). I wonder what George uses? (EDIT: I think I know... I created a zip using 7z with -mx and it matched George's size exactly...that must be it).

We could always go the path that others do and simply create a smorgasbord of flavors. Or at least the few most popular (zip, rar, 7z) and let the user decide. On the server we could track hits to each and see if some simply aren't worth the effort.

Anyway, what could be a 200MB ZIP might very well be a MUCH smaller 7z or rar.