-
Notifications
You must be signed in to change notification settings - Fork 9
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
Conversation
Also link to relevent topical guide content in the orientation guide.
|
@EamonConway @jomonman537 I've pushed my draft notes for yesterday's meeting, here's the online preview. |
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 :) |
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). |
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? |
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.
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.
Thanks @james, I've used "CPU core" / "CPU cores" throughout, and restored "our own experiences". @EamonConway are you happy for me to merge this? |
I've also added links to relevant topical guide content in the orientation guide.