SOG is an open cl app as I understand. Is there a appreciable difference in run time between running open cl on Windoz vs Linux? The reason I ask is Einstein recently came out with an open cl app and it runs 5 to 10 times faster on Linux than Windoz. Is that something inherent in Linux or just the way the app was written?

---

When I moved one of my crunchers from Windows to Linux it briefly ran SoG applications. I found very little difference in run times, but there was a reduction in the demands on the CPU.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Since the seti apps have the same codebase for windows and Linux i can say there is no big difference in speed.
Of course drivers are different so it might vary a little bit.

---

With each crime and every kindness we birth our future.

I have noticed a *tremendous* difference when using Linux vs Windows. My dual Nvidia 1070 system, under Windows, maxes out around 45k RAC, but under Linux, it hovers around 70-75k RAC with the "special sauce" app for Linux. I can't explain why there's a discrepancy, or what causes it, but Linux gets significantly more work done for a given time period than Windows.

The big improvement using the TBar/Petri special application over SoG or SAH is that the special application is very highly optimised, using some "tricks" that may not work properly under Windows. There are a few folks working hard to get them to work under windows, but it is proving to be somewhat challenging.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Is it in essence mostly about "sleep" and timer accuracy?

If so, can in Windows HPET be used? Sure, it has to be enabled first as I think it is disabled by default...

---

Hi,

It is not about sleep and other things. It mostly about
a) distributing the work that has to be done to all 'symmetrical multiprocessing units' (SM/SMX).
b) doing 'some' optimisations on the code itself
c) using shared memory where applicable (that is not published yet to other CUDA developers)
d) doing autocorrelation fft in a novel way needing way less memory accesses and less computation.
e) queueing tasks so that more gets done at a time
f) optimising kernel register usage and kernel size
g) some other minor stuff

The a) is the hardest part to do right.
I'm running now a version l (L stands for locking/synchronising globally). The version helps a lot, but is not bug free. It can not be published yet. Main reason being occasional lockups.

Previous versions had problems with the order of 'finding/reporting' pulses and sometimes reporting a bad value.

My code is something before alpha. I test it first. Then others (superior people) test it and after it has been field proofed by a small and a larger group of users in the beta to be 'valid' the others can get it. Otherwise we'd ruin the science.

You may ask: Why do you run it on main? -- I do, because it is allowed and encouraged to do so. At the same time I can show what is possible and the caveats of doing so. And I also run it on beta ofcause.

--
Petri

---

To overcome Heisenbergs:
"You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones

e) queueing tasks so that more gets done at a time

I suspect that alone saves a good chunk of time.
I notice running SoG that the first 14-20secs of WU processing isn't done on the GPU (GPU load is 0%). Pre-processing the next WU to run so that when it starts, it starts crunching on the GPU straight away would save that 14-20secs on every WU.

---

Grant
Darwin NT

e) queueing tasks so that more gets done at a time

I suspect that alone saves a good chunk of time.
I notice running SoG that the first 14-20secs of WU processing isn't done on the GPU (GPU load is 0%). Pre-processing the next WU to run so that when it starts, it starts crunching on the GPU straight away would save that 14-20secs on every WU.

That is an interesting find.

I'm sure Raistmer can tell more about that. And anyone running SoG can run 2 at a time to overcome that.
The e) queueuing ... is done on CPU to fill the GPU queues to the max. That can be micromanaged too. Sometimes it pays off at the end to do some beforehandwork (Grand total.)

Please insert space(s) where ever you want to. Then after that to the Press Space Bar to continue!
EDIT: My RAC hit 200 000! while writing this.

---

To overcome Heisenbergs:
"You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones

I'm sure Raistmer can tell more about that. And anyone running SoG can run 2 at a time to overcome that.

I've run 2 at a time with my particular command line settings, and the only improvement I got was about an extra 1-1.5 WUs per hour. Not really worth it IMHO.
But it looks like it that gain would mostly be the result of offsetting that initial CPU setup work period. It's nothing like the benefit with CUDA50 of running 2 (or more) at a time.

EDIT: My RAC hit 200 000! while writing this.

Nothing else comes close to boosting the numbers like all Arecibo work.
;-)

---

Grant
Darwin NT

I'm sure Raistmer can tell more about that. And anyone running SoG can run 2 at a time to overcome that.

I've run 2 at a time with my particular command line settings, and the only improvement I got was about an extra 1-1.5 WUs per hour. Not really worth it IMHO.
But it looks like it that gain would mostly be the result of offsetting that initial CPU setup work period. It's nothing like the benefit with CUDA50 of running 2 (or more) at a time.

EDIT: My RAC hit 200 000! while writing this.

Nothing else comes close to boosting the numbers like all Arecibo work.
;-)

Yes,

I noticed the APR to bump up from 1300 to over 1700.
I wonder what it will do: one credit per second times four times 24. (If it lasts)

---

To overcome Heisenbergs:
"You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones