speedup for .class.C for MLP#121
Conversation
863ed7c to
b5cf0ea
Compare
|
just added ec7918b (that switch hardly seemed to do do anything) |
|
looks like the conflict is purely whitespace changes on master, mergeing by hand. |
|
Can one of the admins verify this patch? |
|
Can one of the admins verify this patch? |
|
Could you use |
|
I think that's what I meant. My idea was:
|
9ccce9e to
ef160e4
Compare
|
just rebased (harder than expected). Let me double check I didn't mess up. |
|
@phsft-bot build! @pseyfert, I was wondering can we create a gtest testing that part? This is good for test coverage and documentation purposes... |
|
Starting build on |
|
Build failed on mac1012/native. Errors:
|
|
Build failed on ubuntu14/native. Errors:
|
|
Build failed on centos7/gcc49. Errors:
|
|
Build failed on slc6/gcc62. Errors:
|
|
Build failed on slc6/gcc49. Errors:
|
|
@pseyfert ping... |
|
back on this one. it appears my change is not super numerically stable. I ran the network from tutorials/tmva/TMVAClassification and the floating point comparison from https://stackoverflow.com/a/253874 with rapidcheck and this check and get a failure every ~ 500 tests (i.e. at that rate the numerical noise i generate by changing the network implementation exceeds more than 1000 times floating point precision (NB: the return value is actually a double …)) but this only if i disable the fast tanh evaluation (enabled by default). If i enable the fast tanh evaluation it appears response values change by more than that. will discuss at the next tmva meeting, with a bit more insight. for the build failure, sorry that was a pretty stupid merging mistake i should've seen (… if i had compiled it locally before pushing … instead of postponing that to running the numeric test). |
|
ping. |
ef160e4 to
f2f2ceb
Compare
|
found the issue. ran numeric test here https://github.com/pseyfert/tmva-codegen-rapidcheck |
|
Great! Could you add a gtest incorporating the tmva-codegen-rapidcheck? You can see how it's done here. |
|
@phsft-bot build! |
|
Starting build on |
|
Build failed on slc6/gcc49. Errors:
|
|
@phsft-bot build! |
|
Build failed on slc6/gcc62. Errors:
|
|
Build failed on slc6/gcc62. Errors:
|
|
@phsft-bot build |
|
LGTM. I think Lorenzo will be back from vacation on the 28th. |
|
Starting build on |
|
@phsft-bot build! |
|
Starting build on |
|
Build failed on ubuntu16/native. Errors:
|
|
Build failed on fedora28/native. Errors:
|
|
Build failed on windows10/vc15. |
|
Build failed on mac1013/native. Errors:
|
|
Build failed on slc6-i686/gcc49. Errors:
|
|
@phsft-bot build! |
|
Starting build on |
|
Build failed on ubuntu16/native. |
|
@phsft-bot build just on ubuntu16/native |
|
Starting build on |
|
Build failed on ubuntu16/native. |
|
@phsft-bot build just on ubuntu16/native |
|
Starting build on |
|
Build failed on ubuntu16/native. |
|
@phsft-bot build just on ubuntu16/native |
|
Starting build on |
|
Build failed on ubuntu16/native. |
|
@phsft-bot build just on ubuntu16/native |
|
Starting build on |
I ported the changes from pseyfert/tmva-mlp to the code generation. As a test I just ran the class.C network resulting from tutorials/tmva/TMVAClassification.C (with "MLP") and evaluated it similar to tutorials/tmva/TMVAClassificationApplication.C. According to callgrind the network evaluation is ~17% cpu cycles faster.
NB: i did not port all changes from pseyfert/tmva-mlp - I did not import the SSE/AVX intrinsics and avoided what seemed too difficult (optimising the putIndices and getIndices out)