<zoq[m]>
Hello manav71 (Manav Sanghi) , since you are interested in the examples idea, one next step is to make sure you have a working local jupyter notebook instance running. One way is to use https://github.com/mlpack/examples/blob/master/scripts/jupyter-conda-setup.sh. After that you could contribute a simple example notebook, don't feel obligated, it's just one thing I would recommend to get familiar with the codebase. Since you mentioned you have
<zoq[m]>
experience with GitHub actions, I was actually wondering if we could set up some GitHub Actions job to automatically check the notebooks, if they run without any errors. We already have a job for the non-notebook code.
<ShubhamAgrawal[4>
<zoq[m]> "Hello manav71 (Manav Sanghi..." <- One way to go about it is to convert `.ipynb` to `.py` using nbconvert, and then rename out file to `.cpp` extension, and use it in usual way.
<ShubhamAgrawal[4>
But I think this is very short for a GSoC project. I may be wrong.
<zoq[m]>
> <@shubhamag:matrix.org> One way to go about it is to convert `.ipynb` to `.py` using nbconvert, and then rename out file to `.cpp` extension, and use it in usual way.
<zoq[m]>
> But I think this is very short for a GSoC project. I may be wrong.
<zoq[m]>
Yes, was meant as a contribution to get familiar with the codebase.
<ShubhamAgrawal[4>
zoq[m]: Oh
<ShubhamAgrawal[4>
<Aakash-kaushikAa> "Hey @shubhamag:matrix.org it..." <- Sent now :)
<ShubhamAgrawal[4>
* Sent just now :)
<ShubhamAgrawal[4>
> <@aakash-kaushik-5f3a5ad9d73408ce4fec6e70:gitter.im> Hey @shubhamag:matrix.org it would be great if you mail your idea or discussion to the mailing list.
CaCode has joined #mlpack
CaCode has quit [Remote host closed the connection]
hitesh-anandhite has joined #mlpack
<hitesh-anandhite>
Hello mlpack community,
<hitesh-anandhite>
Hello mlpack community,
<hitesh-anandhite>
Myself Hitesh Anand. I am a computer science undergrad in my 4th semester at IIT Kanpur. I have experience in python, C++, ML and Deep Learning. Also, I am currently working on an undergraduate project related to deep learning. I am interested in contributing to mlpack in the GSoC’22. I have used mlpack and it was a really good experience as a user. Can someone kindly guide me about how to proceed further and whom to discuss my
<hitesh-anandhite>
project ideas with?
<hitesh-anandhite>
Thanks in advance.
<NabanitaDash[m]>
due to unexpected exception with message:
<NabanitaDash[m]>
Mat::max(): object has no elements
<zoq[m]>
<rcurtin[m]> "zoq: is https://github.com/..."; <- One more change, I can do that later.
<rcurtin[m]>
sounds good! I just wanted to know if I could merge it. in this case I will not 😄
<GopiMTatiraju[m]>
Heyy, I had one doubt regarding bandicoot, I see that in kernels directory in cuda there are more folders named onewat twoway and threeway, what is the difference between those?
<rcurtin[m]>
each kernel is written to take a different element type---so depending on settings of the preprocessor, we can compile a kernel for float, double, int, etc.
<rcurtin[m]>
now some of these kernels, like `accu()`, only have one element type
<rcurtin[m]>
(hence, "oneway", although I dunno if that is the best name)
<rcurtin[m]>
some other kernels are "two-way", e.g., a dot-product `dot(A, B)` could be between a GPU matrix `A` that has element type `float` and `B` that has element type `double`
<GopiMTatiraju[m]>
Ohh okay...
<GopiMTatiraju[m]>
So do will join fall under twoway?
<GopiMTatiraju[m]>
We can join matrices to different types, right?
<GopiMTatiraju[m]>
s/do//, s/to/of/
<rcurtin[m]>
it would be possible to do that, but I would actually suggest implementing `join_cols()` and `join_rows()` as requiring the same types. I also think you can do it with cudaMemcpy() and related functions, instead of needing to write a custom kernel (at least for `join_cols()`, maybe `join_rows()` is more complicated)
<rcurtin[m]>
the reason I suggest requiring the same types (at least for the kernels and low-level implementation) is that there is some overhead associated with every kernel we add, so ideally we want to keep the number of kernels low, or as low as we can (and even then there will be many, there is not much way around that)
<rcurtin[m]>
so, the top-level `join_cols()` function can take different matrix types, but if they are different, you can use `conv_to<>` to convert the matrices to the right output type, and then join them
<rcurtin[m]>
(it is true that my suggestion does not give the fastest possible code---but I'm trying to strike a balance between number of kernels and performance. tough to say if that is actually the right tradeoff in user applications... I am just making a somewhat educated guess)
<zoq[m]>
I guess it depends on the usecase, you could add another build step, to remove all the unused kernels.
<rcurtin[m]>
yeah. in fact, if we had a way to cache compiled kernels somewhere on the user's system, then the number of kernels doesn't really matter
<rcurtin[m]>
but currently, every single time we start a program that includes bandicoot, it compiles all kernels at initialization. so, I think most of the test suite runtime is compiling those kernels at the start of runtime, and then the tests all run pretty quickly
Niketkumardheery has joined #mlpack
<Niketkumardheery>
Hi Everyone ,I am Niket a computer science engineer , I have keen interest in data science and i was looking for contributing in Data science community and finally i got MlPack
<zoq[m]>
Yeah, but that is one reason why I'm more on the side of getting the kernels as fast a possible, instead of keeping the number of kernels low; because I'm thinking about a long running process.
<rcurtin[m]>
hmm, in that case, maybe it is better to write `join_rows()` as a two-way kernel, and I suppose `join_cols()` too. In the case where the types are the same, `join_cols()` may be best done as a `cudaMemcpy()` though
<zoq[m]>
But in case of `join_` I think it makes sense to be clever?
<Niketkumardheery>
* Hi Everyone ,I am Niket a computer science engineer , I have keen interest in data science and i was looking for contributing in Data science community and finally i got MlPack ...
<Niketkumardheery>
Now looking forward to work with such enthusiastic peeps
<zoq[m]>
Don't think we can get much performance out of it with an independent kernel?
<rcurtin[m]>
I guess you are right, my intuition was that maybe `join_cols()` and `join_rows()` doesn't happen too much in inner loops, but on second thought I could be totally wrong
<zoq[m]>
> <@niketkumardheeryan-62304a3d6da03739849255da:gitter.im> Hi Everyone ,I am Niket a computer science engineer , I have keen interest in data science and i was looking for contributing in Data science community and finally i got MlPack ...
<zoq[m]>
Hello, in case you haven't seen it already and are searching for a getting started direction - https://www.mlpack.org/community.html should be helpful.
<zoq[m]>
> Now looking forward to work with such enthusiastic peeps
<Niketkumardheery>
* Hi Everyone ,I am Niket a computer science engineer , I have keen interest in data science and i was looking for contributing in Data science community and finally i got MlPack ...
<Niketkumardheery>
Now looking forward to work with such enthusiastic peeps
<Niketkumardheery>
* Hi Everyone ,I am Niket a computer science engineer , I have keen interest in data science and i was looking for contributing in Data science community and finally i got MlPack ...
<Niketkumardheery>
Now looking forward to work with such enthusiastic peeps
<zoq[m]>
rcurtin[m]: That is what I like about it, I just do both and do a quick benchmark.
<rcurtin[m]>
I wonder if maybe we should open an issue for some kind of local compiled kernel caching support for Bandicoot
<rcurtin[m]>
maybe we can just write out any compiled kernels to the user's home directory or something, and look for those
<rcurtin[m]>
but there is some complexity: if we find and load kernels, we have to make sure they correspond to the device that is being used, and that they are compatible with, e.g., the version of OpenCL or CUDA being used
<rcurtin[m]>
definitely not impossible but tedious
<rcurtin[m]>
if it worked, it would mean that there's a big long bandicoot compilation process the first time the user ever runs a bandicoot program (and printing to stderr to tell them what is going on is probably a good idea), but then after that we never need to do it again unless they change their setup
<GopiMTatiraju[m]>
I guess this might add a lot of overhead and future maintenance work as well....
<zoq[m]>
rcurtin[m]: Right, pytorch is doing the same thing I think.
<rcurtin[m]>
yeah, you are right Gopi M Tatiraju but I feel a bit forced into it... the alternative is that the user has to wait for like 10-30 seconds (or is it longer?) every single time they start a bandicoot program
<rcurtin[m]>
we don't have the benefit of PyTorch's development team size, unfortunately 😄😄
<rcurtin[m]>
which actually can be a good thing: the PyTorch core team is up in the hundreds now I believe (and Facebook is aggressively hiring more and more), which causes the complexity and maintainability of the system to explode since team members' priorities are generally to get promoted and produce code, not slowly write maintainable, small-footprint code
<rcurtin[m]>
I see this at my company: there is a lot of pressure to produce code fast, which results in lower-quality code that can't be maintained, and then later refactoring costs spiral into huge, unwieldy efforts that are borderline impossible
<rcurtin[m]>
(I guess the ANN refactoring is a little like this but it's nowhere near as bad as the refactorings I have to do or want to do at work)
<GopiMTatiraju[m]>
Yea I agree...
<GopiMTatiraju[m]>
Once the team size increases its difficult to manage and everyone wants to contribute more so that they can get promoted...
<GopiMTatiraju[m]>
And the code suffers due to this
<Niketkumardheery>
Agree
<GopiMTatiraju[m]>
So what I think now is that we are planning to add `join_` as a custom kernel?
<GopiMTatiraju[m]>
Or should we first try to write out some compiled kernels and see how it goes?
<rcurtin[m]>
it might be easiest just to start with an implementation of `join_cols()` using `cudaMemcpy()` (and the equivalent for OpenCL) for the same types, and then write a custom two-way kernel for `join_cols()` for two objects of different types
<rcurtin[m]>
then as zoq pointed out it would be easy to do some quick benchmark comparisons
<GopiMTatiraju[m]>
Okay, I will get on it then...
<GopiMTatiraju[m]>
Using `cudaMemcpy` is a bit straight forward I guess...
<GopiMTatiraju[m]>
Just have to copy the right elements and some checks I guess?
<rcurtin[m]>
yeah, plus setting up the scaffolding such that `coot::join_cols()` calls into the right backend, etc.; you can take a look at the other functions like `dot()` to see how that works
<GopiMTatiraju[m]>
Yea, I will refer the existing code for that...
<GopiMTatiraju[m]>
we will have a meeting this friday, right?
<GopiMTatiraju[m]>
I hope I can finish this before that so that we can discuss more on this...
<TarekNasser[m]>
Should I use Xeus Cling and Jupyterlab to run cpp notebooks?
<TarekNasser[m]>
on Ubuntu
<GopiMTatiraju[m]>
zoq: to compile tests I build I first build `clBlas` and then `clBLAST`
<zoq[m]>
zoq[m]: Which installs xeus cling, jupyter notebook and the c++ kernel in a conda env.
<TarekNasser[m]>
Ok thank you I got it to work
<TarekNasser[m]>
I plan to do a notebook to demonstrate how well would several machine learning algorithms do on a simple dataset. Am I going in the right direction or should I do something else?
<zoq[m]>
> <@tareknaser:matrix.org> Ok thank you I got it to work
<zoq[m]>
> I plan to do a notebook to demonstrate how well would several machine learning algorithms do on a simple dataset. Am I going in the right direction or should I do something else?
<zoq[m]>
>
<zoq[m]>
Sounds good, keep in mind, that not every mlpack method can do classification or regression.
<TarekNasser[m]>
I will read the documentation for the functions I want to use and ask the community if I get stuck
<shrit[m]>
zoqrcurtin : This project is no longer valid right? Improvisation and Implementation of ANN Modules
<shrit[m]>
Frankly after the refactoring we are doing, I do think we can remove this one
<zoq[m]>
shrit[m]: Depends, I think we still want to add new features and continue to refactor some layers, but more focused.
<zoq[m]>
zoq[m]: But I guess, we should rephrase it.