Excellent.

---

I'd rather they put the energy into fixing the credit system...

Chris

---

I've just been crunching the MB v8 numbers from the Applications page:

				GigaFLOPS
			
Windows	CPU			311,489
	NV			185,044
	ATI			  8,007
	Intel gpu		  3,891
			
Linux	CPU			 52,440
	NV			  2,150
	ATI			    379
	Intel gpu		      3
			
Mac OSX	CPU			 41,418
	NV			    954
	ATI			  3,949
	Intel gpu		  1,062
			
Android	ARM			  2,079
	x86			    121
			
Linux	ARM			    357
			
			Total	613,343

In other words, using those admittedly dodgy figures, Wintel x86 CPUs contribute more to SETI than every other processing path put together.

Modern massively-parallel GPUs aren't well adapted to the sort of mathematical work - yes, VLAR - which SETI needs to do to deal with the results of targeted telescopic observations of candidate planets. Sadly, the GPU tail is trying to wag the SETI dog: it would be better if the GPU power was utilised on the type of mathematics it excels at.

I've just been crunching the MB v8 numbers from the Applications page:

				GigaFLOPS
			
Windows	CPU			311,489
	NV			185,044
	ATI			  8,007
	Intel gpu		  3,891
			
Linux	CPU			 52,440
	NV			  2,150
	ATI			    379
	Intel gpu		      3
			
Mac OSX	CPU			 41,418
	NV			    954
	ATI			  3,949
	Intel gpu		  1,062
			
Android	ARM			  2,079
	x86			    121
			
Linux	ARM			    357
			
			Total	613,343

In other words, using those admittedly dodgy figures, Wintel x86 CPUs contribute more to SETI than every other processing path put together.

Modern massively-parallel GPUs aren't well adapted to the sort of mathematical work - yes, VLAR - which SETI needs to do to deal with the results of targeted telescopic observations of candidate planets. Sadly, the GPU tail is trying to wag the SETI dog: it would be better if the GPU power was utilised on the type of mathematics it excels at.

Makes sense, as there are many many more simple CPU only set and forget users out there than there are powerhouse GPU fiends.....

---

"Time is simply the mechanism that keeps everything from happening all at once."

I was able to contact Dr. Eric Korpela. He indicated that a solution to allow GUPPI VLAR GPU work units to be refused in the Project Prefs. is being worked on. Please pass it along...

Hope this alleviates any of the misgivings that the project admins. aren't aware of this issue or don't care about it.

Excellent news.
As I have said, I will crunch whatever the servers send. However, that does not mean that if preferences are allowed, I would not choose to get work that I can process more efficiently.

I had personally asked Eric for this on the 15th, but he replied that he had tried it on Beta and it did not work.

Glad to hear he kept thinking about it and may be able to offer us the choice.

Thank you, Eric.

Meow!

---

"Time is simply the mechanism that keeps everything from happening all at once."

Alas, the Mac CPU numbers could be nearly doubled if we had stock optimized apps released. They exist but never have made it to main, but that for a different topic I suppose...

Chris

I've just been crunching the MB v8 numbers from the Applications page:

				GigaFLOPS
			
Windows	CPU			311,489
	NV			185,044
	ATI			  8,007
	Intel gpu		  3,891
			
Linux	CPU			 52,440
	NV			  2,150
	ATI			    379
	Intel gpu		      3
			
Mac OSX	CPU			 41,418
	NV			    954
	ATI			  3,949
	Intel gpu		  1,062
			
Android	ARM			  2,079
	x86			    121
			
Linux	ARM			    357
			
			Total	613,343

In other words, using those admittedly dodgy figures, Wintel x86 CPUs contribute more to SETI than every other processing path put together.

Modern massively-parallel GPUs aren't well adapted to the sort of mathematical work - yes, VLAR - which SETI needs to do to deal with the results of targeted telescopic observations of candidate planets. Sadly, the GPU tail is trying to wag the SETI dog: it would be better if the GPU power was utilised on the type of mathematics it excels at.

---

After reading the thread I got a P.M from someone saying to abort the vlars .

Even if Eric can come up with a option to not do them it doesn't fix the problem but only prolongs it . If every one choices to not do them the work just won't get completed

I still think a simple formula to add a extra 80 credits for units that do take longer than a hour and every hour over 1 hour is the fairest thing to do .

And sorry guys I don't believe it can't be done and I don't believe it won't work I also don't believe it would be to complicated either .

The work will get done and there won't be anybody aborting thousands of units

The problem with the vlars is when it switches back to the CPU it slows other units down .

Ergo it's why a CPU AP took more 48hrs to complete . Yes they take a lot longer on a CPU but not that F-ing long more like a max of 28 hrs not over 48
so I got penalised twice , the AP took longer and the Guppi took longer .

hence the Rac in free fall from 7800 to 5900 as of last night . Getting to the point where it just not worth running the GPU at all

Edit : The switching back and forth from cpu to gpu when there is to much noise is causing a problem . If I'm understanding what happens with Vlars ...?

---

Alas, the Mac CPU numbers could be nearly doubled if we had stock optimized apps released. They exist but never have made it to main, but that for a different topic I suppose...

Chris

Well it is connected. Here's some older numbers from my Mac (though less immediately relevant, they are illustrative)

In other words, using those admittedly dodgy figures, Wintel x86 CPUs contribute more to SETI than every other processing path put together.

Those figures Richard used, Unstable as they may be, are better than the Boinc Whetstone being applied as 'peak' to Credit:

From my Mac Host (best example here because CPU is off on my Core2+Windows):

Measured floating point speed 4801.32 million ops/sec

While For v7 CPU Stock (v8 CPU been turned off to keep heat+power down in here):

Average processing rate 18.45 GFLOPS

and Anon v7 CPU:

Average processing rate 34.26 GFLOPS

Cool how by Apple building Harry Potter into the ugliest PC ever made, I can average multiples of 100% efficiency according to the estimate/credit mechanism. Someone should call Elon Musk.

Will be interesting to see what APR drops out to with v8, so enabling some threads later (when I get around to it).

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Depending on how many CPU's I use (usually use around 90% Of the count for CPU crunching and the rest reserved for feeding the GPU’s) my SSE4.1 and AVX enable macs get 25-30GLOPs(AVX) and 16GFLOPs (SSE4.1) with optimized apps compare to 13-15 and 8 respectively. All of this I from the apps Tbar put up on CA.

I just thought k was Apple magic that made them faster that the benchmarks...lol:)

Chris

---

The reason I chose 80 as the extra credit is because a 450 GPU will do one unit per hour at least so would be the mid range of all GPU's out there being used and will not sque the results to much in favour of the slower computers and won't penalise the faster one's to much and would be fair .

You can argue over weather 80 is the right amount to give or try and average out how long the units take and come up with a appropriate value

So please Mr Anderson or Eric consider what I am saying as I do think it's the most appropriate way to go with the least amount of coding .

(yes I don't know the inner workings but I don't think I'm wrong)

I'm talking MB's Cuda as the average for the extra credit not Vlars

---

Depending on how many CPU's I use (usually use around 90% Of the count for CPU crunching and the rest reserved for feeding the GPU’s) my SSE4.1 and AVX enable macs get 25-30GLOPs(AVX) and 16GFLOPs (SSE4.1) with optimized apps compare to 13-15 and 8 respectively. All of this I from the apps Tbar put up on CA.

I just thought k was Apple magic that made them faster that the benchmarks...lol:)

Chris

Lol, yeah, Dat Harry Potter. Mine's Pre-AVX but some massive cached high clocked update (lucked out on eBay I guess). Anyway, pretty clear there already exists a more realistic (global average) number than Boinc Whetstone to normalise to. Averages are bad, but still better than completely inappropriate numbers (single core FPU Whetstone being not applicable here on any machine+app).

In any case, onto re-tooling for the other half of the problem, in that Guppi VLARs genuinely process less efficiently on the GPUs.

The oddly specific 8.3 month estimate I made earlier for the system to 'break', was my prediction of how long it will take to achieve the following:
- apply some special optimisations wholesale.
- Multithread the applications
- Use multiple streams and/or multiple devices more efficiently
- Tools to automatically configure the above depending on user needs
- nanocluster multiple devices to a single Boinc client

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Hehe, this is getting funnier and funnier. I wonder what "will break within the next 8.3 months" as Jason says

Your not wrong there ! , I herd a mummer that Greenbank is coming to the end of it life and will close

So Jason what have you herd ....8.3 months is it ?

---

I've just been crunching the MB v8 numbers from the Applications page:

				GigaFLOPS
			
Windows	CPU			311,489
	NV			185,044
	ATI			  8,007
	Intel gpu		  3,891
			
Linux	CPU			 52,440
	NV			  2,150
	ATI			    379
	Intel gpu		      3
			
Mac OSX	CPU			 41,418
	NV			    954
	ATI			  3,949
	Intel gpu		  1,062
			
Android	ARM			  2,079
	x86			    121
			
