Create Tutorials “introduction-to-cilk-programming”

[behoppe]

Automatically generated by Netlify CMS

[netlify]

✅ Deploy Preview for sage-licorice-6da44d ready!

Name	Link
🔨 Latest commit	6ca5707
🔍 Latest deploy log	https://app.netlify.com/sites/sage-licorice-6da44d/deploys/62ffde2ff3f220000926e796
😎 Deploy Preview	https://deploy-preview-91--sage-licorice-6da44d.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[behoppe]

@cleiserson and @ailiop, would either/both of you be willing to please review my new tutorial, "Introduction to Cilk programming"?

You will see that I opted for a short first tutorial -- which aims to introduce cilk_spawn and cilk_scope purely in terms of semantics, without getting into performance analysis or any other keywords (cilk_for, cilk_sync).

You can disregard the current featured image (trace-dag) for now. I will make a new featured image that shows some code in full-color close-up (as you see now on the site home page).

Thanks for considering this!

[DorothyCurtis]

hello this is a comment from Dorothy

[ailiop]

@cleiserson and @ailiop, would either/both of you be willing to please review my new tutorial, "Introduction to Cilk programming"?

Sure, I will take a stab at reviewing it.

[behoppe]

Some comments from @cleiserson

• focus on runtime, not storage, energy
• be careful about "exceedingly complicated"
• task-parallelism is about logical tasks
• int declarations are ok with cilk_sync but can't happen inside cilk_scope

[DorothyCurtis]

Thanks, Alex, for the update! Dorothy

…

On Wed, Aug 03, 2022 at 01:40:25PM -0700, Alexandros-Stavros Iliopoulos wrote: > @cleiserson and @ailiop, would either/both of you be willing to please review my new tutorial, "Introduction to Cilk programming"? Sure, I will take a stab at reviewing it. -- Reply to this email directly or view it on GitHub: #91 (comment) You are receiving this because you commented. Message ID: ***@***.***>

[behoppe]

Thanks, @ailiop. I am going to make a few edits right now (this afternoon) and then turn it over to you for review.

[behoppe]

OK my edits are done. I tried to address comments from yesterday's meeting, and I also took a stab at tips on using "receiver variables." These tips are not part of the Intro to Algs primary source, and I don't have another good formal source, so I may be technically sloppy, but I think it's helpful to ground Cilk programming with these sorts of examples and tips. My $0.02.

Thanks @ailiop for reviewing.

[ailiop]

@behoppe I just finished a pass over the tutorial. I was finding it difficult to make some of the comments I had in mind using GitHub's code review interface, so in the end I decided to simply attempt and commit a partial rewrite. This may make it difficult to pick and choose subsets of my suggested (i.e., committed) edits. If you feel parts (or the entirety) of my commit need to be reverted, I am happy to help make that happen.

Here is a summary of the changes in my commit, apart from editing or rewriting paragraph text:

1. Discuss cilk_scope together with cilk_spawn
   • I introduced the notion of a "parallel region" to (hopefully) make the spawn/sync discussion clearer
2. Some section restructuring:
   • Move the introductory paragraphs outside of the cilk_scope & cilk_spawn example section
   • Attempt to add some relevant content in the "How OpenCilk runs your program" section
   • Group the danger/success examples into a "Common pitfalls and how to avoid them" section
3. Mention some additional defn keywords:
   • sync, nested parallelism, logical parallelism, continuation
4. Minor restructuring of the example p_fib() & fib() codes
   • Note that this means you'd have to regenerate the figure in the tutorial. Sorry.
5. I added a note about being able to cilk_spawn a block statement

And here are some additional higher-level comments:

(1) One downside of my edits is that they made the tutorial longer. I decided to not pare it down more aggressively before you got a chance to review the edits. My current thoughts on what could be cut down are:

• The "How OpenCilk runs your program" section could be replaced by a link to a documentation page or blog post that talks about just that. The only point which I think is useful for this tutorial is that the programmer is responsible for expressing logical parallelism and the runtime takes care of the rest (maybe also mention that it guarantees near-optimal scheduling/load-balancing).

• The discussion of two forms of a cilk_spawn for void vs non-void functions feels somewhat distracting. It makes certain technical sense (and could perhaps be useful in contrasting Cilk to other parallel platforms) — but here it may be better to try to emphasize simply that spawning a function is syntactically analogous to calling it. The notion of a "receiver variable" might still be useful for the pitfall example where the value x is indeterminate.

• The example of cilk_spawning a non-function block can probably be removed as-is.

(2) While I totally agree with the goal of keeping these tutorials succinct and focused, I am conflicted about leaving cilk_for out of Part 1. The reason is that I suspect the majority of people who want take a first stab at parallelizing something probably start by trying to parallelize a for loop. If you agree with that, I am thinking of two possible ways to address that concern:

• Add a very short section with a trivial example of a cilk_for (e.g., summing two vectors) and a link to the eventual part 2 of the tutorial for more details.
• Add "subtitles" to these tutorials, e.g., "Introduction to Cilk programming, part 1: spawns and parallel recursion", "Introduction to Cilk programming, part 2: parallel loops", etc. I don't think these are necessarily good titles, but the idea is to make it easy for someone who sees a list of the tutorials to know in advance what to expect in each one.

I hope all this makes sense. :)

[behoppe]

Thank you, @ailiop, for your edits. I think the tutorial is much improved. I think the team will be reviewing this tutorial as part of today's meeting. (Right, @DorothyCurtis?) I am going to update the figure right now, and I look forward to sharing this tutorial with the team for their feedback.

[ailiop]

Alright, it appears that the rebasing is done and the conflict is resolved!

For posterity, this entailed the following steps:

1. Find the offending commit(s)

In this case, we could do that by filtering the git log of this PR branch to show only those commits that touched the conflicting image file. For example, in my local clone of the repo where I have checked out the cms/tutorials/introduction-to-cilk-programming branch that tracks this PR, I can run the following:

git log -- src/img/fib-code-multicore.png

Thankfully, this only yielded a handful of commits.

2. Understand the conflict.

There were 3 commits in this PR that related to the conflict.

1. One commit deleted the image file in question.
2. The next one added the image file again.
3. The last commit in the PR modified the image file (to match that in main).

It seems like the error was deleting the image file from the branch as part of commit (1). This was then compounded by trying to fix the error with commits (2) and (3). The image was part of the main branch; moreover, it was being modified throughout the history of the main branch.

So, the desired effect would be to make it as if the offending commits never happened, right?

Well, almost. It turned out that commit (1) included some changes to the text in addition to the image deletion. What we want then, is to keep that part of commit (1) and remove commits (2) and (3) altogether.

3. Rebase (make it happen)

We want to rebase our currently checked-out branch (cms/tutorials/introduction-to-cilk-programming) onto origin/main. We can do that interactively with:

git rebase -i origin/main

This opens up a text editor with a manifest of all commits in our PR branch and the command pick for all of them. We make the following changes:

• Add a break command before the line where commit (1) is picked.
• Change the command for commits (2) and (3) into drop.

Save, exit, and continue the rebase.

When it reaches the break command, it will stop and present us with the staged changes of commit (1). We unstage the undesired deletion of the image and continue the rebase.

...and, fiinally, that's it. We can now force-push our local, rebased and conflict-free branch of the PR to the remote branch of the PR.

Some parting thoughts

1. I think this was more complicated than it could have been due a combination of two reasons: (i) the conflicting file was an image rather than text; and (ii) the conflict involved the file getting deleted, not just edited.
2. In this case, the easiest fix when the image was accidentally deleted would probably have been to: (i) reset the branch to the commit prior to the offending one; (ii) make a new commit which includes the intended changes but not the unintended deletion of the image; and (iii) force-push the change to the remote branch of the PR.

[behoppe]

Thank you @ailiop!!