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

Includes simulation tips section in the docs #1543

Merged
merged 13 commits into from
Apr 14, 2021
Merged

Conversation

tomchor
Copy link
Collaborator

@tomchor tomchor commented Apr 4, 2021

Closes #1478

As mentioned in #1542 I couldn't build the docs locally so I probably made some markdown mistakes along the way, which is why this is a draft pull request. This first draft is also somewhat incomplete.

I figured I'd create the PR early to get some feedback along the way though. I'm especially unfamiliar with the part about converting arrays to CUDA etc., so some help/collaboration there is much appreciated.

CC @ali-ramadhan @glwagner @navidcy @francispoulin

using Oceananigans.Grids: Center, Face
using Oceananigans.Fields: KernelComputedField

@inline ψ²(i, j, k, grid, ψ) = @inbounds ψ[i, j, k]^2
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You did a great job in explaining @inline above. Is it worth having a sentence explaining @inbounds as well?

Copy link
Collaborator Author

@tomchor tomchor Apr 5, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know much about @inbounds in Julia, but from what I can tell the user doesn't need to use it that much (except when creating KernelComputedFields, which has many other difficulties). So I'd say we don't need to touch on that here (maybe in docs for KernelComputedField). But I might be missing something.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sadly, I don't remember when to use @inbuonds and when not to use it. @ali-ramadhan explained it to me once. Maybe he could help in adding a sentence? I would certainly use this when writing code as at the moment it seems mysterious to me when you use it and when you don't.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It just tell julia to not bother checking whether the index is beyond the array’s limit. At least that’s what I think it does...

https://docs.julialang.org/en/v1/devdocs/boundscheck/

Copy link
Collaborator

@francispoulin francispoulin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a reallly nice contribution and I learned some things along the way so thanks.

I have still a lot to learn about efficiency so will let someone else who is more knowledgeable on the topic approve and add more feedback

In practice it's hard to say whether inlining a function will bring runtime benefits _with
certainty_, since Julia already inlines some small functions automatically. However, it is generally
a good idea to at least investigate this aspect in your code as the benefits can potentially be
significant.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It may be worth mentioning that KernelAbstractions "force inlines" all GPU code. I can't remember if CPU code is also force inlined. @vchuravy and @jakebolewski have give advice regarding the use of @inline in the past. Force-inlining suggests that we don't always need the annotation @inline but for some reason it still pervades all our code... ?

Copy link
Member

@ali-ramadhan ali-ramadhan Apr 5, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a suggestion to mention KernelAbstractions.jl but it might not be useful to discuss inlining behavior to new users (many of whom are completely new to Julia).

My (probably unpopular) opinion is that I like to explicitly @inline functions to tell people reading my code that this is a performance-critical function I intend to have inlined whenever possible (even if it'll be force-inlined by the compiler). But this is probably a debate for another place.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the docs on inlining in Julia are a bit scarce. There's a lot of spread out in discourse comments. For the time being I think this is the limit of my knowledge. But feel free to adapt the text if you think it needs more details.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think its fine to recommend @inline for style / clarity. But we shouldn't mislead people in the docs by saying that @inline is necessary for performance if it has no effect.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@glwagner are you suggesting that @inline doesn't impact performance?

Copy link
Member

@glwagner glwagner Apr 14, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it does for GPU, but it might for CPU!

Copy link
Member

@glwagner glwagner Apr 14, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could be fun to illustrate these points with code snippets that do some benchmarking that users can use for themselves (some day).

@glwagner
Copy link
Member

glwagner commented Apr 5, 2021

Thanks for starting this @tomchor .

@ali-ramadhan
Copy link
Member

Docs should show up at https://clima.github.io/OceananigansDocumentation/previews/PR1543/ once a commit has been made after the PR has been opened.

docs/src/simulation_tips.md Show resolved Hide resolved
docs/src/simulation_tips.md Outdated Show resolved Hide resolved
In practice it's hard to say whether inlining a function will bring runtime benefits _with
certainty_, since Julia already inlines some small functions automatically. However, it is generally
a good idea to at least investigate this aspect in your code as the benefits can potentially be
significant.
Copy link
Member

@ali-ramadhan ali-ramadhan Apr 5, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a suggestion to mention KernelAbstractions.jl but it might not be useful to discuss inlining behavior to new users (many of whom are completely new to Julia).

My (probably unpopular) opinion is that I like to explicitly @inline functions to tell people reading my code that this is a performance-critical function I intend to have inlined whenever possible (even if it'll be force-inlined by the compiler). But this is probably a debate for another place.

docs/src/simulation_tips.md Show resolved Hide resolved

### Arrays in GPUs are usually different from arrays in CPUs

Talk about converting to CuArrays and viewing CuArrays as well!
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we also talk about CUDA scalar operations (https://juliagpu.github.io/CUDA.jl/dev/usage/workflow/#UsageWorkflowScalar) and how/when to use CUDA.allowscalar and CUDA.@allowscalar?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My guess is yes, but I know nothing about this topic, so some collaboration would be very much appreciated :)

@tomchor
Copy link
Collaborator Author

tomchor commented Apr 5, 2021

Docs should show up at https://clima.github.io/OceananigansDocumentation/previews/PR1543/ once a commit has been made after the PR has been opened.

This gives me a 404 error!

@navidcy
Copy link
Collaborator

navidcy commented Apr 5, 2021

Docs should show up at https://clima.github.io/OceananigansDocumentation/previews/PR1543/ once a commit has been made after the PR has been opened.

This gives me a 404 error!

I believe you have to open the PR (not have it as "Draft") and then it'll push the preview....

@navidcy navidcy added the documentation 📜 The sacred scrolls label Apr 5, 2021
@tomchor tomchor marked this pull request as ready for review April 7, 2021 01:13
@tomchor
Copy link
Collaborator Author

tomchor commented Apr 7, 2021

I finished the first draft (of the topics I know about at least). I haven't written the very last subsection though, which is about viewing/using arrays in GPU runs because honestly I don't know enough to write about it. I know there's a function called view() that helps with slicing, and you can also use adapt to view CUDA Arrays in REPL for investigating, but I feel like I don't know enough of this aspect of the code to write this. There are two options here:

  • Someone helps me out and writes that last section
  • Or I can merge the PR without it for now (there are many other important things there for the user) and we worry about that last part in a future PR

Thoughts?

@glwagner
Copy link
Member

I'm wondering if we should provide a separate page on "Using GPUs"? While the simulation tips for CPUs are really performance optimizations that are optional, the GPU simulation tips are mostly required to run without errors. There's a few other things that are required to get things working on GPUs --- for example, Oceananigans must be built (not just run) with a GPU / CUDA installation available; this is a common pitfall on clusters.

@tomchor
Copy link
Collaborator Author

tomchor commented Apr 13, 2021

I'm wondering if we should provide a separate page on "Using GPUs"? While the simulation tips for CPUs are really performance optimizations that are optional, the GPU simulation tips are mostly required to run without errors.

That's a good point. Although I think we could avoid creating another page and put that information in the "Using GPUs" page, so that things are more condensed.

@glwagner
Copy link
Member

glwagner commented Apr 13, 2021

I'm wondering if we should provide a separate page on "Using GPUs"? While the simulation tips for CPUs are really performance optimizations that are optional, the GPU simulation tips are mostly required to run without errors.

That's a good point. Although I think we could avoid creating another page and put that information in the "Using GPUs" page, so that things are more condensed.

🤦 there's already Using GPUs of course, silly me...

@navidcy navidcy self-requested a review April 14, 2021 02:34
@navidcy
Copy link
Collaborator

navidcy commented Apr 14, 2021

We have a preview!
https://clima.github.io/OceananigansDocumentation/previews/PR1543/simulation_tips/
Seems like the section needs to be finished (see, e.g., last sentence...). @tomchor?

docs/src/simulation_tips.md Outdated Show resolved Hide resolved
docs/src/simulation_tips.md Outdated Show resolved Hide resolved
docs/src/simulation_tips.md Outdated Show resolved Hide resolved

It may be useful to know that there are some kernels already defined for commonly-used diagnostics
in packages that are companions to Oceananigans. For example
[Oceanostics.jl](https://github.com/tomchor/Oceanostics.jl/blob/13d2ba5c48d349c5fce292b86785ce600cc19a88/src/TurbulentKineticEnergyTerms.jl#L23-L30)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit hesitant to reference the users to a package that is neither registered nor tested. (mostly the latter tbh)
What do others think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oceanostics.jl is registered. It could do with some actual tests but plenty of Oceananigans.jl functionality is not tested.

I think it's good to link to packages outside of Oceananigans.jl to give readers the idea that creating their own packages for extra functionality is okay (and actually encouraged!).

I would even advocate for creating an extra page in the docs to link to other packages related to Oceananigans.jl and being liberal with the packages we include.

tomchor and others added 3 commits April 14, 2021 06:22
Co-authored-by: Navid C. Constantinou <[email protected]>
Co-authored-by: Navid C. Constantinou <[email protected]>
Co-authored-by: Navid C. Constantinou <[email protected]>
@tomchor
Copy link
Collaborator Author

tomchor commented Apr 14, 2021

Thanks for the help with this PR, @navidcy! Much appreciated

Seems like the section needs to be finished (see, e.g., last sentence...). @tomchor?

Ah, that's the limit of my knowledge on GPUs. We could either drop that session for now or someone else could write it. I really don't think I know enough to write that section.

Copy link
Member

@ali-ramadhan ali-ramadhan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added some quick text under the last section. Should be better than nothing.

Happy to merge this as-is now since it's already a great addition to the docs that we can continue expanding in the future as common GPU issues pop up.

docs/src/simulation_tips.md Outdated Show resolved Hide resolved
@navidcy navidcy self-requested a review April 14, 2021 13:51
@ali-ramadhan
Copy link
Member

ali-ramadhan commented Apr 14, 2021

I think GPU tests randomly crapped out (not important for this PR) but docs are still building so as long as the PR docs preview looks good, then this should be good to merge!

@tomchor
Copy link
Collaborator Author

tomchor commented Apr 14, 2021

@ali-ramadhan currently waiting for the preview to load so that I can merge, but I don't think it'll do that with the GPU test failing. How do we fix that?

@ali-ramadhan
Copy link
Member

@tomchor Ah are you okay with committing my suggestion before merging?

I think docs did get built and deployed:
https://buildkite.com/clima/oceananigans/builds/2048#0d49a5b8-1dec-4f7b-b82a-cf6f8809e234/40-574
https://clima.github.io/OceananigansDocumentation/previews/PR1543/simulation_tips/

Working on getting you guys access to Buildkite so you can control it as well. I'm not a Buildkite admin so I have to ask one to invite other people...

@tomchor
Copy link
Collaborator Author

tomchor commented Apr 14, 2021

@tomchor Ah are you okay with committing my suggestion before merging?

Sorry, I forgot to do that!

@ali-ramadhan
Copy link
Member

Everything passed 🎉 Thanks so much for adding this great information to the docs @tomchor!

@tomchor
Copy link
Collaborator Author

tomchor commented Apr 14, 2021

Thanks, everyone. I'll merge this for now and we can improve on it later based on feedback from users.

@glwagner I'm thinking of opening another PR soon to address your comment about using GPUs. Like I mentioned, some of this info is already available in the "Using GPUs" page, but maybe it's useful to expand a bit on it and link this newly created page there.

@tomchor tomchor merged commit 28dadbc into master Apr 14, 2021
@tomchor tomchor deleted the tc/simulation_tips branch April 14, 2021 15:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation 📜 The sacred scrolls
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add "GPU simulation tips" section to the docs
5 participants