Prime95 version 29.6/29.7/29.8

[lycorn]

Originally Posted by newalex

The second ECM factor was found using prime 29.6. And it isn't displayed correctly in reports, too.

https://www.mersenne.org/report_expo...=351457&full=1

And once more it doesn´t appear in the Recent Cleared Report

[irowiki]

So I'm new to the upgrade thing, all I have to do is replace the prime.exe / mprime file?

[Chuck]

Originally Posted by irowiki

So I'm new to the upgrade thing, all I have to do is replace the prime.exe / mprime file?

And also the .dll files that are packaged with the prime95.exe

[newalex]

Look like something was fixed on server side. Now factors are displayed correctly and it presents in all reports.

It is still a bit different from previous version - ecm curves' count and bounds doesn't displayed. For example the latest discovery
https://www.mersenne.org/report_expo...=354121&full=1

with old version
https://www.mersenne.org/report_exponent/?exp_lo=20147&full=1

But it is a minor thing.

[rainchill]

Thanks for the new release and all your hard work!

I'm still not clear on whether we should be running LL or PRP tests. Aren't LL tests expected to eventually be phased out?

Any progress on not filling up the output with daily 'Running Jacobi error check' messages?

Also - With as many issues, updates, suggestions, and feedback as these builds get would it make sense to create a new thread for each build (29.6B1, 29.6B2, etc...) instead of always editing the first post and letting these threads get too long? When a new thread is created the old one can be locked.

Finally - any word on integrating GPU testing into the main client?

[Prime95]

Originally Posted by rainchill

I'm still not clear on whether we should be running LL or PRP tests. Aren't LL tests expected to eventually be phased out?

You can run either. Personally, I am running PRP. Yes, I plan to make PRP the default work type if you select "What makes the most sense".

Any progress on not filling up the output with daily 'Running Jacobi error check' messages?

No. You could run PRP and get Gerbicz error-check messages instead.

Also - With as many issues, updates, suggestions, and feedback as these builds get would it make sense to create a new thread for each build (29.6B1, 29.6B2, etc...) instead of always editing the first post and letting these threads get too long? When a new thread is created the old one can be locked.

A new thread for each build would be too much clutter IMO. The old threads remain open as there are still many users of the old version.

Finally - any word on integrating GPU testing into the main client?

Won't happen. There is vague talk of having these clients get work from the server automatically, but nothing ever seems to come of it.

[axn]

Originally Posted by Prime95

Won't happen.

Thinking out loud. What's preventing this from happening?

[kriesel]

Originally Posted by axn

Thinking out loud. What's preventing this from happening?

I'm sure you know a lot of the following already, and I'm including it for other readers.

It's not simple, and we're short of qualified volunteer code developers. It's illegal to clone humans, at least in the US. There's only one George Woltman, and he lives in Florida. Who would update the prime95 & mprime family of apps for new processor models, and the other things he does now, if he's busy doing gpu programming and interfacing to primenet and prime95? (If anything, rather than finding more for him to do, we should find him some help. And that doesn't stop me from making suggestions or requests either. ;) He gets to decide what's worthwhile to him, and how much time he spends on this project.

There's a lot of identified bug list and feature request work for the several main existing gpu applications. There is no CUDAPRP at all. I think despite the great efforts by a lot of talented people, some of the gpu apps just haven't the quality yet that prime95 has. As is, it's hard to make headway as separate applications on the to-do list, or keep up on maintenance such as CUDA level. Some code does get shared, for efficiency. I think having it divided up into several programs helps though; programmers can work independently, yet share ideas.

The primenet API documentation is still "release candidate 0.97c" dated Nov. 2007, from before gpu computing in GIMPS was a thing, and it's not caught up to current practice in prime95 / mprime, and appears not well suited for gpus. It seems especially not well suited for dealing from a single instance with the cpu and disparate gpus per system of heterogenous-multi-gpu systems like I have. Many have looked at the Primenet API's complexity over the years, and chosen to go with separate assignment / submit scripts instead that work through the "manual" web pages or an altered version, at less effort than the Primenet API would take. Preda's a very recent example, of several. See https://www.mersenneforum.org/showpo...92&postcount=3 and https://www.mersenneforum.org/showthread.php?t=23992

The individual gpu apps each have their own unique ways of doing things. Probably the closest are mfaktc and mfakto. Each gpu app instance has its own worktodo file, ini file, etc. The same variable name in different gpu applications may mean different things. File formats often differ. Etc. Documentation other than the program source code is often quite sparse, or not current.

The development environment is more demanding for gpus. I've seen the installation of the NVIDIA or AMD SDK blow away the OpenCL driver for an Intel igp, ending use of mfakto. The NVIDIA and AMD SDKs may not coexist well. It's known to be tricky to get the gpu card drivers from NVIDIA and AMD to coexist on one system (Windows or linux) and system stability is reduced. Integrating the variety of gpu code into prime95 would complicate the build process and also software testing.

The status quo does not prevent George from helping out now and then on the gpu development side, as he has done occasionally. The status quo allows people like Preda to make rapid progress in a well defined area, independently.

Prime95 is an Intel-style-architecture program. Not all gpus are on Intel cpu systems. Some are on ARM systems (cell phones). There's a move afoot to explore cell phone computing via Mlucas. Ernst may be the second person to implement a Primenet client interface, in Mlucas generally, a cpu-oriented application. He'll probably implement PRP next, not gpu support.

We have abundant opportunity for programming volunteers.

[chalsall]

Originally Posted by Prime95

There is vague talk of having these clients get work from the server automatically, but nothing ever seems to come of it.

It can be argued that this problem space has already been solved. Scott's MISFIT for Windoze and Mark's primetools for Linux are stable and widely used tools.

[GP2]

Originally Posted by chalsall

It can be argued that this problem space has already been solved. Scott's MISFIT for Windoze and Mark's primetools for Linux are stable and widely used tools.

But I think these require you to put your Primenet password in plaintext into the scripts, so not everyone is satisfied with that.

[kriesel]

Originally Posted by chalsall

It can be argued that this problem space has already been solved. Scott's MISFIT for Windoze and Mark's primetools for Linux are stable and widely used tools.

Partially addressed, perhaps. Progress reporting is needed in primality testing, and on longer TF or P-1 assignments it would be good to have also. (Some individual TF bit levels or P-1 stages can take weeks.)

MISFIT looks impressive, but I've balked at installing its multiple requirements everywhere, to gain only TF client support. It _used to_ support CUDALucas but that was discontinued years ago. Never CUDAPm1 or gpuowl or clLucas etc.

Primetools supports clLucas (is anyone still using that?) and mfakto, and "possibly" mfaktc and CUDALucas.

The grid of OS, gpu app, feature combination support is sparse. See the attachment at https://www.mersenneforum.org/showpo...92&postcount=3
If it's not giving due credit for features available, please point me to a reference and I'll update the posted summary table there.