Skip to main content
GameDev.net gamedev.net
🔒 Locked

Integral Pi Approximation on Cell Processor

Started by JonConley Sep 23, 2010 at 11:26 AM 3 replies 900+ views
Original Post
JonConley
JonConley
I am doing an independent study titled "Parallel Programming on the Cell Processor" and one of the initial programs I have made is a program to approximate pi using the integration of the function 4/(1+x^2) between 0 and 1.

Now with 24 billion boxes between 0 and 1 and their area added together I get 7 decimal places of pi. That is not the problem.

The problem becomes that I have to do 2 billion divides per SPE on a double vector. These divides are terribly slow, I have tried using recipd2(1+x^2) * 4, I have tried just a straight division and it slows the program by 600%+.

Pseudo SPU Code

vec double four(4.0,4.0)
vec double one(1.0,1.0)
vec double result(0,0)
vec double tempResult
for(iterations)
tempResult = spu_mul(x,x)
tempResult = spu_add(one, tempResult)
tempResult = divd2(four, tempResult)
result = spu_add(result, tempResult)

double pi = result[0] + result[1]
DMA command send pi to PPU (which works)
exit

I was wondering if there is a way to get around the divide and are double divisions really that slow on the SPU?
KulSeran
KulSeran
Yes, the double precision math is going to be slow. ~8x as slow as single precision unless you have the specialized PowerXCell 8i version of the cell processor.

As to how to fix the math to be faster? not sure.
alvaro
alvaro
If you use Simpson's rule with 8 boxes you already get 9 decimal places of pi. And you can pretty much do it by hand. But I guess that's not really what you are looking for...

JonConley
JonConley
Well I am not too worried about the actual approximation of pi, more of the time involved to do it. Right now the cell is quite a bit slower than my amd dual core (4750 black edition OCed to 3.1ghz). If I get rid of the divide in the cell it becomes quicker than my standard cpu.
KulSeran
KulSeran
Another thought for you then. You have a lot of data dependancies in there, and it might not be optimizing well. I'd take a look at the output assembly first to see how it unrolled the loop. Then I'd try pipelining your loop a bit better with more operations to fill in the data stalls. I don't exactly recall what pairs of instructions issue together on the SPU since there are two pipelines in it, but I do suspect your floatingpoint pipeline isn't quite full.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.