# MPHY0021 - Day 10 (16th December 2021)

:::info
## :tada: Welcome to the tenth day! Speed :clock1:

### Today
Today we will look at
- measuring how long code takes to run
- accelerating Python code
- where the time is spent
:::

### :stopwatch: Time keeper
- [name=Thomas Clarke] :raised_hand: 5' before the end.
- 10:00 - 10:50
- 11:05 - 11:55
- 12:05 - 12:55

### Review from last week

- improving readability of code
- refactoring

#### What was discussed during the week :newspaper:
- using `timeit`
- making code faster using `numpy`
- profiling Python code with `prun` and `lprun`
- notes about Cython

### Understanding quiz
Head to [Mentimeter](https://www.menti.com/119a5tzx9y) (or code `2955 8256`).

### Groups :handshake:

We will be using the breaking rooms functionality of Zoom.

:::danger
Remember to `rename` yourself by clicking on your zoom name (in the participants list) and change it to:
`SGX - Your name` being `X` the number of the group you have been assigned to.

If you disconnect and connect again, please rename yourself again.
:::

### Discussion
:::warning
:question: **What makes code slow? How can we speed up code?**

- Write Notes in the class pad for your group.
- Nominate or volunteer one person for each group to feedback.
- Problem with group (e.g. only one person) - select your operating system in the [zoom help](https://support.zoom.us/hc/en-us/articles/115005769646-Participating-in-Breakout-Rooms) and use the `ask for help` section to get our attention!
:::
- Group 1:
- Avoid complex loops
- Delete repeated code
- Use Numpy rather than list
- Avoid similar code with same function
- Group 2:
- For loops when avoidable
- Use numpy that has built in memory efficientcy when storing arrays in memory.
- Group 3:
- Avoid too many loops in the code
- Use libraries such as Numpy to speed up code
- Run code in parallel
- Group 4:
- To make code run faster:
- Make code more efficient by making it less repetitive
- Smaller library size
- Shortern the length of the code
- Use fewer loops
- Group 5:
- Use a jit complier to speed code up.
- Do not repeat code
- Use as few loops as possible
- Use Numpy instead of list
- only load data once
- if we want to use sin(), using sin() instead of math.sin() makes faster
- Group 6:
- Slow:
- incorrect data structures
- unnessecery nested loops
- loading/writing data
- Faster:
- parallelise code
- vectorisation
- GPU utilisation
- read/write only at start/end of code
- efficient use of data structures (not over complex)
- Group 10:
- Avoidable repeated steps
- Data structure - depending on how you store it can make running code slower
- Group 11:
- Slow:
- which/ how many processor used
- unnecessary loop systems
- data structure
- usage of memory
- Type of variable
- Faster:
- Compiler
- vectorisation
- selection of use for GPU and CPU
-
- Group 12:
- Group 14:
- Group 15:
- Suitable algorithms
- Hardware configuration
- Programming language that we use
- Assign memory in advance
- Group 19:
- Slows down:
- Repetition of code
- Nested loops
- To speed up:
- GPU computing
- Jit compiling
- Preallocation of arrays/memory, instead of changing array size on each iteration
- Group 20:
- To speed up
- hardware acceleration (GPU, FPGA, QPU) as appropriate
- Use the beautiful Quantum Fourier Transform (assuming Full-Scale Fault-Tolerant computing )
- Reduce redundancy
- Vectorization (or list comprehension) over loops
- Remove unnecessary if statements or branching where possible
- Group 21:
- Slow
- Repeatly loading the data
- nest of loops

- Improve:
- flatten the for loops
- take parallel computing for high amount of computational work load
- Method to improve python running efficiency: Use C

- Group 23:
- Redundant code
- Incorrect data structure
- Group 27:
- slow
- python - further away from machine code
- loops
- IO (filesystem, calling to other systems)
- suggestions
- JIT numba
- write in another language like julia or C
- vectorised operations
- GPUs

### Exercise: Accelerating code
:::info

In the homework, you looked at using numpy to accelerate Python code. For this exercise, we will look at two more ways.

Based on your group number, look at the following issue:
| Group number | Issue |
|- | - |
|Even (2, 4, ...) |[Numba and Cython](https://github.com/UCL-MPHY0021-21-22/RSE-Classwork/issues/48)|
|Odd (1, 3, ...) |[MPI](https://github.com/UCL-MPHY0021-21-22/RSE-Classwork/issues/49) |

Follow the instructions to look at the code, run it and measure its performance.

Write down your comments in the space below. Focus on:
- Was the code easy to understand?
- How different was it compared to the original? How easy do you think it is to adapt the original code to this form?
- Does it perform better than the original? Than the `numpy` version? What conditions do you think would make it run faster/slower?
Nominate one person from your group to explain the method and feed back to the class.

If you need help, you can ask for us to drop in, following [these instructions](https://www.youtube.com/watch?v=yIOMPRLQIHA).
:::

Leave your comments here.

- Group 1:
- Group 2:
- Group 3:
- Group 4:
- Group 5:
- Cython we felt was the the most simple to understand, at first glance.
- numba seemed a little complex but was understandable if you looked at it for a while.
- The MPI implementation was quite difficult to understand and not very nice to look at.
- We saw preformance imporvemnts with Mpi, cython and numba.
- Group 6:
- The Python code based on Numba acceleration (80.8 μsec) is nearly 10,000 times faster than the traditional Python code (4.38 msec). To achieve this amazing acceleration, you only need to add a line of jit decorator @jit(nopython=True) without modifying the code itself.
- In the Colab environment, Cython-based code (3.73msec) is faster than traditional Python code (4.38msec), but the degree of acceleration has more room for optimization. %%cython --annotate
- Group 10:
- Using Numba improved the run time significantly, however the inital run of the compiler outputted a different result than the subsequent runs after compilation
- We didn't get cython to work..
- Group 11:
- Group 12: The code was just the same, only the compiler flag was different.
- Group 14:
- Group 15:
- if the points is 10000, NumPy version of our code runs quicker than the MPI one; if the points is much larger (for example, 10,000,000), MPI version performs much more better than the NumPy version.

- Group 19:
- MPI more difficult to understand
- Couldn't get it to run..
- Group 20:
- Group 21:
- Group 23:
- Group 24:
- Numpy took 202 mus per loop
- The declarator for the function with numba is different to that for numpy, but otherwise the functions themselves are pretty mucht the same
- In Numba, @jit is called which tells python to compile this code with the more efficient compiler
- Numba was pretty intuitive to understand

- Group 27:
- MPI took longer when nr was 10,000 but faster when using a larger nr like 10,000,000
- overhead for orchestrating parallelism and combining individial processes

### Quiz: Scaling
Head back to [Mentimeter](https://www.menti.com/119a5tzx9y) (or code `2955 8256`)!

### Homework
- [Official feedback survey](https://opinio.ucl.ac.uk/s?s=75188)
- [End of course survey](https://moodle.ucl.ac.uk/mod/feedback/view.php?id=2375310)
- :christmas_tree:
- :santa:
- :sleeping_accommodation:

# Questions

:::info
Feel free to add any question below. Remember the syntax:

- Example question
  - [name=student_a] Example answer
  - [name=TA_1] Example answer

:::

- will the team be available to help over the break via email if we have questions?
- [name=David] Up till the 23rd of Dec and from the 4th of Jan, for sure. In between, not really.
- will we have office hour next week?
- [name=David] We will have office hours available next week.
- If we were to find our group has people that don't do anything, what should we do?
- [name=Anastasis] Contact us [e-mail]
-

###### tags: `mphy0021` `teaching` `class`