Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: THEend8_
COSC3500/7502 Milestone 1/ Milestone 2
General comments :
The same basic rubric is used for both the Serial (Milestone 1) and Parallel (Milestone 2) presentations.
This will allow feedback you received from Milestone 1 to be more directly applied to Milestone 2.
Each presentation is strictly maximum 10 minutes in duration. The assessors will simply stop watching
after 10 minutes. However do not feel compelled to mindlessly fill up the entire 10 minutes, particularly
for Milestone 1 where there is likely less to talk about. The presentation is “as long as it needs to be”…as
long as it doesn’t need to be more than 10 minutes. A shorter high-quality presentation is better than a
longer low-quality presentation. Obviously if the presentation is too short, it's going to be difficult to
provide much depth. If you’ve been working diligently on your project during the semester, you should
have plenty to discuss. Ultimately the goal here is to impress those assessing you with what you’ve
done, and it’s up to you to strategically allocate your time to various aspects and topics in that 10 minute
or less slot. As everyone has different models they are simulating, naturally some models will require
more introduction/background explanation than others, and the lengths of the talks would naturally not
be the same. If your model is simple and fast to explain, you don’t need to pad out the rest of your talk
to make up the 10 minutes just for the sake of it.
The presentation also serves as a form of identity verified assessment, so you must have your face visible
in the presentation. It is completely fine to record your presentation in multiple takes and splice them
together if you don’t manage to record it the way you like all in one go, but your face must be visible
throughout. Try to do a good job of the video splicing, but seeming as your face is only being shown
for identity verification purposes, it is ok if your head video moves discontinuously during the splice.
That is, we’ll ignore your face other than for identity verification purposes, but the video should be
otherwise well edited/presented.
You do not necessarily have to use all the parallel programming techniques in your Milestone 2 in order
to get a good mark. There are multiple paths to a good final result. In past years, there have been
excellent final submissions that only used a single technique (e.g. AVX, openMP, MPI, or CUDA) but
implemented and analysed the results very thoroughly. Some have compared one or more technologies
(e.g. CPU vs. GPU), and some have done combinations (e.g. openMP+MPI). Probably the least common
path to an excellent mark is to use openMP in isolation, but that has also been achieved in the past.
Comparing a CPU implementation with a GPU implementation is a common approach, likely because
it’s easier to first implement your parallel model on a CPU and check that it works, before progressing
to a scaled up GPU implementation. Given that a GPU is so much faster than a CPU, sometimes an
appropriate role for parallelised CPU code can be in support of the GPU, such as once-off routines at
the start and finish of the simulation, that would be too difficult or tedious to implement on GPU, but
are still computationally intensive enough that there’s benefit to creating an optimised CPU
implementation.
Introduction and background (20%) : A brief introduction to the model you are implementing should
be provided such that the teaching staff can understand what is being simulated. The goal here is to
bring those assessing you up to speed on what exactly it is that you’re trying to do, such that they’ll be
able to understand the rest of your talk. There’s no fixed amount of time you should allocate to this
introduction and background, and it will depend on the model being simulated, as some models will
naturally require more setup than others. There will likely be overlap between the introduction and
background between Milestone 1 and Milestone 2. Each presentation should be self-contained as the
assessors will likely not remember the details of your Milestone 1 when watching Milestone 2. If
relevant you may wish to discuss some relevant results from Milestone 1, or you may like to integrate
any references or discussion of Milestone 1 versus Milestone 2 results in the optimisation/benchmarking
discussion.
Optimisation (25%) : Explain what optimisations you attempted and how they performed. If relevant
explain what techniques you tried that didn’t work, or indeed techniques that you considered, but
ultimately decided against. Discuss aspects like how you structured and/or parallelised (Milestone 2)
your problem so as to make it as fast as possible. Discuss any trade-offs you made or came across.
Benchmarking (25%) : Explain your benchmarks. Explain how you setup your benchmarks, especially
with regards to avoiding inaccurate/misleading benchmarking results. Discuss the benchmarking results
themselves, particularly with regards to things like Amdahl’s law (Milestone 2), Gustafson’s law
(Milestone 2), the identification of hotspots, bottlenecks, how the performance scales with problem size,
etc.
Presentation (20%) : This part concerns how effectively you convey your results to the assessors using
various aspects of visual and verbal presentation. Including both your choice of content to present (i.e.
an appropriate choice of topics to present and an appropriate amount of time allocated to each), but also
the way in which those topics were presented. This includes verbal skills such as how the various parts
of the presentation were described, as well as the visual presentation of information on the slides, data
visualisation/representation, etc.
Reflection/Conclusion 10%) : Summarise the main conclusions. Topics you may like to reflect on
could include, what you learnt or found most surprising, what you would do differently, or how you
would extend upon your work, if you had additional time. For Milestone 1, you might like to look
forward to your plans for Milestone 2.
Code (pass/fail) : Your submission must include well-commented source code, and any other associated
fields such as Makefiles, slurm scripts etc, that are required to compile and check your code. You will
not be directly assessed on these, but they are required for reference and completeness. This is supposed
to serve to verify that you did in fact implement the models you discussed in your presentation, but will
also give the assessors some references for checking points of interest, or to get clarity on some specifics.