Runtime performance of is_current_event_active
Die NEC hat wohl ziemlich Probleme mit skalarem Code.
Durch zahlreiche 'Optimierungen' der NEC-Leute zur Reduktion der Zahl der mtime-Aufrufe bin ich darauf aufmerksam geworden, dass insbesondere "ISCURRENTEVENTACTIVE" einen nennenswerten Beitrag zur Laufzeit leistet. Ich habe diese Modifikationen bislang nicht übernommen, da ich sie nicht besonders schön finde und der Meinung bin, dass das mtime-Performanceproblem an der Quelle gelöst werden muss.
Zur Illustration die top ten des ftrace-Outputs für einen R3B6L90-Tests auf 16 Knoten (91 Tage Vorhersagezeit, um den Beitrag der setup-Phase klein zu halten):
1295804416 659863.147( 30.7) 0.509 314.7 0.0 25.73 121.3
18098.827 485628.986 0.000 55.71 MO_MPI::P_WAIT
167815168 262927.755( 12.2) 1.567 52140.1 18550.1 99.37 223.1
246338.038 14800.372 8616.174 49.96 MO_SOLVE_NONHYDRO::SOLVE_NH
201361408 85074.240( 4.0) 0.422 40984.9 10215.9 99.64 216.1
81478.445 2953.623 817.691 55.44
MO_VELOCITY_ADVECTION::VELOCITY_TENDENCIES
436101120 74866.001( 3.5) 0.172 733.9 0.0 2.20 23.4
2378.271 23448.104 0.000 99.92 MTIME_EVENTS::ISCURRENTEVENTACTIVE
835158016 74800.011( 3.5) 0.090 13745.9 8434.8 95.86 69.4
72594.149 832.849 0.000 95.50 MO_SRTM::SRTM_REFTRA
3728384 66999.976( 3.1) 17.970 28814.8 12241.0 98.58 179.9
66794.855 164.222 328.029 62.54 MO_LRTM_RTRNMR::LRTM_RTRNMR
8216885070 43455.299( 2.0) 0.005 1177.5 0.3 83.68 220.1
3677.187 25351.377 0.000 62.80 MO_MPI::P_ISEND_REAL
40899584 38930.439( 1.8) 0.952 277.5 0.0 1.64 10.0
977.587 28279.697 0.000 98.11 MO_MPI::P_MINMAX_COMMON
1095680 35393.561( 1.6) 32.303 281.8 0.0 1.19 8.0
862.801 25440.167 0.000 100.00 MO_MPI::P_BCAST_REAL_1D
33546240 32998.299( 1.5) 0.984 57450.0 35078.1 99.37 205.3
30951.281 1557.122 6.832 90.73 GSCP_CLOUDICE::CLOUDICE
und ein grep auf mtime liefert
436101120 74866.001( 3.5) 0.172 733.9 0.0 2.20 23.4
2378.271 23448.104 0.000 99.92 MTIME_EVENTS::ISCURRENTEVENTACTIVE
205593600 6429.357( 0.3) 0.031 531.1 0.0 1.76 20.9
159.502 3434.841 0.000 94.91
MTIME_DATETIME::NEWDATETIMEFROMCONSTRUCTANDCOPY
100664320 4128.984( 0.2) 0.041 542.2 0.0 1.68 20.8
95.022 2024.889 0.000 97.66 MTIME_TIMEDELTA::GETPTSTRINGFROMMS
272707614 4076.122( 0.2) 0.015 394.2 0.0 1.64 27.3
47.991 2513.236 0.000 95.78 MTIME_TIMEDELTA::NEWTIMEDELTAFROMSTRING
167734302 1455.706( 0.1) 0.009 422.9 0.0 1.31 12.0
21.541 704.564 0.000 84.10 MTIME_TIMEDELTA::GETTIMEDELTAFROMDATETIME
138494362 1333.494( 0.1) 0.010 377.6 0.0 0.00 0.0
0.000 743.036 0.000 0.00 MTIME_TIMEDELTA::ADDTIMEDELTATODATETIME
134190080 545.028( 0.0) 0.004 317.0 0.0 0.00 0.0
0.000 340.588 0.000 0.00
MTIME_TIMEDELTA::GETTOTALMILLISECONDSTIMEDELTA
33546240 441.195( 0.0) 0.013 1238.5 0.0 0.00 0.0
0.145 170.136 0.000 0.00 MO_UTIL_MTIME::T_MTIME_UTILS_DDHHMMSS
272694302 311.724( 0.0) 0.001 461.9 0.0 0.00 0.0
0.000 173.929 0.000 0.00 MTIME_TIMEDELTA::DEALLOCATETIMEDELTA
33547264 206.539( 0.0) 0.006 362.5 0.0 0.90 10.0
1.158 149.287 0.000 0.00 MO_PHY_EVENTS::MTIME_CTRL_PHYSICS
Wir haben pro Zeitschritt 13 Aufrufe von "mussichimaktuellenzeitschrittetwasarbeitenodernicht", und diese benötigen mehr Rechenzeit als Turbulenz, Mikrophysik und Sättigungsadjustierung zusammen. Da kann doch etwas nicht mit rechten Dingen zugehen! Kannst Du Dir das bitte mal anschauen?
Davon abgesehen sieht man, dass unser MPI-Netzwerk ziemlich lahm ist. Das haben wir bei der Festlegung der Benchmarkkriterien billigend in Kauf genommen, da die Hauptlast unserer Routineanwendungen aus Ensemblevorhersagen bestehen wird. Aber der Rückschritt gegenüber der Cray ist deutlich...