[QUOTE=Bdot;345452]But you need to keep going and find another bug :smile:[/QUOTE]
I'm trying, but mfakto runs so stable and fast now. My production went up with [SIZE=3]50%[/SIZE] with the new software. :tu:

It's a bit slow on lower bitlevels (2^66), runs really fast on double check assignments ( 200-210 GHzd/d ) and a bit slower on the LL front ( 140-170 GHzd/d ).
But then I haven't taken the time to optimize the settings in the ini-file for the different assignments.

/Göran

Overnight test: I am taking the 22420 exponents in 335M range from 65 to 66 bits. Testing a rig with 2xHD7970, 12 workers (is there any "less classes" version of mfakto available? so I won't need to start so many workers to max the GPUs? because this is wasting a lot of time printing, I think...-- it prints that line of text 960 times every 3 seconds!). With an average of 3.2 seconds per exponent, it would take about 20 hours. Stay away from 335M tonight (next 20 hours).

[QUOTE=LaurV;346658]Overnight test: I am taking the 22420 exponents in 335M range from 65 to 66 bits. Testing a rig with 2xHD7970, 12 workers (is there any "less classes" version of mfakto available? so I won't need to start so many workers to max the GPUs? because this is wasting a lot of time printing, I think...-- it prints that line of text 960 times every 3 seconds!). With an average of 3.2 seconds per exponent, it would take about 20 hours. Stay away from 335M tonight (next 20 hours).[/QUOTE]

Got another one I see, nice :razz:


[SIZE="1"](no bother, but I am still curious about [URL="http://mersenneforum.org/showpost.php?p=344429&postcount=828"]this[/URL] only if you have time... two quick ones (low bit level I guess) is fine...)[/SIZE]

[QUOTE=kracker;346661]Got another one I see, nice :razz:


[SIZE=1](no bother, but I am still curious about [URL="http://mersenneforum.org/showpost.php?p=344429&postcount=828"]this[/URL] only if you have time... two quick ones (low bit level I guess) is fine...)[/SIZE][/QUOTE]
I already replied to that (not only once) in the [URL="http://mersenneforum.org/showpost.php?p=344607&postcount=840"]subsequent[/URL] posts. Currently is 13.6 which at the time of installation was a beta (didn't check AMD page after). Between 420 and 440 GHzD/D in LL/DC ranges. The drop (to 390) is normal, see following discussions.

P.S. finished 655 exponents and got 10 factors, which fits amazingly well in the theory about having 1 factor of 65 bits in every 65 or 66 exponents (this is "untouched domain", i.e no selective TF or P-1 was done to eliminate exponents, so the ratio should keep nicely). My hopes to infirm the theory are gone... :razz:

12:35 AM here. Going to bed... nighty night...

[QUOTE=LaurV;346658]is there any "less classes" version of mfakto available? [/QUOTE]
No, there's not. When I started the porting effort, I skipped that to save effort. Since then, the request for it was not overwhelming ...
You can probably save a few microseconds CPU time by trimming ProgressHeader and ProgressFormat to the absolute minimum you need (a fix single-letter string would be fastest) and setting Verbosity=0 to save another few lines output.

But I think that printing is not the majority of overhead - it's rather the per-class-initialization of the kernels. That is not solvable witht the current version of mfakto.

OpenCL 2.0 [URL="http://www.khronos.org/opencl/"]announced[/URL]... see anything interesting? :smile:

Just a note that, on catalyst 13.8 beta mfakto does not run at all,at selftest the driver crashes and I have to hard reset. :no:

yes with the 13.8 beta i cant do nothing.
at selftest you will see a drivercrash.
( i hate ati/amd drivers all ) grrrrrrrrrr

[QUOTE=NormanRKN;347991]yes with the 13.8 beta i cant do nothing.
at selftest you will see a drivercrash.
( i hate ati/amd drivers all ) grrrrrrrrrr[/QUOTE]
Well, they *are* beta. Might want to roll back as I :smile:

yes, beta is relativ ;)
i switched back to the olders.

I'm a little confused by this error message:

[CODE]got assignment: exp=4027913 bit_min=63 bit_max=64 (0.46 GHz-days)
WARNING: SievePrimes is too big for the current assignment, lowering to 284998
It is not allowed to sieve primes which are equal or bigger than the
exponent itself![/CODE]

How was the new limit of 284998 calculated? Note the exponent = 4027913. I had attempted to do a SP of 1000000.

[QUOTE=Jayder;348381]I'm a little confused by this error message:

[CODE]got assignment: exp=4027913 bit_min=63 bit_max=64 (0.46 GHz-days)
WARNING: SievePrimes is too big for the current assignment, lowering to 284998
It is not allowed to sieve primes which are equal or bigger than the
exponent itself![/CODE]

How was the new limit of 284998 calculated? Note the exponent = 4027913. I had attempted to do a SP of 1000000.[/QUOTE]

#primes < 4027913 = 284999. I guess, it is excluding 2 as well, hence 284998.

Oh, duh. I was just interpreting the error message in the stupidest way possible.

Thanks for the quick response.

I hacked up something for the automatic assignment handling, as I could not find anything else that worked. It's not perfect, but works for me:

[URL]https://github.com/teknohog/primetools[/URL]

Oh, and thanks for all the great work on mfakto :)

[QUOTE=TeknoHog;350510]I hacked up something for the automatic assignment handling, as I could not find anything else that worked. It's not perfect, but works for me:

[URL]https://github.com/teknohog/primetools[/URL]

Oh, and thanks for all the great work on mfakto :)[/QUOTE]
Interesting. So is this a python script for submitting results?

P.S.: You might want to check out misfit.

[QUOTE=kracker;350511]So is this a python script for submitting results?

P.S.: You might want to check out misfit.[/QUOTE]

Wow, I didn't know about misfit, but it wouldn't really help me anyway as I use Linux. Mine is just a command-line Python script.

[QUOTE=kracker;347982]Just a note that, on catalyst 13.8 beta mfakto does not run at all,at selftest the driver crashes and I have to hard reset. :no:[/QUOTE]

Just noticed the same on 13.8_beta2 that came with the latest Gentoo updates. It crashed upon restarting mfakto, when the old drivers were still running :huh:

EDIT: downgraded to 13.6_beta while running 13.8_beta2, and mfakto runs just fine again...

[QUOTE=TeknoHog;350510]I hacked up something for the automatic assignment handling, as I could not find anything else that worked. It's not perfect, but works for me:

[URL]https://github.com/teknohog/primetools[/URL]

Oh, and thanks for all the great work on mfakto :)[/QUOTE]

Hi,

I just had a quick look over your script, and I'm quite interested in using it as I'm running a number of Linux machines too.

