mlpack IRC logs, 2018-07-26

Logs for the day 2018-07-26 (starts at 0:00 UTC) are shown below.

July 2018
Sun
Mon
Tue
Wed
Thu
Fri
Sat
1
2
3
4
5
6
7
8
9
10
11
12
13
21
22
23
24
25
26
27
--- Log opened Thu Jul 26 00:00:02 2018
00:11 < rcurtin> zoq: no clue, I sent a follow-up email just to be sure (I don't want to get in trouble or anything for continuing to use their resources)
00:11 < rcurtin> but I have no idea when they will get back to me
00:11 < rcurtin> I don't think Julia is a DB language, but what the team seems to be building is a database written in Julia that can be queried with a language they are designing
00:12 < rcurtin> it will still be some weeks before I understand it fully...
00:21 < zoq> rcurtin: I guess, at some point they get back, with some good news :)
00:34 < rcurtin> yeah, hopefully---we'll see :)
01:49 < Samir> zoq: Hello zoq :), thanks for your reply, sorry I couldn't reach you yesterday. I intend to implement Proximal Policy Optimization Algorithms and Persistent Advantage Learning DQN algorimths. I plan first to study mlpack reinforcement learning methods and to get familiar with the source code. then reading Playing Atari with Deep Reinforcement Learning paper. Do you recommend anything else to do?
03:10 -!- cjlcarvalho [~caio@189-105-81-247.user.veloxzone.com.br] has quit [Quit: Konversation terminated!]
03:13 -!- cjlcarvalho [~caio@189-105-81-247.user.veloxzone.com.br] has joined #mlpack
03:35 < Atharva> zoq: rcurtin: What is the reason we don't return matrices and instead take them as modifiable arguments? Is it to have better performance?
08:37 < ShikharJ> zoq: Still working on that. I will push by Friday.
08:39 < ShikharJ> zoq: Julia is primarily used for scientific computing, computational algebra and high precision arithmetic sort of stuff.
12:52 < zoq> ShikharJ: Great, I guess we could say about the same about haskell.
12:52 < zoq> Atharva: Are you talking about arma::mat& Matrix() { return matrix; } instead of arma::mat Matrix() { return matrix; }? Depending on the case the first one could avoid a copy, I guess the compiler might be able to produce the same results for both cases, at least in some situations. But the first case allows us to modifiy the parameter, .Matrix()[0] = 1
12:52 < zoq> Samir: Sounds like a good plan to me; make sure to checkout and run the existing rl tests; e.g. https://github.com/mlpack/mlpack/blob/master/src/mlpack/tests/q_learning_test.cpp you can run the test suite with bin/mlpack_test -t QLearningTest or a single test with bin/mlpack_test -t QLearningTest/CartPoleWithDQN; Also http://www.mlpack.org/docs/mlpack-git/doxygen/anntutorial.html might be helpful to get a
12:52 < zoq> first overview. If you have any questions please don't hesitate to ask.
13:58 -!- ImQ009 [~ImQ009@unaffiliated/imq009] has joined #mlpack
14:16 < Atharva> zoq: Yeah, also we have functions, for example void Forward(arma::mat input, arma::mat& results) instead of arma::mat Forward(arma::mat input). I was thinking about such cases.
14:31 < zoq> Atharva: I see, that would allow us to cascade/stack the Forward calls, but this would also include some uncessary copies, especially for layer that reuse the input/output value.
14:38 < Atharva> zoq: Oh, thanks for explaining. I don't have a problem with it, was just curious as to why this approach was chosen.
15:00 < Atharva> zoq: I had another doubt, using openBLAS led to no speed improvements, I am pretty sure I used it correctly. Why might that be happening?
16:52 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Read error: Connection reset by peer]
16:58 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
17:44 < rcurtin> Atharva: right, when we originally designed the library it was a way to avoid unnecessary copies
17:44 < rcurtin> I suspect that there are C++11 features now that could allow us to definitely avoid those copies, but I don't think that it would be fun to refactor the entire library...
17:45 < rcurtin> also, returning multiple matrices from a single call is possible with passing references as parameters, which is nice
17:45 < rcurtin> as well as using a matrix as both input and output... for instance, many times the function Optimize(arma::mat& iterate) available in optimizers will used the given iterate as a starting point
17:45 < rcurtin> and then also write the output into the 'iterate' parameter
17:51 < Atharva> rcurtin: Oh I see, there are lots of advantages of that approach.
17:55 < rcurtin> right, maybe some newer C++ features could address these issues also, but it would be a lot of refactoring work for little gain, in my opinion
17:56 < Atharva> rcurtin: Oh sorry, I meant this* approach
17:57 < Atharva> rcurtin: I agree that it's not worth it
17:59 < rcurtin> yeah, I know what you meant, I was just saying that it could be there are new features that could help :)
17:59 < rcurtin> so if we restarted mlpack from scratch today it might be better to decide differently or something (maybe, I am not sure)
18:00 < Atharva> rcurtin: Okay, some confusion :p
18:01 < Atharva> rcurtin: Can you tell me why openBLAS isn't giving any speedup at all?
18:03 < rcurtin> hm, is it possible that the algorithm you are running is not bottleneck by BLAS calls?
18:03 < rcurtin> if you're doing lots of big matrix multiplications, OpenBLAS can be helpful
18:03 < rcurtin> but, e.g., for something like k-nearest-neighbor search with trees, which doesn't use many BLAS/LAPACK calls, OpenBLAS doesn't help much
18:03 < rcurtin> you could watch 'htop' or something to ensure that all the processor cores are being used when you run your code
18:04 < rcurtin> (there are lots of other ways to watch CPU usage too, that one is just my personal favorite :))
18:04 < Atharva> rcurtin: I tried it while training ANN models, so I am sure there were lots of big matrix multiplications.
18:05 < Atharva> Yeah, I will try seeing with htop if all cores are being used
18:06 < rcurtin> the batch size is important for that, so make sure that you are using, e.g., a batch size of 64 or something like this
18:06 < rcurtin> if you use a batch size of 1, it becomes vector-matrix multiplications, which won't benefit as much
18:07 < Atharva> rcurtin: Oh! I will try it with batch size 64
18:07 < rcurtin> (plus, in general, you can see big speedups by increasing the batch size from 1 up to something more like 32, 64, etc.)
18:12 < zoq> just to be sure, did you check ldd armadillo.so, for a reference to OpenBLAS?
18:14 < Atharva> zoq: Sorry I didn't understand
18:15 < Atharva> Do you want to check if there is some reference for openBLAS in armadillo.so?
18:18 < zoq> right, just to make sure, the setup is correct
18:19 < Atharva> I just checked, armadillo.so is a binary file, where did you want to check exactly?
18:36 < rcurtin> Atharva: I think the idea was to run 'ldd libarmadillo.so', to ensure that it is linked against OpenBLAS (libopenblas.so)
18:37 < Atharva> rcurtin: Okay, sorry for that.
18:38 < Atharva> rcurtin: It is linked to openBLAS.
18:38 < Atharva> I will try using batch size 64
18:41 < zoq> okay, at least we know that armadillo links against OpenBLAS
20:01 -!- ImQ009 [~ImQ009@unaffiliated/imq009] has quit [Quit: Leaving]
--- Log closed Fri Jul 27 00:00:04 2018