Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft notes for our August meeting #74

Merged
merged 3 commits into from
Aug 20, 2024
Merged

Conversation

robmoss
Copy link
Owner

@robmoss robmoss commented Aug 9, 2024

I've also added links to relevant topical guide content in the orientation guide.

Also link to relevent topical guide content in the orientation guide.
Copy link

github-actions bot commented Aug 9, 2024

PR Preview Action v1.4.7
Preview removed because the pull request was closed.
2024-08-20 05:05 UTC

@robmoss
Copy link
Owner Author

robmoss commented Aug 9, 2024

@EamonConway @jomonman537 I've pushed my draft notes for yesterday's meeting, here's the online preview.

@robmoss
Copy link
Owner Author

robmoss commented Aug 9, 2024

Once we publish the finalised notes for this meeting, we should let everyone know that we will run an Introduction to Debugging workshop at the SPECTRUM annual meeting :)

@jomonman537
Copy link
Collaborator

I had a look through the meeting notes and made some minor corrections. Other than that, the contents of the meeting notes are mostly correct.

In the GPGPU section of the meeting notes, I noticed that you used "multiple CPUs to make code run more quickly". Do you mean "multiple CPU cores" or "multiple CPUs"? I don't think it is possible to run a computer over multiple CPUs (unless you are talking about a workstation or server farm).

@robmoss
Copy link
Owner Author

robmoss commented Aug 12, 2024

Thanks very much @james.

Unless you're really pushing against hardware limitations, from an end-user perspective there's very little difference between (a) multiple cores in a single CPU, with shared cache; and (b) multiple CPUs with independent caches (Intel has a nice diagram, see Figure 2). In either case, the relevant feature is that each core can run a separate process.

The approaches we discussed in the meeting readily apply to both situations, and it's only when we need to use more complex approaches that the distinction matters. I chose to say "CPU" rather than "CPU core" because I feel that most people have at least a vague notion of what a CPU is, and I thought that saying "CPU core" might be more confusing ... 🤷. What do you think is best?

-    There was strong interest [...] based on **our** own experiences.
+    There was strong interest [...] based on **their** own experiences.

I've tended to use "them", "they", etc, to refer to individual attendees or the attendees as a whole. For this specific remark about recommending packages and libraries, I wanted to refer to our community as a whole — using our collective experiences to make these recommendations. So I'd prefer to leave it as "our own experiences". Does that seem reasonable to you?

@jomonman537
Copy link
Collaborator

The approaches we discussed in the meeting readily apply to both situations, and it's only when we need to use more complex approaches that the distinction matters. I chose to say "CPU" rather than "CPU core" because I feel that most people have at least a vague notion of what a CPU is, and I thought that saying "CPU core" might be more confusing ... 🤷. What do you think is best?

According to Figure 2, it seems we can distinguish between a CPU processor and a CPU core. When I think of parallel computing at the consumer level, using multiple CPU cores is more understandable to me than using multiple CPU processors. And as all CPUs nowadays use multiple cores rather than a single core, from my perspective it should be fine to use CPU cores than CPUs or CPU processors.

I've tended to use "them", "they", etc, to refer to individual attendees or the attendees as a whole. For this specific remark about recommending packages and libraries, I wanted to refer to our community as a whole — using our collective experiences to make these recommendations. So I'd prefer to leave it as "our own experiences". Does that seem reasonable to you?

That should be fine. It implies that we had a group discussion on packages and libraries multiple people recommended than one person proposing ideas from their own experience.

Also restore the message about making recommendations based on *our* own
experiences.
@robmoss
Copy link
Owner Author

robmoss commented Aug 12, 2024

Thanks @james, I've used "CPU core" / "CPU cores" throughout, and restored "our own experiences". @EamonConway are you happy for me to merge this?

@robmoss robmoss merged commit 2aed5b7 into master Aug 20, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants