Menu
▾
▴
matlisp-devel
|
From: Akshay S. <aks...@gm...> - 2012-03-11 18:13:39
|
On 03/11/2012 12:37 PM, Raymond Toy wrote: > On 3/10/12 7:03 PM, Akshay Srinivasan wrote: >> On 03/10/2012 11:16 PM, Raymond Toy wrote: >>> On 3/10/12 8:40 AM, Akshay Srinivasan wrote: >>> >>>>> It would be nice to be able to detect either mode and have >>>>> the ffi do the right thing, but I think many lisps do not >>>>> support structure returns the way gcc is doing it now. >>>> It returns a struct ? I never could get hold of the >>>> documentation for that. >>> That's my understanding. And when I look at the disassembly >>> for a simple Fortran function, it returns the real and >>> imaginary parts in xmm0 and xmm1 (at least on OSX). >> Hmm. Too clumsy and non-portable to support all that, no ? > It would be good if cffi supported that, but I suspect not. >> >>>>> We also have an alternative: Add simple C wrappers that >>>>> use the f2c-mode return and call the Fortran routine >>>>> directly. >>>> CBLAS :) (not the netlib version). After some more thinking, I vote for adding wrapper subroutine around zdotu/zdotc in F77. It'll be far too much boring work to migrate to CBLAS, given that I seem to be able to handle ordering quite well within lisp itself. There aren't any other complex returning functions in BLAS, are there ? We probably don't need any other f2c features, since most functions I know only take character arguments instead of string ones. Akshay |
|
From: Raymond T. <toy...@gm...> - 2012-03-11 18:48:38
|
On 3/11/12 11:11 AM, Akshay Srinivasan wrote: > On 03/11/2012 12:37 PM, Raymond Toy wrote: >> On 3/10/12 7:03 PM, Akshay Srinivasan wrote: >>> On 03/10/2012 11:16 PM, Raymond Toy wrote: >>>> On 3/10/12 8:40 AM, Akshay Srinivasan wrote: >>>> >>>>>> It would be nice to be able to detect either mode and have >>>>>> the ffi do the right thing, but I think many lisps do not >>>>>> support structure returns the way gcc is doing it now. >>>>> It returns a struct ? I never could get hold of the >>>>> documentation for that. >>>> That's my understanding. And when I look at the disassembly >>>> for a simple Fortran function, it returns the real and >>>> imaginary parts in xmm0 and xmm1 (at least on OSX). >>> Hmm. Too clumsy and non-portable to support all that, no ? >> It would be good if cffi supported that, but I suspect not. >>>>>> We also have an alternative: Add simple C wrappers that >>>>>> use the f2c-mode return and call the Fortran routine >>>>>> directly. >>>>> CBLAS :) (not the netlib version). > After some more thinking, I vote for adding wrapper subroutine around > zdotu/zdotc in F77. It'll be far too much boring work to migrate to > CBLAS, given that I seem to be able to handle ordering quite well > within lisp itself. There aren't any other complex returning functions > in BLAS, are there ? Let me do a grep....Nope. Looks like those are the only two. Not quite sure what you're going to do here. You want to write two C wrapper functions that call zdotu/zdotc correctly, and have the wrapper use the f2c convention? Since we already detect if we need -ff2c, what is the utility for this when matlisp builds its own libraries? Of course, for atlas, I can see that we would want this if we've determined that atlas is not compatible. That would be a nice enhancement. > > We probably don't need any other f2c features, since most functions I > know only take character arguments instead of string ones. Fortunately, matlisp is in control of that because I think it is valid fortran to pass in, say, 'Transpose', instead of 'T'. Ray |
|
From: Akshay S. <aks...@gm...> - 2012-03-12 04:35:45
|
>> After some more thinking, I vote for adding wrapper subroutine >> around zdotu/zdotc in F77. It'll be far too much boring work to >> migrate to CBLAS, given that I seem to be able to handle ordering >> quite well within lisp itself. There aren't any other complex >> returning functions in BLAS, are there ? > Let me do a grep....Nope. Looks like those are the only two. > > Not quite sure what you're going to do here. You want to write two > C wrapper functions that call zdotu/zdotc correctly, and have the > wrapper use the f2c convention? No the wrapper will be in F77, which will be a subroutine working like the f2c version (or the CBLAS version). > > Since we already detect if we need -ff2c, what is the utility for > this when matlisp builds its own libraries? Of course, for atlas, > I can see that we would want this if we've determined that atlas is > not compatible. That would be a nice enhancement. Yes, but If we have the wrapper, we don't have to bother with -ff2c flag anymore, and also be able to use ATLAS at the same time without doing much else. Doing it only when we've determined ATLAS doesn't work the way we want, will involve, I think, changing bits of the function definitions of zdotc/zdotu in src/blas.lisp during the build. >> >> We probably don't need any other f2c features, since most >> functions I know only take character arguments instead of string >> ones. > Fortunately, matlisp is in control of that because I think it is > valid fortran to pass in, say, 'Transpose', instead of 'T'. That might only be because Fortran only reads the first character of the string (?). Akshay |
|
From: Akshay S. <aks...@gm...> - 2012-03-13 16:47:56
|
On 03/12/2012 12:18 AM, Raymond Toy wrote: > On 3/11/12 11:11 AM, Akshay Srinivasan wrote: >> On 03/11/2012 12:37 PM, Raymond Toy wrote: >>> On 3/10/12 7:03 PM, Akshay Srinivasan wrote: >>>> On 03/10/2012 11:16 PM, Raymond Toy wrote: >>>>> On 3/10/12 8:40 AM, Akshay Srinivasan wrote: >>>>> >>>>>>> It would be nice to be able to detect either mode and >>>>>>> have the ffi do the right thing, but I think many lisps >>>>>>> do not support structure returns the way gcc is doing >>>>>>> it now. >>>>>> It returns a struct ? I never could get hold of the >>>>>> documentation for that. >>>>> That's my understanding. And when I look at the >>>>> disassembly for a simple Fortran function, it returns the >>>>> real and imaginary parts in xmm0 and xmm1 (at least on >>>>> OSX). >>>> Hmm. Too clumsy and non-portable to support all that, no ? >>> It would be good if cffi supported that, but I suspect not. >>>>>>> We also have an alternative: Add simple C wrappers >>>>>>> that use the f2c-mode return and call the Fortran >>>>>>> routine directly. >>>>>> CBLAS :) (not the netlib version). >> After some more thinking, I vote for adding wrapper subroutine >> around zdotu/zdotc in F77. It'll be far too much boring work to >> migrate to CBLAS, given that I seem to be able to handle ordering >> quite well within lisp itself. There aren't any other complex >> returning functions in BLAS, are there ? > Let me do a grep....Nope. Looks like those are the only two. > > Not quite sure what you're going to do here. You want to write two > C wrapper functions that call zdotu/zdotc correctly, and have the > wrapper use the f2c convention? > > Since we already detect if we need -ff2c, what is the utility for > this when matlisp builds its own libraries? Of course, for atlas, > I can see that we would want this if we've determined that atlas is > not compatible. That would be a nice enhancement. >> >> We probably don't need any other f2c features, since most >> functions I know only take character arguments instead of string >> ones. > Fortunately, matlisp is in control of that because I think it is > valid fortran to pass in, say, 'Transpose', instead of 'T'. I have to flip back on my words. I now think CBLAS is the only way forward. I was writing a wrapper for dgemv (y <- alpha * A . x + beta y) today and really couldn't figure out a way to support row-ordered matrices; to do this I will have to use dgemm at best to doing it completely in lisp at worst. This is bad because, I can't use gemv to support sliced matrices in gemm! I do think it is worth the trouble now, given that I will be able support a lot of matrix-slicey things with access to the order switch which is provided by CBLAS functions. What do you think ? Akshay |
|
From: Raymond T. <toy...@gm...> - 2012-03-14 02:04:48
|
On 3/13/12 9:45 AM, Akshay Srinivasan wrote: > On 03/12/2012 12:18 AM, Raymond Toy wrote: >> On 3/11/12 11:11 AM, Akshay Srinivasan wrote: >>> On 03/11/2012 12:37 PM, Raymond Toy wrote: >>>> On 3/10/12 7:03 PM, Akshay Srinivasan wrote: >>>>> On 03/10/2012 11:16 PM, Raymond Toy wrote: >>>>>> On 3/10/12 8:40 AM, Akshay Srinivasan wrote: >>>>>> >>>>>>>> It would be nice to be able to detect either mode and >>>>>>>> have the ffi do the right thing, but I think many lisps >>>>>>>> do not support structure returns the way gcc is doing >>>>>>>> it now. >>>>>>> It returns a struct ? I never could get hold of the >>>>>>> documentation for that. >>>>>> That's my understanding. And when I look at the >>>>>> disassembly for a simple Fortran function, it returns the >>>>>> real and imaginary parts in xmm0 and xmm1 (at least on >>>>>> OSX). >>>>> Hmm. Too clumsy and non-portable to support all that, no ? >>>> It would be good if cffi supported that, but I suspect not. >>>>>>>> We also have an alternative: Add simple C wrappers >>>>>>>> that use the f2c-mode return and call the Fortran >>>>>>>> routine directly. >>>>>>> CBLAS :) (not the netlib version). >>> After some more thinking, I vote for adding wrapper subroutine >>> around zdotu/zdotc in F77. It'll be far too much boring work to >>> migrate to CBLAS, given that I seem to be able to handle ordering >>> quite well within lisp itself. There aren't any other complex >>> returning functions in BLAS, are there ? >> Let me do a grep....Nope. Looks like those are the only two. >> >> Not quite sure what you're going to do here. You want to write two >> C wrapper functions that call zdotu/zdotc correctly, and have the >> wrapper use the f2c convention? >> >> Since we already detect if we need -ff2c, what is the utility for >> this when matlisp builds its own libraries? Of course, for atlas, >> I can see that we would want this if we've determined that atlas is >> not compatible. That would be a nice enhancement. >>> We probably don't need any other f2c features, since most >>> functions I know only take character arguments instead of string >>> ones. >> Fortunately, matlisp is in control of that because I think it is >> valid fortran to pass in, say, 'Transpose', instead of 'T'. > I have to flip back on my words. I now think CBLAS is the only way > forward. I was writing a wrapper for dgemv (y <- alpha * A . x + beta > y) today and really couldn't figure out a way to support row-ordered > matrices; to do this I will have to use dgemm at best to doing it > completely in lisp at worst. This is bad because, I can't use gemv to > support sliced matrices in gemm! > > I do think it is worth the trouble now, given that I will be able > support a lot of matrix-slicey things with access to the order switch > which is provided by CBLAS functions. > Point me to the version of cblas you want to use. I'll do the work to get the library built. I'll leave the interface changes to you (if they need to be changed). Ray |
|
From: Raymond T. <toy...@gm...> - 2012-03-14 02:00:26
|
On 3/13/12 9:45 AM, Akshay Srinivasan wrote: > On 03/12/2012 12:18 AM, Raymond Toy wrote: >> On 3/11/12 11:11 AM, Akshay Srinivasan wrote: >>> On 03/11/2012 12:37 PM, Raymond Toy wrote: >>>> On 3/10/12 7:03 PM, Akshay Srinivasan wrote: >>>>> On 03/10/2012 11:16 PM, Raymond Toy wrote: >>>>>> On 3/10/12 8:40 AM, Akshay Srinivasan wrote: >>>>>> >>>>>>>> It would be nice to be able to detect either mode and >>>>>>>> have the ffi do the right thing, but I think many lisps >>>>>>>> do not support structure returns the way gcc is doing >>>>>>>> it now. >>>>>>> It returns a struct ? I never could get hold of the >>>>>>> documentation for that. >>>>>> That's my understanding. And when I look at the >>>>>> disassembly for a simple Fortran function, it returns the >>>>>> real and imaginary parts in xmm0 and xmm1 (at least on >>>>>> OSX). >>>>> Hmm. Too clumsy and non-portable to support all that, no ? >>>> It would be good if cffi supported that, but I suspect not. >>>>>>>> We also have an alternative: Add simple C wrappers >>>>>>>> that use the f2c-mode return and call the Fortran >>>>>>>> routine directly. >>>>>>> CBLAS :) (not the netlib version). >>> After some more thinking, I vote for adding wrapper subroutine >>> around zdotu/zdotc in F77. It'll be far too much boring work to >>> migrate to CBLAS, given that I seem to be able to handle ordering >>> quite well within lisp itself. There aren't any other complex >>> returning functions in BLAS, are there ? >> Let me do a grep....Nope. Looks like those are the only two. >> >> Not quite sure what you're going to do here. You want to write two >> C wrapper functions that call zdotu/zdotc correctly, and have the >> wrapper use the f2c convention? >> >> Since we already detect if we need -ff2c, what is the utility for >> this when matlisp builds its own libraries? Of course, for atlas, >> I can see that we would want this if we've determined that atlas is >> not compatible. That would be a nice enhancement. >>> We probably don't need any other f2c features, since most >>> functions I know only take character arguments instead of string >>> ones. >> Fortunately, matlisp is in control of that because I think it is >> valid fortran to pass in, say, 'Transpose', instead of 'T'. > I have to flip back on my words. I now think CBLAS is the only way > forward. I was writing a wrapper for dgemv (y <- alpha * A . x + beta > y) today and really couldn't figure out a way to support row-ordered Can you give an example? You can't just transpose A? Oh. Maybe not because the elements still need to be in column-major order? Ray |
|
From: Akshay S. <aks...@gm...> - 2012-03-14 03:22:25
|
On 03/14/2012 07:30 AM, Raymond Toy wrote: > On 3/13/12 9:45 AM, Akshay Srinivasan wrote: >> On 03/12/2012 12:18 AM, Raymond Toy wrote: >>> On 3/11/12 11:11 AM, Akshay Srinivasan wrote: >>>> On 03/11/2012 12:37 PM, Raymond Toy wrote: >>>>> On 3/10/12 7:03 PM, Akshay Srinivasan wrote: >>>>>> On 03/10/2012 11:16 PM, Raymond Toy wrote: >>>>>>> On 3/10/12 8:40 AM, Akshay Srinivasan wrote: >>>>>>> >>>>>>>>> It would be nice to be able to detect either mode >>>>>>>>> and have the ffi do the right thing, but I think >>>>>>>>> many lisps do not support structure returns the way >>>>>>>>> gcc is doing it now. >>>>>>>> It returns a struct ? I never could get hold of the >>>>>>>> documentation for that. >>>>>>> That's my understanding. And when I look at the >>>>>>> disassembly for a simple Fortran function, it returns >>>>>>> the real and imaginary parts in xmm0 and xmm1 (at least >>>>>>> on OSX). >>>>>> Hmm. Too clumsy and non-portable to support all that, no >>>>>> ? >>>>> It would be good if cffi supported that, but I suspect >>>>> not. >>>>>>>>> We also have an alternative: Add simple C wrappers >>>>>>>>> that use the f2c-mode return and call the Fortran >>>>>>>>> routine directly. >>>>>>>> CBLAS :) (not the netlib version). >>>> After some more thinking, I vote for adding wrapper >>>> subroutine around zdotu/zdotc in F77. It'll be far too much >>>> boring work to migrate to CBLAS, given that I seem to be able >>>> to handle ordering quite well within lisp itself. There >>>> aren't any other complex returning functions in BLAS, are >>>> there ? >>> Let me do a grep....Nope. Looks like those are the only two. >>> >>> Not quite sure what you're going to do here. You want to write >>> two C wrapper functions that call zdotu/zdotc correctly, and >>> have the wrapper use the f2c convention? >>> >>> Since we already detect if we need -ff2c, what is the utility >>> for this when matlisp builds its own libraries? Of course, for >>> atlas, I can see that we would want this if we've determined >>> that atlas is not compatible. That would be a nice >>> enhancement. >>>> We probably don't need any other f2c features, since most >>>> functions I know only take character arguments instead of >>>> string ones. >>> Fortunately, matlisp is in control of that because I think it >>> is valid fortran to pass in, say, 'Transpose', instead of 'T'. >> I have to flip back on my words. I now think CBLAS is the only >> way forward. I was writing a wrapper for dgemv (y <- alpha * A . >> x + beta y) today and really couldn't figure out a way to support >> row-ordered > > Can you give an example? You can't just transpose A? Oh. Maybe > not because the elements still need to be in column-major order? That will only work when A is square though. Akshay |
|
From: Akshay S. <aks...@gm...> - 2012-03-14 03:57:07
|
On 03/14/2012 08:49 AM, Akshay Srinivasan wrote: > On 03/14/2012 07:30 AM, Raymond Toy wrote: >> On 3/13/12 9:45 AM, Akshay Srinivasan wrote: >>> On 03/12/2012 12:18 AM, Raymond Toy wrote: >>>> On 3/11/12 11:11 AM, Akshay Srinivasan wrote: >>>>> On 03/11/2012 12:37 PM, Raymond Toy wrote: >>>>>> On 3/10/12 7:03 PM, Akshay Srinivasan wrote: >>>>>>> On 03/10/2012 11:16 PM, Raymond Toy wrote: >>>>>>>> On 3/10/12 8:40 AM, Akshay Srinivasan wrote: >>>>>>>> >>>>>>>>>> It would be nice to be able to detect either >>>>>>>>>> mode and have the ffi do the right thing, but I >>>>>>>>>> think many lisps do not support structure returns >>>>>>>>>> the way gcc is doing it now. >>>>>>>>> It returns a struct ? I never could get hold of the >>>>>>>>> documentation for that. >>>>>>>> That's my understanding. And when I look at the >>>>>>>> disassembly for a simple Fortran function, it >>>>>>>> returns the real and imaginary parts in xmm0 and xmm1 >>>>>>>> (at least on OSX). >>>>>>> Hmm. Too clumsy and non-portable to support all that, >>>>>>> no ? >>>>>> It would be good if cffi supported that, but I suspect >>>>>> not. >>>>>>>>>> We also have an alternative: Add simple C >>>>>>>>>> wrappers that use the f2c-mode return and call >>>>>>>>>> the Fortran routine directly. >>>>>>>>> CBLAS :) (not the netlib version). >>>>> After some more thinking, I vote for adding wrapper >>>>> subroutine around zdotu/zdotc in F77. It'll be far too >>>>> much boring work to migrate to CBLAS, given that I seem to >>>>> be able to handle ordering quite well within lisp itself. >>>>> There aren't any other complex returning functions in BLAS, >>>>> are there ? >>>> Let me do a grep....Nope. Looks like those are the only >>>> two. >>>> >>>> Not quite sure what you're going to do here. You want to >>>> write two C wrapper functions that call zdotu/zdotc >>>> correctly, and have the wrapper use the f2c convention? >>>> >>>> Since we already detect if we need -ff2c, what is the >>>> utility for this when matlisp builds its own libraries? Of >>>> course, for atlas, I can see that we would want this if we've >>>> determined that atlas is not compatible. That would be a >>>> nice enhancement. >>>>> We probably don't need any other f2c features, since most >>>>> functions I know only take character arguments instead of >>>>> string ones. >>>> Fortunately, matlisp is in control of that because I think >>>> it is valid fortran to pass in, say, 'Transpose', instead of >>>> 'T'. >>> I have to flip back on my words. I now think CBLAS is the only >>> way forward. I was writing a wrapper for dgemv (y <- alpha * A >>> . x + beta y) today and really couldn't figure out a way to >>> support row-ordered >> >> Can you give an example? You can't just transpose A? Oh. >> Maybe not because the elements still need to be in column-major >> order? > > That will only work when A is square though. Sorry I should've thought this through, more carfully. Yes transpose will actually do the trick. I guess we don't need CBLAS after all. I found the source code of: http://netlib.org/blas/blast-forum/cblas.tgz useful. zdotc/zdotu works beautifully by the way (with and without ATLAS). Akshay |
Thanks for helping keep SourceForge clean.
X