No Slide Title
MPP Coursework 1
Feedback on submitted reports
Overall
• Average was (just) very good at 60% (before late penalties)
– but this is a several marks less than expected
• All five marking criteria had very similar averages
– except for “Program Structure” which scored 52%
2
Guidance
• Following 4 slides come from the Induction talk given in
September 2021
3
Coursework
• Lecture material reduces in last few weeks of semester
– to give you time to do the major coursework
– labs continue so you can get practical advice on coursework
• To do well
– attend the lectures
– do practical examples as soon as you can
• coursework will assume you completed them
– start the coursework as soon as possible
• check the hand-in deadlines
– look at the marking scheme
• e.g. leave time for writing the report
– plan your work in advance!
4
Rationale
• Courseworks are not a tickbox exercise
• If we say:
– do this
– do something else
– draw a graph
– …
•
• You should pass if you do all of the above
• … but at Postgraduate Level we will reward:
– doing them well
– showing you understood what you did
– doing something extra, …
5
Mistakes we typically see (i)
• Spend all your time coding and not writing the report
• Not looking at coursework until a week before hand-in
• Trying to run lots of last-minute jobs on Cirrus
– alongside all the other students!
• Only looking at the next deadline
• Not following the coursework guidelines
6
Mistakes we typically see (ii)
• Not looking at the practical examples until the lab session
• Not discussing problems and questions about the
coursework at the labs
– both these require you doing some work in advance
7
Guidelines and Marking Scheme
– Your report should cover:
• Which parts of the existing program need to be changed and why.
• What additional MPI functions you plan to use and why.
• How you plan to structure your program including use of any of your own
functions / subroutines and how it will be split across files.
• What correctness and performance tests you plan for the full program and
brief results of some of these tests applied to the Case Study exercise.
– Marks will be allocated as follows (20% for each category):
• proposed changes;
• use of MPI;
• program structure;
• testing;
• presentation (includes quality of English, layout, figures and diagrams).
8
Overall Comments
• Surprised that many students did not structure their report
around the explicit guidelines
– did not apply their correctness tests to the case study example
– did not address structure of their planned program
– some reports not anonymous (e.g. name or UUN on title page)
• For Part 2, you should read and understand the guidance
– look at the marking scheme
– address all the points in your submission
• In particular, follow specific guidelines for code submission
– much easier if you use gitlab
9
Proposed Changes
• Good points
– generally well done
– most people addressed the fundamental issue of 2D decomposition
requiring additional halo swaps
– some people also discussed challenges for initialisation and IO
• Poorer points
– some people said M = L/P and N = L/P .. this is wrong!
– many people skipped over how to implement stopping criterion
• case study only computes “nchange” on rank 0 using MPI_Reduce
– very few people mentioned the new boundary conditions
– very few drew diagrams – these are an excellent way to explain
• e.g. 2D halo swaps and non-contiguous boundaries
– some covered Case Study “additional exercises” – not what was asked
10
Use of MPI
• Good points
– most reports identified need for new routines such as
MPI_Cart_create, non-blocking send/receive, vectors for non-
contiguous halos
– a few reports addressed overlap of comms and calc
• Poor points
– some reports just listed MPI routines with no explanation of how
they would be used
– many suggested reduce / bcast when allreduce is much better
– often not explicit enough on exactly how non-blocking would be
implemented: used for send and/or receive? where are the waits?
11
Program Structure
• I had expected discussion of the user functions that would
be implemented and how they would be split across files
– this was covered in “tips and tricks”
– very few covered this so I gave credit for more general discussions
• Good points
– some reports identified functionality (e.g. halo-swapping and map
updates) to be isolated as a user function and implemented in
separate files
• Poor points
– many reports seemed not to address this at all
12
Testing
• Good points
– almost all recognised comparison to serial code as key point
– some mentioned unit tests such as turning off various halo swaps
– almost all had performance, often averaged over many runs, and
plotted speedup / efficiency (but few showed standard deviation)
• Poor points
– not enough to say “compare outputs” – what outputs? how will they
be compared? final result (map.pgm) or intermediates (nchange)?
– no-one showed a failed test! does your test pick up issues with
running case-study code on 7 processes?
– often not clear what section of the code was timed – IO included?
– many performance results were only on a single node
• for Part 2, I require multi-node runs on the compute nodes
13
Presentation
• Good points
– generally well presented and easy to follow
– well split up into different numbered sections
• Poor points
– some reports had too much text – diagrams are an excellent way to
explain issues such as 2D decomposition, halo-swapping etc.
– many had no table of contents, some had no page numbers
• all reports should have numbered pages, sections, figures etc.
– some graphs were hard to interpret, e.g. no plot symbols, joined
with curve linesd, data values on plot points make graph very busy
– be careful about what precision you use when quoting data: don’t
say “0.5 seconds” or “0.523131331 seconds”.
14
Performance
• Do not plot raw times!
– these graphs are almost useless
• You should be plotting speedup
– multiple values of L on same graph
– all this was covered in one of the lectures!
• Weak scaling – many people got this wrong
– problem size N scales as L2
– so, if you double L then you need to multiply P by 4
• e.g. L = 480 and P = 4, L = 960 and P = 16, …
15
Any questions?
16