I'd like to refer you to [URL="http://www.mersenneforum.org/showpost.php?p=319728&postcount=53"]this[/URL] post where I briefly explained the file locking that mfakto uses for worktodo and results files. (details in [URL="https://github.com/Bdot42/mfakto/blob/master/src/filelocking.c"]filelocking.c[/URL] :smile:) This should help for directly accessing the files while mfakto is running.

Regarding the latest driver issue, I think I need to report this to AMD ... :rolleyes:.

[QUOTE=Bdot;351021]
I just had a quick look over your script, and I'm quite interested in using it as I'm running a number of Linux machines too.

I'd like to refer you to [URL="http://www.mersenneforum.org/showpost.php?p=319728&postcount=53"]this[/URL] post where I briefly explained the file locking that mfakto uses for worktodo and results files. (details in [URL="https://github.com/Bdot42/mfakto/blob/master/src/filelocking.c"]filelocking.c[/URL] :smile:) This should help for directly accessing the files while mfakto is running.
[/QUOTE]

Thanks! I'll try to implement this, shouldn't be too hard :smile:

[QUOTE=TeknoHog;351027]I'll try to implement this, shouldn't be too hard :smile:[/QUOTE]

[URL]https://github.com/teknohog/primetools/blob/master/mfloop.py[/URL]

[QUOTE=TeknoHog;351038][URL]https://github.com/teknohog/primetools/blob/master/mfloop.py[/URL][/QUOTE]

Hmm, I think this approach has a timing issue as the lockfile testing and creation are not atomically.

I'm not really fluent in python, but from what I've just read, fd = os.open(lockfile, O_CREAT | O_EXCL) should do the trick. Iff it returns a positive number, then you got the lock (and can os.close(fd) and remove(lockfile) when done writing).

[QUOTE=Bdot;351206]Hmm, I think this approach has a timing issue as the lockfile testing and creation are not atomically.

I'm not really fluent in python, but from what I've just read, fd = os.open(lockfile, O_CREAT | O_EXCL) should do the trick. Iff it returns a positive number, then you got the lock (and can os.close(fd) and remove(lockfile) when done writing).[/QUOTE]

Thanks. It wasn't quite as simple in Python, but the basic idea works, now updated in Github.

Is there such as thing as mfakto for exponents <2M? Or do we have to run those on CPU?

There is a mfakt[COLOR=Red][B][U]c[/U][/B][/COLOR] for exponents between 2k and 1M, few of us use it but it is not "distributable", you have to ask Oliver for it. The reasons are multiple, first of all the work is not really needed, considering how much ECM that range had, there would be no factor to 2^100 or 2^180 bits or so (depending on the expo), except eventual ECM misses. Second, is slower (because not much optimization was put into it, and it doesn't really fit for expo/bitlevlel/classes on the mentioned range) - you better use your resources to do faster work on the LLTF front - that work is more needed. Again, due to the qty of ECM done, your chances to find factors at 60-70 bits (20-25digits) is minuscule, almost null. Third, only "trusted" people should report "no factors" in that range. Most probably the bitlevels will not be visited ever, and a missing factor would be missed forever (this is more of an "emotional/subjective" consequence, it has no "objective" negative impact, but you know how people are :razz:).

Okay. So is it a problem if my CPU runs them if I'm not "trusted" then?

[QUOTE=blahpy;351613]Okay. So is it a problem if my CPU runs them if I'm not "trusted" then?[/QUOTE]
Hehe, for sure there is no problem![B] You do what kind of work you like[/B]. OTOH, P95 is a bit "safer" in reporting the results, compared with mfaktc, where some teenager eager for credits can just edit the text file and send false results. With P95 one must have at least some knowledge of computing those checksums, and people with knowledge are generally more "mature" in their thinking. My opinion. One who knows, what and how, would not risk his reputation for few GHDays of credit.

[QUOTE=blahpy;351589]Is there such as thing as mfakto for exponents <2M? Or do we have to run those on CPU?[/QUOTE]

Perfect agreement to LaurV, just a little addition: Last time I checked (a few minutes ago), mfakto was accepting exponents >1M (and prime). So for your question about exponents <2M, you have at least half an answer :smile:.

Still, LaurV's comments about usefulness apply.
[code]
./mfakto -tf 1036769 70 71
...
got assignment: exp=1036769 bit_min=70 bit_max=71 ([B]230.65 GHz-days[/B])
Starting trial factoring M1036769 from 2^70 to 2^71 (230.65GHz-days)
Using GPU kernel "cl_barrett32_77"
No checkpoint file "M1036769.ckp" found.
^C
mfakto will exit once the current class is finished.
press ^C again to exit immediately
^Cmfakto will exit NOW!
[/code]Towards 2M, there are exponents TF'd to "only" 63, with less ECM. There you'd start with ~1GHz-days for the first bitlevel.

Uh-oh, I've developed a problem with my combination of MFAKTO x64 0.13 and the AMD Radeon 7770.

Ever since yesterday, it's been crashing periodically. At first I was getting only messages indicating that the AMD driver had crashed, but today I'm also getting notifications of "application crashes." Here is what the latest such notification looks like:

[B][SIZE=1][COLOR=#0066cc][SIZE=1][COLOR=#0066cc]Problem signature:[/COLOR][/SIZE][/COLOR][/SIZE][/B]
[SIZE=1]Problem Event Name: APPCRASH[/SIZE]
[SIZE=1]Application Name: mfakto_x64.exe[/SIZE]
[SIZE=1]Application Version: 0.0.0.0[/SIZE]
[SIZE=1]Application Timestamp: 5199fc1c[/SIZE]
[SIZE=1]Fault Module Name: amdocl64.dll[/SIZE]
[SIZE=1]Fault Module Version: 10.0.1016.4[/SIZE]
[SIZE=1]Fault Module Timestamp: 5065fc35[/SIZE]
[SIZE=1]Exception Code: c0000005[/SIZE]
[SIZE=1]Exception Offset: 0000000000f5102d[/SIZE]
[SIZE=1]OS Version: 6.1.7601.2.1.0.768.3[/SIZE]
[SIZE=1]Locale ID: 1033[/SIZE]

[SIZE=1][SIZE=2](There are 4 "Additional Information" lines containing long strings. I have removed them in case they pose a privacy issue -- don't know enough about this sort of thing to tell -- but will be happy to put them back in if assured that there's no risk.)[/SIZE]

[SIZE=2]The only possible causes I can think of are:[/SIZE]

[SIZE=2]1) It's been hot around here lately, so the GPU is overheating. (The PC is in the basement.)[/SIZE]

[SIZE=2]2) Something in the GPU is going bad after 8 months of 24/7 operation.[/SIZE]

[SIZE=2]Monitoring by GPU-Z indicates that GPU temps reach 79C, although GPU load is only 2% and the fan speed reaches only 46% of capacity at ~2545 RPM. The last time it crashed, it had been running for just 15 minutes.[/SIZE]

[SIZE=2]Any thoughts? Should I try MFAKTO x32 0.13 or 0.12 (either one) to see what happens? Another thing that comes to mind is to open up the case and see if the inside needs dusting.[/SIZE]

[SIZE=2]Thanks in advance for any clues or advice.[/SIZE]

[SIZE=2]Rodrigo[/SIZE]

[/SIZE]

Have you tried shutting it down for a bit and rebooting? I see 24/7 so not sure if that is what you do sometimes...

Normally (like now) I keep a ton of browser windows open (25 at the moment). Last reboot was for the Windows Updates for August.

Maybe I should close down all those windows and reboot, what do you think?

Rodrigo

[QUOTE=Rodrigo;351814]Normally (like now) I keep a ton of browser windows open (25 at the moment). Last reboot was for the Windows Updates for August.

Maybe I should close down all those windows and reboot, what do you think?

Rodrigo[/QUOTE]

I suggest rebooting first: I've seen the issue of high temps with no load as well, after the driver crashed. Although windows re-inits the graphics driver after a driver crash, that re-init does not seem to be sufficient.

Second guess is, that due to dust or high ambient temps, the current level of overclocking may cause GPU temps to raise too much. Either manually set the fan speed to 60-75%, or reduce the clock speed a bit. I have never understood why the GPU rather fries itself instead of increasing the fan speed above 50% in automatic mode.

BTW: the crash also points to [SIZE=1]amdocl64.dll[/SIZE], i.e. the AMD OpenCL driver.

[QUOTE=Bdot;351852][SNIP]
Either manually set the fan speed to 60-75%, or reduce the clock speed a bit. [B][U]I have never understood why the GPU rather fries itself instead of increasing the fan speed above 50% in automatic mode.[/U][/B][/QUOTE]

This seems to happen with Nvidia GPUs, too, if you don't set a custom fan curve.

[QUOTE=Bdot;351852]I suggest rebooting first: I've seen the issue of high temps with no load as well, after the driver crashed. Although windows re-inits the graphics driver after a driver crash, that re-init does not seem to be sufficient.

Second guess is, that due to dust or high ambient temps, the current level of overclocking may cause GPU temps to raise too much. Either manually set the fan speed to 60-75%, or reduce the clock speed a bit. I have never understood why the GPU rather fries itself instead of increasing the fan speed above 50% in automatic mode.

BTW: the crash also points to [SIZE=1]amdocl64.dll[/SIZE], i.e. the AMD OpenCL driver.[/QUOTE]
Is there an online guide to manually setting the GPU fan speed, that you can recommend? The AMD Catalyst Control Center doesn't seem to have anything like that, at least not labeled that way.

