10:49 < mentekid> rcurtin: I implemented the changes we talked about a few days ago regarding PR #623 (LSH using less memory). I pushed the new code

10:50 < mentekid> I ran tests for 3 different cutoffs: 0.01, 0.05 and 0.1, but there doesn't seem to be any significant improvement, at least not for default parameters (I tested miniboone, pokerhand, and corel. I am not sure if phy is this one: https://snap.stanford.edu/data/cit-HepTh.html)

10:52 < mentekid> at best the new code performs equally to the upstream code, and it some times takes slightly more. I will experiment with parameter values to see if better tuned parameters improves this

11:21 < mentekid> rcurtin: I ran some tuned versions too. Parameters: a) 10 tables, 10 projections and b) 10 tables, 5 projections

11:22 < mentekid> in this case, hybrid is actually much faster than the old one. Specificaly (I run 10000 queries against the entire reference dataset):

11:23 < mentekid> miniboone: 3.5s hybrid and 7s old code

11:23 < mentekid> pokerhand: 20s hybrid and 50s old code

11:23 < mentekid> corel: 2.3s hybrid and 3.9s old code

11:24 < mentekid> (this was parameters a)

11:24 < mentekid> and parameters b:

11:24 < mentekid> miniboone: 3.6s hybrid and 7s old code

11:24 < mentekid> pokerhand: 37.9s hybrid and 57.5s old code

11:25 < mentekid> corel: 50.6s hybrid and 38.58 old code

11:25 < mentekid> so hybrid still slower for corel for some parameters

13:21 < rcurtin> mentekid: those numbers look good; did you play woth a higher cutoff?

13:21 < rcurtin> I wonder if maybe 0.2 or 0.25 might give better performance

13:23 < rcurtin> I think the phy dataset is from the kddcup in some year but I don't think the one you linked to is the right one

13:23 < rcurtin> http://www.ratml.org/datasets/phy.csv

13:23 < rcurtin> should be 78x150000

13:25 < mentekid> I didn't try higher cutoffs, only these three... I think as I increased the cutoff it became slower (for the cases where it was slow already)

13:26 < mentekid> I got phy now, so I'll try that and a few different cutoffs too

13:27 < rcurtin> okay

13:28 < rcurtin> I am on the train now

13:28 < rcurtin> but when I am at my desk I'll play with it a little too

13:29 < mentekid> cool, no hurry, I'll be online for the next few hours

13:32 < tham> Try out the leNet example of cuDNN today, 16 batch size, 5000 iterations, accuracy reach 97.23% around 20 seconds(my laptop is Y410P)

13:34 < tham> Although the codes of GPGPU are harder to maintain, it could boost up speed a lot

13:36 < tham> Studying how to leverage the power of cuDNN, do anyone has interesting to develop a gpu implementation for cnn?

13:53 < rcurtin> do you think maybe using armadillo+nvblas could get the same kind of speedup?

13:53 < rcurtin> or close to it

14:03 < tham> rcurtin : Don't know, but I guess it wouldn't have the same speed, because cuDNN do a lot of jobs to tune the performance of cnn

14:04 < tham> It need to change a lot of codes if I want to make vc2013 can compile the codes of mlpack

14:07 < rcurtin> yeah, the only thought is maybe if the CNN expressions can be written as big linear algebra, nvblas might give good speedup without having to change any code

14:07 < rcurtin> but I haven't played with it

14:12 < tham> maybe cuda8.0 would support vc2015

18:29 < travis-ci> mlpack/mlpack#808 (master - d502539 : Ryan Curtin): The build was broken.

18:29 < travis-ci> Change view : https://github.com/mlpack/mlpack/compare/93eb34cc4daf...d502539e6180

18:29 < travis-ci> Build details : https://travis-ci.org/mlpack/mlpack/builds/128920742