Improve ionic model performance in the MLIR build
What does this MR do?
When using the vectorised version (MLIR CPU target), the MLIR pipeline converts the math functions (pow, exp, log, tan, ...) to calls to optimised implementations of these functions. When available it is often best to link the intel SVML library that implements these functions very efficiently, especially for vectorised code. However a bug in LLVM causes the pow function to not be properly converted. This means that for example when using the AVX-512 instruction set (vectors of size 8 with double precision), instead of calling the SVML function on the vector of size 8, the default implementation of pow (libm) is called 8 times: once for each element of the vector.
This MR proposes a workaround to convert the math functions to SVML calls, thus making some models up to 3 times faster.
This bug will perhaps be fixed in some future LLVM update but it would probably take a few years before the fix is available in a stable release so for now we can use this fix.
Speedup for each model
Execution time for MLIR version and MLIR version with the proposed fix on a CPU with AVX-512 (8 doubles per vector)
name | MLIR | MLIR with fix | ratio | |
---|---|---|---|---|
0 | AlievPanfilov | 0.330962 | 0.329869 | 1.00331 |
1 | AslanidiSleiman | 365.264 | 364.992 | 1.00074 |
2 | Augustin | 185.367 | 55.7734 | 3.32358 |
3 | Bondarenko | 179.778 | 168.179 | 1.06897 |
4 | Campos | 33.7895 | 34.1858 | 0.988407 |
5 | Courtemanche | 16.9475 | 17.153 | 0.98802 |
6 | Defib_AshiharaTrayanova | 0.384894 | 0.385188 | 0.999237 |
7 | DiFrancescoNoble | 13.7294 | 13.1666 | 1.04275 |
8 | DrouhardRoberge | 9.70121 | 9.71073 | 0.999019 |
9 | Electroporation_DeBruinKrassowska98 | 4.51777 | 4.52108 | 0.999267 |
10 | Electroporation_DeBruinKrassowska99 | 0.586898 | 0.593763 | 0.988438 |
11 | Fibroblast_MacCannell | 13.9526 | 13.9624 | 0.999302 |
12 | Fibroblast_Morgan | 17.294 | 17.3288 | 0.997996 |
13 | Fox | 12.8712 | 12.9969 | 0.990323 |
14 | Grandi | 149.235 | 51.2213 | 2.91353 |
15 | GrandiPanditVoigt | 198.771 | 89.0084 | 2.23317 |
16 | HodgkinHuxley | 2.63557 | 2.57373 | 1.02403 |
17 | IACh_Cheng | 0.511711 | 0.531067 | 0.963553 |
18 | IChR2_WilliamsXu | 5.33012 | 5.31389 | 1.00305 |
19 | INa_Bondarenko | 14.8775 | 14.5082 | 1.02545 |
20 | Inada | 13.1373 | 13.4233 | 0.978696 |
21 | IribeKohl | 47.7615 | 19.6132 | 2.43516 |
22 | ISAC_Hu | 0.179525 | 0.180947 | 0.992141 |
23 | Kurata | 38.2749 | 25.8995 | 1.47782 |
24 | Loewe | 53.9512 | 27.6428 | 1.95173 |
25 | LuoRudy91 | 7.5435 | 7.53416 | 1.00124 |
26 | LuoRudy94 | 25.6747 | 25.6712 | 1.00014 |
27 | MacCannell | 16.3805 | 16.1685 | 1.01311 |
28 | MahajanShiferaw | 35.9249 | 36.1177 | 0.994661 |
29 | Maleckar | 11.7024 | 5.27426 | 2.21878 |
30 | MitchellSchaeffer | 0.568674 | 0.570426 | 0.996929 |
31 | Nygren | 29.9012 | 27.8392 | 1.07407 |
32 | OHara | 27.3586 | 27.3156 | 1.00157 |
33 | Pathmanathan | 0.254205 | 0.254524 | 0.998747 |
34 | Plonsey | 0.105589 | 0.102369 | 1.03145 |
35 | Ramirez | 27.1048 | 20.239 | 1.33924 |
36 | Shannon | 517.173 | 453.279 | 1.14096 |
37 | Skibsbye | 42.2446 | 34.3327 | 1.23045 |
38 | Steward | 27.1058 | 25.408 | 1.06682 |
39 | Stress_Lumens | 1.32457 | 1.28597 | 1.03001 |
40 | tenTusscherPanfilov | 18.4888 | 18.5505 | 0.996673 |
41 | Tomek | 36.3113 | 37.4294 | 0.970128 |
42 | WangSobie | 31.8119 | 18.5426 | 1.71561 |
Related issues
Author's checklist
-
Follow the Contribution Guidelines. Sign the CLA and add yourself to the list of contribtutors for your first contribution. -
Describe your change in the CHANGELOG.md
file in the top-level folder of the openCARP repository. -
Apply the appropriate labels. -
Does this commit add new dependencies? If no, just tick the box. If yes, please evaluate carefully if the additional dependency is a more sustainable option than including the functionality in own code. If the former, describe the dependency clearly, add them to the Software Management Plan and the installation instructions (*.md files, CMake files, Docker files etc.).
Reviewer's checklist
All reviewers can help ensure accuracy, clarity, completeness, and adherence to the Contribution Guidelines.
Reviewer
-
Review by a code reviewer or other selected colleague to confirm accuracy, clarity, and completeness. This can be skipped for minor fixes without substantive content changes.
Maintainer
-
Review by assigned maintainer, who can always request/require the above reviews.