[QUOTE=Prime95;273179]James and I are working on the details.[/QUOTE]It looks like I'll be able to help George revise the parsing logic in the near future. Don't expect anything changed today or tomorrow, but if we can collectively decide on a standardized format for the results (by the end of this week, let's say), I'll see if I can get the results parser to understand it all correctly within a few weeks.

Hey Oliver:

Just noticed an overflow in the class-by-class status reporting....suddenly got a huge number of seconds reported for the time field that had nothing to do with what was happening on my wristwatch. This is on Linux 64, mfaktc-0.17, under xubuntu 10.10. The box has been up for about 4 days, and runing mfaktc for most of that time.

Eric



This hapened

Hi Eric,

I know this bug. It doesn't matter how long mfaktc is running (actually I've noticed this rarely while developing with some *very short* runs)

I'll take a look at this.

Oliver

[QUOTE=ckdo;273156]Use the source, Luke:

It adds up the exponents. (And then it gets the hose again.)[/QUOTE]

[QUOTE=James Heinrich;273176]That's what I get for adding features later on and not checking for side effects :redface: I've fixed it now.
(The original incarnation of the balancer did not have a variable definition of "easy", it was just the GHz-days effort, so adding it up made perfect sense.)[/QUOTE]
It seems that the fix broke the 'easy' definition part. It sorts inverted.:ick:

[QUOTE=Uncwilly;273523]It seems that the fix broke the 'easy' definition part. It sorts inverted.:ick:[/QUOTE]Apparently "easy" isn't so easy to define :cool:
Please try again, and let me know if anything still seems out of whack.

Hi,

*hmm* how do we tell the mfaktc users that the time per assignment (time per class) matters, not the "avg. rate"? The hard way: remove the "avg. rate" from the status output... but I don't really like this solution.

Ideas?

Perhaps a nice text in README.txt? Does the average user even read the README?

Oliver

[QUOTE=TheJudger;274100]how do we tell the mfaktc users that the time per assignment (time per class) matters, not the "avg. rate"?[/QUOTE]You need to display something that varies directly with overall performance, whether it's expressed as overall-time-per-exponent (where lower is better), or some inverse measure where bigger is better. What might be nice for the average user, actually, would be to replace "avg. rate" with "GHz-d/day" and calculate the GHz-days credit for the current assignment, and how much credit equivalent would be completed in 24h at the current rate.

[QUOTE=TheJudger;274100]
how do we tell the mfaktc users that the time per assignment (time per class) matters, not the "avg. rate"?
[/QUOTE]

Calculate average rate not on sieved candidates but on all?

I'll go further: what I really want to know is approximate wall time per factor found, assuming the usual statistics....

[QUOTE=apsen;274107]Calculate average rate not on sieved candidates but on all?[/QUOTE]
Yep. That ought to do the trick. If you take care of 100 potential factors -- it doesn't matter if it is "99 by sieve and 1 by TF" or "90 by sieve and 10 by TF", you just took care of 100, period. That is the true measure of overall progress.

[QUOTE=TheJudger;274100]
*hmm* how do we tell the mfaktc users that the time per assignment (time per class) matters[/QUOTE]

With different builds with varying number of classes, even time per class is not that useful.

[QUOTE=Christenson;274112]I'll go further: what I really want to know is approximate wall time per factor found, assuming the usual statistics....[/QUOTE]

While meaningful in itself, this measure can't be used to compare difference in performance across two different assignments, as it is sensitive to both exponent as well as bit level being done.

[QUOTE=TheJudger;274100]Hi,

*hmm* how do we tell the mfaktc users that the time per assignment (time per class) matters, not the "avg. rate"? The hard way: remove the "avg. rate" from the status output... but I don't really like this solution.

Ideas?

Perhaps a nice text in README.txt? Does the average user even read the README?

Oliver[/QUOTE]

Maybe re-arrange the order the fields are displayed so time and ETA are the first thing the user reads and average rate is displayed further to the right along with sieve primes and avg. wait? At least for people whos native language reads left to right that' should highlight which is more important.

Leftmost data may appear more important, perhaps, but the output still lacks a simple "throughput rate" number of some kind, where users can experiment with various settings and see which "gives me the biggest number".

Just call it iteration time. All Prime95 users are familiar with that terminology so will use it to compare benchmarks.

How about garo's iteration time (meaning time per class) and the probability of finding a factor, given the exponent and bitlevel, assuming no P-1? I don't think there will be much difficulty multiplying by the number of classes and dividing by the probability of a factor to get effective rate of finding factors....

I like the iteration rate ~= time per class, and I also like expanding the avg. rate to include sieved candidates. I would use the time output, except that the number of classes done changes with each output, that is, sometimes it does 2 classes, the next output will have 5 more done, etc. Either of the two changes mentioned above would work for me.

[QUOTE=Dubslow;274203]I like the iteration rate ~= time per class, and I also like expanding the avg. rate to include sieved candidates. I would use the time output, except that the number of classes done changes with each output, that is, sometimes it does 2 classes, the next output will have 5 more done, etc. Either of the two changes mentioned above would work for me.[/QUOTE]

I think each line of output is the results of running one class, it's just that some classes don't have to be checked so they're skipped entirely and take no time at all?

The problem with time-per-class type measurements is they're not easily compared between dissimilar assignments. The time-per-class for TF 2^64-65 for 9M or 90M or 900M will be greatly different, even though the GPU is putting forth the same amount of effort. The comparison number needs to be something that stays constant across those types of variations. It does not, however, need to hide difference in performance between the various kernels; if "71bit_mul24" runs faster than "barrett79_mul32" then so be it, it should display the higher numbers.
Which is why I suggested GHz-days/day, since it abstracts the internals of mfaktc into an easily-comparable number, and in bonus one that everyone is already familiar with.

I don't like any abstractions. Too much guesswork (though I will admit it would be very accurate and representative guesswork). Therefore, since under that argument time per class is bad, then I'd prefer to go with an avg. rate that includes sieved candidates rather than just directly tested candidates.

No reason they need to be mutally exclusive. Put in the options for both kinds of output; if display space is limited put a .ini option to pick the display type you prefer (with the default on the most newbie-friendly version, since the newbie is less likely to play with .ini settings).

[QUOTE=James Heinrich;274240]The problem with time-per-class type measurements is they're not easily compared between dissimilar assignments. The time-per-class for TF 2^64-65 for 9M or 90M or 900M will be greatly different, even though the GPU is putting forth the same amount of effort. The comparison number needs to be something that stays constant across those types of variations. It does not, however, need to hide difference in performance between the various kernels; if "71bit_mul24" runs faster than "barrett79_mul32" then so be it, it should display the higher numbers.
Which is why I suggested GHz-days/day, since it abstracts the internals of mfaktc into an easily-comparable number, and in bonus one that everyone is already familiar with.[/QUOTE]

