mfakto: an OpenCL program for Mersenne prefactoring - Page 36

Bdot · 2012-02-03, 23:05

I've added worktodo.add to the todo list. But it's separate from the locking.

The files will not remain locked all the time (this would defeat the purpose of having multiple mfakto instances safely writing to the same results.txt file). The following is planned:mfakto will try to lock the file in question. If it fails to get the lock, it will say so and wait until it can lock the file. After the update to the file it will release the lock.

On Windows this will mean that your editor will complain (either when opening the file, or when attempting to save - depends on the cleverness of the editor), if exactly at this moment mfakto owns the lock. Retrying should work then (again, depends). If you opened the file in an editor while mfakto wants to write something, most editors will block mfakto.

On Linux, by default, only "lock-aware" applications will notice that mfakto holds a lock - locks are not enforced. For instance,

Code:

gvim worktodo.txt

will ignore any locks on worktodo.txt, and mfakto may write updates to the file while you edit it.

Code:

flock worktodo.txt -c gvim worktodo.txt

will keep the file locked while you edit it, blocking mfakto for that time. (Some may have noticed I currently favor flock() over fcntl().)

Do you really think this needs to be configurable?

And another update: I wrote a quick-hack-kernel that uses just 15 bits per int. This way I can completely avoid the expensive 32-bit mul and mul_hi. Kernel Analyzer says that on Cayman this will be ~20% faster than mul24, while it's of no use for the other GPU's. So this kernel could make HD6970 almost as fast as HD5870, or even a bit faster ...

Dubslow · 2012-02-03, 23:32

Quote:

Originally Posted by Bdot

Do you really think this needs to be configurable?

