[QUOTE=garo;363946]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]

Thanks :smile:

[QUOTE=chalsall;363950]Indeed! :smile:

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

Until you try merging divergent branches...

You can have cathedral control in git by picking what you merge into your repository...

[QUOTE=Mark Rose;363965]Until you try merging divergent branches...

You can have cathedral control in git by picking what you merge into your repository...[/QUOTE]

Are you arguing that git is superior to svn for merging?

That has not been my experience (for small teams I'm responsible for), but very happy to have other perspectives on the available options.

[QUOTE=chalsall;363966]Are you arguing that git is superior to svn for merging?

That has not been my experience (for small teams I'm responsible for), but very happy to have other perspectives on the available options.[/QUOTE]

It's the collective experience of everyone where I work. We're a small team of about 10. The amount of forking and merging between branches we do daily would be impossible in svn.

The biggest paradigm shift in moving from cvs/svn to git is that there is not "the repository", but a multitude of repositories that can merge in branches from each other. git is very flexible, especially when bits of work depend on other bits in other branches that haven't been merged into the main release branch yet.

Sometimes merges aren't flawless, but the vast majority of the time they require no human intervention, even if the same file has been modified in the two branches being merged. Only if the specific lines changed conflict do you need too manually merge.

I'm no git expert, but it makes collaborating very easy in my experience.

Can I merge Prime95 with mfaktc/o and cudaLucas/clLucas together and run the resulting exe on the [URL="http://en.wikipedia.org/wiki/Engine_control_unit"]ECU[/URL] of my Altis? (it has ARM mcu, and the altis' engine iself has a lot of horse power!)

:unsure:

Not sure how you intended to say that :razz:

In the past 20 years I have used about a dozen version control systems starting from SCCS all the way down to git and mercurial with CVS, SVN and a host of proprietary systems thrown in. IMAO none is as good as git. (hg comes close). After all, in which other VCS can you do a 32-way octopus merge and come out alive to tell the tale?

[QUOTE=Mark Rose;363982]I'm no git expert, but it makes collaborating very easy in my experience.[/QUOTE]

OK, thanks for that.

I tend to work with very small teams (two or three others at most), and I'm a bit of a "control freak". :smile:

[QUOTE=garo;364018]In the past 20 years I have used about a dozen version control systems starting from SCCS all the way down to git and mercurial with CVS, SVN and a host of proprietary systems thrown in. IMAO none is as good as git. (hg comes close). After all, in which other VCS can you do a 32-way octopus merge and come out alive to tell the tale?[/QUOTE]

It's almost like git were written by a man who needed to deal with thousands of contributors and millions of lines of code and no existing VCS was capable...

Hehe, indeed ...

I've been using (RCS,) Clearcase and Subversion. Just for mfakto I'm using git (in order to learn and see how it works). It sure helped me a lot. But lacking the ton of contributors, there's not much that the others wouldn't have done. Compared to Clearcase and Subversion I like it's speed and miss the ability to abbreviate it's commands. OK, I recently found out that command completion using tab works in git bash, even on windows - something I did not expect.

[QUOTE=Bdot;364113]miss the ability to abbreviate it's commands.[/QUOTE]

[url]https://git.wiki.kernel.org/index.php/Aliases[/url] ;)

I [B]knew[/B] there was some way ... cool examples, BTW. Thanks a lot!

Not Working with Windows 8.1
 

I had installed mfakto 0.13 and it was working well with Windows 8

Just recently upgraded to windows 8.1 and mfakto no longer works.

It stops at self test 4. I get a pop up saying display driver stopped responding but has recovered.

Here is what I have in the command prompt window form mfakto:

[CODE]mfakto 0.13-Win (64bit 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 yes
VectorSize 2
GPUType AUTO
SmallExp no
Compiletime options
MORE_CLASSES enabled
Select device - Get device info - Compiling kernels.

OpenCL device info
name Caicos (Advanced Micro Devices, Inc.)
device (driver) version OpenCL 1.2 AMD-APP (1348.5) (1348.5 (VM))
maximum threads per block 256
maximum threads per grid 16777216
number of multiprocessors 2 (160 compute elements)
clock rate 775MHz

Automatic parameters
threads per grid 2097152
optimizing kernels for VLIW5

running a simple selftest ...
########## testcase 4/17 (#30) ###########[/CODE]

The catalyst control centre show the hardware as:

[CODE]Primary Adapter
Graphics Card Manufacturer Powered by AMD
Graphics Chipset AMD Radeon HD 8470
Device ID 6778
Vendor ID 1002
Subsystem ID 8493
Subsystem Vendor ID 1462
Graphics Bus Capability PCI Express 2.0
Maximum Bus Setting PCI Express 2.0 x16
BIOS Version 013.012.000.041
BIOS Part Number 113-AD5O100-105a
BIOS Date 2013/01/16
Memory Size 1024 MB
Memory Type DDR3
Core Clock in MHz 775 MHz
Memory Clock In MHz 900 MHz
Total Memory Bandwidth in GByte/s 14.4 GByte/s[/CODE]


The software listed in command centre is as follows:

[CODE]Driver Packaging Version 13.251-131 206a-1 66389C-ATI
Catalyst Version 13.12
Provider Advanced Micro Devices, Inc.
2D Driver Version 8.01.01.1360
2D Driver File Path /REGISTRVJMAC HINEJSVSTEM/ControlSeto0l/Controlf
Class/{4d36e968-e32511ce-bfcl-08002be10318}I0000
Direct3D Version 9.14.10.0 1001
OpenGL Version 6.14.10.12618
AMD Catalyst Control Center Version 2013.1206.1603.28764[/CODE]

Try this: [URL]http://mersenneforum.org/showpost.php?p=361160&postcount=933[/URL]

Also, set GCN in mfakto.ini instead of AUTO or VLIW5, it may be faster.

[QUOTE=kracker;365939]Try this: [URL]http://mersenneforum.org/showpost.php?p=361160&postcount=933[/URL]

Also, set GCN in mfakto.ini instead of AUTO or VLIW5, it may be faster.[/QUOTE]

I have tried the above with GPUTYPE set to GCN and it still crashes at selftest #4.

I checked the AMD site and I have the latest drivers.

Mantle drivers -beta- is about to be released. Could it help Mfakto?
[url]http://www.tomshardware.com/news/amd-mantle-drivers-download,25927.html[/url]

[QUOTE=gjmccrac;365919]I had installed mfakto 0.13 and it was working well with Windows 8

Just recently upgraded to windows 8.1 and mfakto no longer works.

...
VectorSize 2

...
name Caicos (Advanced Micro Devices, Inc.)

...
optimizing kernels for VLIW5
[/QUOTE]

For Caicos, VLIW5 is correct, but VectorSize=4 will result in better performance. Plus, there is a chance that the display driver does not abort.

In the example that I used to show the problem to AMD, they found a write beyond array bounds, causing the abort in the example. I was not able to see that kind of source code issue in mfakto, but the result is the same ...

[QUOTE=kracker;365939]Try this: [URL]http://mersenneforum.org/showpost.php?p=361160&postcount=933[/URL]

Also, set GCN in mfakto.ini instead of AUTO or VLIW5, it may be faster.[/QUOTE]

Maybe I should round up my current mfakto development state and release the next version ... though I did not manage to get everything done that I wanted.

But VLIW5 is OK for that GPU. What will resolve the abort for sure, is to go back to CPU sieving (SieveOnGPU=0). So far I've seen the aborts only when GPU sieving.

[QUOTE=firejuggler;366041]Mantle drivers -beta- is about to be released. Could it help Mfakto?
[URL]http://www.tomshardware.com/news/amd-mantle-drivers-download,25927.html[/URL][/QUOTE]

Mantle is of great help for ultra-short kernels, like drawing a few 3D-items, because the scheduling overhead is dramatically reduced. For long-running kernels, like mfakto's, I did not yet find a benefit. However, I still have to see if there's an easier way to inline assembly statements - this could help by offering some instructions that are not exposed in OpenCL.

[QUOTE=Bdot;366256]
Maybe I should round up my current mfakto development state and release the next version ... though I did not manage to get everything done that I wanted.
[/QUOTE]

Wow, there are some 8xxx that are [I]VLIW5[/I]? Rebadge at it's finest. :razz:

[QUOTE=Bdot;366256]
But VLIW5 is OK for that GPU. What will resolve the abort for sure, is to go back to CPU sieving (SieveOnGPU=0). So far I've seen the aborts only when GPU sieving.
[/QUOTE]

Sieving on the CPU worked for the 01.4pre version.

There is a CL compile error for ver 0.13 if I set it to Sieve on CPU.

[QUOTE=gjmccrac;366326]Sieving on the CPU worked for the 01.4pre version.

There is a CL compile error for ver 0.13 if I set it to Sieve on CPU.[/QUOTE]

Hmm. Have you tried a fresh install of the latest drivers? (completely remove, reboot, restart etc) I have had to do that a time or two.

[QUOTE=kracker;366334]Hmm. Have you tried a fresh install of the latest drivers? (completely remove, reboot, restart etc) I have had to do that a time or two.[/QUOTE]

As far as I'm concerned, that is the [U]only[/U] way to install a new graphics driver. Though I'm running nVidia cards now, the same was true in the years I ran ATI. I have seen enough flakiness from installing a new driver over the old. This became even more necessary when running GPGPU applications.

I have a new Windows 7 laptop with an AMD HD8970M GPU on which I just started trying MFAKTO (x64).

The throughput numbers look pretty impressive -- over 200GHz-days/day. However, the performance drops to around 100GHz-d/d when the screen goes to sleep, and I haven't figured out a good way to stop it from doing that.

I'm also running an HD7770 on a Windows 7 desktop machine. This one doesn't have that problem: the display goes to sleep after 20 minutes without affecting the GPU's MFAKTO performance at all.

Have tried all sorts of power settings on the laptop, Device Manager, Catalyst Control Center, what have you, and the only setting change that's prevented this from happening is to set the display to Never go to sleep, but that's not acceptable.

Am I missing something? What else (if anything) can I do to keep the HD8970M running at full capacity when the display goes to sleep? Or is it something that's inherent in laptop PCs (or maybe in mobile graphics cards)?

Rodrigo

[QUOTE=Rodrigo;368191]I have a new Windows 7 laptop with an AMD HD8970M GPU on which I just started trying MFAKTO (x64).

The throughput numbers look pretty impressive -- over 200GHz-days/day. However, the performance drops to around 100GHz-d/d when the screen goes to sleep, and I haven't figured out a good way to stop it from doing that.

I'm also running an HD7770 on a Windows 7 desktop machine. This one doesn't have that problem: the display goes to sleep after 20 minutes without affecting the GPU's MFAKTO performance at all.

Have tried all sorts of power settings on the laptop, Device Manager, Catalyst Control Center, what have you, and the only setting change that's prevented this from happening is to set the display to Never go to sleep, but that's not acceptable.

Am I missing something? What else (if anything) can I do to keep the HD8970M running at full capacity when the display goes to sleep? Or is it something that's inherent in laptop PCs (or maybe in mobile graphics cards)?

Rodrigo[/QUOTE]

It's probably a "power saving" feature... My best bet would be in the Catalyst control center, but it seems you've already checked and tried that... I don't have a mobile GPU so I can't speak much about it.

[QUOTE=Rodrigo;368191]I have a new Windows 7 laptop with an AMD HD8970M GPU on which I just started trying MFAKTO (x64).

The throughput numbers look pretty impressive -- over 200GHz-days/day. However, the performance drops to around 100GHz-d/d when the screen goes to sleep, and I haven't figured out a good way to stop it from doing that.

I'm also running an HD7770 on a Windows 7 desktop machine. This one doesn't have that problem: the display goes to sleep after 20 minutes without affecting the GPU's MFAKTO performance at all.

Have tried all sorts of power settings on the laptop, Device Manager, Catalyst Control Center, what have you, and the only setting change that's prevented this from happening is to set the display to Never go to sleep, but that's not acceptable.

Am I missing something? What else (if anything) can I do to keep the HD8970M running at full capacity when the display goes to sleep? Or is it something that's inherent in laptop PCs (or maybe in mobile graphics cards)?

Rodrigo[/QUOTE]

May I ask why it is not acceptable to keep the screen on? There is not much power-saving from turning it off, and you could dim it to not shorten life-time too much.

Apart from that ... there are "advanced options" in the "modify power plan" screen (not sure about the real wording - I just have the German version here). In there, you can modify the PCI Express power saving ... try turning that off.

[QUOTE=Bdot;368246]May I ask why it is not acceptable to keep the screen on? There is not much power-saving from turning it off, and you could dim it to not shorten life-time too much.

Apart from that ... there are "advanced options" in the "modify power plan" screen (not sure about the real wording - I just have the German version here). In there, you can modify the PCI Express power saving ... try turning that off.[/QUOTE]

Some laptops have severely limited BIOS sadly.

[QUOTE=Bdot;368246]May I ask why it is not acceptable to keep the screen on? There is not much power-saving from turning it off, and you could dim it to not shorten life-time too much.

Apart from that ... there are "advanced options" in the "modify power plan" screen (not sure about the real wording - I just have the German version here). In there, you can modify the PCI Express power saving ... try turning that off.[/QUOTE]
I went back into the advanced power settings. There is indeed a PCI Express item, which leads to a "Link State Power Management" option for battery and plugged-in states. Both were already turned off (must have been a default value, I don't remember changing that setting).

At the bottom of the menu list there is also an "ATI Graphics Power Settings" option, which was set to "Maximize Battery Life" for Battery and to "Maximize Performance" for Plugged-in. Just in case, I now changed the Battery setting to Maximize Performance too. Because it's always plugged in, I'm not hopeful that this will make any difference.

As for why not leave the screen on all the time, it is is an expensive laptop and I would rather not burn in the static image that would be displayed 24/7.

If we can't come up with any settings to make the laptop's screen+GPU behave like the desktop's screen+GPU, my next step will be to try a screensaver or else dimming the screen.

Rodrigo

[QUOTE=kracker;368247]Some laptops have severely limited BIOS sadly.[/QUOTE]
You can say that again. Amazingly, for the price of this laptop there is no choice in the BIOS to disable hyperthreading.

But overall I'm delighted with the machine. Just looking for a way to squeeze its whole potential out of it.

Rodrigo

Solution?

[url]http://superuser.com/questions/142760/is-there-a-way-to-shut-off-a-laptop-monitor[/url]

[QUOTE=Rodrigo;368253]
As for why not leave the screen on all the time, it is is an expensive laptop and I would rather not burn in the static image that would be displayed 24/7.[/QUOTE]

Is this even possible anymore? I thought this was just for CRT screens.

From the manual for our 65 inch LCD/LED TV:
[QUOTE]Avoid displaying still images (such as jpeg picture files) or still image elements (such as TV channel logos, TV shows or movies in panorama or 4:3 format, stock or news scroll bars, etc.) on the screen. The constant display of still pictures can cause ghosting or image burn-in (image retention) on the LED screen, which will affect image quality. To reduce the risk of this effect, please follow the recommendations below:
• Avoid displaying the same TV channel for long periods.
• Always try to display any image in full screen mode. Use the TV's Picture Options menu to select the optimal screen size.
• Reduce brightness and contrast values to the minimum required to achieve the desired picture quality. Values that exceed the minimum may speed up the burn-in process.
• Frequently use all TV features designed to reduce image retention and screen burn-in. Refer to proper user manual section for details.[/QUOTE]

[QUOTE=Xyzzy;368260]From the manual for our 65 inch LCD/LED TV:[/QUOTE]
Thanks, Xyzzy, that jibes with my understanding of the situation.

Rodrigo

P.S. Looking into [URL="http://www.dekisoft.com/mou.php"]Monitor Off[/URL], to which your link led me.

[QUOTE=Rodrigo;368191]I have a new Windows 7 laptop with an AMD HD8970M GPU on which I just started trying MFAKTO (x64).

The throughput numbers look pretty impressive -- over 200GHz-days/day. However, the performance drops to around 100GHz-d/d when the screen goes to sleep, and I haven't figured out a good way to stop it from doing that.

I'm also running an HD7770 on a Windows 7 desktop machine. This one doesn't have that problem: the display goes to sleep after 20 minutes without affecting the GPU's MFAKTO performance at all.

Have tried all sorts of power settings on the laptop, Device Manager, Catalyst Control Center, what have you, and the only setting change that's prevented this from happening is to set the display to Never go to sleep, but that's not acceptable.

Am I missing something? What else (if anything) can I do to keep the HD8970M running at full capacity when the display goes to sleep? Or is it something that's inherent in laptop PCs (or maybe in mobile graphics cards)?

Rodrigo[/QUOTE]

In windows power options, you can set the laptop to never go to sleep, and set closing the lid to do nothing on battery. When you want to crunch numbers, you can close the lid. See if that helps you out.

What you could also try is to set the monitor to never not turn off but close the lid (which will turn off the monitor but not because of any "sleep" stuff).

Get back to us after trying those two options, unless the second really isn't your style.

[QUOTE=TheMawn;368265]In windows power options, you can set the laptop to never go to sleep, and set closing the lid to do nothing on battery. When you want to crunch numbers, you can close the lid. See if that helps you out.[/QUOTE]

Going to sleep is not the problem. The GPU going into power saving "mode" when the screen is off is the problem.

[QUOTE=kracker;368266]Going to sleep is not the problem. The GPU going into power saving "mode" when the screen is off is the problem.[/QUOTE]

Yes, but this should show if it's indeed the monitor being off that actually triggers this or if it's a "sleep" (or similar) effect. That's what I want to get from the second test. Think of it as seeing if it makes a difference whether windows or the GPU or the BIOS or whatever is "telling" the monitor to be off.

[QUOTE=TheMawn;368273]Yes, but this should show if it's indeed the monitor being off that actually triggers this or if it's a "sleep" (or similar) effect. That's what I want to get from the second test. Think of it as seeing if it makes a difference whether windows or the GPU or the BIOS or whatever is "telling" the monitor to be off.[/QUOTE]
OK, I've set the laptop to never sleep and then do nothing when I close the lid. In both cases, on either battery or wall power. Then I closed the lid.

The lid went black anyway when I closed it. Will wait a while and then report back on the results.

Rodrigo

UPDATE: I left the lid closed for a few minutes and then opened it to see how MFAKTO was doing. MFAKTO output was down again --although, curiously, to ~120 GHz-d/d as opposed to ~100 GHz-d/d which is what I've been seeing before tonight's setting changes.

I'll go away for a further while now, leaving the lid open but with these new settings, and see what happens.

Nope -- with these new settings, leaving the lid open didn't make any difference relative to closing it.

Per @TheMawn's most recent post, I'll go into the BIOS and see if there's anything relevant/useful in there for this issue.

Rodrigo

[QUOTE=Rodrigo;368277]Nope -- with these new settings, leaving the lid open didn't make any difference relative to closing it.

Per @TheMawn's most recent post, I'll go into the BIOS and see if there's anything relevant/useful in there for this issue.

Rodrigo[/QUOTE]

One possibility is that the GPU is clocking down due to attached display not being active. In which case, catalyst driver is where you should focus.

[QUOTE=Rodrigo;368277]Nope -- with these new settings, leaving the lid open didn't make any difference relative to closing it.[/QUOTE]

I would also advise you NOT close the lid for long when the CPU and/or GPU are working hard. Many laptops effectively rely on the keyboard as a (sometimes significant) part of the cooling airflow.

Wow, I did not know that. I'll keep the lid open, thanks!!

Rodrigo

[QUOTE=axn;368278]One possibility is that the GPU is clocking down due to attached display not being active. In which case, catalyst driver is where you should focus.[/QUOTE]
I've gone into the Catalyst Control Center a number of times and nothing looks promising there. You'd think that would be the #1 place to go, but I've gone (AFAIK) through every possible setting and there's nothing related to this specific issue. PowerPlay I had already set to "maximize performance."

FWIW the CCC version is 2013.0315.1331.22405.

Not out of options yet. Barring other ideas, next I'll be checking the BIOS for a possible setting in there, and if that doesn't do it then I'll try that "Monitor Off" utility.

Rodrigo

CPUID's HWMonitor is a good tool for monitoring certain things you may not have considered. In my case, it was the HDD temperature.

I do close my laptop monitor while crunching over a long period of time, BUT my graphics are integrated to the CPU and it has a 25W power limit. With a dedicated GPU and a stronger CPU, the overall power consumption is likely to be much higher. HWMonitor can help with that, too.

While I do close the lid, I make sure to at least leave the air intake hanging over the side of a table (or better yet, I prop the laptop on its side pointing the exhaust straight up) to improve things in that regard. HWMonitor logs the max temperature it sees so over the course of a few hours or so you can get a good idea of the range of temperatures your hardware goes through. The highest CPU temperature difference I see is 60C if it's on a flat service, 55C if it hangs over the edge and 50C if it's propped on its side. The average temperature seems to be about 5C less than the max.

Leaving my monitor flap open doesn't affect my CPU temperature but it does affect the hard drive in a small way. Flat, with the lid closed, the hard drive temperature HAS reached 58C once, but I think a windows update ran the hard drive during that time. Usually the hard drive never goes over 50C and the current temperature hovers around the upper-mid 40's.


Long story short, if you ARE committed to using your laptop for GIMPS, expect that you're going to be harming your laptop's life expectancy, though you may not do so in a noticeable way: my four-year-old laptop is a bit sluggish after intermittent Starcraft II, a few other easier games, and a year of P-1 with GIMPS, but it still functions very well otherwise.

Get something to log hardware temperature (and keep the max value) and slowly inhibit cooling to see what you can and can't get away with. Watch for CPU (if you're using it), GPU and HDD temps (and RAM if you happen to have such a thing). Start with an A-frame or propping the laptop on its side, open, and see what you get. Then close it. Then lay it flat on a surface with the vents nice and clear.

If at any point the temperature gets outside your comfortable range, you'll have to make sure you can avoid whatever that cooling configuration was. For me it was seeing my CPU hit 88C and HDD hit 58C when I decided that I needed to have the vents hanging over the side of the desk.

From [url]http://www.amd.com/us/Documents/AMD_Radeon_HD_8970M_GPU_Specs.pdf[/url]

[CODE]AMD PowerPlay™ power management technology
Automatic power management with low power idle states
AMD PowerTune technology
Intelligent TDP management technology
Dynamic clockspeed/performance enhancement for games

AMD ZeroCore Power technology
<1W idle for GPUs with inactive displays
Ultra-low power state support for multi-GPU configurations
<1W idle for slave GPUs in AMD CrossFire™ configurations

AMD Enduro™ technology
Seamlessly powers down GPU when not required, and powers up GPU when you need it
Power state-based control (AC vs. DC power) [/CODE]
There is a whole bunch of power-related stuff there. Haven't got a clue which one is messing you up :no:

Shoot, they do have a lot of possible stumbling blocks there. Bummer.

Rodrigo

[QUOTE=TheMawn;368313]CPUID's HWMonitor is a good tool for monitoring certain things you may not have considered. In my case, it was the HDD temperature.

I do close my laptop monitor while crunching over a long period of time, BUT my graphics are integrated to the CPU and it has a 25W power limit. With a dedicated GPU and a stronger CPU, the overall power consumption is likely to be much higher. HWMonitor can help with that, too.

While I do close the lid, I make sure to at least leave the air intake hanging over the side of a table (or better yet, I prop the laptop on its side pointing the exhaust straight up) to improve things in that regard. HWMonitor logs the max temperature it sees so over the course of a few hours or so you can get a good idea of the range of temperatures your hardware goes through. The highest CPU temperature difference I see is 60C if it's on a flat service, 55C if it hangs over the edge and 50C if it's propped on its side. The average temperature seems to be about 5C less than the max.

Leaving my monitor flap open doesn't affect my CPU temperature but it does affect the hard drive in a small way. Flat, with the lid closed, the hard drive temperature HAS reached 58C once, but I think a windows update ran the hard drive during that time. Usually the hard drive never goes over 50C and the current temperature hovers around the upper-mid 40's.


Long story short, if you ARE committed to using your laptop for GIMPS, expect that you're going to be harming your laptop's life expectancy, though you may not do so in a noticeable way: my four-year-old laptop is a bit sluggish after intermittent Starcraft II, a few other easier games, and a year of P-1 with GIMPS, but it still functions very well otherwise.

Get something to log hardware temperature (and keep the max value) and slowly inhibit cooling to see what you can and can't get away with. Watch for CPU (if you're using it), GPU and HDD temps (and RAM if you happen to have such a thing). Start with an A-frame or propping the laptop on its side, open, and see what you get. Then close it. Then lay it flat on a surface with the vents nice and clear.

If at any point the temperature gets outside your comfortable range, you'll have to make sure you can avoid whatever that cooling configuration was. For me it was seeing my CPU hit 88C and HDD hit 58C when I decided that I needed to have the vents hanging over the side of the desk.[/QUOTE]
Thanks, you've given me a number of things to play with. I have GPU-Z on that laptop, but I'll get the HWMonitor.

Speaking of how to position the laptop, I have another laptop that does LL's which is set flat on a wicker chair over the bowl of the seat to help the airflow. :smile:

Rodrigo

Have you tried using the "blank screensaver"? Just might be the [STRIKE]solution[/STRIKE] workaround for all your problems.

That was a GREAT idea, axn! :tu: Setting the screensaver to "blank" may not cut the signal to the monitor, but it does keep all images off it. Slide a finger on the touchpad, screen comes back on, and the GHz-d/d is still humming at over 200.

Thanks a bunch.

Rodrigo

Is there a schedule on 0.14? 0.13 doesn't work with Windows 8 at the moment (requires newer drivers)

Also, mfakto with GCN passes -st2 on the latest commit build. :smile:

[QUOTE=kracker;369809]Is there a schedule on 0.14? 0.13 doesn't work with Windows 8 at the moment (requires newer drivers)

Also, mfakto with GCN passes -st2 on the latest commit build. :smile:[/QUOTE]
One tiny feature and I can send out a test version. As I can't improve performance a lot, I'm adding other fancy stuff ;-)

I just posted the win version of [URL="http://mersenneforum.org/mfakto/mfakto-0.14pre4/mfakto-0.14pre4-win.zip"]mfakto-0.14pre4[/URL]. It should be pretty much complete, except that I did not check my latest changes on Linux yet. I plan to do that next week. Sometimes valgrind finds some weird stuff that I better change for win too.

These are the changes:

[LIST][*]--perftest enhancements including GPU sieve evaluation (for optimizing GPUSievePrimes etc.)[*]successfully resync when the working directory was temporarily lost (ejected USB device or interrupted network drive)[*]save and reload compiled OpenCL kernels => reduce startup time (UseBinfile config variable)[*]MoreClasses config variable to allow for a "less classes" version for very short assignments (GPU sieve only)[*]BugFix: enforce GPUSieveSize being a multiple of GPUSieveProcessSize[*]FlushInterval config variable to fine tune the number of kernels in the GPU queue => address high CPU load issue of newer AMD drivers[*]MinGW build (thanks to kracker)[*]slight performance improvement for the montgomery kernels[*]improved English wording in program output, ini file etc. (thanks to kracker)[*]recognition of new GPUs (8xxx, R9, new APUs) (thanks to kracker)[*]added a warning when using VectorSize=1 (AMD driver issue (?), [URL]http://devgurus.amd.com/thread/167571[/URL])[*]fix for a small memory leak (~0.5kB per assignment)[*]and it should work on Win8.1[/LIST]I'm interested to hear
[LIST][*]is it really running on Win8.1?[*]when doing real tests with GPU sieving, what's the CPU load, is the performance slower or faster than before?[*]anything odd[/LIST]Observations so far:
[LIST][*] VectorSize=1 is not usable on AMD GPUs (see above). It works on Intel and AMD CPUs, and on NVIDIA GPUs (!)[*]When playing around with various ini-file-settings, it is sometimes necessary to manually delete the binary kernel cache file (see UseBinfile setting)[*]Yes, NVIDIA GPUs finally work, but only with these settings:[LIST][*]VectorSize=1[*]FlushInterval=6 (or lower, depending on the SieveSize)[*]SieveOnGPU=1[/LIST] [*]other settings crash the nvidia driver (out of resources), compiler (mfakto crash) or fail the selftest.[*]on a Quadro 2000M, mfakto runs at 57.7 GHz-days/day (mfaktc: 78.8 GHz-days/day), which is better than I expected.[*]As it runs on one non-AMD platform now, we should go for the HD4000 next.[/LIST]

Working on Win 8.1, HD 7770, Catalyst 14.1. :smile:

I have a crippled Acer Aspire MC605 desktop. Intel Pentium CPU G2030 at 3.0 GHZ ( x 2) and graphics "Intel IvyBridge Desktop". I installed Ubuntu 13.10 on this desktop.

Is thre a way to check if I can run mfakto on this PC? Where should I look?

EDIT: got lspci:

[code]
luigi@luigi-Aspire-MC605:~$ lspci | more
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller (rev 09)
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09)
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b5)
00:1c.2 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 3 (rev b5)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation H61 Express Chipset Family LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family SATA AHCI Controller (rev 05)
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 05)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0b)

[/code]

I'm afraid I can do nothing with this... :sad:

Luigi.

[QUOTE=ET_;369984]I have a crippled Acer Aspire MC605 desktop. Intel Pentium CPU G2030 at 3.0 GHZ ( x 2) and graphics "Intel IvyBridge Desktop". I installed Ubuntu 13.10 on this desktop.

Is thre a way to check if I can run mfakto on this PC? Where should I look?

EDIT: got lspci:

[code]
luigi@luigi-Aspire-MC605:~$ lspci | more

00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09)

[/code]I'm afraid I can do nothing with this... :sad:

Luigi.[/QUOTE]

Well, this is the same question as the HD4000 thing. You seem to have an OpenCL-enabled Intel-GPU, but as I don't have something like that, turnaround times for fixing/debugging things have been quite long.

Try to install the Intel GPU drivers (most likely some proprietary ones), maybe check the Intel forums for requirements to enable OpenCL. These drivers should also ship an "clinfo" binary that allows to see OpenCL details.

"cat /proc/cpuinfo" may also help to find details about which CPU type it is exactly.

And then I will provide the 0.14pre4 binary for Linux within the next few days (I still have a nasty SEGFAULT to iron out) ...

[QUOTE=Bdot;369988]Well, this is the same question as the HD4000 thing. You seem to have an OpenCL-enabled Intel-GPU, but as I don't have something like that, turnaround times for fixing/debugging things have been quite long.

