ASPP/2024-heraklion-comp-arch
9
0
Fork 17
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity

re-order statements

Browse source
This commit is contained in:
Tiziano Zito 2024-08-21 11:18:12 +02:00
parent d40011acac
commit a7c4f01a6c
1 changed files with 3 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
README.md
View file

@ -59,6 +59,7 @@ Setup:
## Back to the Python benchmark (third try) ## Back to the Python benchmark (third try)
- can we explain what is happening now? Yes, more or less ;-) - can we explain what is happening now? Yes, more or less ;-)
- quick fix for the [puzzle](puzzle.ipynb): try and add `order='F'` in the "bad" snippet and see that it "fixes" the bug ➔ why?
- the default memeory layout is also called row-major `== C_CONTIGUOUS` - the default memeory layout is also called row-major `== C_CONTIGUOUS`
- rule of thumb for multi-dimensional numpy arrays: - rule of thumb for multi-dimensional numpy arrays:
- the right-most index should be the inner-most loop in a series of nested loops over the dimensions of a multi-dimensional array - the right-most index should be the inner-most loop in a series of nested loops over the dimensions of a multi-dimensional array
@ -70,10 +71,10 @@ Setup:
``` ```
- … unless of course you plan to mostly loop *across* time series :) - … unless of course you plan to mostly loop *across* time series :)
- watch out when migrating code from MATLAB® or to `pandas.DataFrame` ➔ they store data in memory using the opposite convention, the column-major order!!! - watch out when migrating code from MATLAB® or to `pandas.DataFrame` ➔ they store data in memory using the opposite convention, the column-major order!!!
- quick fix for the [puzzle](puzzle.ipynb): try and add `order='F'` in the "bad" snippet and see that is "fixes" the bug ➔ why?
Notes on the [Python benchmark](benchmark_python/): Notes on the [Python benchmark](benchmark_python/):
- while running it attached to the P-core (`cpu0`), the P-core was running under a constant load of 100% (almost completely user-time) and at a fixed frequency of 3.8 GHz, where the theoretical max would be 5.2 GHz
- while running it attached to one core on my laptop, the core was running under a constant load of 100% (almost completely user-time) and at a fixed frequency of 3.8 GHz, where the theoretical max would be 5.2 GHz
➔ the CPU does not "starve" because it scales its speed down to match the memory throughput? Or I am misinterpreting this? This problem which at first sight should be perfectly memory-bound, becomes CPU-bound, or actually, exactly balanced? From the [Intel documentation](https://lenovopress.lenovo.com/lp1836-tuning-uefi-settings-4th-gen-intel-xeon-scalable-processor): ➔ the CPU does not "starve" because it scales its speed down to match the memory throughput? Or I am misinterpreting this? This problem which at first sight should be perfectly memory-bound, becomes CPU-bound, or actually, exactly balanced? From the [Intel documentation](https://lenovopress.lenovo.com/lp1836-tuning-uefi-settings-4th-gen-intel-xeon-scalable-processor):
> **Energy Efficient Turbo** > **Energy Efficient Turbo**