I was wondering, why do so many BOINC projects waste their time writing a CPU only application for their BOINC project. GPUs are inherently more parallel and always have much higher FLOPS. CPUs struggle to get anywhere near the 1 TeraFLOPS range while most gaming GPUs are 5+ TeraFLOPS.

You have the ability to have multiple GPUs per system, making the FLOPS per watt higher, increasing efficiency and miniming cost for things like power suppply and hard drive.

They don't even make CPU coprocessors on expansion cards for consumers so why would projects like LHC, which have more data to crunch than just about anyone, spend the time to develop a CPU only project?

So... Have you ever written at least one line of the code? No? That's what I thought... ;)

CPU core can be imagined as math professor, GPU as thousand of 8th graders. So when you have to count trees in the forest, bunch of kids would do it faster. But try to use them to calculate optimal path for a rocket going to the moon ;)

In short - not every algorithm can be used on GPU (in fact - the most can't).

Calculating an optimal path of a rocket is millions of trials done by the processor. A CPU does this in serial while a GPU does each trial more slowly but does millions in parallel. Math professor vs 8th graders might not be the best comparison as 8th graders will never be able to come to an accurate conclusion, while a GPU core can, just much more slowly.

Ray tracing is a good example of parallel trajectory calculations. This activity is far too demanding for a serial based CPU to have a real-time result.

We need to step away from single threaded code. Every new project has a GPU application. XANSONS4COD, Drugdiscovery@home, these projects realize this potential. I understand code is written in a very serial fashion but this simply means we need to rethink how we operate and code.

I was wondering, why do so many BOINC projects waste their time writing a CPU only application for their BOINC project.

GPUs are inherently more parallel and always have much higher FLOPS.

CPUs struggle to get anywhere near the 1 TeraFLOPS range while most gaming GPUs are 5+ TeraFLOPS.

You have the ability to have multiple GPUs per system, making the FLOPS per watt higher, increasing efficiency and minimizing cost for things like power supply and hard drive.

They don't even make CPU coprocessors on expansion cards for consumers

so why would projects like LHC, which have more data to crunch than just about anyone, spend the time to develop a CPU only project?

CPU and GPU are different in architecture and purpose. CPUs are designed as CISC, which means they have a rather "Complex Instruction Set" making them more versatile in application and easier to program. However simultaneity is limited and the instruction set balooned for by making them downwards compatible e.g. 16 or 32Bit operation compliance. But the common personal computer wouldn't have started its triumph without it.

Modern GPU are designed a completely different way, their main purpose is maximum concurrency of tasks of similar kind. Their instruction set is limited and therefore reminds of RISC, whereas the concurrency somewhat reminds me of the old transputer concept. (Although the idea of passing tasks from one node to the next node was not followed up, unfortunately.)

Translating CPU code to GPU code e.g. CUDA is not straightforward for the reasons abovementioned. And it does not always make sense anyway. There sometimes are calculations with little substeps and a lot of dependencies, which means, little to decompose and not many tasks to parallelize. In that case, the GPU might even be slower than a CPU.
____________
I would love to see HCF1 protein folding and interaction simulations to help my little boy... someday.

A good example of a very successful CISC concept is the human brain ... little parallelism of a limited number of specialized brain areas, which still show an astounding neuroplasticity. In fact, the brain is getting more and more complex over the years, and it’s the perfect control unit for mastering the challenges of life. Evolution and natural selection prove that.

Guess how successful our brain would be with (GPU-like) 256 olfactory centres and 64 visual centres. You could smell 256 different odors at the same time ... but still you would hardly complete a grammar school education thereby.
____________
I would love to see HCF1 protein folding and interaction simulations to help my little boy... someday.

Calculating an optimal path of a rocket is millions of trials done by the processor. A CPU does this in serial while a GPU does each trial more slowly but does millions in parallel. Math professor vs 8th graders might not be the best comparison as 8th graders will never be able to come to an accurate conclusion, while a GPU core can, just much more slowly.

Ray tracing is a good example of parallel trajectory calculations. This activity is far too demanding for a serial based CPU to have a real-time result.

We need to step away from single threaded code. Every new project has a GPU application. XANSONS4COD, Drugdiscovery@home, these projects realize this potential. I understand code is written in a very serial fashion but this simply means we need to rethink how we operate and code.

"... whereas the concurrency somewhat reminds me of the old transputer concept..."

Wow - there's a term I haven't heard in an age. INMOS, T800, C004, B012, Occam...good times!

Win

CPUs and GPUs are both just dumb machines. All they can do is crunch ones and zeroes. A programmer writes the code to convert these useless ones and zeroes into something useful. It is easier to write code for CPUs than GPUs, okay I got that. It is not impossible to write code for GPUs, (this and other GPU projects are proof of that), just more difficult.

Calculating 27 is bad example to use. From a human perspective, if that all you have to calculate, either will do fine. The human brain will also do fine. However, if you have a vast quantity of simple calculations (even complicated equations are reduced into ones and zeroes by the computer), which machine will do that faster? And how much human time and effort will it take to write the code to make these ones and zeroes into something useful? At some time and point, the GPU will win out. The more there is to crunch, the larger the GPU victory. Again, this and other GPU projects are examples of that.

Oh, don't underestimate 8th graders, some of them are smarter than professors, and they grow up and some become even smarter. We were all once 8th graders.

This is all logic and common sense, no computer talk mumbo jumbo.

CPUs and GPUs are both just dumb machines. All they can do is crunch ones and zeroes. A programmer writes the code to convert these useless ones and zeroes into something useful. It is easier to write code for CPUs than GPUs, okay I got that. It is not impossible to write code for GPUs, (this and other GPU projects are proof of that), just more difficult.

Calculating 27 is bad example to use. From a human perspective, if that all you have to calculate, either will do fine. The human brain will also do fine. However, if you have a vast quantity of simple calculations (even complicated equations are reduced into ones and zeroes by the computer), which machine will do that faster? And how much human time and effort will it take to write the code to make these ones and zeroes into something useful? At some time and point, the GPU will win out. The more there is to crunch, the larger the GPU victory. Again, this and other GPU projects are examples of that.

Oh, don't underestimate 8th graders, some of them are smarter than professors, and they grow up and some become even smarter. We were all once 8th graders.

This is all logic and common sense, no computer talk mumbo jumbo.

CPUs and GPUs are both just dumb machines. All they can do is crunch ones and zeroes. A programmer writes the code to convert these useless ones and zeroes into something useful. It is easier to write code for CPUs than GPUs, okay I got that. It is not impossible to write code for GPUs, (this and other GPU projects are proof of that), just more difficult.

Calculating 27 is bad example to use. From a human perspective, if that all you have to calculate, either will do fine. The human brain will also do fine. However, if you have a vast quantity of simple calculations (even complicated equations are reduced into ones and zeroes by the computer), which machine will do that faster? And how much human time and effort will it take to write the code to make these ones and zeroes into something useful? At some time and point, the GPU will win out. The more there is to crunch, the larger the GPU victory. Again, this and other GPU projects are examples of that.

Oh, don't underestimate 8th graders, some of them are smarter than professors, and they grow up and some become even smarter. We were all once 8th graders.

This is all logic and common sense, no computer talk mumbo jumbo.

The latest generation of Intel server CPUs have 28 cores, and you can put 8 such CPUs in a single server (however it costs $13000 each).

Would FPGAs ever be used in a project like this or are GPUs still faster?

Would FPGAs ever be used in a project like this or are GPUs still faster?

Not everyone in the world has a high performance GPU and many enthusiasts still call in using a modem to get online. Even users with the latest and greatest still have available CPU time that could be used by CPU app projects.

If you are running GPUGRID you are using between 35-45 % of a single "CPU". Milkyway (ATI) about 10% and SETI (nVidia) under %10. Any system working for these clients can afford to pick up some of the rather poorer but worthwhile CPU projects. Rosette and SETI come to mind. Rosette of course has no GPU apps while SETI has a whole slew of CPU apps custom made for various CPUs but their GPU apps dont pay very well.

Here is an example of what could be done: I was recently given a generation one i7 system by one of my kids. It was my first "i-anything" as I use core-2 and upgrade only the GPUs every now and then. The i7-920 ran too hot so I replaced it with a really cheap Xeon X5675 that dropped the power by 35 watts and added 2 more cores for a total of 12 hyperthreads. I moved my GTX1070 to it and enabled all processors for use and added the SETI "CPU only" project apps. So while I am racking up points while helping GPUGRID, the SETI projects gets a lot of units crunched that otherwise would not be done.