-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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)