Try to install the Intel GPU drivers (most likely some proprietary ones), maybe check the Intel forums for requirements to enable OpenCL. These drivers should also ship an "clinfo" binary that allows to see OpenCL details.

"cat /proc/cpuinfo" may also help to find details about which CPU type it is exactly.

And then I will provide the 0.14pre4 binary for Linux within the next few days (I still have a nasty SEGFAULT to iron out) ...[/QUOTE]

Here is my OpenCL system:

[code]
clDeviceQuery Starting...

1 OpenCL Platforms found

CL_PLATFORM_NAME: Intel(R) OpenCL
CL_PLATFORM_VERSION: OpenCL 1.2 LINUX
OpenCL Device Info:

1 devices found supporting OpenCL on: Intel(R) OpenCL

----------------------------------
Device Intel(R) Pentium(R) CPU G2030 @ 3.00GHz
---------------------------------
CL_DEVICE_NAME: Intel(R) Pentium(R) CPU G2030 @ 3.00GHz
CL_DEVICE_VENDOR: Intel(R) Corporation
CL_DRIVER_VERSION: 1.2.0.82248
CL_DEVICE_TYPE: CL_DEVICE_TYPE_CPU
CL_DEVICE_MAX_COMPUTE_UNITS: 2
CL_DEVICE_MAX_WORK_ITEM_DIMENSIONS: 3
CL_DEVICE_MAX_WORK_ITEM_SIZES: 8192 / 8192 / 8192
CL_DEVICE_MAX_WORK_GROUP_SIZE: 8192
CL_DEVICE_MAX_CLOCK_FREQUENCY: 3000 MHz
CL_DEVICE_ADDRESS_BITS: 64
CL_DEVICE_MAX_MEM_ALLOC_SIZE: 958 MByte
CL_DEVICE_GLOBAL_MEM_SIZE: 3832 MByte
CL_DEVICE_ERROR_CORRECTION_SUPPORT: no
CL_DEVICE_LOCAL_MEM_TYPE: global
CL_DEVICE_LOCAL_MEM_SIZE: 32 KByte
CL_DEVICE_MAX_CONSTANT_BUFFER_SIZE: 128 KByte
CL_DEVICE_QUEUE_PROPERTIES: CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE
CL_DEVICE_QUEUE_PROPERTIES: CL_QUEUE_PROFILING_ENABLE
CL_DEVICE_IMAGE_SUPPORT: 1
CL_DEVICE_MAX_READ_IMAGE_ARGS: 480
CL_DEVICE_MAX_WRITE_IMAGE_ARGS: 480

