| Date | |
|---|---|
| 14 November 2023 | Assigned |
| 28 November 2023 | Due, end of day |
| Status |  |
- summarize the process and evaluation techniques of multi-core programming
- implement multi-core program using a shared memory buffer
- calculate and analyze metrics which describe multi-core program performance
- select and apply best-fit multi-core program approaches
- identify best-candidate programs for revision into multi-core implementations
This program is located in hello_core/main.c.
We've looked at this program...so many times. The best part: it still keeps getting more interesting. Here, we'll explore how cores communicate.
Soon, you'll be sent off to boldly go where no one has gone before -- to mine space rocks. Before you go, it'd be helpful to learn a little bit about the diagnostic equipment you have on board your mining craft. Specifically, we're interested in the internal temperature sensor. Previously, it worked, but it was a bit slow. Advances in technology allow us to speed processing up a bit.
This program is located in core_conditions/single_core_conditions/main.c.
Let's look at the way things currently are, first. This program reads from our on-board temperature sensor using a single core in a "thread-blocking" way: we have to execute all instructions synchronously -- each has to finish before we can move on to the next one. This program will provide a baseline against which to observe our more advanced versions.
Complete this work in core_conditions/multi_core_conditions/core_conditions_buffer/main.c.
The first way we can speed up our temperature sensor is to drop information into the shared buffer through which our cores communicate. While this still involves blocking procedures, we'll witness how much faster this setup makes our program.
Complete this program using core_conditions/multi_core_conditions/core_conditions_functions/main.c.
This program presents a quasi-alternative to our buffer strategy: instead of dumping values for cores to "pick up," what if we passed entire functions to the buffer and exchanged their results through buffer transfer? We'll discover a key lesson about the way that our buffer works and develop a new strategy for tacking our speed-up problem.
Complete this work in the folders contained in the core_principles directory.
Your task is to revise a previous lab program from the list below into two multicore versions:
- a one-way buffer read/write version (passes only values)
- a version which passes functions instead of purely values
This will require you to generalize about the code written in both of our multicore examples and apply a few techniques that test the edge of our knowledge. In addition, you'll need to provide the single-core versions of the programs in order to do testing (i.e. speedup and efficiency testing).
The labs from you you can choose are:
cart_corralfrommine-cart-madnessclassifierfromthe-moon-rocksadderfromc-of-tranquilitymajorityfromcircuit-scramble
All but one of these are good candidates for "parallelization" (i.e. multicore programming). If you find the one that's not a great fit, do not despair! You can still finish the lab by answering the quesitons in the report.
See the suggestion below to challenge yourself to implement a Hack. As always, you are allowed to develop your own Hack to satisfy this stretch goal. Place the code for the Hack inline with the code in the corresponding file.
In order to recieve credit for the Hack, you must fill out the hack.md file located in the
docs folder.
This program suffered greatly from our approach. However, is there still a way to make it faster than the single-core version?
Hint: Can you find a way to reduce the memory footprint?
You are free to develop your own "Hack" for this assignment, provided that you respond to all of the questions in hack documentation.
Based on your system setup (refer to your hello-blinky assignment), you will need switch out the .vscode folder in each exercise with the last working copy.
See our wiki's entry on "Configuring Assignments" for more information.