EM searches, BRP Raidiopulsar and FGRP Gamma-Ray Pulsar

Tom M
Tom M
Joined: 2 Feb 06
Posts: 6,258
Credit: 8,917,903,658
RAC: 10,481,830

Peter Hucker of the Scottish

Peter Hucker of the Scottish Boinc Team wrote:

There seems to be a lot of FGRP5 (CPUs?) to do.  Can this not be moved over to graphics cards?

A very good question.  If it was easy to switch them between CPU and GPU tasks someone would probably have noticed it. And told the rest of us (and me too).

A very small stream of grp#1 tasks is being downloaded.  But they usually require either a lot of manual updates to get them or some kind of automated script that triggers the update using the BOINC command line interface.

As it is, if you have an operating system/card that will run brp7 (aka MeerKAT) you can process those much more easily.

Here is what I am told is available.

Hope it helps.

Tom M

 

A Proud member of the O.F.A.  (Old Farts Association).  Be well, do good work, and keep in touch.® (Garrison Keillor)

TRAPPIST-713
TRAPPIST-713
Joined: 13 May 20
Posts: 12
Credit: 2,415,581,413
RAC: 1,477,640

Question out of curiosity: Is

Question out of curiosity: Is it true that CPU-based searches are more thorough but slow while GPU searches are generally less thorough but fast?

Tom M
Tom M
Joined: 2 Feb 06
Posts: 6,258
Credit: 8,917,903,658
RAC: 10,481,830

TRAPPIST-713 wrote: Question

TRAPPIST-713 wrote:

Question out of curiosity: Is it true that CPU-based searches are more thorough but slow while GPU searches are generally less thorough but fast?

That is a great question.  And I don't have a clue.  I am presuming the actual algorithms are the same.  Its just that gpus can run the code in parallel which speeds it up (significantly :)

But you raise a good point.  Gary? Petri?  Someone who has asked that question and/or studied the code(s)?

Tom M

A Proud member of the O.F.A.  (Old Farts Association).  Be well, do good work, and keep in touch.® (Garrison Keillor)

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4,305
Credit: 248,831,406
RAC: 33,669

TRAPPIST-713 wrote:Question

TRAPPIST-713 wrote:

Question out of curiosity: Is it true that CPU-based searches are more thorough but slow while GPU searches are generally less thorough but fast?

Not exactly. There are a couple of things that determine whether a search would run on the CPUs or the GPUs. These include:

- total computing power needed for a search: of course

- boundary conditions: the Gamma-Ray search for isolated pulsars (currently FGRP5) requires an FFT length that we can't get on the GPUs, at least we couldn't get with the libraries and GPU memory that was available at the time when we started it.

- memory access / algorithm: GPU memory access is horribly slow compared to computation. It took us a couple of years and four (IIRC) attempts to find and implement an algorithm for the GW search with a memory access pattern such that using the GPU is really faster than using the CPU

- workunit "size": With the first GPU apps we had for the Arecibo Radio-Pulsar search (an early BRP, I think even called ABP2) the turnaround times became so short that it blew the whole system (DB, workunit generator etc.). Ultimately we learned to deal with it, mostly by "bundling" "atomic" tasks together for shipping. Putting the current FGRP5 tasks on the GPUs as they are might have a similar effect, though our whole system is much more powerful and robust nowadays.

- computing/data ratio: it doesn't help much if the GPU computing is held up by downloading the tasks. Searches that have a low computing/data ratio are better ran on the CPU (I don't think we currently have such searches, though).

BM

GWGeorge007
GWGeorge007
Joined: 8 Jan 18
Posts: 2,997
Credit: 4,926,044,438
RAC: 129,282

Bernd Machenschalk

Bernd Machenschalk wrote:

TRAPPIST-713 wrote:

Question out of curiosity: Is it true that CPU-based searches are more thorough but slow while GPU searches are generally less thorough but fast?

Not exactly. There are a couple of things that determine whether a search would run on the CPUs or the GPUs. These include:.....

.....snip.....

And that, my friends, is why Bernd is there working with others of his caliber at Einstein, while we are just sitting around watching our computers do the things that Bernd says we should do.

Way to go, Bernd!

George

Proud member of the Old Farts Association

TRAPPIST-713
TRAPPIST-713
Joined: 13 May 20
Posts: 12
Credit: 2,415,581,413
RAC: 1,477,640

Bernd, great insight! Thanks.

Bernd, great insight! Thanks.

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4,305
Credit: 248,831,406
RAC: 33,669

And of course the most

And of course the most obvious one is still missing in that list: E@H is in the comfortable situation that we finally have GPU versions of basically all our search applications. However a completely new application is much easier to develop and deploy for CPUs. Porting to the GPU then is another step that takes some extra time and effort.

BM

Boca Raton Community HS
Boca Raton Comm...
Joined: 4 Nov 15
Posts: 233
Credit: 9,513,528,920
RAC: 23,166,502

Question. So, these tasks are

Question. So, these tasks are set to use .2 of the CPUs and I have it set to use .33 of the GPUs. In our system that has three GPUs (so it is running 9 of these tasks at any given time), will it also "fill" a CPU core and use 1 core for 5 of these tasks simultaneously (.2 + .2 + .2 + .2 + .2) OR is the core completely reserved for one work unit at a time? Would there be any advantage to changing the CPUs usage from .2? 

I hope this makes sense. 

Keith Myers
Keith Myers
Joined: 11 Feb 11
Posts: 4,895
Credit: 18,439,447,334
RAC: 5,765,226

The tasks do not really use

The tasks do not really use 0.2 of a cpu.  They use exactly how much or how little of a cpu that they need for each task.  No one seems to grasp the concept that the application itself determines how much cpu it needs for a task.

BOINC has no control over the science application resource usage.

The only thing you are doing is describing to BOINC is how much cpu a task might use for BOINC scheduling purposes.

 

Mr P Hucker
Mr P Hucker
Joined: 12 Aug 06
Posts: 838
Credit: 518,662,512
RAC: 39,417

Indeed.  What I do is set

Indeed.  What I do is set Boinc to use 100% of CPU cores, so it tries to run GPU and CPU stuff all at once.  I then check using MSI Afterburner (or similar) to see % usage of CPU and GPU.  I try to make them both near 100%, especially the more powerful GPU.  If the GPU is too low, I first try to run multiple instances at once (up to 4 per card), also limited by GPU RAM usage.  If that isn't enough, I allocate CPU cores to the GPU tasks in app_config, 1 core at a time, until I get a fully utilised GPU.

For example, an i5 8600K (6 core CPU) with two Radeon R9 280X (Tahiti) GPUs.  I set to 100% CPU usage and this in the app config for Einstein:

<app_config>
    <app>
        <name>einsteinbinary_BRP7</name>
        <gpu_versions>
            <gpu_usage>0.500000</gpu_usage>
            <cpu_usage>0.500000</cpu_usage>
        </gpu_versions>
    </app>
</app_config>

This means 2 per card, totalling 4 tasks, which together reserve 2 CPU cores.

This is better than manually lowering the CPU cores used, because it's different for every project.

If this page takes an hour to load, reduce posts per page to 20 in your settings, then the tinpot 486 Einstein uses can handle it.

Comment viewing options

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