Problem with GPU-CPU tasks

Jonatan
Jonatan
Joined: 20 Jun 10
Posts: 66
Credit: 25782906
RAC: 0
Topic 197423

Why am I crunching in the place of GPU one CPU + GPU, and it´s a CPU task, in the place of GPU task??

(1CPU+GPU) Gamma-ray task...I don´t understand...

Help please

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5872
Credit: 117920691281
RAC: 34549033

Problem with GPU-CPU tasks

Quote:
Why am I crunching in the place of GPU one CPU + GPU, and it´s a CPU task, in the place of GPU task??


With the new FGRP3 run, the same task could run on the CPU only (and take a long time) or it could run partially on the GPU and partially on the CPU (effectively tying up both) but taking much less time overall. For more details, read the announcement thread in Technical News.

Quote:
(1CPU+GPU) Gamma-ray task...I don´t understand...


A lot of the calculation still needs to be done on the CPU. It's just like when BRP4 first started on the GPU. It will improve over time.

Cheers,
Gary.

Pooh Bear 27
Pooh Bear 27
Joined: 20 Mar 05
Posts: 1376
Credit: 20312671
RAC: 0

With the improvements of the

With the improvements of the GPU App on BRP5, why is it still forcing a full CPU to hold on to? It seems it's mostly just feeding the GPU now and not using it much, if at all for calculation. My older ATI is running 2 simultaneous units at about 40K seconds, but only uses about 3.5K seconds (1.75K per unit) of CPU. I could be using that CPU for other work. It seems like a waste of a CPU now. I'd rather have the other 35+K seconds to utilize crunching another CPU project than to be idle.

Please consider releasing the CPU for other work.

mikey
mikey
Joined: 22 Jan 05
Posts: 12718
Credit: 1839121786
RAC: 3572

RE: With the improvements

Quote:

With the improvements of the GPU App on BRP5, why is it still forcing a full CPU to hold on to? It seems it's mostly just feeding the GPU now and not using it much, if at all for calculation. My older ATI is running 2 simultaneous units at about 40K seconds, but only uses about 3.5K seconds (1.75K per unit) of CPU. I could be using that CPU for other work. It seems like a waste of a CPU now. I'd rather have the other 35+K seconds to utilize crunching another CPU project than to be idle.

Please consider releasing the CPU for other work.

I agree...either use and release the cpu, or use it all the way thru at a level that makes sense to those of us crunching more then just Einstein. I also don't have any problem using and releasing, using and releasing, etc all the way thru the unit as long as the use and release part let's me also crunch Einstein cpu units for example, or cpu units from someplace else during the release phase. I think you could use the Boinc priority thing to grab the cpu for a running gpu unit for a very short time, then release it back to its regular crunching. Sure the cpu units will take a little bit longer, but I am effectively crunching 2 units at once on it. Not at EXACTLY the same time, but I think you know what I am trying to say.

Pooh Bear 27
Pooh Bear 27
Joined: 20 Mar 05
Posts: 1376
Credit: 20312671
RAC: 0

Can the admins of this

Can the admins of this project review our request and reply, or should we start a new thread to get attention?

Thanks.

floyd
floyd
Joined: 12 Sep 11
Posts: 133
Credit: 186610495
RAC: 0

I'm no admin but you have my

I'm no admin but you have my attention. However, I'm not sure I understand exactly what you're talking about. I'm not even sure you're all talking about the same thing. Just some comments on two topics that could be meant in my opinion.

CPU assignment: Which job does or does not get to use the CPU. Neither Einstein nor BOINC control this. In particular, noone can hog the CPU without using it and noone actively prevents others from getting the CPU.

BOINC's job management: How many jobs to start, when to suspend or resume them. Einstein can only influence this indirectly by telling BOINC how much CPU and GPU use to assume for a particular application. These values are purely informational however, they don't control the actual use. Plus they can't be correct for every system. If you want to adjust the numbers, or if you just want to trick BOINC into starting more jobs than can run at the same time to make sure the CPU is never idle, you might want to read about the app_config file. But beware, there is no such thing as keeping a CPU core free for GPU jobs.

If it's something else you were talking about please be more explicit.

Pooh Bear 27
Pooh Bear 27
Joined: 20 Mar 05
Posts: 1376
Credit: 20312671
RAC: 0

RE: f it's something else

Quote:
f it's something else you were talking about please be more explicit.


Einstein steals a CPU for any GPU work. I run 4 cores CPU, and my GPU, but when I run Einstein it takes one of the CPUs, so only 3 run. Other projects (MW, PG, Seti, etc), I can still run all 4 CPUs and the GPU and not have it steal one.

The GPU application is mostly GPU now, unlike previous iterations of Einstein applications, so I would like Einstein to release the hold on the CPU as it does and allow that CPU to crunch other items and only take it over when needed like other projects allow.

Richard Haselgrove
Richard Haselgrove
Joined: 10 Dec 05
Posts: 2143
Credit: 2963929022
RAC: 710516

RE: RE: f it's something

Quote:
Quote:
f it's something else you were talking about please be more explicit.

Einstein steals a CPU for any GPU work. I run 4 cores CPU, and my GPU, but when I run Einstein it takes one of the CPUs, so only 3 run. Other projects (MW, PG, Seti, etc), I can still run all 4 CPUs and the GPU and not have it steal one.

The GPU application is mostly GPU now, unlike previous iterations of Einstein applications, so I would like Einstein to release the hold on the CPU as it does and allow that CPU to crunch other items and only take it over when needed like other projects allow.


But compare your observation with OverToneSinger's post just now in the News area. If a CPU core isn't made available by Einstein 'grabbing' it (as you put it), einstein apps tend to run very, very, slowly: I commented on that when testing the OpenCL BRP app for Intel_GPU.

At the moment, you pays your money and you takes your choice: either surrender a CPU, so other projects suffer but Einstein runs fast, or keep it out of Einstein's clutches and watch Einstein sulk.

The strange thing with the Intel GPU app was that it didn't seem to actually do anything with the freed CPU - it just liked to have it around, like a comfort blanket. That behaviour is unusual, by comparison with other GPU projects I've run: if Einstein could cure the behaviour, then (and only then) would be the time to stop it claiming a CPU to help the GPU app as well.

Pooh Bear 27
Pooh Bear 27
Joined: 20 Mar 05
Posts: 1376
Credit: 20312671
RAC: 0

RE: The strange thing with

Quote:
The strange thing with the Intel GPU app was that it didn't seem to actually do anything with the freed CPU - it just liked to have it around, like a comfort blanket. That behaviour is unusual, by comparison with other GPU projects I've run: if Einstein could cure the behaviour, then (and only then) would be the time to stop it claiming a CPU to help the GPU app as well.


You are talking Intel GPU, I am talking ATI GPU. Two who different animals. I can understand Intel taking a GPU. ATI and NVidia are much more efficient because they are not part of the same chipset as the Intel GPU is.

floyd
floyd
Joined: 12 Sep 11
Posts: 133
Credit: 186610495
RAC: 0

RE: RE: f it's something

Quote:
Quote:
f it's something else you were talking about please be more explicit.

Einstein steals a CPU for any GPU work. I run 4 cores CPU, and my GPU, but when I run Einstein it takes one of the CPUs, so only 3 run. Other projects (MW, PG, Seti, etc), I can still run all 4 CPUs and the GPU and not have it steal one.

The GPU application is mostly GPU now, unlike previous iterations of Einstein applications, so I would like Einstein to release the hold on the CPU as it does and allow that CPU to crunch other items and only take it over when needed like other projects allow.

Sorry, I can't reproduce that. I can run any single BRP task without it blocking a CPU core. Either you are running multiple in parallel or something has changed from BOINC 7.0 to 7.2.

You can make BOINC run 4 CPU tasks and 1 GPU task or even more using app_config.xml, but the results may not be what you hope for. Depending on the real CPU load you may experience a significant slowdown on all 5 tasks, especially with FGRP.

Edit: app_config (was app_info)

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5872
Credit: 117920691281
RAC: 34549033

RE: With the improvements

Quote:
With the improvements of the GPU App on BRP5, why is it still forcing a full CPU to hold on to?


Nothing is being 'forced'. It's a 'recommendation' that BOINC accepts and you are quite free to change it if you so desire. You can change it by setting up an app_config.xml file.

For NVIDIA GPUs, the recommendation is 0.2 CPUs per concurrent GPU task and for AMD it's 0.5. For your situation, if you were to change the 0.5 to 0.45 (for example) BOINC would then allow 2 GPU tasks with all CPU cores also running tasks. I'm pretty sure there would be a significant drop in overall performance if you did that, though. You might actually get better overall performance by cutting back to just one GPU task (which may well take only half the time - so no loss of output) and allowing all CPU cores to run. Run times should be less affected by GPU support duties. Have you tried that?

Cheers,
Gary.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.