mfakto: an OpenCL program for Mersenne prefactoring

[Bdot]

Originally Posted by bcp19

Hmmm, does that mean the exp's I've been doing on the 32 bit client are suspect?

No. If the selftest succeeds, then the code works well and the results can be trusted. To be sure, you can run the extended selftest (-st).


Fighting the problem, I found out that reinstalling Windows helps - in a new Windows installation, with Catalyst 11.9, mfakto resumed normal operation. So the problem is either caused by some bad registry entries, or files, or persistent hardware state that are not corrected when deinstalling 11.10 and installing 11.9 again ... I'm trying to compare the registry, but the new Windows installation has corrupted my bootloader.

[Dubslow]

Originally Posted by Bdot

No. If the selftest succeeds, then the code works well and the results can be trusted. To be sure, you can run the extended selftest (-st).


Fighting the problem, I found out that reinstalling Windows helps - in a new Windows installation, with Catalyst 11.9, mfakto resumed normal operation. So the problem is either caused by some bad registry entries, or files, or persistent hardware state that are not corrected when deinstalling 11.10 and installing 11.9 again ... I'm trying to compare the registry, but the new Windows installation has corrupted my bootloader.

Reminds me of this :)

[Ethan (EO)]

Originally Posted by Bdot

I did not yet change all the trace statements to work for vectors. The kernel trace is only accurate when tracing non-vectored kernels. That´s also the reason for the "arguments don´t match" message.

I changed the trace format strings to v4 and v8 for the first few outputs from each kernel for the output I posted above... the "arguments don't match" message marks the end of the changes I made.

[Bdot]

Originally Posted by Ethan (EO)

I changed the trace format strings to v4 and v8 for the first few outputs from each kernel for the output I posted above... the "arguments don't match" message marks the end of the changes I made.

I see ... I now have a version that allows tracing all the way through, but that does not help. The trace shows that the input b value is zero for all components. Not having a one anywhere can never find a factor.

I suspect the new compiler does not handle a struct of 6 uints passed by value. I'll see that I can change that. If that does not work either, then I'll just send the bit-position of the 1 and each kernel thread needs to calculate b on its own.

This catalyst version does not leave a good impression. AMD says APP SDK 2.6 will come out soon, with a newer compiler. Lets see if that already fixed this. I cannot get rid of 11.10, so one machine can now throw all cores at P-1 and LL testing ... and the GPU temp is 35 degrees lower than usual.

[bcp19]

I've been noticing a weird thing with mfakto. I have an i5-2400 with an HD 6770 running 2 instances of the 32 bit mfakto with P95 running a P-1 and an LL. If I have P95 selected as the 'active' window, both instances of mfakto show 40-44M/s. If I have one of the mfakto windows 'active', the active runs at 55M/s while the other runs at 46M/s. I cannot test the 64 bit bersion thanks to 11.10, but I see no similiar behavior on my other 2 GPU machines which are running the 64 bit mfaktc. Any thoughts?

[LaurV]

Originally Posted by bcp19

Any thoughts?

Could be from windows? Priorities? In Win7 rightclick on Computer, properties, advanced, performance, and check how the priorities a balanced between "background task" or "service" and "program in front". You can set windows to automatically (dynamic) give more priority to the tasks according with their z-level, windows in front get more processor power.

[bcp19]

Originally Posted by LaurV

Could be from windows? Priorities? In Win7 rightclick on Computer, properties, advanced, performance, and check how the priorities a balanced between "background task" or "service" and "program in front". You can set windows to automatically (dynamic) give more priority to the tasks according with their z-level, windows in front get more processor power.

It has 2 selections, Programs and Background Services. If I change the setting both instances run slower regardless of task in front so I left it as it was.

Chalk up another reason to dislike Win7.

[Bdot]

Originally Posted by bcp19

I've been noticing a weird thing with mfakto. I have an i5-2400 with an HD 6770 running 2 instances of the 32 bit mfakto with P95 running a P-1 and an LL. If I have P95 selected as the 'active' window, both instances of mfakto show 40-44M/s. If I have one of the mfakto windows 'active', the active runs at 55M/s while the other runs at 46M/s. I cannot test the 64 bit bersion thanks to 11.10, but I see no similiar behavior on my other 2 GPU machines which are running the 64 bit mfaktc. Any thoughts?

I've seen this behavior too, also with 64-bit-mfakto on Win7.

mfakto (in fact, OpenCL) uses a background thread to handle the communication with the GPU. So whenever the main thread says "Go!" and then waits for the results, some background thread will do some magic to drive the GPU, collect the execution status and trigger the main thread when the kernel has finished. I did not check yet, but have the feeling that this background thread runs at lower-than-normal priority. This way, the prime95-threads (running at lowest priority) can interfere with the mfakto threads. And then the fact that LaurV posted can help mfakto, if it is the foreground application. Collecting the kernel results requires two thread switches (from p95 to the background thread, and then to the main thread). Priorities can play a big role, but certainly other things as well, e.g. CPU cache invalidation, as p95 and mfakto compete for memory access.

What throughput do the two instances have when no P95 runs? Probably ~60M/s each?

[jeebee]

People with problems with 11.10 might as well try out the newest revision 11.11. I'm still on 11.9 and don't plan on switching until confirmation the software renews its compatibility...

[Bdot]

Originally Posted by jeebee

People with problems with 11.10 might as well try out the newest revision 11.11. I'm still on 11.9 and don't plan on switching until confirmation the software renews its compatibility...

Deinstalling 11.10, removing system32\amdocl64.dll, system32\amdoclcl64.dll, syswow64\amdocl.dll and syswow64\amdoclcl.dll, and then installing 11.9 did the trick, now mfakto runs again, also in 64-bits!

And now that I know that these are the critical files that are not removed during the driver deinstallation, I can as well try the latest version ;-)

Edit: I tried, and 11.11 has the same issues as 11.10. So 11.9 stays the last usable version (for mfakto).

[bcp19]

Originally Posted by Bdot

I've seen this behavior too, also with 64-bit-mfakto on Win7.

mfakto (in fact, OpenCL) uses a background thread to handle the communication with the GPU. So whenever the main thread says "Go!" and then waits for the results, some background thread will do some magic to drive the GPU, collect the execution status and trigger the main thread when the kernel has finished. I did not check yet, but have the feeling that this background thread runs at lower-than-normal priority. This way, the prime95-threads (running at lowest priority) can interfere with the mfakto threads. And then the fact that LaurV posted can help mfakto, if it is the foreground application. Collecting the kernel results requires two thread switches (from p95 to the background thread, and then to the main thread). Priorities can play a big role, but certainly other things as well, e.g. CPU cache invalidation, as p95 and mfakto compete for memory access.

What throughput do the two instances have when no P95 runs? Probably ~60M/s each?

There is no change in the throughput when I shut down P95. There are only 3 'states' of the mfakto window... if 'on top' and selected it runs 55-56M/s, if 'on top' and not selected it runs at 46M/s. If another window is active over it (like IE, P95 maximized, Notepad, etc) both 'background' instances run at 40-42M/s.