CL_DEVICE_IMAGE <dim> 2D_MAX_WIDTH 16384
2D_MAX_HEIGHT 16384
3D_MAX_WIDTH 2048
3D_MAX_HEIGHT 2048
3D_MAX_DEPTH 2048
CL_DEVICE_PREFERRED_VECTOR_WIDTH_<t> CHAR 1, SHORT 1, INT 1, FLOAT 1, DOUBLE 1


clDeviceQuery, Platform Name = Intel(R) OpenCL, Platform Version = OpenCL 1.2 LINUX, NumDevs = 1, Device = Intel(R) Pentium(R) CPU G2030 @ 3.00GHz

System Info:

Local Time/Date = 18:48:04, 03/30/2014
CPU Name: Intel(R) Pentium(R) CPU G2030 @ 3.00GHz
# of CPU processors: 2
Linux version 3.11.0-15-generic (buildd@batsu) (gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu8) ) #23-Ubuntu SMP Mon Dec 9 18:17:04 UTC 2013


TEST PASSED

[/code]

Is it worth anything?

:smile:

Luigi

Your cpu's graphics(HD 2500) are comparable to my 8600GTS. I don't run anything on it as it is so slow.
The next generation(HD 4000) has much better performance.
Mine is single precision only. I assume that yours has double precision support.
Almost all of the gpus NVidia sells currently have higher performance.

