COSC3500代做、代写c/c++，Java程序

日期：2023-07-31 09:01

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.

Submission format (pass/fail) : Your video must be H.264 format and less than 200Mb in size. This

would correspond with a video bitrate of approximately 2 Mbit/s or less. The video should be named

‘Milestone{#milestone number}_{your 8 digit student number}.mp4’, e.g. Milestone1_43210987.mp4

Your code should be submitted as a single .zip archive with the same naming convention, e.g.

Milestone1_43210987.zip.