re-order statements

README.md

@@ -59,6 +59,7 @@ Setup:
 
 ## Back to the Python benchmark (third try)
   - 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`
   - 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
@@ -70,10 +71,10 @@ Setup:
         ```
     - … 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!!!
-  - 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/):
-  - 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):
     > **Energy Efficient Turbo**