[QUOTE=henryzz;370005]Your cpu's graphics(HD 2500) are comparable to my 8600GTS. I don't run anything on it as it is so slow.
The next generation(HD 4000) has much better performance.
Mine is single precision only. I assume that yours has double precision support.
Almost all of the gpus NVidia sells currently have higher performance.[/QUOTE]

Thanks Henry, the problem is that actually I have no Nvidia GPU on my PCs... :sad:

Luigi

I just posted the [URL="http://mersenneforum.org/mfakto/mfakto-0.14pre4/mfakto-0.14pre4-Linux.tgz"]Linux version[/URL], basically untested (will test tomorrow).

But you could give it a try. "mfakto-pi" is the "PerformanceInfo" version that measures each kernel's run time. _x32 and _x64 are the normal, optimized versions.

Try playing around with these mfakto.ini parameters to see if any combination works:
VectorSize
SieveOnGPU
GPUType

Depending on the errors you'll encounter, other settings may be needed too.

I agree that the GIMPS contribution in terms of GHz-days will be rather limited. But isn't getting the achievement "First to run mfakto on Intel GPU" something to be proud of :smile: ? I think we're closing in on it ...

[QUOTE=ET_;369998]Here is my OpenCL system:

[code]
1 devices found supporting OpenCL on: Intel(R) OpenCL

