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: