Parallel Programming Course Project

[homercles337]

Just to be my usual contentious self:

A recent ISCA paper: Debunking the 100X GPU vs. CPU myth: an evaluation of throughput computing on CPU and GPU
(from Intel)
http://portal.acm.org/citation.cfm?...&dl=GUIDE&CFID=11111111&CFTOKEN=2222222&ret=1

Thanks for that reference--just printed it. In my experience there is a lot of variability. FFTs see about 1.5x speed up, Euclidean distances are up to 7x, and as i said before Jaccard distances are up to 22x speed up. This is max speedup and occurs when the dataset sizes are as big as the card will handle. Which, in my case is 4096^2. In reality, the datasets i deal with are often in the millions. I should also note that that my code for Euclidean and Jaccard distances is highly optimized.

 

[schenley101]

I am a computational scientist (phd level) in chembio/cheminformatics and parallelizing code is something i do all the time. Of course this is from an applied perspective since slicing a for loop up into chunks and shipping it off to the cluster is not difficult or challenging. Recently i have been playing with Matlab/CUDA (via Accelereyes and GPUmat) and see some really impressive gains with simple vectorized matlab code. I dont know the scope of this project, but if i was going to stick and undergrad with a parallel project i would want to see performance trade off between cluster/CPU and a GPGPU solution. But since i have been piloting this stuff for our Research Computing Group at work im a bit biased. Nonetheless, this does pose an interesting project since there are trade-offs for cluster/CPU v GPGPU.

the newest version of MATLAB 2010b has built in (For Nvidia only) GPGPU functions and is relatively easy to use, especially compared to CUDA/OpenCL. I just mested around with it for a few hours and so far and have noted speed ups with large arrays and dealing with trig functions, and small speed ups on fft's. none of the speed ups were mind blowing but they existed none the less.

 

[homercles337]

the newest version of MATLAB 2010b has built in (For Nvidia only) GPGPU functions and is relatively easy to use, especially compared to CUDA/OpenCL. I just mested around with it for a few hours and so far and have noted speed ups with large arrays and dealing with trig functions, and small speed ups on fft's. none of the speed ups were mind blowing but they existed none the less.

We tried to get into the more extensive beta for this GPGPU capability (part of the parallel toolbox), but missed the deadline. I have used this release and found it to be VERY limited. When sum() throws an error because its not supported, this signals to me that its not ready for even alpha. I know Mathworks is expanding this, but until they do i found it to be prohibitively limited for anything but benching left divide, matrix multiply, and FFTs. Future releases should be more adept though...

 

[degibson]

We tried to get into the more extensive beta for this GPGPU capability (part of the parallel toolbox), but missed the deadline. I have used this release and found it to be VERY limited. When sum() throws an error because its not supported, this signals to me that its not ready for even alpha. I know Mathworks is expanding this, but until they do i found it to be prohibitively limited for anything but benching left divide, matrix multiply, and FFTs. Future releases should be more adept though...

Indeed. But it's hard to blame NVidia for that -- the GPGPU market is approximately $0Billion a year. Not a lot of incentive for them -- mostly intellectual incentive and bragging rights.

 

[homercles337]

Indeed. But it's hard to blame NVidia for that -- the GPGPU market is approximately $0Billion a year. Not a lot of incentive for them -- mostly intellectual incentive and bragging rights.

I wasnt blaming nVidia, i was blaming Mathworks.

 

[degibson]

I wasnt blaming nVidia, i was blaming Mathworks.

Well, they deserve plenty of blame for shipping untested products. You have to start somewhere I suppose -- it'll get easier to test GPGPU stuff as GPGPU becomes more standardized.

 

[beginner99]

do the chess engine project, then when its finished get a (C) account at www.freechess.org [ (C) stands for computer, i.e. an account that is ran by a chess engine instead of a human ], then complete against other (C) and/or human accounts and see how high of an ELO you guys can get.

connecting to fics:
http://www.freechess.org/Help/HelpFiles/addresses.html

I would say that's much more complicated than one would think because you have exponential growth of possibilites. The issue is how to decide which move is the best one.
Most of these chessprogramms have somekind of a database with stored positions and good moves to do in those.
Anyway the hard part will be the decision making (single threaded) not the calculations themselves.

 

[hooflung]

I would say whatever you do write, that you should take a look at python 2.6/2.7 and use the multiprocessing library. Then, as a project I would urge you to make a simple procedurally generated map for a ascii character based game.

For even more wickedness, go Stackless and combine the multiprocessing library with microthreads (slackless' thread library). When you graduate, apply to CCP games the makers of EVE Online.

 

[Cogman]

I would say whatever you do write, that you should take a look at python 2.6/2.7 and use the multiprocessing library. Then, as a project I would urge you to make a simple procedurally generated map for a ascii character based game.

For even more wickedness, go Stackless and combine the multiprocessing library with microthreads (slackless' thread library). When you graduate, apply to CCP games the makers of EVE Online.

Sorry, but I would suggest staying away from python. It completely defeats the reason to do parallel programming with how slow it is. There are several languages can do everything that python can, and do it better.

 

[hooflung]

Sorry, but I would suggest staying away from python. It completely defeats the reason to do parallel programming with how slow it is. There are several languages can do everything that python can, and do it better.

Python is far from slow. You do realize one of the largest concurrent MMO games, EVE Online, has been running stackless python since 2003? They make extensive use of green threads, aka microthreads in stackless, and are starting to develop using the multiprocess library now that they have 2.6+ compatible python running on the client and servers.

Also, unless you are doing a compute intensive task that saturates a cpu 100% python is quite the swift beast. Parallel programming doesn't have to be all math, it can be completely I/O intensive... and python excels at that.

 

[Cogman]

http://www.timestretch.com/FractalBenchmark.html
http://www.osnews.com/story/5602/Ni...ce_Round-up_Benchmarking_Math_File_I_O/page3/

Umm. yeah, there are few languages that perform as slow as python does.

As for the IO, sorry, but when IO is the limiting fact then any language is going to be just as fast as another. So then the question becomes "What language provides the most features." To which I would firmly say "C#".

Multithreaded programs that focus on multithreaded processing (What the OP seems to be implying) is really quite rarely limited by IO. In that case, it usually doesn't make sense to do multithreaded programming.

 

[degibson]

Python is fine for concurrent, I/O bound jobs.
Not so fine for parallel compute-bound jobs.