Message boards : Number crunching : Going OpenCL
Message board moderation

To post messages, you must log in.

AuthorMessage
zeta reticuli

Send message
Joined: 28 Apr 16
Posts: 2
Credit: 363
RAC: 0
Message 27776 - Posted: 19 Jun 2016, 15:06:57 UTC

Good day everyone,

Yesterday i finally got some tasked from this project, but
i noticed they are CPU only. Why not switch over to OpenCL
instead? For instance my CPU is ~80GFlops, and the total on
the server status is:
current GigaFLOPs 2,516 (i assume that is 2.5 TFlops)
Now, my GPU alone has more horsepower then that sitting idle 90% of
the time i use my PC, so why not using a mix of OpenCL too?
ID: 27776 · Report as offensive     Reply Quote
10esseeTony

Send message
Joined: 9 Feb 15
Posts: 3
Credit: 4,899,366
RAC: 0
Message 27778 - Posted: 1 Jul 2016, 1:35:30 UTC - in response to Message 27776.  
Last modified: 1 Jul 2016, 1:38:33 UTC

Difficult it is, to code then debug, for GPU. -Yoda

I can barely configure a wireless router, but my understanding is that not all applications are suitable for the type of processing the GPU is able to provide (parallel streams? or is that don't cross the streams, can't remember), compared to the all-around do-anything nature of a modern CPU.

Think of GPU's as a pocket calculator you had back in the 90's...really really really good at several types of math, because it was specifically designed for that purpose, but really sucked as a word processor. I mean seriously, I can only think of two words a calculator could spell: 1134, and 35007, and even then you had to turn the darn thing upside down to read the words.

However, there are a great many projects that CAN be optimized for use on a GPU. Sadly many of those projects are assisted by college-kid-coders who are spending every spare moment trying to stay on top of their class work and keep up the GPA. And the projects all seemingly are run on a super tight budget, so hiring a professional coder is out of the question.

It's sad, I agree, to see so much 'horse power' wasted. 'Tis a sad state of affairs indeed.
ID: 27778 · Report as offensive     Reply Quote
Eric Mcintosh
Volunteer moderator
Project administrator
Project developer
Project tester
Project scientist

Send message
Joined: 12 Jul 11
Posts: 857
Credit: 1,619,050
RAC: 0
Message 27779 - Posted: 7 Jul 2016, 9:16:55 UTC - in response to Message 27776.  

Well, first SixTrack is a Fortran application. There are medium/long term plans
to use C/C++ but for now we are Fortran. Nonetheless some colleagues have
created a GPU version which shows some encouraging results. We have been stuck
now for a couple of years trying to build Windows executables. The Intel ifort compiler
for Windows does not provide correct floating-point arithmetic. We are trying gfortran
which would seem to be appropriate for a volunteer system like SixTrack/BOINC.
The numeric results are just fine, but we are having great difficulty building the
BOINC api (Fortran) static libs. We used to do this on cygwin, and we are trying
MinGW but no luck so far. More news on all this when I can report some progress.
I agree it is a shame we can't use GPUs right now, but we must first solve the really
basic problems with Windows executables. (I also have a MacOS executable ready
to go.) We are also looking at ARM. We also have to adapt to some major changes
to the CERN infrastructure. I know, excuses, excuses but we are largley volunteers
as well. Thanks for your feedback. Eric.
ID: 27779 · Report as offensive     Reply Quote
mikey
Avatar

Send message
Joined: 30 Oct 11
Posts: 23
Credit: 4,489,001
RAC: 0
Message 27785 - Posted: 28 Jul 2016, 23:18:30 UTC - in response to Message 27779.  

Well, first SixTrack is a Fortran application. There are medium/long term plans
to use C/C++ but for now we are Fortran. Nonetheless some colleagues have
created a GPU version which shows some encouraging results. We have been stuck
now for a couple of years trying to build Windows executables. The Intel ifort compiler
for Windows does not provide correct floating-point arithmetic. We are trying gfortran
which would seem to be appropriate for a volunteer system like SixTrack/BOINC.
The numeric results are just fine, but we are having great difficulty building the
BOINC api (Fortran) static libs. We used to do this on cygwin, and we are trying
MinGW but no luck so far. More news on all this when I can report some progress.
I agree it is a shame we can't use GPUs right now, but we must first solve the really
basic problems with Windows executables. (I also have a MacOS executable ready
to go.) We are also looking at ARM. We also have to adapt to some major changes
to the CERN infrastructure. I know, excuses, excuses but we are largley volunteers
as well. Thanks for your feedback. Eric.


It would also be really cool if you guys could figure out if Asic boxes could be used here too, they also do math really quickly but right now only work on Bitcoin stuff within Boinc.
ID: 27785 · Report as offensive     Reply Quote
[AF>FAH-Addict.net]toTOW

Send message
Joined: 9 Oct 10
Posts: 77
Credit: 3,671,357
RAC: 0
Message 27786 - Posted: 30 Jul 2016, 10:47:46 UTC

Unfortunately ASICs are dedicated to the task they are designed for ... they can't do something else.

The market of ASICs for a specific BOINC application would be too small to pay for the development and production costs ...
ID: 27786 · Report as offensive     Reply Quote
Carsten Milkau

Send message
Joined: 3 Oct 06
Posts: 2
Credit: 1,769,561
RAC: 0
Message 27799 - Posted: 16 Aug 2016, 7:38:09 UTC

How about a testing application for Linux/OSX while Windows progress is stalled?
ID: 27799 · Report as offensive     Reply Quote

Message boards : Number crunching : Going OpenCL


©2022 CERN