GPU effort for 64 bits at 900M is significantly less than at 9M...there are lots fewer 900M candidates under 900M....even though each 900M candidate takes more effort...

GHz-Days per day is a fine number....however, the question is how is the naive newbie to know how well he or she is doing for Gimps as a whole, at a glance, from the mfaktc iteration output?

Seriously, factoring at 80 bits on a given exponent will find about the same number of factors as at 70 bits, but at 1,000 times the effort. This is why I think time per average factor (without P-1) or it's reciprocal is actually the right measure.

However, it may not matter -- assuming Primenet hands out the assignments, automatically, and Nelly Newbie just downloads mfaktc 1.0 and lets it run...then GHz days/day is fine.

HI guys. I just got mfaktc to run on my windows machines. I have a few questions. Sorry, this post is too long to read through everything.

1) do i need to stop mfaktc to add more to the worktodo.txt file?
2) on a similar question, will the completed work automatically be removed from the worktodo file?

Thanks,
Rysk

[QUOTE=rysk;274440]1) do i need to stop mfaktc to add more to the worktodo.txt file?
2) on a similar question, will the completed work automatically be removed from the worktodo file?[/QUOTE]1) No
2) Yes
:smile:

(I haven't looked at the code, so this is just observed behaviour).
After each assignment, mfaktc re-reads and re-writes worktodo.txt:
* remove the current assignment (usually the first line of the file) if complete, or rewrite it if processing a large bit range in stages
* any unknown lines will be warned about, but skipped over and left in the file

[QUOTE=rysk;274440]HI guys. I just got mfaktc to run on my windows machines. I have a few questions. Sorry, this post is too long to read through everything.

1) do i need to stop mfaktc to add more to the worktodo.txt file?
2) on a similar question, will the completed work automatically be removed from the worktodo file?

Thanks,
Rysk[/QUOTE]

2) will be done automatically
1) Appending to the file can be done on the fly. Basically you must not modify the first line, otherwise mfaktc may not find the current task for updating. The usual restrictions for simultaneous access apply - in other words, take care to do your updates quickly without reverting mfaktc's updates .


... simultaneous answers in the forum work, luckily ...

thanks!

[QUOTE=Bdot;274466]
... simultaneous answers in the forum work, luckily ...[/QUOTE]

lol :smile:

So I thought I had mfaktc going correctly, but the times are extremely slow??? Can anyone shed some light on what I should do? Or is it just my video card? I'm using the win64 files from [url]http://www.mersenneforum.org/mfaktc/[/url] running win7 home premium with an i7 860 (2.8Ghz) processor and 8 G's of ram and here are my results....


[CODE]
C:\mfaktc>mfaktc-win-64.exe
mfaktc v0.17-Win (64bit built)

Compiletime options
THREADS_PER_BLOCK 256
SIEVE_SIZE_LIMIT 32kiB
SIEVE_SIZE 193154bits
SIEVE_SPLIT 250
MORE_CLASSES enabled

Runtime options
SievePrimes 25000
SievePrimesAdjust 1
NumStreams 3
CPUStreams 3
GridSize 3
WorkFile worktodo.txt
Checkpoints enabled
Stages enabled
StopAfterFactor bitlevel
PrintMode full
AllowSleep no

CUDA device info
name GeForce GT 220
compute capability 1.2
maximum threads per block 512
number of multiprocessors 6 (48 shader cores)
clock rate 1335MHz

CUDA version info
binary compiled for CUDA 3.20
CUDA driver version 4.0
CUDA runtime version 3.20

Automatic parameters
threads per grid 786432

running a simple selftest...
Selftest statistics
number of tests 31
successfull tests 31

selftest PASSED!

got assignment: exp=59193781 bit_min=70 bit_max=71
tf(59193781, 70, 71, ...);
k_min = 9972260602920
k_max = 19944521211061
Using GPU kernel "71bit_mul24"

found a valid checkpoint file!
last finished class was: 2891
found 0 factor(s) already

class | candidates | time | avg. rate | SievePrimes | ETA | avg. wait
2895/4620 | 463.99M | 31.665s | 14.65M/s | 25000 | 3h08m | 44549us
2900/4620 | 459.28M | 31.348s | 14.65M/s | 28125 | 3h06m | 44115us
2903/4620 | 454.56M | 31.027s | 14.65M/s | 31640 | 3h04m | 43606us
2904/4620 | 450.63M | 30.653s | 14.70M/s | 35595 | 3h01m | 42871us
2915/4620 | 445.91M | 30.108s | 14.81M/s | 40044 | 2h57m | 41872us
2916/4620 | 441.19M | 29.793s | 14.81M/s | 45049 | 2h55m | 41221us
2919/4620 | 437.26M | 29.527s | 14.81M/s | 50680 | 2h53m | 40526us
2924/4620 | 433.32M | 29.264s | 14.81M/s | 57015 | 2h51m | 39789us
2928/4620 | 428.61M | 28.947s | 14.81M/s | 64141 | 2h48m | 39010us
2931/4620 | 424.67M | 28.684s | 14.81M/s | 72158 | 2h46m | 38187us
2936/4620 | 420.74M | 28.419s | 14.80M/s | 81177 | 2h44m | 37308us
2939/4620 | 416.81M | 28.177s | 14.79M/s | 91324 | 2h42m | 36416us
2943/4620 | 413.66M | 28.000s | 14.77M/s | 102739 | 2h41m | 35478us
2960/4620 | 409.73M | 27.807s | 14.73M/s | 115581 | 2h39m | 34563us
2963/4620 | 405.80M | 27.530s | 14.74M/s | 130028 | 2h37m | 33433us
2964/4620 | 402.65M | 27.282s | 14.76M/s | 146281 | 2h35m | 32178us
2975/4620 | 398.72M | 26.983s | 14.78M/s | 164566 | 2h33m | 30871us
2979/4620 | 395.58M | 26.856s | 14.73M/s | 185136 | 2h32m | 29675us
2988/4620 | 393.22M | 26.663s | 14.75M/s | 200000 | 2h31m | 28695us
2991/4620 | 393.22M | 26.580s | 14.79M/s | 200000 | 2h30m | 28547us
class | candidates | time | avg. rate | SievePrimes | ETA | avg. wait
2996/4620 | 393.22M | 26.581s | 14.79M/s | 200000 | 2h29m | 28537us
2999/4620 | 393.22M | 26.640s | 14.76M/s | 200000 | 2h29m | 28644us
3000/4620 | 393.22M | 26.856s | 14.64M/s | 200000 | 2h30m | 29019us
3003/4620 | 393.22M | 26.632s | 14.76M/s | 200000 | 2h28m | 28620us
3008/4620 | 393.22M | 26.610s | 14.78M/s | 200000 | 2h28m | 28575us
3015/4620 | 393.22M | 26.662s | 14.75M/s | 200000 | 2h27m | 28676us
3020/4620 | 393.22M | 26.694s | 14.73M/s | 200000 | 2h27m | 28751us[/CODE]