----------------------------------
Device Intel(R) Pentium(R) CPU G2030 @ 3.00GHz
---------------------------------
CL_DEVICE_TYPE: CL_DEVICE_TYPE_CPU

[/code][/QUOTE]

Oh, I just noticed, that the OpenCL system did not yet recognize your GPU. What is listed here, is the CPU (I'm quite certain that mfakto will run on that).

Making the GPU show up in the list may need additional effort (drivers/BIOS/hacks/whatever) ... that is something that the Intel forums should be able to provide help for.

Last I looked, Intel only has Windows drivers for OpenCL support. The forums indicated Linux support was not on the horizon.

Hmm, I did not think any company could still run that strategy ...

Well, ET_, this means your system won't run mfakto on the Intel GPU anytime soon ...

[QUOTE=Bdot;370028]Hmm, I did not think any company could still run that strategy ...

Well, ET_, this means your system won't run mfakto on the Intel GPU anytime soon ...[/QUOTE]

Thank you for your effort and hints :smile:

I'll stay on doublemersennes project for now.

Luigi

Did anyone try the 0.14pre4 version on Intel HD yet (obviously only on win)? Did anything change compared to 0.13?

Is anyone besides kracker testing 0.14pre4 at all?

I am trying it and it seems to be working.

Windows 8.1
AMD Radeon HD 8470 (Device 6778)

Catalyst Version 13.12

I've tested on my AMD Radeon HD 6970

[CODE]OpenCL device info
name Cayman (Advanced Micro Devices, Inc.)
device (driver) version OpenCL 1.2 AMD-APP (1124.2) (1124.2 (VM))
maximum threads per block 256
maximum threads per grid 16777216
number of multiprocessors 24 (1536 compute elements)
clock rate 880MHz[/CODE][CODE]Selftest statistics
number of tests 287351
successful tests 287351

selftest PASSED!
[/CODE]:tu:

New test, now on an AMD Radeon HD 6950 and under Linux (Linux version 3.2.0-4-686-pae Debian 3.2.54-2)

[CODE]OpenCL device info
name Cayman (Advanced Micro Devices, Inc.)
device (driver) version OpenCL 1.2 AMD-APP (938.2) (CAL 1.4.1741)
maximum threads per block 256
maximum threads per grid 16777216
number of multiprocessors 22 (1408 compute elements)
clock rate 800MHz
[/CODE][CODE]Selftest statistics
number of tests 287351
successful tests 287351

selftest PASSED!
[/CODE]:tu:

Some lagging on the screen when running faster assignments. The screen froze for half a second every update to the console. The strange thing is that it seems to have disappeared when I changed "PrintMode=1" to avoid scrolling.
It could be some other thing too as this is the first time I'm running mfakto under linux.

Thanks to you all for your testing. Everything seems to be successful - I'll try to release 0.14 next week.

The lag can be reduced a bit by lowering the GPUSieveSize. Your Linux Catalyst version also seems to be much lower (938.2) than your win version (1124.2) - and they are all quite old, Catalyst 13.12 has version 1348.5. Anyway it is good to know that mfakto 0.14 also works with older drivers.

Did anyone (besides me) run the selftest with the LessClasses mode (MoreClasses=0)?

[QUOTE=Bdot;370977]
Did anyone (besides me) run the selftest with the LessClasses mode (MoreClasses=0)?[/QUOTE]

On it on GCN :smile:

st2 with lessclasses, 287351 tests passed :smile:

mfakto 0.14 available
 

I have released [URL="http://mersenneforum.org/mfakto/mfakto-0.14/"]mfakto 0.14.[/URL]

As most people seem to use the GPU sieve, I no longer created the versions with different (CPU-) sieve sizes. If anyone still needs them, just let me know.

Thanks to all testers!

Here again what's new:
[LIST][*]--perftest enhancements including GPU sieve evaluation (for optimizing GPUSievePrimes etc.)[*]successfully resync when the working directory was temporarily lost (ejected USB device or interrupted network drive)[*]save and reload compiled OpenCL kernels => reduce startup time (UseBinfile config variable)[*]MoreClasses config variable to allow for a "less classes" version for very short assignments (GPU sieve only)[*]BugFix: enforce GPUSieveSize being a multiple of GPUSieveProcessSize[*]FlushInterval config variable to fine tune the number of kernels in the GPU queue => address high CPU load issue of newer AMD drivers[*]MinGW build (thanks to kracker)[*]slight performance improvement for the montgomery kernels[*]improved English wording in program output, ini file etc. (thanks to kracker)[*]recognition of new GPUs (8xxx, R9, new APUs) (thanks to kracker)[*]added a warning when using VectorSize=1 (AMD driver issue (?), [URL]http://devgurus.amd.com/thread/167571[/URL])[*]fix for a small memory leak (~0.5kB per assignment)[*]works on Win8.1[/LIST]

I guess my OS is too old :razz:
[code]
./mfakto-x64: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.15' not found (required by ./mfakto-x64)
./mfakto-x64: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./mfakto-x64)
[/code]

I don't like it:
[LIST][*]there is no double speed improvement[*]there is no triple speed improvement[*]it can not play minesweeper! (thanks to kracker)...[/LIST]
:razz:


[COLOR=White]good work guys! thanks a lot![/COLOR]

[QUOTE=LaurV;371493]I don't like it:
[LIST][*]there is no double speed improvement[*]there is no triple speed improvement[*]it can not play minesweeper! (thanks to kracker)...[/LIST]
:razz:


[COLOR==White]good work guys! thanks a lot![//COLOR][/QUOTE]

[URL="http://fc02.deviantart.net/fs70/f/2010/185/3/0/Driving_Too_Fast_by_Fire_Warrioress.jpg"]...[/URL]

Is there any practical difference in the results from the pre4 version to the release? I discovered that I left the pre4 version running assignments for a couple of days. If needed I'll just rerun them but I rather run new assignments if I can. :smile:

/Göran

[QUOTE=Axelsson;371502]Is there any practical difference in the results from the pre4 version to the release? I discovered that I left the pre4 version running assignments for a couple of days. If needed I'll just rerun them but I rather run new assignments if I can. :smile:

/Göran[/QUOTE]

No, the different version string is the biggest difference :smile:
No need to rerun anything.

[QUOTE=kracker;371468]I guess my OS is too old :razz:
[code]
./mfakto-x64: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.15' not found (required by ./mfakto-x64)
./mfakto-x64: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./mfakto-x64)
[/code][/QUOTE]

Oops, I did not notice this new requirement when I switched to gcc 4.9 :shock: Can you install the 4.9 version or should I try to build on older gcc for you? :boxer:
I need to update the requirements section ...

[QUOTE=Bdot;371515]Oops, I did not notice this new requirement when I switched to gcc 4.9 :shock: Can you install the 4.9 version or should I try to build on older gcc for you? :boxer:
I need to update the requirements section ...[/QUOTE]

Don't worry, I built it myself again :smile:

Testing the latest version with R9 295X2. I tried varying a bunch of different settings, and the best I get is around 575 GHz-days/day. Not sure if I need to look at tweaking some AMD settings or if that's just the limit it can achieve. Definitely not hitting that predicted 1229 over in mersenne.ca though.

[QUOTE=tapion64;373008]Testing the latest version with R9 295X2. I tried varying a bunch of different settings, and the best I get is around 575 GHz-days/day. Not sure if I need to look at tweaking some AMD settings or if that's just the limit it can achieve. Definitely not hitting that predicted 1229 over in mersenne.ca though.[/QUOTE]

Have you tried running two instances?

[QUOTE=tapion64;373008]Testing the latest version with R9 295X2. I tried varying a bunch of different settings, and the best I get is around 575 GHz-days/day. Not sure if I need to look at tweaking some AMD settings or if that's just the limit it can achieve. Definitely not hitting that predicted 1229 over in mersenne.ca though.[/QUOTE]

Did you use the -d switches? For example: the first GPU on the 295X should be started with a .bat file > mfakto.x64 -d 1, the second: > mfakto.x64 -d 2

Ah, that was it. I didn't realize it would treat them as cross-fired devices instead of a single card. Making it separate instances works fine. Is there a way to have it draw work from one worktodo.txt for both, or do they just have to be in different directories?

[QUOTE=tapion64;373020]Is there a way to have it draw work from one worktodo.txt for both, or do they just have to be in different directories?[/QUOTE]

MISFIT will take care of the two worktodo.txt files for you, and feed them from a common staging file. AFAIK, mfaktX of all flavors requires separate directories and working files for multiple cards.

[QUOTE=tapion64;373008]Testing the latest version with R9 295X2. I tried varying a bunch of different settings, and the best I get is around 575 GHz-days/day. Not sure if I need to look at tweaking some AMD settings or if that's just the limit it can achieve. Definitely not hitting that predicted 1229 over in mersenne.ca though.[/QUOTE]

Nice, first look at the Hawaii core!
Well, with a bit of fiddling you should be able to get 600 GHz per core.

I guess I need to look into setting up MISFIT. The second core of the card is getting ~600, so I think just the cost of running graphics for my new monitor lowers the first one by about 50. Not that bad though, ~1175 combined.

[QUOTE=tapion64;373088]I guess I need to look into setting up MISFIT. The second core of the card is getting ~600, so I think just the cost of running graphics for my new monitor lowers the first one by about 50. Not that bad though, ~1175 combined.[/QUOTE]

I've used MISFIT for a long time. You can have it do as much, or as little as you like. You can make it a "set it and forget it" controller, which can handle much more than two instances, fetching, distributing, and submitting the results of processing. You can also use it as a convenient monitoring utility, and a flexible manual control interface.

I ran the oldest version of mfakto I could just for fun :razz:

0.10: 14m36s
0.14: 7m59s

[QUOTE=kracker;374137]I ran the oldest version of mfakto I could just for fun :razz:

0.10: 14m36s
0.14: 7m59s[/QUOTE]
Any newer or beta mfakto we could test on our GCN cards? I'd love to squeeze some more performace out of them. They're not 79xx renames, they're the real deal new chips.

If you want to squeeze more performance from mfakto, try to factor lower than 73 bits only. Contrary to mfaktc, where there is no big drop in performance for higher bitlevels (or, say, no big gain in performance for lower bit levels), for mfakto, especial for higher GCN cards, the "shorter" kernels are much faster. For example, I get from my HD7970 GHz edition, something like: 450GHzD/D when factoring 6xM to 74, but I get 500GHzD/D when factoring to 73 only, and so on. Decreasing the bitlevel increase the "gain" (but helps GIMPS less) and also decreasing the exponent increase the "gain", but only a little. For example, the same card I described above, gives 630-650GHzD/D when factoring 4xM exponents to 69 bits. Right now, Chris made them unavailable from GPU72, to channel the workers toward Cat4 exponents, but there are still [URL="http://www.gpu72.com/reports/current_level/"]35 thousands[/URL] of them (44-47M) at 68 bits, you can take them to 69 directly from PrimeNet, or ask Chris to make them available. For this range of expos and bitlevel, the performance of the card (kernel) is about 50% higher.

[QUOTE=tului;376583]Any newer or beta mfakto we could test on our GCN cards? I'd love to squeeze some more performace out of them. They're not 79xx renames, they're the real deal new chips.[/QUOTE]

If you have 0.14, that is basically the latest. Here's mfakto on github, if you're curious.
[url]https://github.com/Bdot42/mfakto[/url]

[QUOTE=kracker;376615]If you have 0.14, that is basically the latest. Here's mfakto on github, if you're curious.
[url]https://github.com/Bdot42/mfakto[/url][/QUOTE]

Yea, cloned the repository and built it with VS2013, so maybe with /AVX I get some small boost. Most of the files were dated with the 0.14 release so looks like nothing has changed since then. I also downloaded and built MISFIT from source and was playing with that some.

/avx can certainly help when the sieve runs on the CPU (SieveOnGPU=0). But usually, the CPU can no longer keep up with the GPU, especially for high-end GPUs.

Which cards do you have, I'd be interested to see some performance info, but I'm not yet finished with my changes for the --perftest mode ...

If you build it yourself, could you uncomment the #define CL_PERFORMANCE_INFO in params.h and build this as a special version (e.g. mfakto_pi.exe) ...
Then modify the mfakto.ini file to set SieveOnGPU=0 and run

mfakto_pi -st > st_pi.log

This will run the selftest with timing information for each of the kernel invocations. Using that information I can see if using different kernels can improve performance.

[QUOTE=Bdot;376664]/avx can certainly help when the sieve runs on the CPU (SieveOnGPU=0). But usually, the CPU can no longer keep up with the GPU, especially for high-end GPUs.[/QUOTE]

Hmm, I thought there has to be specific AVX code in source to be used?

[QUOTE=kracker;376667]Hmm, I thought there has to be specific AVX code in source to be used?[/QUOTE]

intrinsics can be used directly but afaik most modern compilers can look at the overall idea of what you're trying to do and possibly use AVX, SSE etc to improve it.

[QUOTE=Bdot;376664]/avx can certainly help when the sieve runs on the CPU (SieveOnGPU=0). But usually, the CPU can no longer keep up with the GPU, especially for high-end GPUs.

Which cards do you have, I'd be interested to see some performance info, but I'm not yet finished with my changes for the --perftest mode ...

If you build it yourself, could you uncomment the #define CL_PERFORMANCE_INFO in params.h and build this as a special version (e.g. mfakto_pi.exe) ...
Then modify the mfakto.ini file to set SieveOnGPU=0 and run

mfakto_pi -st > st_pi.log

This will run the selftest with timing information for each of the kernel invocations. Using that information I can see if using different kernels can improve performance.[/QUOTE]

I've got it running on 2 R7 260X cards at the moment. IB i5-3570K 16GB RAM at CAS 9 1866MHz. Do you want me to uncomment that and build them with the /SSE /AVX as well as all the other differing optimization levels or just use Ox(the full optimization mode) for all of them?

edit - anyone else having the main site crapping out with database errors right now @ 0122UTC ?

Attached are the logs, one for "SSE2" which is the default minimum for an x64 build. The other is of course with AVX, which has to be enabled via /arch:AVX.

Sadly I don't own a Haswell yet as I'm waiting for Haswell-E or I'd test AVX2 as well. If my wife lets me use her laptop I can get you numbers on an AMD A10-5750M APU with AVX as well. Sadly I don't think VS12 has any FMA options to play with.

[url]https://drive.google.com/file/d/0B0Yq8K5dWh1BaTU4V2FkRnY5M0E/edit?usp=sharing[/url]

[url]https://drive.google.com/file/d/0B0Yq8K5dWh1BU3FhX0ZOQTZXVGs/edit?usp=sharing[/url]

edit - Just glancing at them I don't see much difference. The small percentages here and there I see could be small bursts of CPU usage on my system. You know the kernels better than me so maybe they'll mean something to you.

[QUOTE=tului;376781]Attached are the logs, one for "SSE2" which is the default minimum for an x64 build. The other is of course with AVX, which has to be enabled via /arch:AVX.

Sadly I don't own a Haswell yet as I'm waiting for Haswell-E or I'd test AVX2 as well. If my wife lets me use her laptop I can get you numbers on an AMD A10-5750M APU with AVX as well. Sadly I don't think VS12 has any FMA options to play with.

[url]https://drive.google.com/file/d/0B0Yq8K5dWh1BaTU4V2FkRnY5M0E/edit?usp=sharing[/url]

[url]https://drive.google.com/file/d/0B0Yq8K5dWh1BU3FhX0ZOQTZXVGs/edit?usp=sharing[/url]

edit - Just glancing at them I don't see much difference. The small percentages here and there I see could be small bursts of CPU usage on my system. You know the kernels better than me so maybe they'll mean something to you.[/QUOTE]

[code]
WARNING: Your GPU was detected as GCN (Graphics Core Next). These chips perform very slow with vector sizes of 4 or higher. Please change to VectorSize=2 in mfakto.ini and restart mfakto for optimal performance.
[/code]

[QUOTE=kracker;376796][code]
WARNING: Your GPU was detected as GCN (Graphics Core Next). These chips perform very slow with vector sizes of 4 or higher. Please change to VectorSize=2 in mfakto.ini and restart mfakto for optimal performance.
[/code][/QUOTE]

Yes, but I was running with GPU Sieving off so afaik nothing was sent to the GPU. On my "production" build I have vectors set to 2

Well, it's true that some parts of the work (namely the sieving) will move to the CPU, but that's not the part that is measured by the PERFORMANCE_INFO test. This test takes timings of the actual trial factoring of the sieved list of factor candidates - and is still done on the GPU.

We had different goals: you wanted to test how CPU-code optimization affects performance, I wanted to get GPU performance figures for the newer GCN generation :smile:.

So while the GPU tests with VectorSize=4 are interesting, the same would be needed for VectorSize=2, in order to see which is faster. Though not likely, it is possible that the newer GCN/openCL compilers have improved performance for higher vectorization, but I still think that 2 is the number to choose. For the next mfakto version I will change the default ...

Could you please use the same binaries and run this test again with VectorSize=2?

To do the optimization tests you wanted, please build a binary with CL_PERFORMANCE_INFO and SIEVE_SIZE_LIMIT commented out. Then have a look at the ini-file settings

TestSieveSizes
TestSievePrimes
TestGPUSieveSizes

The first two define the CPU-sieving tests to be performed, the second and third define the GPU-sieving tests.

To actually run these tests, start 'mfakto --perftest <n>' where <n> is the number of times each test is repeated for more reliable results, default is 10. This test is aimed at finding the optimal sieve size, which depends on both the CPU architecture and the SievePrimes value to be used.

I'm enhancing the perftest piece by piece - the actual trial factoring is not yet included. But the sieving performance can be tested very well already.

I'm quite sure that you will see differences for the different optimization levels here.

[url]https://drive.google.com/file/d/0B0Yq8K5dWh1BWjlqRjAyVjY0elE/edit?usp=sharing[/url]

[url]https://drive.google.com/file/d/0B0Yq8K5dWh1BMS1waG5qZXhKVXM/edit?usp=sharing[/url]

Here they go.