Possible bug in magmablas_dswap [MAGMA 1.1.0 and 1.2*]

Open discussion for MAGMA

Possible bug in magmablas_dswap [MAGMA 1.1.0 and 1.2*]

Postby jgpallero » Wed Mar 21, 2012 7:17 am

Hello:

Attached I send a simple testing program for magmablas_dswap. I think that the function has several bugs.

First of all, if I try to use magmablas_dswap with increments equals zero or positive in vector x and y, tha result is that the vector x is copied into y but y is not changed to x, so the result is x in x and x in y.

Second, if I try to operate with increments equals -1, an error CUBLAS_STATUS_MAPPING_ERROR occurs (code error 11 in cublas_api.h).

This tests can be done in the attached file changing the value of the variable 'incCalc' in order to try differents increments (-1, 0, 1)

Cheers

PS: I'm using CUDA 4.1 and gcc 4.6.3 from Debian Sid
Attachments
test_dswap.c
Simple magmablas_dswap test
gcc test_dswap.c -o test_dswap -lmagma -lmagmablas -lmagma -lopenblas -lcuda -lcublas -llapack
(2.43 KiB) Downloaded 114 times
Last edited by jgpallero on Tue Jul 17, 2012 7:51 am, edited 1 time in total.
jgpallero
 
Posts: 29
Joined: Tue Nov 15, 2011 12:38 pm

Re: Possible bug in magmablas_dswap [MAGMA 1.1.0 and 1.2*]

Postby jgpallero » Tue Jul 17, 2012 7:50 am

Hello again:

The reported bug in magmablas_dswap is presented in magma 1.2.1 too

Cheers
jgpallero
 
Posts: 29
Joined: Tue Nov 15, 2011 12:38 pm

Re: Possible bug in magmablas_dswap [MAGMA 1.1.0 and 1.2*]

Postby Stan Tomov » Tue Jul 17, 2012 6:05 pm

Hello,
I think the bug is actually in the example file, in particular, you have used expressions like sizeof(x1), which in your case is 32 (4 doubles), instead of sizeof(x[0]) or just sizeof(double).
Stan
Stan Tomov
 
Posts: 249
Joined: Fri Aug 21, 2009 10:39 pm

Re: Possible bug in magmablas_dswap [MAGMA 1.1.0 and 1.2*]

Postby jgpallero » Thu Jul 19, 2012 10:46 am

Stan Tomov wrote:Hello,
I think the bug is actually in the example file, in particular, you have used expressions like sizeof(x1), which in your case is 32 (4 doubles), instead of sizeof(x[0]) or just sizeof(double).
Stan


You are right (partially). I have changed the sizeof calls to sizeof(double), but I have two problems.

1- When the increment between the elements of the vectors is 0, the reference BLAS does no computations, so the output vectors are the same than the input ones. But MAGMA swaps the two first elements x[0] and y[0] and does no operations with the remaining. I think that the behavior should be the same as in reference BLAS for increments equals 0, so I think that this is a bug in MAGMA

2- When the increments are -1 I obtain an cublasGetVector error, status=11. I think that all the code is correct and I suspect a bug too.

Attached I send the new fixed test_dswap.c code (only the incCalc=*; line is need to change)

Cheers
Attachments
test_dswap.c
gcc test_dswap.c -o test_dswap -lmagmablas -lmagma -lopenblas -lcuda -lcublas -llapack
(2.52 KiB) Downloaded 75 times
jgpallero
 
Posts: 29
Joined: Tue Nov 15, 2011 12:38 pm

Re: Possible bug in magmablas_dswap [MAGMA 1.1.0 and 1.2*]

Postby mgates3 » Tue Jul 24, 2012 1:34 pm

incx = 0 is an error condition; you are not passing a vector. Most of the BLAS routines such as DGEMV explicitly state that INCX must not be zero. The CPU implementation actually DOES swaps of the first element, but for even n, it does an even number of swaps, so the end result is the same. Try with n=3 to see that the first element is swapped. Nonetheless, the user should not call dswap with incx=0 or incy=0.

I agree that negative increments are not handled by the current MAGMA BLAS dswap code.

Note that the cublasDswap routine works correctly for negative increments, so I recommend using that one. (The MAGMA BLAS dswap routine probably dates from a time before CUBLAS was fully implemented.)

-mark
mgates3
 
Posts: 401
Joined: Fri Jan 06, 2012 2:13 pm

Re: Possible bug in magmablas_dswap [MAGMA 1.1.0 and 1.2*]

Postby jgpallero » Fri Jul 27, 2012 10:44 am

mgates3 wrote:incx = 0 is an error condition; you are not passing a vector. Most of the BLAS routines such as DGEMV explicitly state that INCX must not be zero. The CPU implementation actually DOES swaps of the first element, but for even n, it does an even number of swaps, so the end result is the same. Try with n=3 to see that the first element is swapped. Nonetheless, the user should not call dswap with incx=0 or incy=0.


But in my tests with magma_dswap() the first element is always interchanged, with N odd or even. Although incX and incY are wrong values I think that reproduce the same results as the reference netlib BLAS is a good feature
jgpallero
 
Posts: 29
Joined: Tue Nov 15, 2011 12:38 pm


Return to User discussion

Who is online

Users browsing this forum: No registered users and 9 guests