[SOLVED] Cpe2600 lab 11 -multiprocessing

Lab 11 Multiprocessing
Acknowledgement: Many aspects of this assignment are modeled after this: Operating Systems Principles (fiu.edu). See additional acknowledgements in the template code.
Topical Concepts
Multiprocessing
Although there are a number of benefits of multiprogramming, the most obvious is to achieve speedup of lengthy operations. To really explore these benefits, we have to have a lengthy operation. How about generating an image of a fractal? The Mandelbrot set is one such calculation that can be made and easily visualized. Depending on a variety of parameters, generation of a single image of the Mandelbrot set can take up to a few seconds on modern computing hardware. To aid in visualization often many images are calculated by varying parameters such as origin or scale factor then pieced into a movie. Examples can be seen here: Mandelbrot set – Wikipedia. The primary goal of this phase of the project will employ multiprocessing to enjoy a speedup while generating Mandelprot plots.
A program in the starter repository (mandel) has been provided that features a command line interface which allows adjustment of various parameters and will then generate a Mandelbrot set visualization and save it to a jpeg file.
Note that mandel uses ‘getopt’ to process command line arguments. You will need to use getopt for your new program or extend it to accommodate the new command line options if you choose to modify the existing program.
Once you have your 50 frames (or more if you wish) you can stitch them together into a movie using ffmpeg (you will need to install – sudo apt update / sudo apt install ffmpeg). Note, you will also need to install a development library to handle jpeg files to build mandel (sudo apt install libjpeg-dev).
Once everything is working, use the time command to measure the time it takes to generate the 50 images with various allowed numbers of children processes (1, 2, 5, 10, 20 for example). Plot the results. Does using more processes always speedup the operation? See below for the deliverable.
In Lab 12 we will investigate a multithreaded version.
Git Source Version Control – Next Steps
Branches
So far we have been using git in its simplest form, really just as a tool to track a “linear” set of changes to a software project. We have an easy way to track changes, to mark milestones, and to undo changes. This is quite useful by itself if you are a solo developer and are not really sharing your code or repository with anyone.
In reality, you will rarely be a solo developer, and your repository will likely be accessed by other developers and stakeholders. So, we must introduce additional features to deal with more complicated scenarios. The first new concept is that of a branch. Like many things, this can get very complicated, so we will just be scratching the surface here as well.
So far, we have just a single branch in our repository. By default, it is named “main.” As we made changes, we committed those changes to the main branch. However, if we are working with other developers or even just publishing our repository for public consumption of our project, there is a expectation that the main branch is always deployable. That is, a tested, stable version of the project. In addition, the numerous commits that you make leading up to that next stable version can ultimately create a lot of clutter.
So, you should be doing your actual development on a branch, leaving the main branch unchanged until the new features developed are fully tested and ready to deploy on the branch. At that point the branch can be merged back to the main branch. Some guidelines suggest maintaining a parallel development branch and only merge to main for releases.
With the -b option, this will create and switch to the new branch. Any commits made now will be on the branch. You can go back to the main branch with another git checkout command, but be careful. Any commits made on the main branch will complicate merging the branches later.
We can commit to this branch now, but, technically the branch does not exist in the remote repository, so right now, at least, we cannot push. To do that, there is one additional step we need to take. The following command will push to remote and specifically make the same branch on the remote repository.

Now we can commit changes locally and push to remote the same way we have always done. Until we checkout a different branch or commit in the repo, we will be adding all commits on the branch (which is what we want).
Interestingly, as long as no commits are made to main, commits will still appear “linear.” If you were to graph commits, you might see this:

Merging
Ultimately, changes made on a branch will need to be merged back onto the main branch. As stated, ideally, no commits have been made to main since you are doing your work on a branch. So, the process of a merge is pretty trivial.
Be sure that you have no uncommitted changes when you start a merge, or you might wind up with some unintended issues.
If your current location (HEAD) is still on the branch, and you attempt to merge with main, nothing really happens because, although it is called a branch, if no commits have been made on main, there is no bifurcation in the history.
To successfully merge to main, you will need to change your location to the main branch (checkout) and issue the merge from there.

Note the message – “Fast-forward”. This basically acknowledges no changes were made to main since the branch. If changes had been made, it would be a “true merge” or a “three-way merge” which has a potential for conflicts. If there are conflicts you will have the opportunity to under the merge or proceed. If you proceed, your files will be marked where there are conflicts and you will need to manually fix them. A pain in a large project, for sure.
You can push to remote when done and have your new “release” ready to go.
The Exercise
Specific Instructions
1. Accept the new GitHub Classroom assignment at https://classroom.github.com/a/0nNkoC5K and clone the repository.

2. Before making any changes, create a branch name “labWeek11dev” and switch to that branch. Push the branch to the remote repo as shown above.

5. Collect runtime for 1, 2, 5, 10, and 20 children processes. Plot into a graph with # processes on the X axis and runtime on the Y axis. Prepare a brief report in README.md (edit the one in your repository). In the report, include:

a. A brief overview of your implementation.
b. The graph of your runtime results. You will need to export the plot (from Excel) into an image, add the image to your repo, and then link it into the README.md.
c. A brief discussion of your results.

6. Create a movie of your 50 images. You can use the ffmpeg tool – this command should work: ffmpeg -i mandel%d.jpg mandel.mpg
*** We will demo a few people’s movie in the lab. Include your best movie in your repo for review and grading. ***
Deliverable
• When you are ready to submit your assignment prepare your repository:
• Make sure your name, assignment name, and section number are all files in your submission – in comment block of source file(s) and/or at the top of your report file(s).
• Make sure you have completed all activities and added all new program source files to repository.
• Make sure your assignment code is commented thoroughly.
• Make sure all files are committed and pushed to the main branch of your repository.
• Tag your repo with the tag “`vFinal“`
• Include your best movie in the repo (we would not normally include such a file in a repo but for grading we do)
***NOTE***: Do not forget to ‘add’, ‘commit’, and ‘push’ all new files, branches, and changes to your repository before submitting.
To submit, copy the URL for your repository and submit the link to associated Canvas assignment and add a comment on Canvas that you have completed Lab 11.