All my settings are as they came from the vendor (I haven't done any overclocking).

Regarding the reboot -- I'll do that as soon as I finish clearing out all my browser windows. :smile:

Thanks very much.

Rodrigo

[QUOTE=Rodrigo;351905]Is there an online guide to manually setting the GPU fan speed, that you can recommend? The AMD Catalyst Control Center doesn't seem to have anything like that, at least not labeled that way.

All my settings are as they came from the vendor (I haven't done any overclocking).

Regarding the reboot -- I'll do that as soon as I finish clearing out all my browser windows. :smile:

Thanks very much.
Rodrigo[/QUOTE]

I don't have an AMD setup to refer to, but I would look into the Catalyst Control Center to see if there are fan adjustments there.

The weather broke yesterday as we enter an autumn pattern, and so the temperature in my cave has dropped enough to where the problem isn't happening any more.

I don't know whether to feel relieved that the problem stopped, or frustrated that I can't troubleshoot it!

FWIW, I couldn't find any settings in the Catalyst Control Center that are clearly intended for manual fan speed control. Maybe they're in there, but I went through every setting and there's no reference to fans or their speed.

Rodrigo

Oh well. I had hopes you would find something for the fans. I'm glad the trouble has subsided, at least. With all the nVidia control apps out there it is rather strange that nobody has cooked something up for AMD/ATI.

[QUOTE=kladner;352022]Oh well. I had hopes you would find something for the fans. I'm glad the trouble has subsided, at least. With all the nVidia control apps out there it is rather strange that nobody has cooked something up for AMD/ATI.[/QUOTE]

On my HD 7770 in Catalyst CC there [B]is[/B] a fan control option... also MSI afterburner works very well.

[B]I[/B]IRC, (and it has been a while):
(1) some AMD cards don't allow manual fan adjustment via CCC and
(2) one needs to activate 'AMD OverDrive' under the performance section for the manual fan control to be exposed on those cards that support it.

[QUOTE=kracker;352023]On my HD 7770 in Catalyst CC there [B]is[/B] a fan control option... also MSI afterburner works very well.[/QUOTE]

I had no idea that Afterburner worked cross-platform. Thanks!

[QUOTE=sdbardwick;352024][B]I[/B]IRC, (and it has been a while):
(1) some AMD cards don't allow manual fan adjustment via CCC and
(2) one needs to activate 'AMD OverDrive' under the performance section for the manual fan control to be exposed on those cards that support it.[/QUOTE]

#2 makes sense. I am only running GeForce right now, but it is always good to know what works. Thanks!

[QUOTE=kracker;352023]On my HD 7770 in Catalyst CC there [B]is[/B] a fan control option... also MSI afterburner works very well.[/QUOTE]

What's the sequence of choices/clicks to get to the fan control option?

(A --> B --> C --> D)

Rodrigo

[QUOTE=Rodrigo;352180]What's the sequence of choices/clicks to get to the fan control option?

(A --> B --> C --> D)

Rodrigo[/QUOTE]
Right now, I am not at home so I can't say. But if you don't see it, MSI Afterburner works very well.

In Afterburner you go to the Settings (red circle). In Settings, go to the Fan tab and check "Enable user defined....." Click on points to drag them, or on the line to add a point. Hit Delete to remove a selected point. Click OK.

Back on the main control panel, note that User Define is selected (green circle) and the speed control is surrounded by a green box. If desired, you can uncheck the Auto button, also in the circle, and drag the fan slider to set speed manually. You must press the Apply button for this to take effect.

There are many more setting possible in Afterburner. You can customize the Monitor panel and choose what parameters are displayed. You can set the range of these parameters. Note that if you want your settings to be applied at every startup, you must enable the "Apply overclocking at system startup" item at the lower left of the main panel, [B][U]and[/U][/B] check "Start with Windows" on the General tab of the Settings.

If you click on a numerical parameter on the main panel, you can enter desired numbers. Press Enter key, and click Apply button to put the change into effect. Pressing the Reset button at the bottom sets all values to defaults, including fan control. Click on User Define to re-enable your custom fan curve. "Default" means factory settings for your particular card, including factory OC.

[QUOTE=Rodrigo;352180]What's the sequence of choices/clicks to get to the fan control option?

(A --> B --> C --> D)

Rodrigo[/QUOTE]
[LIST=1][*] Start "AMD VISION Engine Control Center"[*] On the left pane, click "Performance"[SUP]*[/SUP][*]In the opened sub-menu select "AMD Overdrive"[*]In the right pane, activate "AMD OverDrive"[SUP]*[/SUP] and then "Graphics OverDrive"[SUP]*[/SUP][*]In the left pane, select the "Graphics OverDrive" sub-menu[*]In the right pane, check "activate manual fan control"[SUP]*[/SUP][*]Adjust the corresponding slider to your needs[*]Click "Apply"[SUP]*[/SUP][/LIST][SUP]*[/SUP] The wording might be slightly different as I translated my German UI ...

Isn't that easy? :smile:

Edit: Maybe you can skip this all and just remove the thick dust layer - [URL="http://mersenneforum.org/showpost.php?p=306284&postcount=503"]helped my card a lot[/URL].

[QUOTE=kladner;352199]In Afterburner you go to the Settings (red circle). In Settings, go to the Fan tab and check "Enable user defined....." Click on points to drag them, or on the line to add a point. Hit Delete to remove a selected point. Click OK.

Back on the main control panel, note that User Define is selected (green circle) and the speed control is surrounded by a green box. If desired, you can uncheck the Auto button, also in the circle, and drag the fan slider to set speed manually. You must press the Apply button for this to take effect.

There are many more setting possible in Afterburner. You can customize the Monitor panel and choose what parameters are displayed. You can set the range of these parameters. Note that if you want your settings to be applied at every startup, you must enable the "Apply overclocking at system startup" item at the lower left of the main panel, [B][U]and[/U][/B] check "Start with Windows" on the General tab of the Settings.

If you click on a numerical parameter on the main panel, you can enter desired numbers. Press Enter key, and click Apply button to put the change into effect. Pressing the Reset button at the bottom sets all values to defaults, including fan control. Click on User Define to re-enable your custom fan curve. "Default" means factory settings for your particular card, including factory OC.[/QUOTE]
That's interesting, thanks! Does the MSI Afterburner work on (1) AMD cards (2) that were not not made by MSI?

Rodrigo

[QUOTE=Bdot;352255][LIST=1][*]Start "AMD VISION Engine Control Center"[*]On the left pane, click "Performance"[SUP]*[/SUP][*]In the opened sub-menu select "AMD Overdrive"[*]In the right pane, activate "AMD OverDrive"[SUP]*[/SUP] and then "Graphics OverDrive"[SUP]*[/SUP][*]In the left pane, select the "Graphics OverDrive" sub-menu[*]In the right pane, check "activate manual fan control"[SUP]*[/SUP][*]Adjust the corresponding slider to your needs[*]Click "Apply"[SUP]*[/SUP][/LIST][SUP]*[/SUP] The wording might be slightly different as I translated my German UI ...

Isn't that easy? :smile:

Edit: Maybe you can skip this all and just remove the thick dust layer - [URL="http://mersenneforum.org/showpost.php?p=306284&postcount=503"]helped my card a lot[/URL].[/QUOTE]

Fortunately, the weather's turned cool and the problem hasn't come back (yet). But it won't hurt to open the case and look around...

Now, I don't seem to have this AMD Vision Engine Control Center. The only thing I have that's AMD-related is the Catalyst Control Center, which of course doesn't have any of the settings you describe. :unsure:

Rodrigo

[QUOTE=Rodrigo;352273]That's interesting, thanks! Does the MSI Afterburner work on (1) AMD cards (2) that were not not made by MSI?

Rodrigo[/QUOTE]

I have Kracker's word that it works on AMD, but no personal experience.

On nVidia GPUs, it definitely works with cards other than MSI. I am using it with a Gigabyte and an Asus as I write.

Wow, that MSI Afterburner is VERY cool. :cool: And it did enable me to control the AMD Radeon 7770's fan manually. First time I ever heard it blowing!

Unfortunately, that didn't solve the problem (which came back today, with a vengeance -- the card wouldn't run for more than 5 minutes at a time before crashing, even with the fan whooshing). Next thing I did was to update the driver via AMD's website (Windows Device Manager kept claiming that my driver from a year ago was up to date). That, plus a reboot, does seem to have solved the problem, for now anyway.

The machine is still due for an interior dusting; that's coming soon.

Thanks guys for the advice and info.

Rodrigo

Glad to hear you got access to the controls. I hope you can resolve the crash problem. Indeed, dusting never hurts.

I just tried 12.10 with mfakto, still a no-go. [SIZE=1](however clLucas runs fine)[/SIZE]

There are noticeable speed differences between the bitlevels/kernels as most people may have noticed.

On my HD7950 with settings:
SieveOnGPU=1
GPUSievePrimes=82486
GPUSieveSize=64
GPUSieveProcessSize=16


2^65 - 2^68 gives ~250 GHzdays/day uses cl_barrett32_76 (more bitlevels at once)(horrible on 7xxx cards)(LMH range)
2^68 - 2^69 gives ~405 GHzdays/day uses cl_barrett15_69 (DC TF range)
2^69 - 2^70 gives ~365 GHzdays/day uses cl_barrett15_71 (DC TF range)
2^70 - 2^71 gives ~330 GHzdays/day uses cl_barrett15_73 (DC TF range)
2^71 - 2^72 gives ~330 GHzdays/day uses cl_barrett15_73 (LL TF range)
2^72 - 2^73 gives ~330 GHzdays/day uses cl_barrett15_73 (LL TF range)
2^73 - 2^74 gives ~295 GHzdays/day uses cl_barrett15_82 (LL TF range)

[QUOTE=VictordeHolland;355009]There are noticeable speed differences between the bitlevels/kernels as most people may have noticed.

On my HD7950 with settings:
SieveOnGPU=1
GPUSievePrimes=82486
GPUSieveSize=64
GPUSieveProcessSize=16


2^65 - 2^68 gives ~250 GHzdays/day uses cl_barrett32_76 (more bitlevels at once)(horrible on 7xxx cards)(LMH range)
2^68 - 2^69 gives ~405 GHzdays/day uses cl_barrett15_69 (DC TF range)
2^69 - 2^70 gives ~365 GHzdays/day uses cl_barrett15_71 (DC TF range)
2^70 - 2^71 gives ~330 GHzdays/day uses cl_barrett15_73 (DC TF range)
2^71 - 2^72 gives ~330 GHzdays/day uses cl_barrett15_73 (LL TF range)
2^72 - 2^73 gives ~330 GHzdays/day uses cl_barrett15_73 (LL TF range)
2^73 - 2^74 gives ~295 GHzdays/day uses cl_barrett15_82 (LL TF range)[/QUOTE]

Interesting. I'll have to try tuning for both DC and LL.

[SOLVED: the "Power Control Settings" had to be bumped up (currently at +10%) in AMD Overdrive, which is under the Performance tab in AMD's Catalyst Control Center software]

I'm seeing something odd.

Running a Trial Factor from 2^71 to 2^72

My GHzdays/day start out ~350.
About 30 seconds in it drops to ~320.
After another 30 seconds it drops to ~230.

My setup:[LIST][*]Radeon 7950 w/ boost (Sapphire 3L) @ stock clocks[*]AMD Catalyst 13.1[*]Windows 7 64-bit[*]mfakto-0.13: running mfakto_x64 with all default .ini settings except VectorSize=2 for GCN.[/LIST]
Sounds like I should be seeing around 300 GHzdays/day. I've tried changing various settings in the mfakto.ini, downclocking GPU to 800 MHz, clean installs of Catalyst 12.10, 13.1, 13.4, 13.9 and 13.11beta (both of the last two result in display driver resets). Nothing seems to keep me steady at 300 GHzd/d. None of the GPU-z sensors seem to change during the reductions either.

Any ideas?

My guess, thermals. Have you checked clocks, temperatures, etc wile running? It may be throttling.

[QUOTE=kracker;355957]My guess, thermals. Have you checked clocks, temperatures, etc wile running? It may be throttling.[/QUOTE]
Thanks for the reply. I found my issue and updated my message (2 posts up) with the answer. Now sitting at ~350 GHzd/d and steady.

Just for fun I tried compiling mfakto under Windows/Mingw/GCC.

[QUOTE=kracker;358327]Just for fun I tried compiling mfakto under Windows/Mingw/GCC.[/QUOTE]

That's strange ... I thought that the open()/close() file modes are defined by one or another gcc standard header. Either additional headers need to be included, or you'd need to switch to the windows branch of the code (try defining _MSC_VER to something that could mimic a recent MS compiler).

BTW, I managed to reproduce the high-CPU-load issue of the newer AMD drivers using a [URL="http://devgurus.amd.com/message/1301028"]rather simple test program[/URL] (still being moderated) - lets see if AMD has any help to offer. When copying the 13.1 amdocl64.dll into the test program's directory, it runs at 0.04% CPU.

[QUOTE=Bdot;358414]That's strange ... I thought that the open()/close() file modes are defined by one or another gcc standard header. Either additional headers need to be included, or you'd need to switch to the windows branch of the code (try defining _MSC_VER to something that could mimic a recent MS compiler).

BTW, I managed to reproduce the high-CPU-load issue of the newer AMD drivers using a [URL="http://devgurus.amd.com/message/1301028"]rather simple test program[/URL] (still being moderated) - lets see if AMD has any help to offer. When copying the 13.1 amdocl64.dll into the test program's directory, it runs at 0.04% CPU.[/QUOTE]

Good, I'll be very happy when they fix those two :smile:

After a long time of nothing... I finally got around to trying it again.

After a ton of warnings:

mfakto 0.14pre2 - for testing only
 

I can't access mersenneforum.org/mfakto at the moment, so I attached it here. Please give this one a try. Most important thing is that it should not abort nor make Catalyst die anymore. Second, when GPU-sieving, it reads a new config setting, FlushInterval. It determines after how many scheduled kernels it will wait for completion. Low values (1 .. 3) reduced the CPU load to almost zero, but lower values generally have a slightly lower throughput. 0 is unlimited which was the old behavior.

It also has a fix for a small memory leak (~0.5kB per assignment).

It is not yet completely tested - do not yet submit no-factor results to primenet.

Ah, and it tries to read a config setting, UseBinfile, which is not yet fully implemented - please ignore.

Will do :smile: I have 13.4 here, will test other computer with 13.10 later this weekend

EDIT:

AMD Catalyst 13.4

0.14p2=0.3-0.5% cpu, basic selftest pass.
0.13=crash

Catalyst 13.11 beta 9.4. Test case 2966/32927 for st2 and no failures so far. Looking good. :tu:

st2 passed perfectly. CPU usage at 0.6%. Would it be fine for me to use this version and report results with it?

[QUOTE=Jayder;361221]st2 passed perfectly. CPU usage at 0.6%. Would it be fine for me to use this version and report results with it?[/QUOTE]
Yes, for me it also passed amost all tests.

The only thing you must not use, is VectorSize=1. But this will fail the minimal selftest too anyway. And for AMD HW, there is no reason to not use Vectors.

Therefore I think it is safe to use this version.

OK, we are here now:
Windows XP 32 bits SP3 on a Pentium D extreme 3.4GHz, 4G RAM, fresh installation, all updates to the last. Amd Radeon HD 7970 ghz edition from XFX. Drivers 13.1 or 13.9 (both can be installed, not simultaneously, but "disk format" in between, it only takes few minutes for a clean winxp reinstallation). WinXP32 versions, both. None of them seem to install openCL.dll, which is missing when trying to run mfakto. Installing the SDK 2.5, or (alternatively) copying the dll file only, into windows/system32, will let mfakto (0.13, win 32) to run, but it will not be able to detect the GPU. So, every trial to run it without GPU sieving (or completely deleting the mfakto.ini file) will run perfectly but... falling bach to CPU, with only 1 [U]Meg[/U] Hz Days per Day or so. Trying to run it with GPU sieving results in this:

[CODE]mfakto 0.13-Win (32bit build)


Runtime options
Inifile mfakto.ini
Verbosity 1
SieveOnGPU yes
GPUSievePrimes 82486
GPUSieveSize 64Mi bits
GPUSieveProcessSize 16Ki bits
WorkFile worktodo.txt
ResultsFile results.txt
Checkpoints enabled
CheckpointDelay 300s
Stages enabled
StopAfterFactor class
PrintMode compact
V5UserID none
ComputerID none
TimeStampInResults no
VectorSize 2
GPUType AUTO
SmallExp no
Compiletime options
MORE_CLASSES enabled
Select device - GPU not found, fallback to CPU.
Get device info - Compiling kernels.

BUILD OUTPUT
.\common.cl(31): warning: unrecognized #pragma
#pragma "Enabling printf"
^

.\common.cl(41): warning: unrecognized #pragma
#pragma "Replacing popcount"
^

.\common.cl(91): warning: unrecognized #pragma
#pragma "Emulating amd_max3"
^

.\gpusieve.cl(95): warning: integer conversion resulted in a change of sign
1<<16, 1<<17, 1<<18, 1<<19, 1<<20, 1<<21,[/CODE](billions of errors follow). We guess the card is too new for those drivers, and we can not install newer sdk/etc because they are not running on that old OS. There is no way to linux or update the OS to win7 (pentium D, remember?) as this computer is dedicated to other things too.

Any idea? What are we doing wrong, what are we missing?

The card is installed in a PCIe20 slot (yes, this old mobo with socket 775 [U]has[/U] a pcie 2.0 slot!), and it runs ok through all the (other, non-mfakto) tests, including gaming, and it can also do scrypt-mining and folding-it without problems, which makes us think that the problem is in mfakto, except for the case we are doing something stupid..

mfakto's error could be that the package does not include all the OpenCL libs that could be required.
I'm not sure anymore if XP already had a system32 ... but the libs should be:

[B]"c:\Windows\System32\OpenCL.dll", amdocl.dll, amdocl_as32.exe, amdocl_ld32.exe

[/B]If these files were not installed by the Cat13.9 installation, then the installation did not succeed. Did it at least install [B]clinfo[/B]? It is a prerequisite for mfakto detecting the GPU that clinfo reports it:

[code]
C:\Users>which clinfo
clinfo:
[B]C:\Windows\system32\clinfo.EXE[/B]

C:\Users>clinfo
Number of platforms: 1
Platform Profile: FULL_PROFILE
Platform Version: OpenCL 1.2 AMD-APP (1348.4)
Platform Name: AMD Accelerated Parallel Processing
Platform Vendor: Advanced Micro Devices, Inc.
Platform Extensions: cl_khr_icd cl_amd_event_callback cl_amd_offline_devices cl_khr_d3d10_sharing cl_khr_d3d11_sharing cl_khr_dx9_media_sharing


Platform Name: AMD Accelerated Parallel Processing
Number of devices: 2
Device Type: CL_DEVICE_TYPE_GPU
Device ID: 4098
Board name: AMD Radeon HD 5700 Series
...
[/code]Maybe it's worth checking the Catalyst installation. It also provides a "manual" option where you can select OpenCL support (selected by default, but ...)

No idea if it is any good ... I took the mentioned files from my syswow64 folder (Cat13.11beta though) and loaded it to [URL="https://app.box.com/s/736s1k1it5mwqhe5pf5b"]box.com[/URL]. If you put them right next to mfakto, maybe it is loading them and happy with it. Apart from that, I don't have good suggestions.

Well, I did not understand your comment about the processor and Linux. AFAIK, there are still 32-bit-versions of recent distributions ([URL="http://software.opensuse.org/131/en"]SuSE[/URL], for instance), and the kernel dropped 386 support just a year ago ... Pentium probably will be supported a few more decades.

You could also check "the other (successful) tests" (furmark, sandra, ... ?) what their OpenCL test configuration reveals ... BTW, games do not count as they are are not usually using OpenCL (or do you have such a game?).

Just for the record, a Pentium D can run Win7 well or even the hated 8. (it has SSE2) But I know you said you couldn't upgrade anyways. (other things)

Also, no game I know of uses OpenCL atm. (OpenGL/DX)

EDIT: It should run x64 as well, assuming you have enough RAM.

The as.exe and ld.exe (no numbers in the file names), together with clionfo.exe, are installed into ProgramFiles/AMD_APP/bin/x86, by the AppSDK kit. There is none of them in the system32 folder. The opencl.dll instals there if I install the sdk stuff. Without it, i mean only with the 13-9(or 1)_xp32_dd_ccc_whql.exe installed, there is no clinfo nor opencl. Also, there is no error signalled during installation, and every other applications I can think of except mfakto (I did not try ccLucas yet!) detects and uses the card right. One reason I don't like radeons... Still the nVidia guy. Giving up for now, after 3 days of trials, I don't think there is any stone unturned, beside of going into mfakto sources, which I don't have enough time to do it...

I know (again) that you're stuck with xp for one reason or another... but that probably is your biggest problem. Neither AMD or MS supports it anymore.

You are very right. After your former message (not the last one) I convinced "the right person" to install win7. (The point was that I was not very convinced myself, but your post made me change my mind - you seemed to know what you are talking about :razz:). Everything ran from the box! I mean, drivers installed, click on mfakto, boom! working. I am currently crunching with 360GD/D with the 7970, on that old mobo and CPU, and is quite amazing responsive, I expected to click and wait hours, but it is not the case. I can not increase the speed of mfakto right now, because Catalyst Control Center does not run yet - same as AMD's MOM, and same as Misfit - CCC and they all need dotNet 4.0 or higher, and the Win7 is still crawling through the list of 138 "important updates" and about 10 or 15 "optional updates" (which I deselected), the .Net is the 100th in the list, or something. :razz: (this is normal behavior after fresh reinstallation - the windows update will crawl for few hours till it updates everything "to date" - in this time mfakto is running! [edit: hey! already found a factor!]).

Bad part is that now this computer needs to have always a mouse plugged in, but I found an old one and stuck it in its butt. One reason of using XP was the "synergy" environment, which is only partially running on win7 (for example, you can not click the TechpowerUp's GPU-Z's window with a mouse connected over synergy, on win7, the GPU-Z application is totally invisible for synergy (!?!?) also, in win7 you need first to login to activate synergy, therefore I need now to use no password (otherwise it would need a keyboard too...), etc. One ugly thing is that when you try to install something, win7 will popup a system window asking you if you are sure that you want to change the system folders (or the registry), and (optional) make the rest of the screen black. You may know this behavior, which is not easy (and not safe) to get rid of (it can be canceled if you play wit the local security policies). Well, the system window in cause, is also transparent for the mouse connected over synergy, but not only: after you use a "local" mouse to click that "yes" button, the local synergy is killed (!?!? no joke, the service is aborted!). Well, but that is a different story.

Funny thing: my man is using Christian Ghisler's Total Commander (I corrupted him, I mean my man, some time ago, and I still believe this is the best file browser for windoze). When you change TC's settings, it writes a file called wincmd.ini in C:\windows folder (the program was former called "windows commander", but Microsoft sued the developer for the name - one more reason for me to like this program: it stepped on M$'s toes :razz:). The location of the file can only be specified at installation time, and can not be changed after (only if you edit the files in binary, it is not storred in the registry or else). We have "unlimited" license for it, and because is easier to copy the files (comparing with installation plus applying the lic, etc), we copy the files from another computer every time we do a new installation. Well, the old installation wanted to create the ini into the windows folder. This works well with XP, but it doesn't work with Win7, because it will not allow an "unknown" program (which does not come from a verified installation) to write in the windows folder, unless you don't go to the folder, use right-click, properties, security, and change the security attributes for the folder to allow everyone to write there. Which again, it is not safe... but well... Now imagine my man's face when he started TCmd and saw that he is still seeing the old tabs and folders, from the old computer (which of course were empty here!) every time he starts the program, and not the new folders he had when he closed the program (the program is supposed to remember the status it was when you closed it, when you will open it next time). Very frustrating, you could see it on his face, hehe, but here is my domain...

(since I write this, the dotNet came, it will be installed soon, after the other downloads will come, 62% now, from the total).

[edit: errata on my former post: i wanted to write "clinfo" and not "cloinfo", i just saw it now]

[edit 2: I just tried CLLucas, it is also working fine - for this I only have 64 bit exe, so I could not try it on XP, luckily, otherwise I would spend/waste some hours/days with it too...]

Yes.. first updates are a PAIN. And the computer is a lot slower while it's doing it.

I might have an (empirical) idea how to make mfakto faster, about two times faster than currently is, at least for some cards.

Facts: my (overclocked, air cooled) 7970, crunching exponents from 47M to 69M, from 69 to 74 bits, here is a small table with GHzDays/Day. These are not (only) the (pre)calculated values given by mfakto, but (also) the (postcalculated) wall-clock real time values. There was also a small "tuning" done for the number of primes, but once established, it was not changed. Can anyone with a HD79xx card confirm the (proportion between the) values?

[CODE]
[FONT=Courier New]bitlevel 69-70 70-71 70-71 71-72 72-73 73-74
exponent GHzDays/Day
48M 630 610 560 523 488
52M 638 615 565
55M 568 538 503
62M 615 580 545 503 448
65M 633 601 550 521 463
68M 633 601 550 521 463 [/FONT][/CODE]So, it is clear that when it deals in smaller chunks for sieving, the card is much faster. Larger chunks do more access to slower common memory. The idea would be to "break" the higher bitlevels in "subbitlevels", for example split the 74 into 4 subranges, "73 to 73+71", "73+71 to 73+72", "73+72 to 73+72+71", and "73+72+71 to 74". This way, the 7970 would achieve 630G in average, instead of 440G in average, as it achieves now.

Remark that we mostly do 64M to 74 bits, therefore using this cart at [U][B]half[/B][/U] of its capacity! I changed all my assignments for this card to maximum 73 bits, and the production overnight jumped 150% (in GHzD/D).

What the hack, this card is 3 times faster for mining compared with a gtx580, and the sha256/scrypt-ing it is not more/less computation hungry than mfakto-ing, this card can give much more for mfakto!

Sounds odd to me. Assuming that mfakto works similar to mfaktc than the relative small fractions of the range are processed at once, than the next one and next one until the full range is done. So in fact mfakt[co] is working on "subbitlevels" already.

Oliver

Honestly it sounds a bit odd to me too, but the speed difference is real. It may also be related to the fact that mfakto is using many different kernels for (almost) every bit, and the higher-bit kernels are less efficient (from the "barrett15" family, there are kernels for 69,71,73,74,76 bits, or so) when they do the inverses, but I still can't understand why the differences are so big. Doing a 74 bit for a 120M exponent still gets higher speed, so I considered that the difference is not so much related to the bitlevel (kernel) but to sieving (the amount of candidates for 120M to 72 is the same as 60M to 73).

I've always known that lower exponents and bitlevels on mfakto were much faster but I've never really thought about it.

Sieving does not really care about bit levels. The sieve block size can be configured. Using different kernels, however, makes the majority of the difference. As long as a 5x15-bit kernel can be used, it should still be quite fast, up to 73 bits. Below 73, there are multiple levels of optimizations based on George's improvements for mfaktc 0.20. The lower the bitlevel, the more "relaxed" is mfakto's math as there are more bits available to catch calculation errors.

However, I cannot explain why mfakto's speed should be different for the same bitlevel and different exponents. Every binary 1 in the exponent causes a bit more effort than a 0. Every doubling of the exponent causes one more round in the exponentiation algorithm, causing it to slow down as the exponent increases. I cannot see any reason for gaining speed on higher exponents.

[QUOTE=LaurV;362809]Honestly it sounds a bit odd to me too, but the speed difference is real. It may also be related to the fact that mfakto is using many different kernels for (almost) every bit, and the higher-bit kernels are less efficient (from the "barrett15" family, there are kernels for 69,71,73,74,76 bits, or so) when they do the inverses, but I still can't understand why the differences are so big. Doing a 74 bit for a 120M exponent still gets higher speed, so I considered that the difference is not so much related to the bitlevel (kernel) but to sieving (the amount of candidates for 120M to 72 is the same as 60M to 73).[/QUOTE]

Here is an excerpt from mfakto source:
[CODE]/* GPU_GCN (7850@1050MHz, v=2) / (7770@1100MHz)*/
BARRETT69_MUL15, // "cl_barrett15_69" (393.88 M/s) / (259.96 M/s)
BARRETT70_MUL15, // "cl_barrett15_70" (393.47 M/s) / (259.69 M/s)
BARRETT71_MUL15, // "cl_barrett15_71" (365.89 M/s) / (241.50 M/s)
BARRETT73_MUL15, // "cl_barrett15_73" (322.45 M/s) / (212.96 M/s)
BARRETT82_MUL15, // "cl_barrett15_82" (285.47 M/s) / (188.74 M/s)
BARRETT76_MUL32, // "cl_barrett32_76" (282.95 M/s) / (186.72 M/s)
BARRETT77_MUL32, // "cl_barrett32_77" (274.09 M/s) / (180.93 M/s)
BARRETT83_MUL15, // "cl_barrett15_83" (267.27 M/s) / (176.79 M/s)
BARRETT87_MUL32, // "cl_barrett32_87" (248.77 M/s) / (164.12 M/s)
BARRETT79_MUL32, // "cl_barrett32_79" (241.48 M/s) / (159.38 M/s)
BARRETT88_MUL15, // "cl_barrett15_88" (239.83 M/s) / (158.46 M/s)
BARRETT88_MUL32, // "cl_barrett32_88" (239.69 M/s) / (158.22 M/s)
BARRETT70_MUL24, // "cl_barrett24_70" (226.74 M/s) / (149.63 M/s)
BARRETT92_MUL32, // "cl_barrett32_92" (216.10 M/s) / (142.61 M/s)
[/CODE]

This shows the fastest-to-slowest kernels for GCN type GPUs (HD 7xxx is a GCN). 69-70 will be handled by BARRETT70_MUL15, 70-71 by BARRETT71_MUL15, etc... The numbers in parentheses are raw candidates/second (this too comes from the source code -- not my numbers:smile:). As you can see there is a significant difference between each of the kernels, which is entirely sufficient to explain the differences between your columns.

No idea how to explain the differences b/w rows :sad:

[BTW, you have two "70-71" columns. Whats up with that? :confused:]

[QUOTE=axn;362926][BTW, you have two "70-71" columns. Whats up with that? :confused:][/QUOTE]
That is me trying to be more explanatory than necessary. The initial columns were 69, 70, 71, etc, and I tried to "add a clarification" during the manual alignments. :blush: So, the first two columns are labeled wrong (a bit more).

A question regarding barett15 kernels and their bitlevels. From the source:
[CODE] { BARRETT69_MUL15, "cl_barrett15_69", 60, 69, 0, NULL},
{ BARRETT70_MUL15, "cl_barrett15_70", 60, 69, 0, NULL},
{ BARRETT71_MUL15, "cl_barrett15_71", 60, 70, 0, NULL},
[/CODE]

From the naming convention, I'd had assumed that the 70 & 71 kernels would have bit max of 70 & 71 respectively, instead of 69 & 70 that is hardwired into the code. Is this intentional? If so, the 70 kernel is superfluous as the 69 kernel also handles same range and is (almost?) always faster.

The naming reflects what I planned the kernels originally for, but some did not live up to that. So yes, _70 could be removed. I just thought that some day I could find a tweak to really make it do the 70 bits.

BTW, for those hunting for factors in the <10M range: GPU-sieving on the fast 15-bit kernels is available down to 60 bits. Just no "LESS_CLASSES"-version.

For comparison, same card (HD7850@1050MHz):

2.3M 63->64: 315 GHz-days/day
2.3M 64->65: 325 GHz-days/day
2.3M 65->67: 330 GHz-days/day

65M 63->64: 112 GHz-days/day
65M 64->65: 180 GHz-days/day
65M 65->66: 234 GHz-days/day
65M 66->67: 274 GHz-days/day
65M 67->69: 276 GHz-days/day
65M 69->70: 261 GHz-days/day
65M 70->73: 234 GHz-days/day
65M 73->80: 213 GHz-days/day

:beer:

Is this automatic? Or do I have to manually do something for those kernels?

Thanks! :smile:

This thread should really be stickied, just like the mfaktc thread.

[QUOTE=kracker;363578]Is this automatic? Or do I have to manually do something for those kernels?

Thanks! :smile:[/QUOTE]
All plain and out-of-the-box.

After a crapload of errors... it has "appeared" :toot: Now to see if it works... :smile:

sched_setaffinity is I found out is only for linux... lol It didn't "define" it because it wasn't MSVC.

You could not use SetThreadAffinityMask?

[QUOTE=Bdot;363613]You could not use SetThreadAffinityMask?[/QUOTE]

Not sure, I used the code for MSVC. mfakto in general seems to be working, though :smile:

I just checked in a version that reads a "MoreClasses" config item (only when GPU-sieving, I did not want to touch the CPU sieve). MoreClasses=0 seems to have advantages when the time per class is below 0.4-0.5 seconds (on my old 5770).

Thanks! Will check it out later this evening... :smile:

Nice...! :smile:

Running 6M 63 to 64, I get 207 from 193 :smile:

EDIT: Ok, I believe I fixed SieveCPUMask on MinGW/gcc,
[code]
mfaktc.c

#include <stdio.h>
#include <stdlib.h>
#ifndef _MSC_VER
#include <unistd.h>
#define _GNU_SOURCE
#include <sched.h>
#endif
#ifndef __MINGW32_
#include <windows.h>
#endif
#include <string.h>
#include <errno.h>
#include <time.h>
#include <CL/cl.h>
[/code]

[code]
mfaktc.c line 1183

#if defined _MSC_VER || __MINGW32__
SetThreadAffinityMask(GetCurrentThread(), mystuff.cpu_mask);
#else
sched_setaffinity(0, sizeof(mystuff.cpu_mask), mystuff.cpu_mask);
#endif
[/code]

I've committed your second part, but skipped the first (including windows.h is no good, and did not apply to MinGW anyway).
[code]
--- a/src/mfaktc.c
+++ b/src/mfaktc.c
@@ -1180,7 +1180,7 @@ int main(int argc, char **argv)
// no need to do this if we're sieving on the GPU
if (mystuff.cpu_mask)
{
[COLOR=red]-#ifdef _MSC_VER[/COLOR]
[COLOR=green]+#if defined _MSC_VER || __MINGW32__[/COLOR]
SetThreadAffinityMask(GetCurrentThread(), mystuff.cpu_mask);
#else
sched_setaffinity(0, sizeof(mystuff.cpu_mask), mystuff.cpu_mask);
[/code]

Hmm, I see. I tried compiling mfakto again with newest commit, it doesn't work.

(fyi, mingw does have a windows.h in the "core" includes [URL="http://pastebin.com/YfjkBQ4P"]windows.h[/URL]

Anyways, here it is with cpu sieving:
[URL="http://imagebin.org/285341"]http://imagebin.org/285341
[/URL]

This is with windows.h included.
[URL="http://imagebin.org/285342"]http://imagebin.org/285342[/URL]

PS: Also on filelocking.c it compiles when I change line28 to
[code]
#if defined _MSC_VER || __MINGW32__
[/code]

Sorry I didn't say so in previous post. :bangheadonwall:

Thanks :smile:

Where did you include windows.h? Your code block had an "#ifndef __MINGW32_" in front of it ...

And it does not compile in VS10 when that windows.h is there, and probably neither on Linux.

I added the filelocking.c change as well, but did not yet commit.

BTW, "git diff" gives you all changes made in your working copy :wink:
And I made you contributor for the github repo.

[QUOTE=Bdot;363904]Where did you include windows.h? Your code block had an "#ifndef __MINGW32_" in front of it ...

And it does not compile in VS10 when that windows.h is there, and probably neither on Linux.

I added the filelocking.c change as well, but did not yet commit.

BTW, "git diff" gives you all changes made in your working copy :wink:
And I made you contributor for the github repo.[/QUOTE]

:facepalm:

I have a lot of different files lying around... it is "#ifndef __MINGW32__".

This is in mfaktc.c.

EDIT: I have frankly, never tried git :smile: I'll see if I can find a guide, will probably be useful in the future.

EDIT2: Ah screw this, brain is too foggy now >_<. Trying tomorrow.

[QUOTE=kracker;363911]
EDIT: I have frankly, never tried git :smile: I'll see if I can find a guide, will probably be useful in the future.
[/QUOTE]

Walk, no run and read this [url]http://git-scm.com/[/url] and [url]http://git-scm.com/documentation[/url]
You will not regret the time spent learning git.

[QUOTE=garo;363946]You will not regret the time spent learning git.[/QUOTE]

Indeed! :smile:

And for a more "cathedral" (vs. "bazaar") development environment that you're the authority for, Subversion can be a very good friend.