I really had no idea about the details of your goals and implementation, and was only stating what I liked (or rather that's what I should have done). If you think that my way and this locking thingy are still compatible, that's fine by me. I suppose my only real request is that when this is all cut and dried, that I know whether (and how) I can still edit worktodo on the fly.

chalsall · 2012-02-03, 23:49

Quote:

Originally Posted by Bdot

I've added worktodo.add to the todo list. But it's separate from the locking. On Linux, by default, only "lock-aware" applications will notice that mfakto holds a lock - locks are not enforced

Of course. Locks are agreed upon; they are semaphores.

Dubslow · 2012-02-04, 20:15

I tried looking through undoc.txt, but couldn't find the following: How does multiple workers work with worktodo.add? Do I put all the assignments in one list, or do I split it up as in the .txt file? Sorry, but like I said, I couldn't find this anywhere in undoc.txt.

flashjh · 2012-02-04, 20:20

Quote:

Originally Posted by Dubslow

I tried looking through undoc.txt, but couldn't find the following: How does multiple workers work with worktodo.add? Do I put all the assignments in one list, or do I split it up as in the .txt file? Sorry, but like I said, I couldn't find this anywhere in undoc.txt.

Add a section for each worker.

[Worker #1]

[Worker #2]

etc...

It adds the work to the bottom of each worker. I've never tried it without the sections, so I don't know what would happen. The only thing I don't like it Prime95 stops all workers when it adds work with the .add file so all stage-2 P-1 workers have to 'start over' which takes a lot of time when there are a lot of Relative Primes.

Jerry

Edit: I see you already pointed out the S-2 delay...

chalsall · 2012-02-04, 20:32

Quote:

Originally Posted by flashjh

It adds the work to the bottom of each worker. I've never tried it without the sections, so I don't know what would happen.

Everything is added to Worker #1.

Quote:

Originally Posted by flashjh

The only thing I don't like it Prime95 stops all workers when it adds work with the .add file so all stage-2 P-1 workers have to 'start over' which takes a lot of time when there are a lot of Relative Primes.

But this is also true if you stop Prime95.

Although I agree -- I can think of no reason the current program state has to change for work underway when the program is simply adding lines to worktodo.txt from worktodo.add.

flashjh · 2012-02-04, 20:36

Quote:

Originally Posted by chalsall

But this is also true if you stop Prime95.

Yes, which is why I don't like messing with Prime95 once it's up and running P-1s.

Quote:

Everything is added to Worker #1.

Ahh...

chalsall · 2012-02-04, 20:42

Quote:

Originally Posted by Bdot

I've added worktodo.add to the todo list. But it's separate from the locking.

Sorry -- was too fast (busy) yesterday. I should have thanked you for that.

Quote:

Originally Posted by Bdot

(Some may have noticed I currently favor flock() over fcntl().)

I don't disagree at all -- flock facilitates everything you're after, and is available from the shell(s) and scripts.

Dubslow · 2012-02-04, 21:05

Seems to me then there's absolutely no reason to use the worktodo.add function then. I was looking into it because I thought it wouldn't reset anything, that's my main problem... (and it can't add work besides to Worker 1?)
[/offtopic]

chalsall · 2012-02-04, 21:12

Quote:

Originally Posted by Dubslow

(and it can't add work besides to Worker 1?)

Reread the above. It *can* add work to all workers; the file is in the exact same format as worktodo.txt, and will add work to each worker as specified (although, as you point out, appended rather than in order of exponents / cost of the work / etc).

DigiK-oz · 2012-02-05, 17:26

I am working on a sort of GUI for mfakto. I would also like it to play nice with mfaktc. This brings me to questions about the -d option.

On single-GPU systems, things are easy. I simply start mfakto/mfaktc with no parameters and let them sort it out :). This simply works.

Multi-GPU systems are harder. Mfakto seems to work nice if I pass -d 1, -d 2 etc. Mfaktc seems to start with 0, so -d 0, -d 1 etc?

Mixed systems (i.e. 1 ATI and 1 Nvidia GPU are a mystery (I now simply start both with no parameters, which seems to (sometimes?) work.

Systems with any other combination (i.e. 2 ATI and 1 Nvidia GPUs) are killing me. Can anybody explain the -d option in great detail, given the cases:

ATI x 2 (-d 1 and -d 2 ?)
Nvidia x2 (-d 0 and -d 1?)
ATI x 1, Nvidia x 1 (no parameters for either, or one (which?) with no parameter, and the other being the second GPU?
ATI x 2, Nvidia x 1 (Baffles me)

Bottom line : how are the device-ids to use with -d allotted in above cases?

Cheers!

2012-02-03, 23:05	#386
Bdot Nov 2010 Germany 255₁₆ Posts	I've added worktodo.add to the todo list. But it's separate from the locking. The files will not remain locked all the time (this would defeat the purpose of having multiple mfakto instances safely writing to the same results.txt file). The following is planned:mfakto will try to lock the file in question. If it fails to get the lock, it will say so and wait until it can lock the file. After the update to the file it will release the lock. On Windows this will mean that your editor will complain (either when opening the file, or when attempting to save - depends on the cleverness of the editor), if exactly at this moment mfakto owns the lock. Retrying should work then (again, depends). If you opened the file in an editor while mfakto wants to write something, most editors will block mfakto. On Linux, by default, only "lock-aware" applications will notice that mfakto holds a lock - locks are not enforced. For instance, Code: gvim worktodo.txt will ignore any locks on worktodo.txt, and mfakto may write updates to the file while you edit it. Code: flock worktodo.txt -c gvim worktodo.txt will keep the file locked while you edit it, blocking mfakto for that time. (Some may have noticed I currently favor flock() over fcntl().) Do you really think this needs to be configurable? And another update: I wrote a quick-hack-kernel that uses just 15 bits per int. This way I can completely avoid the expensive 32-bit mul and mul_hi. Kernel Analyzer says that on Cayman this will be ~20% faster than mul24, while it's of no use for the other GPU's. So this kernel could make HD6970 almost as fast as HD5870, or even a bit faster ...

2012-02-05, 17:26	#396
DigiK-oz Jul 2008 2³×3 Posts	I am working on a sort of GUI for mfakto. I would also like it to play nice with mfaktc. This brings me to questions about the -d option. On single-GPU systems, things are easy. I simply start mfakto/mfaktc with no parameters and let them sort it out :). This simply works. Multi-GPU systems are harder. Mfakto seems to work nice if I pass -d 1, -d 2 etc. Mfaktc seems to start with 0, so -d 0, -d 1 etc? Mixed systems (i.e. 1 ATI and 1 Nvidia GPU are a mystery (I now simply start both with no parameters, which seems to (sometimes?) work. Systems with any other combination (i.e. 2 ATI and 1 Nvidia GPUs) are killing me. Can anybody explain the -d option in great detail, given the cases: ATI x 2 (-d 1 and -d 2 ?) Nvidia x2 (-d 0 and -d 1?) ATI x 1, Nvidia x 1 (no parameters for either, or one (which?) with no parameter, and the other being the second GPU? ATI x 2, Nvidia x 1 (Baffles me) Bottom line : how are the device-ids to use with -d allotted in above cases? Cheers! Last fiddled with by DigiK-oz on 2012-02-05 at 17:47

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
mfaktc: a CUDA program for Mersenne prefactoring	TheJudger	GPU Computing	3498	2021-08-06 21:07
gpuOwL: an OpenCL program for Mersenne primality testing	preda	GpuOwl	2719	2021-08-05 22:43
LL with OpenCL	msft	GPU Computing	433	2019-06-23 21:11
OpenCL for FPGAs	TObject	GPU Computing	2	2013-10-12 21:09
Program to TF Mersenne numbers with more than 1 sextillion digits?	Stargate38	Factoring	24	2011-11-03 00:34

2012-02-04, 20:15	#389
Dubslow Basketry That Evening! "Bunslow the Bold" Jun 2011 40<A<43 -89<O<-88 16065₈ Posts	I tried looking through undoc.txt, but couldn't find the following: How does multiple workers work with worktodo.add? Do I put all the assignments in one list, or do I split it up as in the .txt file? Sorry, but like I said, I couldn't find this anywhere in undoc.txt.

2012-02-04, 21:05	#394
Dubslow Basketry That Evening! "Bunslow the Bold" Jun 2011 40<A<43 -89<O<-88 3×29×83 Posts	Seems to me then there's absolutely no reason to use the worktodo.add function then. I was looking into it because I thought it wouldn't reset anything, that's my main problem... (and it can't add work besides to Worker 1?) [/offtopic]