-
Notifications
You must be signed in to change notification settings - Fork 33
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
Analyse, tune and debug 'launch' tests (automatic comparison scripts; use fewer events; etc...) #711
Comments
Looking at time performance
Focusing on ggttgg and ggttggg, even if they are those where Fortran crashes For ggttgg
For ggttggg
So overall a speedup 2x to 3x for CPP and around 6x to 15x for CUDA with respect to FORTRAN, which is not bad. Note that here CUDA speedups is with respect to all 4 cores on the CPU, not a single core. |
Looking at events in lhe files - note that two runs crashed in #710
|
Concerning results
This is interesting because results are identical for CUDA, CPP and FORTRAN for ggtt, ggttg. But for ggttgg and ggttggg there is a tiny difference between CUDA and CPP (why?). And the FORTRAN fails as per #710 |
…raph5#710 with Olivier's select_color change The price to pay is the tmad failures in ggttgg madgraph5#655 Add to the git repo the two ggttggg FORTRAN logs that were previously failing The duration of these tests needs some tuning, the ggttggg take too long madgraph5#711 ls -ltr tlau/logs_ggtt*/*txt -rw-r--r--. 1 avalassi zg 3590 Jun 17 03:41 tlau/logs_ggtt_CUDA/output.txt -rw-r--r--. 1 avalassi zg 3588 Jun 17 03:41 tlau/logs_ggtt_FORTRAN/output.txt -rw-r--r--. 1 avalassi zg 3580 Jun 17 03:42 tlau/logs_ggtt_CPP/output.txt -rw-r--r--. 1 avalassi zg 3462 Jun 17 03:42 tlau/logs_ggttg_CUDA/output.txt -rw-r--r--. 1 avalassi zg 3571 Jun 17 03:43 tlau/logs_ggttg_FORTRAN/output.txt -rw-r--r--. 1 avalassi zg 3515 Jun 17 03:44 tlau/logs_ggttg_CPP/output.txt -rw-r--r--. 1 avalassi zg 4106 Jun 17 03:46 tlau/logs_ggttgg_CUDA/output.txt -rw-r--r--. 1 avalassi zg 4425 Jun 17 04:00 tlau/logs_ggttgg_FORTRAN/output.txt -rw-r--r--. 1 avalassi zg 4349 Jun 17 04:05 tlau/logs_ggttgg_CPP/output.txt -rw-r--r--. 1 avalassi zg 6766 Jun 17 04:50 tlau/logs_ggttggg_CUDA/output.txt -rw-r--r--. 1 avalassi zg 7069 Jun 17 20:45 tlau/logs_ggttggg_FORTRAN/output.txt -rw-r--r--. 1 avalassi zg 6967 Jun 18 01:29 tlau/logs_ggttggg_CPP/output.txt
…adgraph5#711 Revert "[launch] in lauX.sh go back to 10000 unweighted events..." This reverts commit 7021bc6. I realised that also unweighted event generation does take a very long time in these tests
…r survey and refine (8192 events, 1 iteration) Note: cmd.opts['accuracy'] comes from cmd._survey_options where cmd is in madevent_interface.py
In the latest commits I have rerun the testst after fixing #710 (using @oliviermattelaer select_color patch ... which however reintroduces #655 that will need to be fixed). The latest timings are as follows
This includes everything including all build overheads. It is here with the default survey/refine/generate settings. The most interesting speedups, as usual, are for ggttggg - which however I will try to make shorter as these tests are really very long. Anyway in practice
The cross sections are very similar but with a few small differences
I think that this is due to the fact that the numbers of events are not multiples of 2, so effectively CUDA/CPP process a different number of events than scalar FORTRAN. I will try to tune this too. I also need to check the LHE files including color and helicity... |
This remains one of the highest priorities in my opinion. One part of this is also being able to configure the use of fewer events in launch, to make faster tests for development (fewer events are clearly a nogo in production, but are essential for developer tests). |
As discussed in #855 and #852, I remain convinced that making it possible to tune the machinery to run generate_events with reduced precision and fewer events is a priority, to enable QUICK and SYSTEMATIC tests of all processes, all fptype combinations, etc. While a reduced precision is not what the users will use, it is what developers need for unit tests and integration tests. To be discussed... |
Hi @oliviermattelaer @roiser @hageboeck @zeniheisser @Jooorgen I have finally done a few systematic 'launch' tests (using the scripts lauX.sh of #683). This is really ./bin/generate_events.
No time to analyse the details now, but the files are in WIP MR #709.
There are some icolamp crashes, see #710
And then there is the analysis of physcs results and of timing performance to do, which I will do here
First impressions
The text was updated successfully, but these errors were encountered: