You can subscribe to this list here.
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(6) |
Aug
(30) |
Sep
(1) |
Oct
(10) |
Nov
(8) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2013 |
Jan
|
Feb
(9) |
Mar
(3) |
Apr
(1) |
May
(2) |
Jun
(2) |
Jul
(73) |
Aug
(145) |
Sep
(32) |
Oct
(45) |
Nov
(4) |
Dec
(76) |
2014 |
Jan
(24) |
Feb
(92) |
Mar
(27) |
Apr
(15) |
May
(57) |
Jun
(49) |
Jul
(105) |
Aug
(125) |
Sep
(7) |
Oct
(19) |
Nov
(70) |
Dec
(4) |
2015 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
(8) |
Jun
|
Jul
(40) |
Aug
(29) |
Sep
|
Oct
(8) |
Nov
(1) |
Dec
(7) |
2016 |
Jan
(12) |
Feb
(7) |
Mar
(8) |
Apr
(4) |
May
(20) |
Jun
(4) |
Jul
(38) |
Aug
(44) |
Sep
(11) |
Oct
(10) |
Nov
(13) |
Dec
(4) |
2017 |
Jan
|
Feb
(7) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Andreas I. <ar...@ih...> - 2013-07-21 14:59:35
|
Hi again, here's another problem which just occured to me while working with the latest developer version from GitHub. I have a program which has to iteratively solve a number of independent equation systems. The actual number of systems may vary between 1 and 10. Because they are totally independent from each other, we assign each system a number of OpenMP threads allowing them to be solved in parallel at the same time. Now I tried to integrate ViennaCL into that scheme and used the multithreaded.cpp example as a guide. The main difference is that I use OpenMP threads instead of Boost ones. My approach is to first create as many different OpenCL contexts as equation systems do exist and split the existing OpenCL devices over them. If just one device exists, its gonna be used by all contexts, which shouldn't be a problem. Then I call viennacl::ocl::switch_context() for every equation system and allocate all the required VCL vectors and matrices required just afterwards. This makes sure they are assigned and allocated for the context they actually belong to. This all still takes place in serial mode and doesn't bring me in trouble :-) The actual problems begin, when the solver routine of our programm is called in parallel mode. 1.) It fills a preallocated STL matrix with the current coefficients and updates the RHS vector. These are gonna be copied to their VCL counterparts using viennacl::copy(stlmat,vclmat); What happens exactly during this call is that viennacl::copy()-> viennacl::detail::copy_impl()-> gpu_matrix.set()-> viennacl::backend::memory_create() (in compressed_matrix.hpp at row 519ff) allocates 3 new buffers which should be created for the context they belong to. This could be achieved by calling viennacl::ocl::switch_context() before the copy takes place. Unfortunately this isn't an option because I would have to use a OMP Critical region to make sure that the parallel calls to switch_context() & copy() do not overlap each other leading to race conditions. So what I need is an oportunity to specify a context in which the copy() takes place without having to change the actual context. 2.) The same problem happens afterwards when calling the actual Preconditioner and solve() routines. They too allocate memory for the currently active context. I built a temporary workaround by putting the whole sequence into a OpenMP Critical region which prevents context errors in ViennaCL, but makes it impossible to solve the equation systems in parallel. Any suggestions on that? Kind regards Andreas Rost |
From: Shantanu A. <sha...@gm...> - 2013-07-14 16:28:18
|
Hi Andreas, You can try building the project 'kernels' generated by CMake. It generated and placed the header files in the appropriate place in my case. Regards, Shantanu On Sun, Jul 14, 2013 at 9:24 PM, Karl Rupp <ru...@iu...> wrote: > Hi Andreas, > > > > maybe a stupid question... :-) > >> >> I tried to build the latest ViennaCL developer version from Github on my >> Windows system. >> >> Building it using CMake-Gui (2.8.11.2) apparently worked fine (after >> removing all errors shown by Configure and finally performing Generate). >> Afterwards the build subfolder was filled with the output produced by >> CMake. >> >> The only problem is, that the subdir <ViennaCL-Dev-Path>\build\**viennacl\linalg\kernels >> exists but still doesn't contain any Header files... >> > > The problem here is that the OpenCL kernel generation from the developer > repository does not yet work on Windows properly. There are some > CMake-based scripts involved which we currently try to get rid of, but have > never tested this on Windows. > > The easiest way for you to generate the <ViennaCL-Dev-Path>\build\**viennacl\* > folder is on a Linux machine, then copy it over. > If this is not possible, feel free to just use the zip-file attached. It > works for the current head in master, but as we are currently approaching > the 1.5.0 release, it may be obsolete soon. > > Best regards, > Karli > > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > ViennaCL-devel mailing list > Vie...@li... > https://lists.sourceforge.net/lists/listinfo/viennacl-devel > > |
From: Karl R. <ru...@iu...> - 2013-07-14 15:55:07
|
Hi Andreas, > maybe a stupid question... :-) > > I tried to build the latest ViennaCL developer version from Github on my Windows system. > > Building it using CMake-Gui (2.8.11.2) apparently worked fine (after removing all errors shown by Configure and finally performing Generate). > Afterwards the build subfolder was filled with the output produced by CMake. > > The only problem is, that the subdir <ViennaCL-Dev-Path>\build\viennacl\linalg\kernels exists but still doesn't contain any Header files... The problem here is that the OpenCL kernel generation from the developer repository does not yet work on Windows properly. There are some CMake-based scripts involved which we currently try to get rid of, but have never tested this on Windows. The easiest way for you to generate the <ViennaCL-Dev-Path>\build\viennacl\* folder is on a Linux machine, then copy it over. If this is not possible, feel free to just use the zip-file attached. It works for the current head in master, but as we are currently approaching the 1.5.0 release, it may be obsolete soon. Best regards, Karli |
From: Andreas I. <ar...@ih...> - 2013-07-14 15:43:28
|
Hi @all, maybe a stupid question... :-) I tried to build the latest ViennaCL developer version from Github on my Windows system. Building it using CMake-Gui (2.8.11.2) apparently worked fine (after removing all errors shown by Configure and finally performing Generate). Afterwards the build subfolder was filled with the output produced by CMake. The only problem is, that the subdir <ViennaCL-Dev-Path>\build\viennacl\linalg\kernels exists but still doesn't contain any Header files... Any help appreciated! Best regards Andreas Rost |
From: Karl R. <ru...@iu...> - 2013-06-05 21:59:37
|
Hi Evan, > Check out: https://github.com/viennacl/viennacl-dev/blob/master/auxiliary/ell_matrix/align1/vec_mul.cl > > why the condition inside the loop? that would cause thread divergence > if your matrix contains zeros. Under what circumstances would it be > necessary/beneficial? If I'm not mistaken (I'm not the author of the kernel), this is necessary in order to skip 'empty' entries in the ELL format, i.e. values for which col may contain an invalid index. For example, an ELL format for 6 entries per row needs to deal with rows containing less than six entries as well. You're probably right that the data structure can/should be corrected such that it avoids thread divergence at the cost of possibly unnecessary index read operations. Best regards, Karli |
From: Evan B. <bo...@gm...> - 2013-06-05 16:07:05
|
Hey Karl, Check out: https://github.com/viennacl/viennacl-dev/blob/master/auxiliary/ell_matrix/align1/vec_mul.cl why the condition inside the loop? that would cause thread divergence if your matrix contains zeros. Under what circumstances would it be necessary/beneficial? -Evan -- -Evan Bollig bo...@gm... bo...@sc... |
From: Philippe T. <phi...@gm...> - 2013-05-23 08:46:13
|
Hi Shantanu, I think I am the author of such duplicate, introduced in the first iteration of the generator. This mainly comes from the fact that I was using internally viennacl::ocl::info<> (which will come in ViennaCL 1.5.0, you can have a look in the development branch). I had just did not see one of the functions, and created an additional one... Thanks for reporting anyway, I'll fix my mistake ASAP (or you can do a pull request on github !) 2013/5/23 Shantanu Agarwal <sha...@gm...> > Hi, > > The functions max_compute_units() and compute_units() & > max_workgroup_size() and max_work_group_size() in devices.hpp appear to be > identical. Is there a reason for this? > > Thanks > > Regards, > Shantanu > > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > _______________________________________________ > ViennaCL-devel mailing list > Vie...@li... > https://lists.sourceforge.net/lists/listinfo/viennacl-devel > > |
From: Shantanu A. <sha...@gm...> - 2013-05-23 07:37:35
|
Hi, The functions max_compute_units() and compute_units() & max_workgroup_size() and max_work_group_size() in devices.hpp appear to be identical. Is there a reason for this? Thanks Regards, Shantanu |
From: Karl R. <ru...@iu...> - 2013-04-29 03:06:20
|
Dear ViennaCL users, ViennaCL 1.4.2 is now available for download at http://viennacl.sourceforge.net/ This is a bugfix release, particularly addressing issues on Visual Studio 2012. From the changelogs: - Largely refactored the internal code base, unifying code for vector, vector_range, and vector_slice. Similar code refactoring was applied to matrix, matrix_range, and matrix_slice. This not only resolves the problems in VS 2012, but also leads to shorter compilation times and a smaller code base. - Improved performance of matrix-vector products of compressed_matrix on CPUs using OpenCL. - Resolved a bug which shows up if certain rows and columns of a compressed_matrix are empty and the matrix is copied back to host. - Fixed a bug and improved performance of GMRES. Thanks to Ivan Komarov for reporting via sourceforge. - Added additional Doxygen documentation. Thanks to all contributors :-) Best regards, Karl Rupp |
From: Karl R. <ru...@iu...> - 2013-03-16 18:47:52
|
Dear all, the ViennaCL developer repository moved to https://github.com/viennacl/viennacl-dev Please update your repository path in .git/config accordingly. Thanks and best regards, Karli |
From: Karl R. <ru...@iu...> - 2013-03-13 13:04:07
|
Hi Evan, I guess you will be even more shattered to hear/read that NVIDIA still does not provide OpenCL 1.2 support (unlike Intel, AMD), i.e. you are limited to OpenCL 1.1 on your new iMac... There is not much hope that this will change anytime soon. Best regards, Karli On 03/13/2013 07:37 AM, Evan Bollig wrote: > Got a new iMac (2013) with a NVidia 680MX. Was excited to toy with > OpenCL out-of-order event queues last night. Wanted to verify > scheduling on multiple concurrent branches of the same queue DAG. My > hopes and dreams were shattered when I realized that the only valid > OpenCL platform is from Apple, not NVidia. Even worse is that the > whole out-of-order event queue feature is disabled. (. _ .") > > Anyone have insider info regarding a release date for a new NVidia OSX > driver? Btw, I haven't dug into this yet: do you know if the current > OSX NVidia platform supports spec 1.2? Apple is limited to 1.1. > > Meanwhile, back to the M2070. > > Cheers, > -Evan > |
From: Evan B. <bo...@gm...> - 2013-03-13 12:37:46
|
Got a new iMac (2013) with a NVidia 680MX. Was excited to toy with OpenCL out-of-order event queues last night. Wanted to verify scheduling on multiple concurrent branches of the same queue DAG. My hopes and dreams were shattered when I realized that the only valid OpenCL platform is from Apple, not NVidia. Even worse is that the whole out-of-order event queue feature is disabled. (. _ .") Anyone have insider info regarding a release date for a new NVidia OSX driver? Btw, I haven't dug into this yet: do you know if the current OSX NVidia platform supports spec 1.2? Apple is limited to 1.1. Meanwhile, back to the M2070. Cheers, -Evan -- -Evan Bollig bo...@gm... bo...@sc... |
From: Karl R. <ru...@iu...> - 2013-02-22 21:43:46
|
Dear ViennaCL users, ViennaCL 1.4.1 is now available for download! This release focuses on improved stability and performance on AMD devices rather than introducing new features. Highlights: - Included fast matrix-matrix multiplication kernel for AMD's Tahiti GPUs if matrix dimensions are a multiple of 128. Our sample HD7970 reaches over 1.3 TFLOPs in single precision and 200 GFLOPs in double precision. - Fixes and improved support for BLAS-1-type operations on dense matrices and vectors. - Vector expressions can now be passed to inner_prod(), norm_1(), norm_2() and norm_inf() directly. - Improved performance when using OpenMP. - Better support for Intel Xeon Phi (MIC). - The future development platform is now on github: https://github.com/karlrupp/viennacl-dev/ Thanks to all contributors :-) Best regards, Karl Rupp |
From: Philippe T. <phi...@gm...> - 2013-02-05 12:44:05
|
Hi, I worked a tiny bit with github last year, and it is a pretty good memory. So I vote for it :p Best regards, Philippe 2013/2/5 Karl Rupp <ru...@iu...> > Hi guys, > > my colleagues in Vienna and I recently discussed about the possibility > of running all the ViennaCL development via github. Discrete release > handling including email lists and webpage will be kept on sourceforge > since we consider sourceforge to be the better platform for this purpose. > > The expected benefit of steering the latest development of ViennaCL via > github is better accessibility of the sources, a simplified handling of > pull-requests, inline source comments, and a better bugtracker. It > should also allow us to attach BuildHive for continuous code > integration, even though this is fairly non-trivial with all the > different GPU-hardware required for complete coverage. > > What is your opinion or experience on such a split? Evan Bollig created > a fork on github already, so his github-experiences are of particular > interest :-) > > Best regards, > Karli > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_jan > _______________________________________________ > ViennaCL-devel mailing list > Vie...@li... > https://lists.sourceforge.net/lists/listinfo/viennacl-devel > |
From: Philippe T. <phi...@gm...> - 2013-02-05 12:37:50
|
Hi hi, 2013/2/5 Aanchan mohan <aa...@gm...> > Hi Karl and Philippe > > Thanks for your replies. My work does involve linear algebra. I work with > parameteric estimation (mostly in the maximum likelihood sense) of the > estimation of Gaussian mixture densitites (GMMs) in HMMs. These (GMMs) > routinely used in speech recognition. So I work with operations like matrix > multiplications, SVD, eigen-value decompositions, LU Decompositions, > Cholesky Factorizations, matrix inverses (various methods such as either > with the SVD or the Cholesky) to name a few. I am also interested in > gradient descent/ascent procedures in general. These are again routinely > used to estimate the weights of neural net-work based hybrid ANN-HMM > systems. So, Karl and Philippe, any open development suggestions along > these lines are quite welcome. > > I see. If you are very familiar with the OpenCL Kernels, there is still a relatively open problem in GPGPU computing which has an implementation in the CUDA domain but not in the OpenCL domain which is Sparse GEMM... Concerning learning for solving the weights of a neural network, I started a library about 1 ~ 1.5 years ago, which is dead since then ( http://code.google.com/p/mlcl/) . Some learning algorithms are implemented. According to my experiments, Rprop+ works better on the GPU than the Conjugate Gradient method, from a convergence speed point of view. Anyway, Conjugate Gradient Minimization used to be implemented. Another option would be to integrate in ViennaCL non linear function minimization tools, such as Gradient Descent, Conjugate Gradient or LBFGS. (This library is now the topic of my M.Sc thesis, so i'll get back on it after some more work on ViennaCL, probably this summer. If you want to work on this when I get back to it, you're also welcome) Philippe thanks for the suggestions regarding the random number generation > issue, and the PCA. It would be good to start on the random number > generation issue, since it seems do-able and has been precisely defined by > you. The PCA was something I was wondering if it had already been > implemented. I'd be glad to work on it. > Oh yes, that reminds me I forgot to tell you that I used in the above project MWC64X to initialize a ViennaCL vector with random uniform values. I can pull out this piece of code if you want, so you can make a generic random initializer. Concerning PCA, I think you could even work on Kernel PCAs if you want it! > > Regards, > > Aanchan > > Best regards, Philippe > On Mon, Feb 4, 2013 at 5:01 AM, Philippe Tillet <phi...@gm...>wrote: > >> Hello Aanchan, >> >> Welcome! :) >> Your research area is somehow close to my MSc research, which is machine >> learning. >> It is likely that you have to deal with noise, and that you therefore >> need to simulate random numbers. You might want to add support for random >> numbers in ViennaCL. >> There are two external libraries that deal with random numbers on OpenCL >> : http://cas.ee.ic.ac.uk/people/dt10/research/rngs-gpu-mwc64x.html ans >> http://www.deshawresearch.com/resources_random123.html. The first one is >> simpler, but the second one looks more robust. >> Because of licensing issues, it should be easier to require these >> functions as an external dependancy and provide a function vector<double> >> x = random_vector(1000, random_generator_tag). >> After that, it should be possible to add support for the inverse >> transform sampling method using the upcoming version of the generator, to >> add something like : >> vector<double> x = random_vector(1000, random_generator_tag(sqrt(X))). >> >> Hmmm, something else I can think of, more related to speech recognition, >> but not to markov models, is to add an implementation of the PCA. There are >> some missing tools as far as I know to deal with it for now, ie sorting and >> maybe the Eigenvalue computation problem. >> If it is too specific to be integrated in ViennaCL (is it, Karl?), it >> could still be part of the examples suite. >> The same goes for Independant Components Analysis, but this one if more >> complicated :P >> >> Best regards, >> Philippe >> >> >> 2013/2/4 Karl Rupp <ru...@iu...> >> >>> Hi Aanchan, >>> >>> great, welcome! :-) Which are the main linear algebra operations you use >>> in your research? I've once worked with Markov chains, where one of the >>> main operations are eigenvalue computations, but I don't know whether >>> this applies to speech recognition as well. >>> >>> Best regards, >>> Karli >>> >>> >>> On 02/03/2013 06:31 PM, Aanchan mohan wrote: >>> > Hello Vienna CL Developers, >>> > >>> > I am a PhD student at McGill University working in the area of Speech >>> > Recognition. I work with developing algorithms with open source >>> software >>> > in C mainly with the Hidden Markov Model toolkit (HTK) for my own >>> > research. I have interests in scientific computing, and I chanced upon >>> > this project. I am enthusiastic to contribute to the ViennaCL project >>> > and I was wondering what the existing open threads for development >>> might >>> > be. I clicked on the contribute tab on the webpage for the project, and >>> > there was a suggestion to e-mail to this list to find out. Any leads >>> > would be great. >>> > >>> > Cheers, >>> > -- >>> > Aanchan Mohan >>> > >>> > >>> > >>> > >>> ------------------------------------------------------------------------------ >>> > Everyone hates slow websites. So do we. >>> > Make your web apps faster with AppDynamics >>> > Download AppDynamics Lite for free today: >>> > http://p.sf.net/sfu/appdyn_d2d_jan >>> > >>> > >>> > >>> > _______________________________________________ >>> > ViennaCL-devel mailing list >>> > Vie...@li... >>> > https://lists.sourceforge.net/lists/listinfo/viennacl-devel >>> > >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Everyone hates slow websites. So do we. >>> Make your web apps faster with AppDynamics >>> Download AppDynamics Lite for free today: >>> http://p.sf.net/sfu/appdyn_d2d_jan >>> _______________________________________________ >>> ViennaCL-devel mailing list >>> Vie...@li... >>> https://lists.sourceforge.net/lists/listinfo/viennacl-devel >>> >> >> > > > -- > Aanchan Mohan > > |
From: Karl R. <ru...@iu...> - 2013-02-04 21:23:50
|
Hi guys, my colleagues in Vienna and I recently discussed about the possibility of running all the ViennaCL development via github. Discrete release handling including email lists and webpage will be kept on sourceforge since we consider sourceforge to be the better platform for this purpose. The expected benefit of steering the latest development of ViennaCL via github is better accessibility of the sources, a simplified handling of pull-requests, inline source comments, and a better bugtracker. It should also allow us to attach BuildHive for continuous code integration, even though this is fairly non-trivial with all the different GPU-hardware required for complete coverage. What is your opinion or experience on such a split? Evan Bollig created a fork on github already, so his github-experiences are of particular interest :-) Best regards, Karli |
From: Karl R. <ru...@iu...> - 2013-02-04 21:09:16
|
Hi, > Thanks for your replies. My work does involve linear algebra. I work > with parameteric estimation (mostly in the maximum likelihood sense) of > the estimation of Gaussian mixture densitites (GMMs) in HMMs. These > (GMMs) routinely used in speech recognition. So I work with operations > like matrix multiplications, SVD, eigen-value decompositions, LU > Decompositions, Cholesky Factorizations, matrix inverses (various > methods such as either with the SVD or the Cholesky) to name a few. I am > also interested in gradient descent/ascent procedures in general. These > are again routinely used to estimate the weights of neural net-work > based hybrid ANN-HMM systems. So, Karl and Philippe, any open > development suggestions along these lines are quite welcome. Alright, so apparently your research is more in the 'dense' world. Most of the decompositions/factorizations in ViennaCL are currently in an experimental state, mostly missing a nice C++ convenience layer on top. Since your background is more in C, this might be a bit too hard to start with. Are the gradient descent methods you mentioned used with sparse matrices? > Philippe thanks for the suggestions regarding the random number > generation issue, and the PCA. It would be good to start on the random > number generation issue, since it seems do-able and has been precisely > defined by you. The PCA was something I was wondering if it had already > been implemented. I'd be glad to work on it. I think random numbers fits well, because it is a well-defined piece of functionality with only little complexity with respect to the user interface. Ideally, the interface will not only support OpenCL, but also CUDA and a standard C/C++ (OpenMP?) implementation. Once you have the OpenCL version working, it's usually fairly simple to deduce a CUDA/OpenMP version. Best regards, Karli |
From: Aanchan m. <aa...@gm...> - 2013-02-04 18:08:47
|
Hi Karl and Philippe Thanks for your replies. My work does involve linear algebra. I work with parameteric estimation (mostly in the maximum likelihood sense) of the estimation of Gaussian mixture densitites (GMMs) in HMMs. These (GMMs) routinely used in speech recognition. So I work with operations like matrix multiplications, SVD, eigen-value decompositions, LU Decompositions, Cholesky Factorizations, matrix inverses (various methods such as either with the SVD or the Cholesky) to name a few. I am also interested in gradient descent/ascent procedures in general. These are again routinely used to estimate the weights of neural net-work based hybrid ANN-HMM systems. So, Karl and Philippe, any open development suggestions along these lines are quite welcome. Philippe thanks for the suggestions regarding the random number generation issue, and the PCA. It would be good to start on the random number generation issue, since it seems do-able and has been precisely defined by you. The PCA was something I was wondering if it had already been implemented. I'd be glad to work on it. Regards, Aanchan On Mon, Feb 4, 2013 at 5:01 AM, Philippe Tillet <phi...@gm...>wrote: > Hello Aanchan, > > Welcome! :) > Your research area is somehow close to my MSc research, which is machine > learning. > It is likely that you have to deal with noise, and that you therefore need > to simulate random numbers. You might want to add support for random > numbers in ViennaCL. > There are two external libraries that deal with random numbers on OpenCL : > http://cas.ee.ic.ac.uk/people/dt10/research/rngs-gpu-mwc64x.html ans > http://www.deshawresearch.com/resources_random123.html. The first one is > simpler, but the second one looks more robust. > Because of licensing issues, it should be easier to require these > functions as an external dependancy and provide a function vector<double> > x = random_vector(1000, random_generator_tag). > After that, it should be possible to add support for the inverse transform > sampling method using the upcoming version of the generator, to add > something like : > vector<double> x = random_vector(1000, random_generator_tag(sqrt(X))). > > Hmmm, something else I can think of, more related to speech recognition, > but not to markov models, is to add an implementation of the PCA. There are > some missing tools as far as I know to deal with it for now, ie sorting and > maybe the Eigenvalue computation problem. > If it is too specific to be integrated in ViennaCL (is it, Karl?), it > could still be part of the examples suite. > The same goes for Independant Components Analysis, but this one if more > complicated :P > > Best regards, > Philippe > > > 2013/2/4 Karl Rupp <ru...@iu...> > >> Hi Aanchan, >> >> great, welcome! :-) Which are the main linear algebra operations you use >> in your research? I've once worked with Markov chains, where one of the >> main operations are eigenvalue computations, but I don't know whether >> this applies to speech recognition as well. >> >> Best regards, >> Karli >> >> >> On 02/03/2013 06:31 PM, Aanchan mohan wrote: >> > Hello Vienna CL Developers, >> > >> > I am a PhD student at McGill University working in the area of Speech >> > Recognition. I work with developing algorithms with open source software >> > in C mainly with the Hidden Markov Model toolkit (HTK) for my own >> > research. I have interests in scientific computing, and I chanced upon >> > this project. I am enthusiastic to contribute to the ViennaCL project >> > and I was wondering what the existing open threads for development might >> > be. I clicked on the contribute tab on the webpage for the project, and >> > there was a suggestion to e-mail to this list to find out. Any leads >> > would be great. >> > >> > Cheers, >> > -- >> > Aanchan Mohan >> > >> > >> > >> > >> ------------------------------------------------------------------------------ >> > Everyone hates slow websites. So do we. >> > Make your web apps faster with AppDynamics >> > Download AppDynamics Lite for free today: >> > http://p.sf.net/sfu/appdyn_d2d_jan >> > >> > >> > >> > _______________________________________________ >> > ViennaCL-devel mailing list >> > Vie...@li... >> > https://lists.sourceforge.net/lists/listinfo/viennacl-devel >> > >> >> >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_jan >> _______________________________________________ >> ViennaCL-devel mailing list >> Vie...@li... >> https://lists.sourceforge.net/lists/listinfo/viennacl-devel >> > > -- Aanchan Mohan |
From: Philippe T. <phi...@gm...> - 2013-02-04 10:02:26
|
Hello Aanchan, Welcome! :) Your research area is somehow close to my MSc research, which is machine learning. It is likely that you have to deal with noise, and that you therefore need to simulate random numbers. You might want to add support for random numbers in ViennaCL. There are two external libraries that deal with random numbers on OpenCL : http://cas.ee.ic.ac.uk/people/dt10/research/rngs-gpu-mwc64x.html ans http://www.deshawresearch.com/resources_random123.html. The first one is simpler, but the second one looks more robust. Because of licensing issues, it should be easier to require these functions as an external dependancy and provide a function vector<double> x = random_vector(1000, random_generator_tag). After that, it should be possible to add support for the inverse transform sampling method using the upcoming version of the generator, to add something like : vector<double> x = random_vector(1000, random_generator_tag(sqrt(X))). Hmmm, something else I can think of, more related to speech recognition, but not to markov models, is to add an implementation of the PCA. There are some missing tools as far as I know to deal with it for now, ie sorting and maybe the Eigenvalue computation problem. If it is too specific to be integrated in ViennaCL (is it, Karl?), it could still be part of the examples suite. The same goes for Independant Components Analysis, but this one if more complicated :P Best regards, Philippe 2013/2/4 Karl Rupp <ru...@iu...> > Hi Aanchan, > > great, welcome! :-) Which are the main linear algebra operations you use > in your research? I've once worked with Markov chains, where one of the > main operations are eigenvalue computations, but I don't know whether > this applies to speech recognition as well. > > Best regards, > Karli > > > On 02/03/2013 06:31 PM, Aanchan mohan wrote: > > Hello Vienna CL Developers, > > > > I am a PhD student at McGill University working in the area of Speech > > Recognition. I work with developing algorithms with open source software > > in C mainly with the Hidden Markov Model toolkit (HTK) for my own > > research. I have interests in scientific computing, and I chanced upon > > this project. I am enthusiastic to contribute to the ViennaCL project > > and I was wondering what the existing open threads for development might > > be. I clicked on the contribute tab on the webpage for the project, and > > there was a suggestion to e-mail to this list to find out. Any leads > > would be great. > > > > Cheers, > > -- > > Aanchan Mohan > > > > > > > > > ------------------------------------------------------------------------------ > > Everyone hates slow websites. So do we. > > Make your web apps faster with AppDynamics > > Download AppDynamics Lite for free today: > > http://p.sf.net/sfu/appdyn_d2d_jan > > > > > > > > _______________________________________________ > > ViennaCL-devel mailing list > > Vie...@li... > > https://lists.sourceforge.net/lists/listinfo/viennacl-devel > > > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_jan > _______________________________________________ > ViennaCL-devel mailing list > Vie...@li... > https://lists.sourceforge.net/lists/listinfo/viennacl-devel > |
From: Karl R. <ru...@iu...> - 2013-02-04 05:00:46
|
Hi Aanchan, great, welcome! :-) Which are the main linear algebra operations you use in your research? I've once worked with Markov chains, where one of the main operations are eigenvalue computations, but I don't know whether this applies to speech recognition as well. Best regards, Karli On 02/03/2013 06:31 PM, Aanchan mohan wrote: > Hello Vienna CL Developers, > > I am a PhD student at McGill University working in the area of Speech > Recognition. I work with developing algorithms with open source software > in C mainly with the Hidden Markov Model toolkit (HTK) for my own > research. I have interests in scientific computing, and I chanced upon > this project. I am enthusiastic to contribute to the ViennaCL project > and I was wondering what the existing open threads for development might > be. I clicked on the contribute tab on the webpage for the project, and > there was a suggestion to e-mail to this list to find out. Any leads > would be great. > > Cheers, > -- > Aanchan Mohan > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_jan > > > > _______________________________________________ > ViennaCL-devel mailing list > Vie...@li... > https://lists.sourceforge.net/lists/listinfo/viennacl-devel > |
From: Aanchan m. <aa...@gm...> - 2013-02-04 00:31:57
|
Hello Vienna CL Developers, I am a PhD student at McGill University working in the area of Speech Recognition. I work with developing algorithms with open source software in C mainly with the Hidden Markov Model toolkit (HTK) for my own research. I have interests in scientific computing, and I chanced upon this project. I am enthusiastic to contribute to the ViennaCL project and I was wondering what the existing open threads for development might be. I clicked on the contribute tab on the webpage for the project, and there was a suggestion to e-mail to this list to find out. Any leads would be great. Cheers, -- Aanchan Mohan |
From: Karl R. <ru...@iu...> - 2012-12-03 03:26:25
|
Dear ViennaCL users, ViennaCL 1.4.0 is now available for download! The release features the largest number of additions, improvements, and cleanups since the very initial release. The most important changes are as follows: - Now three compute backends: CUDA, Host-based (single-threaded/OpenMP), and OpenCL - Added mixed-precision CG solver (OpenCL-based). - Greatly improved performance of ILU0/ILUT preconditioners (up to 10x). - Added initializer types from Boost.uBLAS (unit_vector, zero_vector, scalar_vector, identity_matrix, zero_matrix, scalar_matrix). - Added incomplete Cholesky factorization preconditioner. - Added element-wise operations for vectors as available in Boost.uBLAS (element_prod, element_div). - Added restart-after-N-cycles option to BiCGStab. - Added level-scheduling for ILU-preconditioners. Performance strongly depends on matrix pattern. - Reduced overhead when copying to/from ublas::compressed_matrix. - ViennaCL objects (scalar, vector, etc.) can now be used as global variables (thanks to an anonymous user on the support-mailinglist). - Kernel generator: Various new features, including support for multiple arguments, a repeat() feature for generating loops inside a kernel, element-wise products and division, and support for every one-argument OpenCL function. Thanks to all contributors :-) Best regards, Karl Rupp |
From: Karl R. <ru...@iu...> - 2012-11-23 12:57:17
|
Thanks to Denis for creating the ebuild :-) -------- Original Message -------- Subject: ViennaCL package for Gentoo Linux Date: Fri, 23 Nov 2012 10:45:59 +0400 From: Denis Demidov <den...@gm...> To: Karl Rupp <ru...@mc...> Hello Karl, I have created a Gentoo ebuild for ViennaCL-1.3.1 (https://github.com/ddemidov/ebuilds/blob/master/dev-util/viennacl/viennacl-1.3.1.ebuild). It just clones git repository from sourceforge, checks out tag 'release-1.3.1' and copies 'viennacl' folder to /usr/include. This may be of use for some of your users. -- Cheers, Denis |
From: Karl R. <ru...@iu...> - 2012-11-18 05:13:27
|
Hi guys, I've pushed my recent updates to sourceforge. For those of you who have used the iterative solvers, I've got great news: By getting rid of using an uBLAS-type interface internally and using a low-level implementation instead, the ILU0 und ILUT-preconditioners experience performance gains by about an order of magnitude. Also, a GPU-version of ILU0 substitutions using level scheduling is implemented, which is expected to yield good performance gains for linear systems of equations that stem from three-dimensional meshes. A lot of functionality is already available on standard CPU, OpenCL *and* CUDA. Just some notes for using the developer version: When pulling from the sourceforge repository, the OpenCL kernels are generated in build/ after typing make in this folder. With each pull adding new OpenCL kernels in auxiliary/, it is a good idea to just delete build/auxilary, otherwise old kernels might interfere with the new ones. My initial plan/hope of releasing these days unfortunately doesn't hold, but most work is done. I expect a release by the end of the month. Any testing, feedback, comments etc. is of course welcome :-) Best regards, Karli |
From: Karl R. <ru...@iu...> - 2012-11-15 15:01:36
|
Hi, I've checked the code and fortunately the bug does not show up in my latest branch (I'll soon push that to sourceforge). As for the performance regression: I've compared my current branch against the generator (vector size 10^6, 10 runs) * Single precision: GTX 285 inner_prod() time: 0.001483 GTX 285 generator time: 0.001473 HD 7970 inner_prod() time: 0.010 HD 7970 generator time: 0.010 * Double precision: GTX 285 inner_prod() time: 0.002252 GTX 285 generator time: 0.002237 HD 7970 inner_prod() time: 0.013855 HD 7970 generator time: 0.013184 Thus, the difference is within the accuracy of the timer in all four cases. It is, however, interesting to observe that the HD 7970 is showing rather poor performance despite its higher memory bandwidth - I think I know how to fix this. > My current guess is from the sum kernel. There is a line, "if(option>0) > ... else ...", which is greatly discouraged in the opencl guides I have > read, quoted from the AMD Guide (quoted below) > I'll double check my toy benchmark to be sure of sure though > > ============== > (...) > ==================== > > basically option==0?a:b would probably offer better performances. The guide is certainly right in terms of raw cycles. However, the sum kernel is HEAVILY dominated by kernel launch overhead anyway, as it just sums ~128 entries. Also, the if ... else ... construct does not really matter for any of the vector kernels: First, there is no thread divergence, and second this is only a startup dispatch. (Yes, I have benchmarks confirming that claim ;-) ) The reason for the option-thing is that basically all the following operations are dealt with in the same kernel: v1 = v2 * a + v3 * b v1 = v2 / a + v3 * b v1 = v2 * a + v3 / b v1 = v2 / a + v3 / b v1 = -v2 * a + v3 * b v1 = -v2 / a + v3 * b v1 = -v2 * a + v3 / b v1 = -v2 / a + v3 / b v1 = v2 * a - v3 * b v1 = v2 / a - v3 * b v1 = v2 * a - v3 / b v1 = v2 / a - v3 / b v1 = -v2 * a - v3 * b v1 = -v2 / a - v3 * b v1 = -v2 * a - v3 / b v1 = -v2 / a - v3 / b In addition, one needs to distinguish between a and b being CPU or GPU scalars and eventually take an additional (-a) and (-b) coming from the GPU into account. In a naive approach one would end up with at least 64 kernels, while the option-thing allows to use only four kernels. Best regards, Karli |