verne.freenode.net changed the topic of #mlpack to: http://www.mlpack.org/ -- We don't respond instantly... but we will respond. Give it a few minutes. Or hours. -- Channel logs: http://www.mlpack.org/irc/
govg has quit [Ping timeout: 255 seconds]
benchmark has joined #mlpack
benchmark has quit [Client Quit]
govg has joined #mlpack
anvesh22 has joined #mlpack
anvesh22 has quit [Quit: Page closed]
mikeling has joined #mlpack
mikeling has quit [Quit: Connection closed for inactivity]
mikeling has joined #mlpack
govg has quit [Quit: leaving]
govg has joined #mlpack
vinayakvivek has joined #mlpack
travis-ci has joined #mlpack
< travis-ci>
mlpack/mlpack#1758 (master - 69b6499 : Marcus Edel): The build has errored.
< zoq>
okay, let's open a PR and see if the change increases the build time
mikeling has quit [Quit: Connection closed for inactivity]
< zoq>
hm, looks like it has an effect on the build time.
govg has joined #mlpack
< zoq>
Running with -j3 instead of -j2 is slightly faster about 1.5 minutes compared to the last run, so probably worth to make the change. The improvement could also be test or hardware related.
aditya__ has quit [Quit: Ex-Chat]
aditya__ has joined #mlpack
aditya__ has quit [Remote host closed the connection]
shivanshuiitg has joined #mlpack
< rcurtin>
yeah, 2150.2s for mlpack/core.hpp vs. 2447s for mlpack/prereqs.hpp
< rcurtin>
I'm not sure I have an explanation for why that would be
< rcurtin>
unless the j2/j3 difference accounted for that
< rcurtin>
but I also see that an earlier commit to master only took 2187s for the build:
< rcurtin>
and I think that was after the ANN merge
< rcurtin>
so I wonder if what we are seeing is an artifact of unusual load on the travis servers or something
< zoq>
195332555 is the one without the core.hpp replacement
< rcurtin>
ah, sorry, now I see
< rcurtin>
strange... I have no idea for an explanation on this one
< zoq>
195586422 is with core.hpp and -j2 and 195606356 is also with core.hpp and -j3 and 195545740 is with -j2 and prereqs.hpp
< zoq>
not sure, the problem is, every PR will fail because we run out of time
< zoq>
so I think 'revert' the prereqs.hpp commit is the best option for now
< rcurtin>
yeah, perhaps that is the best idea for now
< rcurtin>
some of the refactoring I am doing should allow us to avoid including boost::program_options headers, so that can help some too
< rcurtin>
when I was investigating this more in depth, I found the vast majority of the compile time was parsing, so if we can reduce the number of headers we have to include, this could help hugely
< rcurtin>
I think precompiled headers are another possible solution too
< zoq>
I agree
< zoq>
Maybe it will work with prereqs.hpp and -j3 I'll test that first.
< shivanshuiitg>
Hi everyone !!
< shivanshuiitg>
I am shivanshu, I want to contribute to mlpack
< shivanshuiitg>
How should I go through ?? Any help would be appreciated