From the looks of it you have it set up and running properly, it's just your video card is slow. You may be able to get a little more performance if you decrease the GridSize.

Well, you're using a GT 220, that's a near-the-bottom-of-its-generation from 2 generations ago, while the CPU is top-of-the-line 1 generation old. The avg. wait indicates how long the CPU is waiting for work. If it's greater than 1000, than the CPU is waiting a lot, which means the GPU is overwhelmed. Sieve Primes controls how much work is done on the CPU; that's why the program auto-adjusted that up to 200,000 (the default is 25,000, and 5,000 is the minimum). Given the very nice CPU and much slower GPU, I'd say these numbers are to be expected. I don't think there's much you can do besides buying new hardware, sorry :P. Other forum members, does this analysis seem correct?

Having reread what delta_t said, his advice seems the best. (I'm not as familiar with GridSize as other parameters, so if he says so, go for it.)

thanks guys. I'll play around with it. Maybe I'll try to pick up a new card. :grin:

I downloaded the 32 bit version of CudaLucas and unzipped it, but when I try to run it I get an error "cufft32_32_16.dll not found". I have tried searching both the forum and the web for this but have had no success. Can anyone point me in the right direction?

@Dubslow: Good...
@BCP19: I get that file by installing the developer's kit from nvidia...it may be posted here somewhere, too.

I installed the Cuda Toolkit 4.0 and still get the same error :/

[QUOTE=bcp19;274652]I downloaded the 32 bit version of CudaLucas and unzipped it, but when I try to run it I get an error "cufft32_32_16.dll not found". I have tried searching both the forum and the web for this but have had no success. Can anyone point me in the right direction?[/QUOTE]

The zip from [url=http://www.mersenneforum.org/showpost.php?p=273900&postcount=363]this post[/url] contains "cudart32_32_16.dll". Perhaps helps.

Nope, cudart and cudafft are different. There are various 64 bit cudafft files floating around the forum, but I haven't yet found a 32 bit. I'll keep looking.

Edit: I'm pretty sure the file you need is in the download you installed, but CUDALucas won't find it unless it's in the same directory. Do you remember "where" you installed CUDA 4.0, or does somebody else know where it installs? Also could a mod move this to the CUDALucas thread?

"Nope, cudart and cudafft are different"

That's "cufft", in various permutations of "cufft_##_##_##.dll", right?

I need a 32bit version of that.

Right...you need cufft_32_xx_xx.dll. You can find it in the place where nvidia installed the developer's kit. Just go to the root of the installation and search for files named cufft...IIRC, it installs either in C:\nvidia or C:\program files\nvidia....the simple thing to do is to copy it into the directory with CUDALucas, the more complicated way is to ensure that that binary directory is on your path when you call CUDALucas....either with a set command in your batch file, or by adding it to the global PATH environment variable, or possibly be the settings for your desktop icon.

"You can find it in the place where nvidia installed the developer's kit. Just go to the root of the installation and search for files named cufft...IIRC,..."

Thanks! I downloaded and installed that, but have not dug into it yet. The roadmap is appreciated.

[QUOTE=Christenson;274692]Right...you need cufft_32_xx_xx.dll. You can find it in the place where nvidia installed the developer's kit. Just go to the root of the installation and search for files named cufft...IIRC, it installs either in C:\nvidia or C:\program files\nvidia....the simple thing to do is to copy it into the directory with CUDALucas, the more complicated way is to ensure that that binary directory is on your path when you call CUDALucas....either with a set command in your batch file, or by adding it to the global PATH environment variable, or possibly be the settings for your desktop icon.[/QUOTE]
In Linux I've found that regardless of PATH, it doesn't find the requisite file, and in fact looks for a file with a slightly different name. Ask The Judger about the fix, as he's who I copied: Creating a subdirectory (in mfaktc or cudalucas) with a properly named (what mfaktc/cudalucas look for) shortcut to the file (as named by nVidia). Their best bet is to just copy the dll's into the proper directory.

[QUOTE=Dubslow;274710]In Linux I've found that regardless of PATH, it doesn't find the requisite file, and in fact looks for a file with a slightly different name.[/QUOTE]
LD_LIBRARY_PATH

Recommended reading: man ldconfig :smile:

[QUOTE=bcp19;274652]I downloaded the 32 bit version of CudaLucas and unzipped it, but when I try to run it I get an error "cufft32_32_16.dll not found". I have tried searching both the forum and the web for this but have had no success. Can anyone point me in the right direction?[/QUOTE]

Got it. It's located in C:\Program Files (x86)\NVIDIA GPU Computing Toolkit\CUDA\v4.0\bin .
You can also download it from [url]http://filesmelt.com/downloader/cufft32_40_17.dll[/url] . (I didn't want to bother zipping it to attach it.)

the _40_ indicates it's from CUDA 4.0. If that doesn't work, I can get you a 3.2 _32_ version, though I'm pretty sure the 4.0 version will work.

[QUOTE=Ralf Recker;274713]LD_LIBRARY_PATH

Recommended reading: man ldconfig :smile:[/QUOTE]

The nVidia instructions indicate adding certain folders to both PATH and LD_LIBRARY_PATH, which I did, to no avail. That trick I mentioned includes setting LD_LIBRARY_PATH=mfaktc/cufft . Like I said, ask The Judger for details.
Edit2: [url]http://www.mersenneforum.org/showpost.php?p=270670&postcount=1175[/url]
That tarball has an extra directory 'lib' with the library files that it can never find. I used a variant of this hack to get mfaktc (and later CUDALucas) running in Linux.

Edit: I am forced to admit that after reading [url]http://linux.die.net/man/8/ldconfig[/url] I am no closer to understanding what that command does. :P Could you try explaining it please?

[QUOTE=Dubslow;274715]The nVidia instructions indicate adding certain folders to both PATH and LD_LIBRARY_PATH, which I did, to no avail. That trick I mentioned includes setting LD_LIBRARY_PATH=mfaktc/cufft . Like I said, ask The Judger for details.
Edit2: [url]http://www.mersenneforum.org/showpost.php?p=270670&postcount=1175[/url]
That tarball has an extra directory 'lib' with the library files that it can never find. I used a variant of this hack to get mfaktc (and later CUDALucas) running in Linux.

Edit: I am forced to admit that after reading [url]http://linux.die.net/man/8/ldconfig[/url] I am no closer to understanding what that command does. :P Could you try explaining it please?[/QUOTE]

OK, here goes:
Windows instructions break on Linux...Big surprise! :smile:

ldconfig sets up Shared Object files (.so -- analogous to windows DLL) so they can be found when called for at run-time. I don't remember having to fool with this with mfaktc on my Linux box, so I think it must have been handled as part of the instructions (make install). The medium-level GT440 is saturated by one core, so I haven't tried CUDALucas on Linux.

But copying SO's/DLLs into the directory with the executable is fine with me...it's not like they take up huge amounts of very cheap disk space or anything...

Hi,

.so files (shared object) on Linux are similar to DLLs on Windows.[LIST][*][I]ldconfig[/I] is a utility which parses (usually) [I]/etc/ld.so.conf*[/I] to create some kind of database in which directory which .so can be found. OK, this does a little bit more but for now this should be enough. With [I]ldconfig[/I] you setup your .so files [B]systemwide[/B][*][I]LD_LIBRARY_PATH[/I] is a environment variable which contains a list of directories which should [B]additionally[/B] included when searching .so files. This is only for the current process and (if LD_LIBRARY_PATH is exported) to the child processes of the current process.[/LIST]
You can use [I]ldd[/I] to check which libraries are used. (OK, it is possible to fool the output of ldd but lets assume we don't want to fool ldd.)

Using this [url]http://www.mersenneforum.org/mfaktc/mfaktc-0.17.linux64.tar.gz[/url] on my Linux box:
[CODE]o@Lysithea:~/foo/mfaktc-0.17> ldd mfaktc.exe
linux-vdso.so.1 => (0x00007fff53ac4000)
[COLOR="Red"]libcudart.so.3 => not found[/COLOR]
libc.so.6 => /lib64/libc.so.6 (0x00007ff7d8ef3000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007ff7d8be9000)
libm.so.6 => /lib64/libm.so.6 (0x00007ff7d8992000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff7d9253000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ff7d877c000)
[/CODE]

setting the variable LD_LIBRARY_PATH temperary ONLY for this command
[CODE]o@Lysithea:~/foo/mfaktc-0.17> LD_LIBRARY_PATH=./lib/ ldd mfaktc.exe
...
[COLOR="Red"]libcudart.so.3 => ./lib/libcudart.so.3 (0x00007f6264d23000)[/COLOR]
...
[/CODE]

setting the variable for the current shell and all their child processes
[CODE]o@Lysithea:~/foo/mfaktc-0.17> export LD_LIBRARY_PATH="./lib:${LD_LIBRARY_PATH}"
o@Lysithea:~/foo/mfaktc-0.17> ldd mfaktc.exe
...
[COLOR="Red"]libcudart.so.3 => ./lib/libcudart.so.3 (0x00007f3a716d6000)[/COLOR]
...
[/CODE]

Oliver

Thanks for the help, I did finally get cufft32_32_16.dll by installing the 3.2 toolkit and there are no more errors.

Hey guys, is this how mfaktc is supposed to work? When I TF a number in the 59,xxx,xxx range from 70 to 71, it takes me about 6 hours or so on my card. I read that it is more efficient to take a number from a low bit to a high bit, so I tried TF'ing 306,xxx,xxx from 65 up to 71. I saw that it did this in stages, from 65 up to 69 first and then 69 to 70 and then 70 to 71. When it did 70 to 71, I thought it would take me longer then the 6 hours it took me to take the 59M number from 70 to 71, but this only took me 1.5 hours. Is this how it is supposed to work?

[QUOTE=rysk;274986]Hey guys, is this how mfaktc is supposed to work? When I TF a number in the 59,xxx,xxx range from 70 to 71, it takes me about 6 hours or so on my card. I read that it is more efficient to take a number from a low bit to a high bit, so I tried TF'ing 306,xxx,xxx from 65 up to 71. I saw that it did this in stages, from 65 up to 69 first and then 69 to 70 and then 70 to 71. When it did 70 to 71, I thought it would take me longer then the 6 hours it took me to take the 59M number from 70 to 71, but this only took me 1.5 hours. Is this how it is supposed to work?[/QUOTE]

Yes. All factors of the Mersenne number Mp - hence all candidates for trial factorisation - are of form 2kp+1. The larger the exponent, the greater the gap between successive candidates, and the fewer candidates there are at any single bit level.

thanks!

New Nvidia GPU driver 285.62
 

Nvidia released a new driver, 285.62, and looks like it has CUDA 4.10. I just installed it on my computer with a GTX 460M and the current win64 mfaktc (compiled under CUDA 3.2) is working fine. I haven't tried CUDALucas yet, but I figured many CUDALucas people check this thread, so perhaps one of you can test and report in that thread?

[QUOTE=delta_t;275650]Nvidia released a new driver, 285.62, and looks like it has CUDA 4.10. I just installed it on my computer with a GTX 460M and the current win64 mfaktc (compiled under CUDA 3.2) is working fine. I haven't tried CUDALucas yet, but I figured many CUDALucas people check this thread, so perhaps one of you can test and report in that thread?[/QUOTE]

Did you see any differences in timings?

Luigi

[QUOTE=delta_t;275650]Nvidia released a new driver, 285.62, and looks like it has CUDA 4.10. I just installed it on my computer with a GTX 460M and the current win64 mfaktc (compiled under CUDA 3.2) is working fine. I haven't tried CUDALucas yet, but I figured many CUDALucas people check this thread, so perhaps one of you can test and report in that thread?[/QUOTE]

I just installed the new NVIDIA drivers as well, and I have a GTS 450 running CUDALucas and everything is working fine.

[QUOTE=ET_;275666]Did you see any differences in timings?

Luigi[/QUOTE]

I just installed the new driver; I noted a few timings that were on the screen before shutting down both instances of mfaktc.

After installing the new driver I waited for a couple of TFs to complete. I would say there is either no difference or maybe the new driver is taking a littler bit longer.

New Driver
 

It's working fine for me. I can't judge about speed, because I just started doing work for Mr. P-1 in a range I'm not experienced with.

In driver version 285.62 I noticed a slight improvement in speed compared to 267.59.
avg. rate ~ 116 M/s vs ~ 115 M/s
avg. wait ~ 2100 us vs ~ 2200 us
Version 270.61 showed a lot worse performance - I didn't bother to take readings, just uninstalled it rightaway.

System info:
GPU GTS 450
CPU i3-2100

[QUOTE=S45653;275829]In driver version 285.62 I noticed a slight improvement in speed compared to 267.59.
avg. rate ~ 116 M/s vs ~ 115 M/s
avg. wait ~ 2100 us vs ~ 2200 us
Version 270.61 showed a lot worse performance - I didn't bother to take readings, just uninstalled it rightaway.

System info:
GPU GTS 450
CPU i3-2100[/QUOTE]

Unfortunately none of those are good measures of speed since they can vary depending on minor variations in sieve_primes (caused by a variety of things, including using the computer for normal light tasks while mfaktc is running). Compare time per class or time per exponent instead.
Of course with avg. wait so high maybe your sieve_primes is pinned at 200,000? In that case, this is a real speedup, but as you said, minor.

I just downloaded and installed 285.62 and the news is not good. At least not for my config. I'm running with SievePrimes fixed so that cannot explain this variation either. I find that the new version is about 4-5% slower. I wonder if compiling with 4.10 might help.

[QUOTE=garo;276271]I just downloaded and installed 285.62 and the news is not good. At least not for my config. I'm running with SievePrimes fixed so that cannot explain this variation either. I find that the new version is about 4-5% slower. I wonder if compiling with 4.10 might help.[/QUOTE]

I thought it seemed just a little slower. Should we go back to the previous version? I use the GPU only for Prime95 so any other changes don't make any difference to me. I was using 280.26 before this update.

I was using 266.71 and 285.62 is definitely slower by 4-5%.

I need to amend the above post :redface:

I tried setting CPU affinity again and the difference between the driver versions has dropped to less than a percent. The 4-5% difference was not correct.

[QUOTE=Chuck;275705]I just installed the new driver; I noted a few timings that were on the screen before shutting down both instances of mfaktc.

After installing the new driver I waited for a couple of TFs to complete. I would say there is either no difference or maybe the new driver is taking a littler bit longer.[/QUOTE]
[url=http://www.youtube.com/watch?v=eeqUUNHwAl8]Baby Driver[/url]

could someone give me a hand getting mfaktc to run on my second GPU? I currently have 2 gtx 285 and one is going to waste not being utilized.

[QUOTE=fruitflavor;277087]could someone give me a hand getting mfaktc to run on my second GPU? I currently have 2 gtx 285 and one is going to waste not being utilized.[/QUOTE]

Can you add more detail?

What's the command you are using?

For code to run on the 2nd gpu, you need to add the "-d 1" switch on the command line.

-- Craig

They're counted as 0 and 1 then?

[QUOTE=Dubslow;277155]They're counted as 0 and 1 then?[/QUOTE]

Yep.

I have 2x dual GPU machines.

I vaguely recall you need to make sure that SLI is _OFF_

-- Craig

[QUOTE=fruitflavor;277087]could someone give me a hand getting mfaktc to run on my second GPU? I currently have 2 gtx 285 and one is going to waste not being utilized.[/QUOTE]

Check the FAQ section in README.txt.

Oliver

[QUOTE=Dubslow;277155]They're counted as 0 and 1 then?[/QUOTE]

Yepp, mfaktc numbers the GPUs in same way as nvidia does.

Oliver

Hello,

it has been a relative long time since the last mfaktc release release. So here is a little teaser for mfaktc 0.18. So far there are more than usual minor updates but the performance numbers are pretty much the same compared to mfaktc 0.17.

Stock 285 GTX, barrett79 kernel, raw GPU speed (without sieving)[CODE]
| CUDA 3.2 | CUDA 4.1-RC1
mfaktc 0.17 | 74.19M/s | 74.16M/s
mfaktc 0.18-pre9 | 74.46M/s | 74.46M/s[/CODE]

Factory overclocked GTX 560Ti (1701MHz), barrett79 kernel, raw GPU speed (without sieving)[CODE]
| CUDA 3.2 | CUDA 4.1-RC1
mfaktc 0.17 | 260.94M/s | 261.93M/s
mfaktc 0.18-pre9 | 260.80M/s | 258.97M/s[/CODE]

Stock GTX 470, barrett79 kernel, raw GPU speed (without sieving)
This is my development system, so I have more detailed benchmarks here[CODE]
| CUDA 3.2 | CUDA 4.0 | CUDA 4.1-RC1
mfaktc 0.17 | 305.25M/s | 319.32M/s | 322.63M/s
mfaktc 0.18-pre8 | 308.28M/s | 319.53M/s | 321.34M/s
mfaktc 0.18-pre9 | 312.18M/s | 323.28M/s | 335.56M/s[/CODE]

mfaktc 0.18-pre9 has some CUDA >= 4.1 specific code. CUDA 4.1 has new instructions for Fermi class GPUs (multiply-add [B]with carry[/B]). Of course it is still compileable with older CUDA releases and for CC 1.x GPUs!

I have to check why it is slower on GTX 560 Ti...

So for the mfaktc 0.18 release[LIST][*]I want to rework the barrett92 kernel (CUDA 4.1 optimizations)[*]I want to wait for official CUDA 4.1 release[*]ask Eric which of his new code should be included[/LIST]
Eric works on the automated primenet interaction. The current code does [B]not[/B] contain any code to interact with the primenet server but e.g. the parsing of worktodo has been rewritten (taking care of the assignmend ID, ...)

Oliver

Any "cosmetics" on the horizon? Like for example the output file name in the ini file (now results.txt). For the people running many copies of mfaktc, to keep all the result in the same file, and no need to walk from a folder to another, to report them... And also mark somehow in the table that a factor is found (for example adding an asterisk after the class number, or replacing the "|" tabular character with "#" or "*", so if I missed a factor on the screen I can see, and scroll up for it? (these were just some dummy ideas).

oh, I didn't mention: benchmarks were for M66362159 from 2[SUP]69[/SUP] to 2[SUP]70[/SUP].

LaurV: yes, some cosmetics included, but nothing you've mentioned. You could try "PrintMode=1" in mfaktc.ini for your "missed factors" issue.

Oliver

A very desired update, and a offer of service!
 

[B]TheJudger[/B]: Thank you for all the work you've done too make us able to crunch for GIMPS using GPU. I almost completely exited GIMPS, as a protestation of not having the capacity of crunching with GPU, but now i plan to configure my cluster to restart. But i have 1 big problem with the actual version, as windows really su**s, and don't have job control commands, i can't unleash my main computer without blocking me to do anything else like playing Skyrim. So i would really, really, appreciate if you can add a simple control to be able to pause/restart the app, to replace ctrl+z fg combination of the great Bash. This way, when i wanna play, i can pause till i stop, restarting the crunching after. So this was what i hope you'll take the time to embed, and i'm pretty sure i'm not alone in this situation. If you have a hints that i must know that will do the job, tell it to me please. I think about making a small Python GUI launcher, that will have the ability to pause restart, but i need you to at least add a signal event catcher, or any control char catcher, that will catch ctrl-d and leave ctrl-c to interrupt, and make it do the 2 job simply alternating between state. Use a common combination, that will work with win&linux, even if linux don't need it. So if you want, i can make a Python/Tk GUI to control the app, even controlling more than one app at the same time, starting 1 per core, whatever. Leave me a message if you're interested!! If you make me the pause restart, i'll make you the GUI/Launcher!! Deal?

Maybe a complete GUI?
 

[B]TheJudger[/B]: An hour later, i got an idea, more than making a complete gui that will handle all the automation job, maybe i can add a automatic job assignment, using the manual job request of the GIMPS site, by making a robot and a parser to fill the form, gos the work, than do the same for the result. But if someone i doing the same, i'll not do it. Just a GUI that will handle task automation with multicore support. So i wait your comment...

[QUOTE=PsycO;279634]i can't unleash my main computer without blocking me to do anything else like playing Skyrim. So i would really, really, appreciate if you can add a simple control to be able to pause/restart the app... when i wanna play, i can pause till i stop, restarting the crunching after.[/quote]What GPU do you have? Older GPUs (especially prior to compute 2.0) can benefit tremendously from tweaking some mfaktc.ini settings (such as GridSize).

You already have pause/continue functionality built into Windows: the Pause key on your keyboard. Hit "pause" and execution stops; hit any other key (e.g. <enter>) to resume processing. This applies to any CLI program running in Windows, and in many places outside Windows too (during POST, for example).

[quote=PsycO]maybe i can add a automatic job assignment[/quote]Hold on for that, it's already being worked on and will be integrated properly into mfaktc in the near future.

[B]James Heinrich :[/B]
[QUOTE]What GPU do you have? Older GPUs (especially prior to compute 2.0) can benefit tremendously from tweaking some mfaktc.ini settings (such as GridSize).[/QUOTE]I have one GT-430(1.1) and one GTS-450(2.1). But this will not be these one in few weeks, i plan to transfert these two on one node of my cluster, and buy 2xGTX-470. But for the moment, maybe yes the GT-430 may need some tweaking, as it run 2.5 times less than the GTS-450. But i have done a hardware hack to be able to plug it in a 2xPCI-e, so maybe the transfert rate are for something here. I will change my motherboard for a sli of the same model as i already said. What do you suggest as tweaking for the GT-430, i can try it, maybe it will worth it!!
[QUOTE]You already have pause/continue functionality built into Windows: the Pause key on your keyboard. Hit "pause" and execution stops; hit any other key (e.g. <enter>) to resume processing. This applies to any CLI program running in Windows, and in many places outside Windows too (during POST, for example).
[/QUOTE]Excellent, i will go to sleep a little less silly tonight!!! Haha Thanks!!! I don't like windows, but i stuck with it as in a gaming trip these days! I'm a Linux lovers, and my bash misses me a lot when i'm on win...
[QUOTE]Hold on for that, it's already being worked on and will be integrated properly into mfaktc in the near future. [/QUOTE]Alright, if someone is already working on it, that's perfect!!

If you are interested in a GUI for mfaktc/o, let me know, i will be please to make a universal launcher, for win and linux, that will handle the configuration and launching of the exe. It will detect the number of core and deal with the cmdline options. So let me know if someone is interested, i will be please to participate to the project!!

Another question is, does mfaktc do a lot of IO, on a temp file or to save backup?? This is to know if it is usefull to setup a ramdisk so all operation will stay in ram?? More info's on: [URL]http://memory.dataram.com/products-and-services/software/ramdisk[/URL]

A last thing, for the pause button of the keyboard, do you know pressing the button issue what signal to windows(the shell)?? I wanna know that, this will surely have utility in one of my future project!!!

[QUOTE=PsycO;279661] and my bash misses me a lot when i'm on win...[/QUOTE]

That totally gives you away as a Francophone... :smile: And sure enough, you're from Québec!
(Right? If not, I'm so sorry!)

(LaurV I meant Francophone :P) (Si je n'avais pas vu qu'il [ou qu'elle, je suppose] vient de Québec, je n'aurais rien dit.)

:smile:

Now an actual contribution occurs to me: Keep in mind that it is presumed (isn't it?) that mfaktc will eventually be integrated into Prime95, and thus building any sort of GUI would be at the bottom of the list. If on the other hand you still want to volunteer to do that, I suppose I can't stop you (nor do I have the authority anyways :P:) ).

[QUOTE=PsycO;279661]Another question is, does mfaktc do a lot of IO, on a temp file or to save backup?? This is to know if it is usefull to setup a ramdisk so all operation will stay in ram?? More info's on: [URL]http://memory.dataram.com/products-and-services/software/ramdisk[/URL][/QUOTE]

It's what I do. I find I get a few % more running from ramdisk.

That ramdisk software is excellent.

-- Craig

When using this, how do you guard against data loss in the case of a power outage or some such?

[URL="http://65.181.149.90/member.php?u=12800"]Dubslow[/URL]: C'est Il, et oui mon anglais sort parfois du fond des rang du québec!!! hehe
And i have forgotten to take into account the possibility that he will be integrated into Prime95... Maybe i'll do one, but since there is no need for it, if i get bored to start it with the cmdline, this may be enough to mind me to do it!!

nucleon: Alright, i will try it i the next days!

And a last thing, the GT-430 is 2.1 not 1.1...

If kladner's around somewhere, he knows a lot about the cmd commands to open mfaktc/CUDALucas (read: he spent a lot of time experimenting). As for just opening it, I just use a shortcut, which accepts CLI commands in "Target" and then pin the shortcut to my taskbar. Then just click it and the CLI window appears and it starts automatically.

(Et aussi en anglais on dirait 'I miss my bash' qui serait litteralement en français 'Bash je le manque' ou quelque chose inversé comme ça. Je me souviens de cette différence qui ont confondu (est-ce le bon mot?) tous les élèves de mon cours de français.)

[QUOTE=bcp19;279725]When using this, how do you guard against data loss in the case of a power outage or some such?[/QUOTE]

This is why that specific ram drive is pretty cool.

It saves an image every x-seconds you specify. It loads the image on bootup. It also as a backup in case power failure during an image write. It's a lot safer now than the earlier versions.

Also as a secondary precaution, I rsync all mfaktc instances to my nas every hour.

Worst case for me I lose say 2 hours. I've been in this unit for about 2months - no power issues for me.

But if you're having a power issue <1/fortnight, I think you have greater issues :)

Another benefit - you can migrate the image to another PC if required. Complete file structure ready to go.

-- Craig

[QUOTE=nucleon;279773]This is why that specific ram drive is pretty cool.

It saves an image every x-seconds you specify. It loads the image on bootup. It also as a backup in case power failure during an image write. It's a lot safer now than the earlier versions.

Also as a secondary precaution, I rsync all mfaktc instances to my nas every hour.

Worst case for me I lose say 2 hours. I've been in this unit for about 2months - no power issues for me.

But if you're having a power issue <1/fortnight, I think you have greater issues :)

Another benefit - you can migrate the image to another PC if required. Complete file structure ready to go.

-- Craig[/QUOTE]

I don't have power issues, I just tend to think about the worst case scenario. I've probably had the power go out twice in the last year, so it's not a big deal.

I didn't look at all the tabs, that is pretty neat, thanks.

CMD and Start commands
 

[QUOTE=Dubslow;279772]If kladner's around somewhere, he knows a lot about the cmd commands to open mfaktc/CUDALucas (read: he spent a lot of time experimenting).[/QUOTE]

Hello PsycO: I just noticed this discussion. I use CMD and the Start command to run mfaktc from batch files. I think that this can also be done with a shortcut, but I have not experimented very much with that. My understanding from others here is that this only works completely in Windows 7 or Vista 64 bit versions.

There is more discussion here:
[url]http://www.mersenneforum.org/showpost.php?p=275440&postcount=77[/url]

I currently run three instances of mfaktc, so there are three slightly different command lines to set different core affinities.

The command lines are:

cmd.exe /k "start /b /low /affinity 0x20 mfaktc-win-64.exe"

cmd.exe /k "start /b /low /affinity 0x10 mfaktc-win-64.exe"

cmd.exe /k "start /b /low /affinity 0x08 mfaktc-win-64.exe"

These run mfaktc on cores 4,5, and 6. As you can see, the core affinities are specified by the hex values. Core numbering starts with 0.

I have intended to set up a batch which would start all of these together, but my initial attempts did not work correctly. At the moment I run three different batch files.

My machine remains fairly usable in most situations with the following settings in mfaktc.ini:

NumStreams=3
CPUStreams=3
GridSize=3
AllowSleep=1

AllowSleep=1 frees a small amount of CPU time on the three cores which are feeding mfaktc. Reducing NumStreams to 2 makes the system more responsive without too much impact on mfaktc performance. Reducing GridSize to 2, or even 1, improves responsiveness a lot, but at considerable cost to mfaktc.

For gaming you are probably better off just stopping mfaktc. Unlike P-1 factoring in P95, there does not seem to be a large penalty in restarting it.

[QUOTE=kladner;279843]The command lines are:

cmd.exe /k "start /b /low /affinity 0x20 mfaktc-win-64.exe"

cmd.exe /k "start /b /low /affinity 0x10 mfaktc-win-64.exe"

cmd.exe /k "start /b /low /affinity 0x08 mfaktc-win-64.exe"

These run mfaktc on cores 4,5, and 6. As you can see, the core affinities are specified by the hex values. Core numbering starts with 0.

I have intended to set up a batch which would start all of these together, but my initial attempts did not work correctly. At the moment I run three different batch files.
[/QUOTE]

On my WinXP machine I run a batch for starting 8 instances of LLRnet in different directories like this:

[code]
@echo off
start "LLRnet Client1" /DLLRnet1 do.bat
start "LLRnet Client2" /DLLRnet2 do.bat
start "LLRnet Client3" /DLLRnet3 do.bat
rem (...) more clients analogous
exit
[/code]

So the batch starts all LLRnet clients in an own DOS-Box and will close itself.

The do.bat's in those directories are starting every LLRnet client and could be other programs, too.

[QUOTE=kar_bon;279849]On my WinXP machine I run a batch for starting 8 instances of LLRnet in different directories like this:

[code]
@echo off
start "LLRnet Client1" /DLLRnet1 do.bat
start "LLRnet Client2" /DLLRnet2 do.bat
start "LLRnet Client3" /DLLRnet3 do.bat
rem (...) more clients analogous
exit
[/code]So the batch starts all LLRnet clients in an own DOS-Box and will close itself.
[/QUOTE]

Thanks, kar_bon! When I attempted this I was using the "Call" command to start the individual batch files. This caused the master batch to stop and wait after the first batch. I'll try using "Start".
...............

And indeed, using "start" did the trick!
Thanks, again!

Hello!

[QUOTE=PsycO;279661]But i have done a hardware hack to be able to plug it in a 2xPCI-e, so maybe the transfert rate are for something here.[/QUOTE]

PCIe 2x? Assuming worst case (2.5GT/s) that is 500MB/sec, with 80% bandwidth efficiency this is enough for 100M FCs per second.

[QUOTE=PsycO;279661]If you are interested in a GUI for mfaktc/o, let me know, i will be please to make a universal launcher, for win and linux, that will handle the configuration and launching of the exe. It will detect the number of core and deal with the cmdline options. So let me know if someone is interested, i will be please to participate to the project!![/QUOTE]

Well, why not giving a try? To be honest I don't think that I'll use that GUI but other users might have a different opinion. :blush:

[QUOTE=PsycO;279661]Another question is, does mfaktc do a lot of IO, on a temp file or to save backup??[/QUOTE]
If enabled mfaktc writes a checkpoint file every time a class is finished. The file is ~50 bytes big. [B]Perhaps[/B] I should add a minimum delay between two checkpoint writes (e.g. 30 seconds or so).

[QUOTE=PsycO;279661]A last thing, for the pause button of the keyboard, do you know pressing the button issue what signal to windows(the shell)?? I wanna know that, this will surely have utility in one of my future project!!![/QUOTE]
Does the pause key work for you? Anyway I'll see if there is a simple [B]and[/B] save way to do so.

Oliver

[QUOTE=TheJudger;279880]If enabled mfaktc writes a checkpoint file every time a class is finished. The file is ~50 bytes big. [B]Perhaps[/B] I should add a minimum delay between two checkpoint writes (e.g. 30 seconds or so).[/QUOTE]:surprised
No perhaps, please(!) add in some code to limit the frequency of writing checkpoint files! I didn't realize such murderous I/O was involved. Not in number of bytes written, but in number of writes. I'd suggest making it .ini configurable with a default interval of 60 seconds, maybe even 300 seconds. Nobody's going to care if they lost one minute of work (it'll take that long to notice and restart mfaktc anyway), it's where the assignment has been running many hours that you care about losing work.

[QUOTE]No perhaps, please(!) add in some code to limit the frequency of writing checkpoint files! I didn't realize such murderous I/O was involved. Not in number of bytes written, but in number of writes. I'd suggest making it .ini configurable with a default interval of 60 seconds, maybe even 300 seconds.[/QUOTE]I'm totally with James Heinrich for this point, a delay of 300 sec or like then write at the beginning of the next class will be enough. Just make a thread that will do the job, this will eliminate code in the loop!! Less code in loop == faster code!!!:smile: Just eliminating these IO's will speed up the app a lots! IO's are very consuming!!
[QUOTE]PCIe 2x? Assuming worst case (2.5GT/s) that is 500MB/sec, with 80% bandwidth efficiency this is enough for 100M FCs per second.[/QUOTE]Perfect, this elimitate one of my potential bottleneck!
[QUOTE]Well, why not giving a try? To be honest I don't think that I'll use that GUI but other users might have a different opinion. :blush:[/QUOTE]As i see from you and the others, nobody really want it, so i'll not waste my time! If you have somethings else i can do in Python/Tk, let me know. I have a base in C that is enough to review correct already done code, but not enough to make complex things.
If i can know the info's about Primenet protocol's, i can write a module that will deal with it! Maybe with this feature, the GUI will worth the time to make it!
[QUOTE]Does the pause key work for you? Anyway I'll see if there is a simple [B]and[/B] save way to do so.[/QUOTE]Don't waste your time, the pause button pause the app in the second, freeing available resource to play a game or whatever else, and after, press start and the app restart where it left without any problem!! No need to implement a function to do it! If a control is needed in the future, just find the control char that represent the pause on the keyboard and write it to the stdin of the console!

[QUOTE=PsycO;279905]
If i can know the info's about Primenet protocol's, i can write a module that will deal with it! Maybe with this feature, the GUI will worth the time to make it!
[/QUOTE]
Is [URL="http://v5.mersenne.org/v5design/v5webAPI_0.97.html"]this[/URL] what you were referring to?

[QUOTE=TheJudger;279880]If enabled mfaktc writes a checkpoint file every time a class is finished. The file is ~50 bytes ...[/QUOTE]

That's good to know, which begs the next question. Is a checkpoint file written when a ctrl-c (break) is invoked?

(I can afford to take the 30-60 minute lost processing [on rare occasions] to gain a few percentage points in processing. My power situation is fairly stable.)

[QUOTE=kladner;279843]
cmd.exe /k "start /b /low /affinity 0x20 mfaktc-win-64.exe"
etc <snip>[/QUOTE]
you don't really need to make it so complicate, unless you want to specify express which CPU core is used for which copy, and which copy to run on which GPU, etc, the -d switch works perfectly in mfaktc. I use something like:

mfaktc1 -d 0
mfaktc2 -d 0
mfaktc3 -d 0
mfaktc4 -d 1
mfaktc5 -d 1
mfaktc6 -d 1

to launch 6 copies of mfaktc on two GPU's, win7 is enough intelligent to split the CPU burden. The 6 mfaktcX.exe are all identical copies of mfaktc-win-64.exe, placed in different subfolders, each with its own ini and worktodo file. The advantage is that I can customize better the inputs, adding work only to the thread that need (they are not always running at the same speed, depending on the assignments and the CPU/GPU burden for the daily real-life job). The input files can be customized in the ini file, so they can all be in the parent folder, and you don't need to walk to each subfolder to add work. Just look at their size in explorer/totalcmd and you know which one is ready to go dry. Renaming the exe files has also the advantage that you know in every moment what copy of mfaktc does what, because the name appears in the title of the cmdprompt window. Of course this can also be realized on your version if you add the "title" parameter for "start" command (there is an additional parameter where you can specify window's title). The disadvantage of my method is that the results files will be in the subfolders. This can not be (yet) customized in the ini files. But for that I made a batch file to collect all the result.txt from subfolders, so I don't need to walk on each subfolder and look for them.

[QUOTE=Dubslow;279909]Is [URL="http://v5.mersenne.org/v5design/v5webAPI_0.97.html"]this[/URL] what you were referring to?[/QUOTE]
Yes this is exactly what i was referring to!!!
But... Woaaaaaaa, tons of work here!!! The server is really complete!!!
Feasable, but i need to know if integration to Prime95 is planned, on a medium time scale, or in the next year??? If not, the project is interesting....
[B]TheJudger: [/B]Do you have talked to Woltman on a possible integration??? And do you are the CUDALucas develloper(For permission)?? As they are develloped for the same goal, the ability to crunch for mersenne on GPU, if i make GUI with primenet integration, i will surely integrate them all(mfaktc, mfakto, CUDALucas)!!!

[QUOTE=LaurV;279922]you don't really need to make it so complicate, unless you want to specify express which CPU core is used for which copy, and which copy to run on which GPU, etc,[snip][/QUOTE]

I do have such concerns. Since I'm splitting up a 1090T between mfaktc and P95, I want to lock down the affinities. Two of the switches in the line (/k and /b) result in a single prompt window for each instance of mfaktc, which will stay open if worktodo.txt should happen to run dry. /low sets priority, at least for the CPU work involved in mfaktc. The other part of these settings is in the .ini. I have these settings there:
[CODE]NumStreams=3
CPUStreams=3
GridSize=3
AllowSleep=1[/CODE]All this helps noticeably with usability for the computer for other tasks.


[QUOTE=LaurV;279922]The disadvantage of my method is that the results files will be in the subfolders. This can not be (yet) customized in the ini files. But for that I made a batch file to collect all the result.txt from subfolders, so I don't need to walk on each subfolder and look for them.[/QUOTE]

I would be grateful for an example of such a batch. It sounds very convenient indeed.

[QUOTE=PsycO;279924]Yes this is exactly what i was referring to!!!
But... Woaaaaaaa, tons of work here!!! The server is really complete!!!
Feasable, but i need to know if integration to Prime95 is planned, on a medium time scale, or in the next year??? If not, the project is interesting....
[B]TheJudger: [/B]Do you have talked to Woltman on a possible integration??? And do you are the CUDALucas develloper(For permission)?? As they are develloped for the same goal, the ability to crunch for mersenne on GPU, if i make GUI with primenet integration, i will surely integrate them all(mfaktc, mfakto, CUDALucas)!!![/QUOTE]
If you mean making mfaktc capable of 'talking' to PrimeNet and automatically collecting assignments, that is already in the works. Ask Christenson if you really want to help there. As for integration, there is much work to be done yet before mfaktc is fully mature, and correct me if I'm wrong The Judger and Prime95, but I doubt it will be done in the next year.

Is there any way to share multiple instances in one folder?

[QUOTE=Xyzzy;279928]Is there any way to share multiple instances in one folder?[/QUOTE]
Not really, or I don't know any. The problem is that all copies need to access and modify the first line of worktodo.txt, and it would be very easy to result in conflicts, as missing an intermediary bit level, a complete assignment line, or duplicating the same work on different instances. To specify a different worktodo for each copy you could modify the ini file, but then you will need different ini files for each copy, so we are in a vicious circle here. But this is not a problem. The solution with subfolders works ok.

[QUOTE=James Heinrich;279886]
No perhaps, please(!) add in some code to limit the frequency of writing checkpoint files![/QUOTE]
OK, added to my todo-list.

[QUOTE=RichD;279914]That's good to know, which begs the next question. Is a checkpoint file written when a ctrl-c (break) is invoked?[/QUOTE]

up to mfaktc 0.17: no!
mfaktc 0.18: 1st ^C pressed: finish the current class write a checkpoint and exit. 2nd ^C pressed: exit now (like older versions)
I don't have plans for checkpoints within a class.

[QUOTE=Xyzzy;279928]Is there any way to share multiple instances in one folder?[/QUOTE]
Not on my todo-list. It would be easy to add such a basic functionality but I guess that this increases the chance that a user unintentional runs two instances on the same data.

[QUOTE=PsycO;279924]Do you have talked to Woltman on a possible integration??? And do you are the CUDALucas develloper(For permission)??[/QUOTE]
Yes, possible but AFAIK no concrete plan yet.
No to the second question.


Oliver