+ phys machine is using SunGrid job scheduler (/qstat/), but it is not well documented for MPCDF machines. Markus will send me a template for running jobs on this machine
- [X] Only later realized that the influence of the pipelining is not so big, so actually measuring the time on "GPU only" and "CPU only" might be better approach. Implementing another autotuning approach might be interesting. Could even evaluate both and present results
- [ ] Markus thinks that enabling autonuning with GPUWORKLOAD=-1 or without stating GPUWORKLOAD might be the best idea
+ Pilar agrees, and this should be activated by default (GPUWORKLOAD='')
+ Final code should look like this before merging (and keeping only one Autotuning algorithm)
- [ ] Discuss on following meeting the possibility to recalibrate the workload during the execution. For now there seems to be no need for such a thing, but it can be added quite easily and cheaply in terms of the performance overhead and code development
+ Pilar believes that this can be useful, check with Markus
+ Propose an environment variable for this, as well as for the number of comparisons to get stable performance (STABILIZER)
- [X] Check if there is another approach for Autotuning, described in Numerical Recipes book
+ Yes with bisection, performance results will show if this is better than other approaches
- [] Report error regarding documentation of the computation of GPUWORKLOAD
- [X] Report error regarding documentation of the computation of GPUWORKLOAD
+ Done, waiting for the reply and someone to correct this
+ If Pilar doesnt reply by Wednesday 21st, commit in main project and add tag 1.0.2
- [ ] Discuss with Markus possibility of hyperthreading and whether they generally use it
+ Fixed and pushed
- [X] Discuss with Markus possibility of hyperthreading and whether they generally use it
+ Could be a thing to test, although Markus doesnt expect a significant improvements from it
+ On draco, hyperthreading (if I configured it correctly), seems to bring negative influence on the performance
- [X] Create another type of the visulization (Timeline vs Time for projection), possibly add events for the optimal workload (or colors for workload)
** 2017-06-20
*** TODO Other code things to add for BioEM [1/5]
*** TODO Other code things to add for BioEM [2/5]
:LOGBOOK:
- State "TODO" from "TODO" [2017-06-22 Thu 11:59]
- State "TODO" from "TODO" [2017-06-20 Tue 16:23]
- State "TODO" from "TODO" [2017-06-20 Tue 16:13]
- State "TODO" from [2017-06-20 Tue 10:19]
:END:
- [X] Problems with installing BioEM on hydra machine with Intel recipe that used to work. Issues seem unrelated to autotuning changes, but something regarding bio:configure and reading the parameters. Actually, before Luka was not using the right Intel compilers, with the correct one everything compiles fine
- [] Need to find a proper way of handling errors in the code
- [X] Need to find a proper way of handling errors in the code
- [ ] Need to do a nice cleanup before merging into the main project
- [ ] Add nice printf for writing the Optimal Workload
- [ ] Add more profoud CUDA profiling, possibly using specialized CUDA tools for that. We will certainly need it in future when doing more developments in BioEM
- [ ] Ensure that pinning is done correctly (in Intel case there shouldnt be any problem)
+ If this is true, additional code in BioEM is needed, to make sure it can work on similar machines
+ We checked it, and indeed the problem on dvl machines was caused by the EXCLUSIVE_PROCESS mode of GPUs. In DEFAULT mode everything works smoothly, even with the GPU testing code
+ I need to investigate why EXCLUSIVE_PROCESS mode is causing troubles for BioEM
** 2017-06-23
*** Analyzing workload choice for Autotuning 3 on dvl
#+begin_src R :results output graphics :file :file (org-babel-temp-file "figure" ".png") :exports both :width 600 :height 400 :session org-R