GoogleCodeExporter
commented
8 years ago Vivek
Thanks for the code I think it will spawn a couple more bug reports! ;)
First your code exposed a bytecode to OpenCL conversion error for me (how did
you run it?). That was sad but I will add the pattern to the JUNIT test suite
and see if I can see what is going on. javac (Oracle) optimizes back branches
if nested conditionals do not contain elses.
So
if (cond1){
if (cond2){
...
}
}else{
if (cond3){
...
}
}
I had seen this previously and *thought* I had fixed it, clearly not.
To workaround this I just added dummy else branches to your run() method.
Something like
if (cond1){
if (cond2){
...
}else{
temp=temp;
}
}else{
if (cond3){
...
}else{
temp=temp;
}
}
Oh and I had to initialize temp to 0;
Now the code will run using OpenCL on CPU and GPU ;)
Sadly when array length was > 2^20 (1048576 ints) the OpenCL version of the
code was 'failing' your sanity test. Not sure why this would be. I need to dig
into this. Anyway for the time being I set array length to 2^20.
These are the #'2 I got after making these changes:
Arraylength = 1048576
SEQ: 5952 ms // Aparapi emulating sequential code
JTP: 1869 ms // Aparapi thread pool (I have 6 cores but aparapi only uses 4
- power of 2))
CPU: 1571 ms // Aparapi-> OpenCL using CPU mode of AMD driver (OpenCL CPU
using all 6 cores)
GPU: 1234 ms // Aparapi ->OpenCL using GPU (5770)
So GPU won for me. My GPU is a 5770.
The bitonic sort algorithm was actually the test-case that persuaded me to add
explicit buffer management. The nature of the bitonic sort algorithm basically
ends up with a tight loop executing a kernel.
for (....){
kernel.execute(n);
}
If you look at the aparapi patterns wiki page you will see that this is the
pattern that suggests the use of explicit buffer management.
So the changes that I made to your code (other than a work around for the
bytecode->opencl bug!) were
1) sort.setExplicit(true)
2) sort.put(theArray) before entering the loop
3) sort.get(theArray) after exiting the loop
The #'s for me now are.
SEQ: 5929 ms // Aparapi emulating sequential code
JTP: 1855 ms // Aparapi thread pool (I have 6 cores but aparapi only uses 4
- power of 2))
CPU: 1327 ms // Aparapi-> OpenCL using CPU mode of AMD driver (OpenCL CPU
using all 6 cores)
GPU: 610 ms // Aparapi ->OpenCL using GPU (5770)
So the SEQ + JTP did not change (makes sense no opencl involved)
CPU went down a little (buffer txfer costs are NO-OPS when using OpenCL CPU) so
I would not expect tohave had a big advantage here.
GPU was much better 2XCPU for me.
Would you retest using the attached code (with my changes)
Original comment by frost.g...@gmail.com on 17 Dec 2011 at 5:03
Attachments:
Original issue reported on code.google.com by
vivek.ku...@gmail.comon 17 Dec 2011 at 2:31Attachments: