Prime95 version 29.6/29.7/29.8

[axn]

Originally Posted by Prime95

Thoughts on whether prime95 should rethink this old decision?

Yes, definitely need to rethink it. However, rather than update P95 / Primenet to do this, leverage existing platform that already does this -- BOINC!

[Thecmaster]

Originally Posted by ixfd64

I think update notifications can be as simple as printing a message in the communication window the next time Prime95 connects to the server. Something like this will do:



A pop-up window is fine but should probably be disabled by default. Users would be able to enable it by editing their local.txt file.

This is a good idea. But I would rather have it as an option in gui for prime95. Maybe where you put in you username and proxy. A box you can klick in and you will get the popup info about new version and link to it. And only put stable and tested builds there.

Maybe also if you click ok you don't get it again until next build. Maybe you can make a check for really bad versions to make a recommended to upgrade because your version is bad popup. Just ideas.

[pokemonlover123]

For mprime, the Prime95 variant for Linux, you could create a deb file so users running a Debian variant such as Ubuntu could install it/uninstall it at will, as well as a PPA to install from. The advantages of a PPA would be that running apt update would see any upgrades to mprime. In addition, having it installed would make it easier to run mprime (for example, you wouldn't need to go to the folder mprime is in to run it). The only downside is in order to run multiple instances of mprime, some new option would be needed that set the current instance to run or some other way of doing it. Not sure if this has been suggested or what other detriments or obstacles to such a solution would be.

[UBR47K]

mprime's available now on https://flathub.org/apps/details/org.mersenne.mprime (with optional steps at https://github.com/flathub/org.mersenne.mprime) .


Can be kept up to date just like you'd do with any package manager.

[Madpoo]

Originally Posted by Prime95

Fifteen plus years ago, the community felt this was a bad idea. It was 1) viewed as a potential security risk and 2) viewed as a nuisance popping-up an "update now?" dialog box (especially if you've installed prime95 on a friends machine).

Nowadays, this behavior is commonplace. I suspect most people set to auto-update without notification or simply click yes to the numerous you-have-an-update-ready messages they get each week.

Thoughts on whether prime95 should rethink this old decision?

I think something as simple as changing the color of the title bar and a message saying something like "an update is available" is as non-obtrusive as possible and leaves it up to the user what to do. No pop ups, no flashing things, etc. Just a little visual reminder.

On the server side all we'd really need to do is place a little txt file in the root, something like www.mersenne.org/latetversion.txt that holds the value like "29.8b4".

Although at this point you really should consider using major.minor.build.revision versioning or whatever. Version 29.8b3 would be 29.8.3 -- it just makes comparing one version to another easier, with easy like "if 29.8.3 <= 29.8.4 then ..."

It gets weird doing that with text values. Is "29.8b3" <= "29.8b10" ? Of course you'd want to make sure you're using actual version comparisons because even then, if you're comparing versions as text you'll get funny results, like "29.10" would be considered less than "29.9" even though it's greater than.

[kriesel]

Originally Posted by Madpoo

I think something as simple as changing the color of the title bar and a message saying something like "an update is available" is as non-obtrusive as possible and leaves it up to the user what to do. No pop ups, no flashing things, etc. Just a little visual reminder.

On the server side all we'd really need to do is place a little txt file in the root, something like www.mersenne.org/latetversion.txt that holds the value like "29.8b4".

Although at this point you really should consider using major.minor.build.revision versioning or whatever. Version 29.8b3 would be 29.8.3 -- it just makes comparing one version to another easier, with easy like "if 29.8.3 <= 29.8.4 then ..."

It gets weird doing that with text values. Is "29.8b3" <= "29.8b10" ? Of course you'd want to make sure you're using actual version comparisons because even then, if you're comparing versions as text you'll get funny results, like "29.10" would be considered less than "29.9" even though it's greater than.

Perhaps make it moot by making versioning a decimal real:
29.048 (instead of 29.4b8)
29.083 (instead of 29.8b3)
29.084
29.092
29.101
Are there ever more than 9 separately numbered builds of x.y?
I just checked, and did not find a 29.8b4 to download.
https://www.mersenneforum.org/showpo...41&postcount=1 is all 29.8b3
although https://www.mersenneforum.org/showpo...42&postcount=2 makes at least 4 references to 29.8b4

[James Heinrich]

No, just leave the version number as-is (29.10b17) and let the single function inside Prime95.exe worry about appropriate version-compare functionality.
Speaking of which, consideration may be needed to "most-current" version number for different OSs that are not always in sync.

[Madpoo]

Originally Posted by James Heinrich

No, just leave the version number as-is (29.10b17) and let the single function inside Prime95.exe worry about appropriate version-compare functionality.
Speaking of which, consideration may be needed to "most-current" version number for different OSs that are not always in sync.

My frustration with version numbers comes from my recent work dealing with Dell firmware revisions. Older systems have versions like A13, A27, etc. At least doing a simple <= is easy.

New systems use major.minor.build like 1.3.12 which is fine, but when working with different models that use one or the other, I can't use the same code because then 1.3.12 would compute as less than 1.3.8 which is wrong.

To work around it in powershell I can do a [system.version] thing which will do proper comparisons of each part of the version string. It's actually pretty nice.

The thing with major.minor.build.revision is that it's very common. I don't know if I'd go so far as to say it's a standard (although it may be close, or a de-facto standard) because there are clearly plenty of counter examples.

What is *uncommon* is the way Prime95 builds are numbered, with a curious mix of major.minor and then the "b" followed by build. Maybe it was more common a decade or two ago.

It only bugs me (and let's be clear, it's not like it's a major annoyance, just one of those nits to pick) when doing string comparisons to see if a version is greater or less than some reference. String comparisons do funny things. Or rather, they work exactly as they should, but not how humans think they should work.

[S485122]

Originally Posted by kriesel

Perhaps make it moot by making versioning a decimal real:
29.048 (instead of 29.4b8)
29.083 (instead of 29.8b3)
29.084
29.092
29.101
Are there ever more than 9 separately numbered builds of x.y?

This would be a good idea, it could be something like 29.09.04.
At the moment the "File version" of prime95.exe version 29.8 build 3 is 29.8.1.0 and the "Program Version" is 29.8.0.0. This discrepancy (the file properties not being updated) occurred in the past as well.

Originally Posted by kriesel

I just checked, and did not find a 29.8b4 to download.
https://www.mersenneforum.org/showpo...41&postcount=1 is all 29.8b3
although https://www.mersenneforum.org/showpo...42&postcount=2 makes at least 4 references to 29.8b4

29.8b4 is for Mac OSX only and it is available at ftp://mersenne.org/gimps. As James remarked, sometimes a particular flavour of Prime95 needs an intermediary build.

Jacob

[UBR47K]

Originally Posted by kriesel

Perhaps make it moot by making versioning a decimal real:
29.048 (instead of 29.4b8)
29.083 (instead of 29.8b3)
29.084
29.092
29.101
Are there ever more than 9 separately numbered builds of x.y?

https://semver.org seems a good alternative.

[AG5BPilot]

I guess Intel has pulled a page out of AMD's playbook.

Some of their mid/low range Xeon CPU's have only one AVX-512 execution unit instead of two. When LLR runs AVX-512 on these CPUs, it's significantly slower than the FMA3 transform. Although we haven't tried it, presumably P95 exhibits the same behavior.

The bottom line is that right now, if you run on some AVX-512 CPUs, you get a significant increase in performance, while on others, you get a significant decrease in performance.

I'm not sure if the software can be adapted to get better performance on single-unit AVX-512 CPUs, or if using FMA3 is the better option.

Details can be found over in the LLR thread: https://www.mersenneforum.org/showpo...08&postcount=7

(Before someone inevitably suggests it, LLR lacks the CpuSupportsAVX512F flag, so it can't be disabled.)