Linux	ARM			    357
			
			Total	613,343

In other words, using those admittedly dodgy figures, Wintel x86 CPUs contribute more to SETI than every other processing path put together.

Modern massively-parallel GPUs aren't well adapted to the sort of mathematical work - yes, VLAR - which SETI needs to do to deal with the results of targeted telescopic observations of candidate planets. Sadly, the GPU tail is trying to wag the SETI dog: it would be better if the GPU power was utilised on the type of mathematics it excels at.

How Anonymous platform work accounted here?

I'd rather they put the energy into fixing the credit system...

Chris

Agree 100%. But until management accepts that it *IS* a problem, nothing will be done.

All the best,
Aaron Lephart

---

I've just been crunching the MB v8 numbers from the Applications page:

GigaFLOPS

Windows CPU 311,489
NV 185,044
ATI 8,007
Intel gpu 3,891

Linux CPU 52,440
NV 2,150
ATI 379
Intel gpu 3

Mac OSX CPU 41,418
NV 954
ATI 3,949
Intel gpu 1,062

Android ARM 2,079
x86 121

Linux ARM 357

Total 613,343

In other words, using those admittedly dodgy figures, Wintel x86 CPUs contribute more to SETI than every other processing path put together.

Modern massively-parallel GPUs aren't well adapted to the sort of mathematical work - yes, VLAR - which SETI needs to do to deal with the results of targeted telescopic observations of candidate planets. Sadly, the GPU tail is trying to wag the SETI dog: it would be better if the GPU power was utilised on the type of mathematics it excels at.

How Anonymous platform work accounted here?

What Raistmer says

hehehe That's why it's credit screw bro hehehehe

---

I was able to contact Dr. Eric Korpela. He indicated that a solution to allow GUPPI VLAR GPU work units to be refused in the Project Prefs. is being worked on. Please pass it along...

Hope this alleviates any of the misgivings that the project admins. aren't aware of this issue or don't care about it.

It would be nice if the selection for all types of WU in the project prefs was selectable seperately for GPU and CPU.

---

Kevin

Chris

Well it is connected. Here's some older numbers from my Mac (though less immediately relevant, they are illustrative)

In other words, using those admittedly dodgy figures, Wintel x86 CPUs contribute more to SETI than every other processing path put together.

Those figures Richard used, Unstable as they may be, are better than the Boinc Whetstone being applied as 'peak' to Credit:

From my Mac Host (best example here because CPU is off on my Core2+Windows):

Measured floating point speed 4801.32 million ops/sec

While For v7 CPU Stock (v8 CPU been turned off to keep heat+power down in here):

Average processing rate 18.45 GFLOPS

and Anon v7 CPU:

Average processing rate 34.26 GFLOPS

Cool how by Apple building Harry Potter into the ugliest PC ever made, I can average multiples of 100% efficiency according to the estimate/credit mechanism. Someone should call Elon Musk.

Will be interesting to see what APR drops out to with v8, so enabling some threads later (when I get around to it).

Also keep in mind that running multiple WUs on a GPU results in a much lower APR number, even though you actually process more work...

---

Grant
Darwin NT

Hehe, this is getting funnier and funnier. I wonder what "will break within the next 8.3 months" as Jason says

Your not wrong there ! , I herd a mummer that Greenbank is coming to the end of it life and will close

So Jason what have you herd ....8.3 months is it ?

Just read in this article

"In July 2015, the NRAO received 
funding for the Green Bank Telescope for at least five more years."

Of course, in an earlier article I also read that they were looking for sponsors, and some universities had kicked in some funds in exchange for some exclusive access, so not sure what if any effect it might have on us here.

---

Hehe, this is getting funnier and funnier. I wonder what "will break within the next 8.3 months" as Jason says

Your not wrong there ! , I herd a mummer that Greenbank is coming to the end of it life and will close

So Jason what have you herd ....8.3 months is it ?

Just read in this article

"In July 2015, the NRAO received 
funding for the Green Bank Telescope for at least five more years."

Of course, in an earlier article I also read that they were looking for sponsors, and some universities had kicked in some funds in exchange for some exclusive access, so not sure what if any effect it might have on us here.

Nothing too mysterious there. It's my calculation of when modern multithreaded+heterogeneous applications start to completely replace single resource focussed applications. Use the best tool for the best job is becoming a thing, in the age of efficiency. Heterogeneous models break Boinc.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

The Listen Breakthrough initiative is supporting Green Bank, Parkes in Australia and the Lick Observatory for optical SETI.
Tullio

---