-
Notifications
You must be signed in to change notification settings - Fork 6
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
Benchmarking (and testing) framework #53
Milestone
Comments
I had a look into some testing frameworks and finally decided to use Boost.Test. There were no big differences between the test frameworks, but since we are using boost anyways there is no reason to ship more dependencies with our code. |
very reasonable thinking |
Just to give a reference to ongoing work of this issue. |
This was referenced Jul 9, 2015
slizzered
modified the milestones:
1.5 - extended features,
1.4 Graybat, usability and Windows compatibility,
2.0 - the next generation
Sep 8, 2015
erikzenker
added a commit
to erikzenker/haseongpu
that referenced
this issue
Oct 5, 2015
9dfdb96 fix missing OpenMP link flag b9f099c fix foldrAll ICC bug 83ddac5 disable the OpenMP 4 back-end by default 8644064 fix Vec for Intel 819e5d9 fix boost 1.56 missing const bug f9cd663 really fix Intel cpuid 330d983 remove incorrect docu 9f1b692 fix Intel compiler cpuid 1aa4c86 fix missing OMP_NUM_THREADS reset in getMaxOmpThreads 328e866 fix CUDA compilation 33c7888 remove ICC from the readme (untested / not compiling) 40a8465 always interpret all source files as .cu files for nvcc 25f4670 allow vectorize to be called without the element type 882c0a9 enhance documentation 05454a6 fix ambiguous template specialization for GetWorkDiv 5b70326 remove call to std::ref in BlockSharedAllocCudaBuiltIn e15c40a fix fix AtomicOmpCritSec afffe2f fix wrong atomic implementation for AccCpuOmp2Blocks 2a60bbb fix BufCudaRt destruction 062378d add ALPAKA_ADD_EXECUTABLE to alpakaConfig.cmake b9a4125 use DimInt more consistently 919dc26 move ElemType from mem::view to elem 2807fc8 add initial ALPAKA_ADD_EXECUTABLE f019e70 fix BufPlainPtrWrapper pitch 1ca1923 fix missing OpenMP linker flag 9ee231d fix getFreeGlobalMemSizeBytes 7e853c6 Merge pull request ComputationalRadiationPhysics#54 from psychocoderHPC/fix-cudaSet 6796eff Merge pull request ComputationalRadiationPhysics#55 from psychocoderHPC/fix-callingHostFunctionFromDevice 9f3d8e6 fix warning calling host function from device 000a250 fix wrong usage of `getPitchBytes<>()` 8be955d Merge pull request ComputationalRadiationPhysics#53 from psychocoderHPC/topic-suppressHostDeviceWarning b7c877d Merge pull request ComputationalRadiationPhysics#52 from psychocoderHPC/tpoic-updateGitIgnore 0b94251 suppress host device warning 33a59be update `.gitignore` 237898f refactoring d0ad945 implement getFreeGlobalMemSizeBytes f85e233 allow accelerators to inherit from rand implementation d96e8b5 fix CUDA set implemenentation git-subtree-dir: include/alpaka git-subtree-split: 9dfdb96b0cb2fc32a1f2e447de755905f7538bf4
We should get rid of a matlab based testing proceedure. Better would be some free available scripting language! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This could be split into 2 issues, but for development of ideas 1 issue might be sufficient now... both features will be closely related in code. (after doing a test, just record the time...)
It would be great to have some code that will
a) test some defined input/output of the whole application (we had this before, but it was never really easy to see immediately if the results are the same or minimally different). Might be difficult since results are not 100% deterministic
b) maybe also some unit-tests for smaller functions (mostly necessary if later some internal stuff will be improved/changed, like #51)
c) create some fixed benchmarking scenarios (for whole simulation and also for single functions), so we have a fixed and reliable time value that we can use to measure performance changes that are introduced through new features. It would be good to have quite a list of parameter combinations.
d) We should have a
PERFORMANCE.md
file that holds those values for different releases, so we can track the speed development over a longer timeframeThings to compare in the future:
The text was updated successfully, but these errors were encountered: