mlpack / benchmarks

Machine Learning Benchmark Scripts
101 stars 49 forks source link

Use local installations for benchmarking #53

Closed rcurtin closed 7 years ago

rcurtin commented 7 years ago

This sets the environment variables correctly so that the libraries installed in libraries/ are used for benchmarking.

I removed a lot of the now-unnecessary variables from the Makefile.

I tested this (though incompletely) on my local system enough to convince myself it at least mostly works. It'll receive more testing as I get it up on Jenkins (but that will have to happen after merge).

zoq commented 7 years ago

I think once we decided what to do with the weka environment variable, this is ready to be merged.

rcurtin commented 7 years ago

@mlpack-jenkins test this

zoq commented 7 years ago

I think this is ready to be merged, once jenkins is reconfigured the test should pass.

rcurtin commented 7 years ago

@mlpack-jenkins test this

I have a problem running the tests locally on slake that I haven't figured out yet. It looks like Jenkins runs the tests fine, but there may be a couple to debug and it may take me a few more iterations to get it all right.

rcurtin commented 7 years ago

@mlpack-jenkins test this

zoq commented 7 years ago

I tested the code on slake and besides that the hlearn installations fails, it looks like everything else works as expected.

rcurtin commented 7 years ago

HLearn doesn't work with newer versions of ghc, so I think that we should uninclude it from the benchmarks for now until upstream is updated (not sure when that will be). I can't easily make it compile with ghc 8, and even compilation with ghc 7 has problems---it seems like other Haskell dependencies weren't compiled with -fPIC, which causes problems.

zoq commented 7 years ago

I agree, uninclude it for now, maybe @mikeizbicki could tell us more about if there are any plans to support ghc 8 as well.

rcurtin commented 7 years ago

Looks like things are very busy for him: https://github.com/mikeizbicki/HLearn/issues/84 but if it ever happens, definitely we can reinclude it then.

rcurtin commented 7 years ago

Bad news, I think we have to remove mlpy too---the reason is that mlpy depends on pygsl which in turn depends on libgsl 1, but Debian now provides only libgsl 2. I tried a local installation of libgsl 1.16, but ld loading order issues (I think) cause python3 to segfault after the computation now. mlpy is entirely unmaintained and dead now, so I think it is not a huge loss.

I won't remove it in this PR, but we can do that later, and I think we will have failing tests until that is done.

zoq commented 7 years ago

Oh, okay, if it's unmaintained, I guess the chances are almost null that we would see an updated version.

rcurtin commented 7 years ago

Ok, I think I am ready to merge this, if you think it is okay. Once that is done, I'll update Jenkins to build all of the libraries locally, and then I can start fixing whichever tests are broken. Then it will be much easier to merge in new libraries and the other PRs.

zoq commented 7 years ago

Sounds good for me.