KarlViennaCL: Sparse Matrix-Matrix Multiplication
| |
| | | | | | | |
| ViennaCL: Sparse Matrix-Matrix MultiplicationDescription |
| |
| View on www.iue.tuwien.ac.at | Preview by Yahoo |
| |
| |
Do you have any example in ViennaCL that actually does this? Can you please
point this out? I was rethinking my strategy and was wondering if I formulate
my Dense matrix multiplication as a sparse matrix multiplication and,a.) Use
The modified Strassen algorithm to reduce the workload Strassen's Matrix
Multiplication Relabeled
| |
| | | | | | | |
| Strassen's Matrix Multiplication RelabeledStrassen's Matrix Multiplication
Relabeled Sarah M. Loos David S. Wise Computer Science Department Computer
Science Department Indiana University Indiana U... |
| |
| View on src.acm.org | Preview by Yahoo |
| |
| |
b.) Use the sparse vs sparse matrix multiplication routine (of course with a
sufficiently large base size) - With my GPU I can reduce the size to at least
8192 x 8192
Thanks and Regards
Sumit
From: Karl Rupp <r...@iue.tuwien.ac.at>
To: Sumit Kumar <dost_4_e...@yahoo.com>
Cc: "viennacl-devel@lists.sourceforge.net"
<viennacl-devel@lists.sourceforge.net>
Sent: Tuesday, July 28, 2015 4:01 PM
Subject: Re: [ViennaCL-devel] ViennaCL reductions
Hi,
> That worked. So, the final question I have would be as follows:
> viennacl::copy(vcl_C, eigen_mat);
> is a valid statement
> However, if I want to copy vcl_C to some particular region of a host
> matrix, then, do I have to first create a temporary host matrix and then
> copy that host matrix into a larger matrix or is there anything direct?
> Something like this:
> viennacl::copy(vcl_C, prod.block(0, j, source.rows(), bTemp.cols()));
>
> Otherwise the only way I can think of is this:
> RMMatrix_Float temp(rows,cols);
> viennacl::copy(vcl_C, temp);
> RMMatrix_Float biggerMatrix.block(0,j,rows,cols) = temp
you can either use temporaries, or create an Eigen::Map<> from your
Eigen matrix for wrapping your existing matrix accordingly:
http://eigen.tuxfamily.org/dox/classEigen_1_1Map.html
Best regards,
Karli
> ------------------------------------------------------------------------
> *From:* Karl Rupp <r...@iue.tuwien.ac.at>
> *To:* Sumit Kumar <dost_4_e...@yahoo.com>
> *Cc:* "viennacl-devel@lists.sourceforge.net"
> <viennacl-devel@lists.sourceforge.net>
> *Sent:* Tuesday, July 28, 2015 2:06 AM
> *Subject:* Re: [ViennaCL-devel] ViennaCL reductions
>
> Hi,
>
> > That's why I explicitly stated in my previous mail "Optional" :) I am
> > one of those folks who likes the coziness of compile time decisions and
> > (if possible) would like to make it available in VCL. However, I am not
> > sure if doing this is possible via the current API structure of VCL. I
> > will look into this as I first need to understand the intricacies of
> > OpenCL.
> >
> > BTW, a previous question of mine was unanswered (or I may have
> > overlooked). Are there any equivalent functions in VCL to do the
> following:
> > a.) Two matrices, when transferred to the GPU should undergo
> > element_wise multiplication ?
> > b.) A unary operation on a matrix that has been transferred to the GPU?
>
> a.) and b.) sound a lot like you are looking for element_*-functions
> http://viennacl.sourceforge.net/doc/manual-operations.html#manual-operations-blas1,
> <http://viennacl.sourceforge.net/doc/manual-operations.html#manual-operations-blas1,>
> which work for vectors and matrices alike.
>
> Best regards,
> Karli
>
>
>
> > ------------------------------------------------------------------------
> > *From:* Karl Rupp <r...@iue.tuwien.ac.at <mailto:r...@iue.tuwien.ac.at>>
> > *To:* Sumit Kumar <dost_4_e...@yahoo.com <mailto:dost_4_e...@yahoo.com>>
> > *Cc:* "viennacl-devel@lists.sourceforge.net
> <mailto:viennacl-devel@lists.sourceforge.net>"
> > <viennacl-devel@lists.sourceforge.net
> <mailto:viennacl-devel@lists.sourceforge.net>>
> > *Sent:* Monday, July 27, 2015 9:13 PM
> > *Subject:* Re: [ViennaCL-devel] ViennaCL reductions
> >
> > Hi Sumit,
> >
> > > Agreed, the names can be returned in any order. As you are using CMake
> > > would it be possible to:
> > > a.) Write a small helper script using CMake that lists what
> devices the
> > > user has on his/her machine that are OpenCL compliant?
> >
> > Exactly this is provided by running viennacl-info:
> > $> mkdir build && cd build
> > $> cmake ..
> > $> make viennacl-info
> > $> examples/tutorial/viennacl-info
> >
> >
> > > b.) Make VCL select the appropriate device so that these issues of
> > > context selection etc can be avoided?
> >
> > In most cases the first OpenCL device returned is the most appropriate
> > device for running the computations. If you know of any better strategy
> > for picking the default device, please let us know and we are happy to
> > adopt it. :-)
> >
> >
> > > c.) Of course, this would be purely optional and only available if the
> > > user wants to pre-select the device before writing any VCL code!
> >
> > How is that different from what is possible now? What is the value of
> > making a runtime-decision (current ViennaCL code) a compile-time
> > decision (CMake)?
> >
> > Imagine you are building a big application with GUI and other bells and
> > whistles. In such a scenario you would like the user to select the
> > compute device through a dialog at runtime rather than asking the user
> > to recompile the whole application just to change the default device.
> > Our current mindset is to incrementally move away from compile time
> > decisions in cases where they are not needed.
> >
> > Best regards,
> > Karli
> >
> >
> >
> >
> >
> >
> >
> > >
> ------------------------------------------------------------------------
> > > *From:* Karl Rupp <r...@iue.tuwien.ac.at
> <mailto:r...@iue.tuwien.ac.at> <mailto:r...@iue.tuwien.ac.at
> <mailto:r...@iue.tuwien.ac.at>>>
> > > *To:* Sumit Kumar <dost_4_e...@yahoo.com
> <mailto:dost_4_e...@yahoo.com> <mailto:dost_4_e...@yahoo.com
> <mailto:dost_4_e...@yahoo.com>>>
> > > *Cc:* "viennacl-devel@lists.sourceforge.net
> <mailto:viennacl-devel@lists.sourceforge.net>
> > <mailto:viennacl-devel@lists.sourceforge.net
> <mailto:viennacl-devel@lists.sourceforge.net>>"
> > > <viennacl-devel@lists.sourceforge.net
> <mailto:viennacl-devel@lists.sourceforge.net>
> > <mailto:viennacl-devel@lists.sourceforge.net
> <mailto:viennacl-devel@lists.sourceforge.net>>>
>
>
>
> > > *Sent:* Monday, July 27, 2015 7:03 PM
> > > *Subject:* Re: [ViennaCL-devel] ViennaCL reductions
> > >
> > > Hi Sumit,
> > >
> > > > Thanks for the update. I will check it out. As for the second one,
> > > > indeed thats what I ended up doing:
> > > >
> > > > // Get some context information for OpenCL compatible GPU
> devices
> > > > viennacl::ocl::platform pf;
> > > > std::vector<viennacl::ocl::device> devices =
> > > > pf.devices(CL_DEVICE_TYPE_GPU);
> > > > // If no GPU devices are found, we select the CPU device
> > > > if (devices.size() > 0)
> > > > {
> > > > // Now, often we may have an integrated GPU with the CPU. We
> > would
> > > > // like to avoid using that GPU. Instead, we search for a
> > discrete
> > > > // GPU.
> > > > viennacl::ocl::setup_context(0, devices[1]);
> > > > }
> > > > else
> > > > {
> > > > devices = pf.devices(CL_DEVICE_TYPE_CPU);
> > > > viennacl::ocl::setup_context(0, devices[0]);
> > > > }
> > >
> > > Keep in mind that devices may be returned in arbitrary order. I've
> > > already seen cases where the discrete GPU is returned as the first
> > > device. (Unfortunately I don't know of a robust and general way of
> > > dealing with such cases).
> > >
> > >
> > > > Here is my kludge. Is there any "real" example of data
> > partitioning and
> > > > using multiple GPU's?
> > >
> > > No. PCI-Express latencies narrow down to sweet spot of real
> performance
> > > gains for most algorithms in ViennaCL a lot. Only algorithms relying
> > > heavily on matrix-matrix multiplications are likely to show good
> benefit
> > > from multiple GPUs. As a consequence, we are currently keeping our
> focus
> > > on single GPUs. There is some multi-GPU support through ViennaCL as a
> > > plugin for PETSc available, but that focuses on iterative solvers and
> > > does not cover any eigenvalue routines yet.
> > >
> > >
> > >
> > >
> > > Best regards,
> > > Karli
> > >
> > >
> > >
> >
> >
> >
>
>
>
------------------------------------------------------------------------------
_______________________________________________
ViennaCL-devel mailing list
ViennaCL-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
