René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Suggestions for the slideshow for day 1 the EsiWACE3 training ","articleBody":"# Slides for training \"GPU Optimization with Kernel Tuner\". Day 1 (12 Sept 2024)\r\n\r\n## On this issue\r\n1. I follow on the invitation dropped during the training to provide feedback. The permalink to the document is https://github.com/KernelTuner/kernel_tuner_tutorial/blob/d33bd6db03958667a6a71e89750b710f0e70203e/slides/2024_VSC_ESiWACE3/GPU%20Optimization%20with%20Kernel%20Tuner%20-%20Day%201.pdf.\r\n1. Purpose of the notes. These notes propose possible improvements for attendees that are (growing) experts in a topical field, have been exposed to computer science mostly empirically, and whose working memory does not contain all pre-knowledge required by the training. These learners will also naturally come back to the same slides as study material for all that was not clear on the fly during the training. This persona for the beneficiary is close enough to profile of the training attendees, I presume. I would expect that these notes prompt a slide edit rather than individual answers to all points. \r\n1. Stage of development of these notes. I wrote them as I was studying the slides after the training. I opened this issue in the repo before completing my own study precisely to track and highlight where something can prove unclear on first contact. In this way, the suggestions should be generalisable to a wider range of learners with varying familiarity with the training topic. Lastly, I might revisit this document a few more times as the staircase wit pushes me to do so; for a heavier engagement in the revising work we may discuss a collaboration on other terms. \r\n1. Scope of remarks. Most of the remarks regard word choices. Some might also regard the order of the slides and the order of topics inside a single slide. Some questions are rhetorical in the sense that they express doubts arising while reading the slides. Lastly, many things in the slides work just fine, and I don't mention them for lack of time and not of appreciation; this bias is unfair to the instructors, admittedly.\r\n1. Content organisation. The sectioning below reflects the separations in the slide set. The low-level headings report the slide number in point. \r\n1. Notes are shared as is, like the slides themselves. I hope every little helps, although realistically you may have to triage which little actually helps. \r\n\r\n---\r\n## Introduction\r\n\r\n#### 6 Learning objectives\r\n1. \"Integrate the tuning results into your application\": I do not think the training day covers this topic. \r\n\r\n### Introduction to Auto-Tuning and Kernel Tuner\r\n\r\n#### 8 Auto-tuning GPU applications\r\n1. I would arrange the bullet list in a more tangible order, for example from the smallest unit of programming (thread) to largest combinations of relevant notions.\r\n1. 'Loop unrolling factors': delete **factors** if you don't cover such factors later. The word factor is prone to ambiguity too, because different disciplines use it differently.\r\n1. Take note that the phrase **design space** morphs into **search space** in the following. Learners should be aware of the change of meaning. Managing that difference carefully may also bear opportunities for useful distinctions. Until we speak of optimisation, for auto-tuning problems I would stick to **design space**.\r\n\r\n#### 9 Manual optimization versus auto-tuning\r\n1. Take note of this first use of **template**. That can have more meanings in computing. There should be no confusion for the learners. I assume that here 'templated' means having generic parameters that are tunable. This issue returns below.\r\n1. Describe or illustrate briefly what a **code generator** is. The term is technical. Illustrations (in words) can be useful. Wikipedia does not help single out a simple meaning for it.\r\n1. Take note of the first use of **benchmark**. Benchmarking is easily intended as a comparison against a benchmark, a touchstone, a reference case, that is, some ground truth. Here you seem to use it for 'measuring'. The issue returns below.\r\n\r\n#### 10 Large search space of kernel configurations\r\n1. Please add in the title (either the slide or the graph) how many configurations have been tested here. \r\n\r\n#### 13 Kernel Tuner is:\r\n 1. A hint that **optimisation methods** are discussed later in the day give a sense of perspective.\r\n 1. The notion of **development-time** does not fit this region of text clearly: is that a time where no compiling occurs? Is it possible to tune empirically before computation?\r\n 1. **Software based** is a meagre description here and perhaps obvious: this line is an opportunity to hint at more to come (written in Python, and so on...)\r\n 1. **Easy to integrate** is not explained in these slides, I think. Fine to mention this property in this one list, though.\r\n1. **Discrete parameters** made me wonder if I should watch out for non-discrete parameters in numerical computing. Or do you mean the tunable parameters must be given as a collection of discrete items (lists, tuples, and so forth)? Are we talking maths or computer science here?\r\n \r\n#### 14 Kernel Tuner architecture\r\n1. Take note of the use of the word **function** here. Troubles of ambiguity ahead.\r\n1. The backend **cuda-python** is not mentioned any longer after this slide. Is it redundant here (then delete) or is it omitted afterwards (then touch upon it again)?\r\n\r\n#### 15 Minimal example\r\n1. This slide deserves to be copied in the next section to support the explanation there within close range.\r\n\r\n#### 16 What Kernel Turner does\r\n1. Whose **instance**? Instance is a potentially very ambiguous word as soon as it intersects the OOP descriptions. Is 'parameter configuration' a valid alternative?\r\n1. Take note of **benchmark** occurring. (I will not underline all occurrences of it.)\r\n\r\n#### 17 Installation...\r\n1. See 14. This is the first place where **cuda-python** is lacking.\r\n1. You could add a pointer here about finding out other GPUs elsewhere and work out the hands-on exercises after the training.\r\n\r\n---\r\n## Integrating Kernel Tuner with your Code and User-Defined Metrics\r\n \r\n#### 22 Kernel Tuner compiles...\r\n1. **Kernel Tuner is written in Python** but you also show some code in C++ in slide 79. If this alternative to Python exists, this slide is the place to prepare the learners.\r\n \r\n#### 23 Specifying Kernel source code\r\n1. There is no information about the most frequent positional argument, **`tune_params()`**, and that surely deserves room. \r\n1. Take note of a second usage of word **function**.\r\n1. Explain (hint at) what a **templating engine** is, for the uninitiated.\r\n1. Instead of **option** I suggest **optional argument**. \r\n1. **lang option** should be formatted differently as code and text fonts.\r\n\r\n#### 24 Kernel compilation\r\n1. **Template expansion**: are you thinking of templates as in C++? or just of a template in a generic sense? or precisely of the templating that KT offers? **Expansion** could also be explained for the uninitiated with a synonym (substitution, for example).\r\n1. Take note that **host code** is ambiguous. Which? Do you mean the code the kernel was originally part of? Or the Python code the kernel gets embedded into because we use KT? Or both? This issue returns elsewhere, although I will not signal all occurrences.\r\n\r\n#### 26 Kernel argument types\r\n1. First sentence. It sounds strange that Python cannot **reconstruct** something of NumPy. Rephrase and clarify 'reconstruct' perhaps. \r\n1. Last sentence. Is the performance recommendation **general** because it makes KT run robustly? Or because GPUs work best like that regardless?\r\n\r\n#### 27 Summary\r\n1. This summary contains information that has not been presented before, hence it is not a summary. Is guidelines a better name perhaps?\r\n1. **linkage** sounds abruptly technical. Do you have a better term/paraphrase for it?\r\n1. **on-the-fly wrapper generation** is obscure. Rephrase like _KT gives a limited support for wrapping templates on the fly with \\[specify what\\]_? \r\n1. Returning ambiguity of **template** and **host code** when explaining CuPy.\r\n1. Whose **templates** by the way?\r\n1. Note why, after having said (correctly) \"isolate device code from host code to simplify separate compilation\", **host code** has to be defined precisely each time to avoid confusion.\r\n\r\n### Grid and thread block dimensions\r\n\r\n#### 29 CUDA Thread Hierarchy\r\n1. Linguistic ambiguity in **fixed-sized blocks**. Don't we tune their size in fact (see slides 30, 32)? Are they fixed as machine presets by the vendor? Are they fixed at compile-time by the user? Hint: use 'set' instead of 'fix'?\r\n\r\n#### 31 Why do thread block....\r\n1. Opt for writing either **threads block** or **thread block** all over the document.\r\n1. SMs. If the independence is **full**, it sounds odd that they **contain** \"thread block slots\", which relate to the super-unit of the SMs themselves. \r\n1. What do you actually mean with **independence**? In the sequel you play around with the threads: perhaps with their independence too? The wording has a bearing on the content to come.\r\n1. What should a learner think of when reading **slots**?\r\n\r\n#### 32 Specifying thread block dimensions...\r\n1. **`params`** is a new variable name; is this a reserved KT word or a generic placeholder for something else that is left unspecified?\r\n1. Can you make a little space in the slide to illustrate the usage of **`block_size_name`**?\r\n \r\n#### 33 Specify thread block...\r\n1. What kind of **access** action do you have in mind? I feel you mean you 'set' them up here and not that you 'get' them.\r\n1. **compile-time sizes multi-dimensional data** is cryptic and perhaps ungrammatical. Did you mean that the compiler reserves the shared memory based on the block dimensions, or something like that?\r\n\r\n#### 36 Specifying grid dimensions\r\n1. **`problem_size`** is an important positional argument and is not explained clearly here. \"Describes the dimensions across which threads are created\" is very generic: the drawing also suggests that `problem_size` is the size of the grid used to process the input data, which is more tangible. Please rephrase.\r\n1. Make the distinction between data input size and `problem_size` clear.\r\n\r\n#### 37 Grid divisor lists\r\n1. This topic is unclear.\r\n1. Since this is an optional argument, you should first mention what its default value is and means. As a learner I wonder why I would ever need to disable this optional feature in the first place. \r\n1. I would use **optional argument** instead of **optional parameter** for global consistency.\r\n1. This slide breaks the reading flow because it splits apart two slides on the same topic `problem_size`. Please swap with 38.\r\n\r\n#### 38 `problem_size`\r\n1. **'use strings'** sounds like a shorthand for defining a dictionary key. This uncertainty is compounded with the fact that you have not introduced `tune_params()` in/around slide 23.\r\n1. The last code line is an illustration of `grid_div_x` but is unclear for the same reasons as slide 37.\r\n1. What is `reduction.py`? What makes this new entity relevant for this slide? Unclear for the learner.\r\n\r\n### User-defined metrics\r\n\r\n#### 41 User-defined metrics\r\n1. Code. What is the variable (dictionary key, I presume) **`p`**? Is it a shorthand that the instructors use just in these slides, or always in KT? Is it a shorthand that the learners can use too without further caution? This returns later in slide 90.\r\n\r\n---\r\n## GPU Optimization and the Search Space\r\n\r\n#### 44 Title slide\r\n1. **Search-Space Restrictions** is fairer to the content and gives the title more balance.\r\n1. Recalling the remark on slide 10, I would still speak of **design space restrictions** since no search is in order here, because we are still optimizing the GPU performance by code manipulation.\r\n1. Are these operations really **optimisation** in the sense that will be invoked soon? For example, are we minimising a cost function? Is **accelerating** maybe a better term? \r\n\r\n#### 45 GPU code optimization\r\n1. I suggest this order for the bullet points: 2-1-3-4. The notion of **tunability** is new and needs to be introduced as some kind of ease at tuning things.\r\n1. Note the use of **parameters** here as distinct from the **arguments** for the KT calls. While conventional, this distinction helps separate two contexts in these slides.  \r\n\r\n#### 46 Overview of GPU Optimizations\r\n1. The link to the paper https://dl.acm.org/doi/full/10.1145/3570638 would be timely here; you give it later on the second training day.\r\n\r\n#### 48. (Partial) Loop Unrolling\r\n1. The **partial** in the slide title is not explained in the slide body. So remove it if it is not essential because it creates a false expectation for detail.\r\n1. **Code generator** and **compiler** appear to be two different things, even though compilers are about code generation. Possible confusions should be forestalled; see also slide 9.\r\n1. What is the practical difference between **not allowed** and **disabled** in the explanation of `#pragma unroll \u003cvalue\u003e`?\r\n1. Clear that KT inserts parameters with `#define`. But should it be **remembered** because it has been noticed before (where?) or because it is important information in itself? In the latter case, slide 33 already touches upon `#define` in KT. So closing the topic of passing parameters there makes the story line more compact.\r\n1. Understanding the handling of `loop_unroll_factor_` still requires substantial reflection. To connect with previous lines, that must be a variable of type integer, so it ought to be declared earlier. But the example in the following slide does not show an assignment line and does not comfort that expectation. There, the loop variable `k` has been appended to the name `loop_unroll_factor_`, but this construction could be presented more orderly. This topic needs to be rephrased.\r\n1. And **what** is **unrolling** in the first place? You correctly focus on why and how, but the what-question is important to the learners too.\r\n\r\n#### 49 Partial loop unrolling\r\n1. This loop unrolling sounds as though it is really **partial** because the latter word is not between parentheses in the slide title. But this partial quality has not been explained or indicated either here or in slide 49.\r\n1. Bring the note on `loop_unroll_factor_k` to the top of the slide or to the previous slides for compactness?\r\n1. This slide, unlike the following one, does not show a baseline code and a modified code. That would be useful here too.\r\n \r\n#### 50 Reducing register usage\r\n1. Why? I doubt that a limited resource limits occupancy. I suggest **saturate** occupancy instead.\r\n1. How? **Compiling** is an operation of creating executable files from source code, while **keeping values in register** is an operation of memory management. Doing the one \"rather than\" other sounds like mixing apples and pears: how the one is an alternative to the other is unclear in the first place. Do you perhaps mean that you'd better set the constant values at compile-time rather than as tunable parameters in a template? Would that imply the message 'do not tune too much'?\r\n1. How? Note the ambiguity of **templates**. Do you mean the templates of KT, which normally works with tunable parameters? Or templates of another kind and origin? (Incidentally, to repeat as hangover cure, a clear terminology seems to go like the tunable _parameters_ are an _argument_ of KT _methods_.)\r\n1. How? **Limiting and disabling loop unrolling** was the technique to speed up computing shown in the previous slides. So that technique has an important counterproductive effect, which could have been highlighted early in slide 48 as one more bullet point.\r\n\r\n#### 51 Reducing register usage\r\n1. `block_per_sm` is a new, unexplained variable.\r\n1. You could refer to these two code snippets as 'baseline' and 'variant' for example, and use this glossary everywhere else to direct the attention of the learners where the focus is.\r\n\r\n#### 52 Varying work per thread\r\n1. Title. Is the proposed strategy about **varying** (up and down, as in the slide title) or only increasing (up, as in the slide body)? In the latter case there is no need make things in the title vaguer. The stress question is whether one should increase the work per thread to obtain a reduction of data reuse and locality; the correct terminology follows from the answer.\r\n \r\n#### 53 Varying work per thread\r\n1. Introduce which calculation we are working with here. To me this looks calculating a single entry in a product matrix.\r\n1. Introduce why `#pragma roll` is relevant here, all the more because it is a technique already explained (although you did not say _what_ that does).\r\n1. The name `global_size_x` in the picture is new. Previously the same object was named `problem_size[0]`. Please link the two notions or use a consistent terminology.\r\n1. Explain that we increase the work per thread by borrowing values from other blocks, if I understood the code snippet correctly.\r\n\r\n#### 54 Vectorization\r\n1. The **what** question is lacking. Add one line saying what a **vector** is in computing. I presume that presenting it from the hardware perspective is better. The term has widely different interpretations across disciplines.\r\n1. Why? Explain with a short phrase what **memory throughput** is. Specifying the units of measurement can help to the same effect.\r\n1. How? The points are short and cryptic. The question **how** can cover two kinds of answers interesting to the learners: (1) How the user writes the code to reap that benefit; (2) How the computer implements that technique. It would be nice that the instructors hint at both. This suggestions on the how-question applies to the previous slides on the other techniques.\r\n\r\n### Output verification\r\n\r\n#### 56 Programming tunable application\r\n1. **Source** is ambiguous. I presume you mean the **source code**. Is this a viable rephrasing? _Tunable source code lets you maintain in a single document many different versions of the same program_ or _Tunable parameters lets you maintain in a single source code many different versions of the same program_.\r\n\r\n#### 57 Output verification\r\n1. Inform first that **`answer`** is an optional argument of KT.\r\n1. **Reference** can have a special meaning in programming and create confusion (for example, with the instructors as they speak freely about coding). As alternative I suggest **baseline**, **touchstone**, **yardstick**.\r\n1. **Benchmarking** becomes ambiguous and confusing here. Returning issue. Do you understand benchmarking as the operation of assessing the _correctness_ of a calculation or the operation of _measuring_ its performance? The phrase **before benchmarking** muddles what happens when.\r\n1. Why is KT running the kernel just **once** here? Take note that benchmark as in ground-truth value returns in slide 65 (on caching).\r\n1. Note that `answer` is a set of kernel arguments and cannot be compared with an output, unless you say earlier that the baseline results are passed as an item of `answer`.\r\n1. Are the kernel arguments that don't need verification always the input data? In that case you could simply say that we use `None` for the kernel input arguments.\r\n1. In the nested list, the order should be 1,2,4,3 so that all items about `answer` come one after another, and the subtopic is rounded up neatly.\r\n\r\n#### 58 Simple answer example\r\n1. `answer=answer` works but can cause confusion, surely when the instructors speak during the training. I propose something like `answer=baseline`, where the optional argument and the variable have different names. This guideline is already applied in slide 62 to a clean effect.\r\n\r\n### Search space restrictions\r\n\r\n#### 61 Dependent parameters example\r\n1. Title. What do **dependent** parameters depend on here? What explains the dependence in point? Recall that dependent variable has a mathematical ring to it that the learners are probably more familiar with.\r\n1. Consider simplifying the last sentence into _blocks do not contain more than 512 threads each_?\r\n\r\n### Caching tuning results\r\n\r\n#### 64 Caching\r\n1. Recall that the learners may be more familiar with the other meaning of **cache**, as in memory hierarchies. Please reassure that caching = saving = backing up here.\r\n1. I suggest the consistent usage of 'optional argument' for **option**.\r\n1. The ambiguity of **benchmarking** strikes again here, since it could mean either the comparison with a reference simulation (validation language) or the measure of performance in executing a configuration of the kernel (profiling-like language). At this point of the slide set, we have spoken of both meanings.\r\n\r\n#### 68 Performance portability\r\n1. 'The property that...' is unfinished writing. I suggest something like _An application with similar performance on different hardware is said to be portable_.\r\n1. **Application** is a new salient word showing up here. You have already used code or program in a similar sense, I think. So, if there is no purpose in introducing this new term in a special sense, I would stick to code or program.\r\n1. In 'we select a kernel based on...' I have that impression that you just select a kernel **configuration** and you do not pick up a new kernel.\r\n1. The missing word is in parenthesis here in \"can be done (at) compile-time or run-time\".\r\n1. 'earlier obtained tuning results' -\u003e 'tuning results obtained earlier'.\r\n\r\n#### 69 store_results\r\n1. **Function** is better described as a 'method' in this Python-savvy context.\r\n1. Write **`store_results()`** with empty arguments to underline this is a method, as already done in slide 23, for example.\r\n1. Because of a muddled order of presentation, it is unclear that **`env`** is an optional argument of KT, while that new item could be usefully introduced here.\r\n1. Take note that **`problem_size`** returns here. Defining it more clearly above pays off in the long run.\r\n\r\n#### 70 Compile-time kernel selection\r\n1. Are you **selecting a kernel** here, actually? It all looks like you are primarily selecting the GPU you run the kernel on and, hence, just an optional argument or a configuration parameter of the same tunable kernel.\r\n1. **Host** and **application** are both prone to ambiguity. What is the **host application** here? (a) the Python script calling KT? (b) the original code from which one has to isolate the kernel each time, according to the best practice you suggested from the start?\r\n\r\n#### 71 Compile-time kernel selection example\r\n1. **`create_device_targets()`** is a new method that deserves an introduction, at this time lacking.\r\n\r\n#### 76 Compile-time kernel selection example\r\n1. First appearance of **make**. Many users may know what a Makefile does but not how it works. And some may compile the code from the command line without make. Please consider a new line of text that explains whether the snippet underlines that make is necessary (because it does something irreplaceable) or that we need to add to the compiler nvcc some specific flags (options, by the way). \r\n\r\n#### 77 Run-time kernel selection\r\n1. That the programming language of the **host application** can vary is breaking news here. If the host application is KT, then its language is not just Python, as said earlier in slide 22. If the host application is where the kernel was embedded originally, its language should not be relevant any longer, because you recommend to move the kernel into a Python script. It looks like the story line of the slides has a hiccup here. Please repair.\r\n\r\n#### 78 Run-time kernel selection in Python\r\n1. Comment on (and/or highlight) which code lines are the same as in the compile-time selection, and which are specially edited to implement the run-time selection instead.\r\n1. **\"Python host application\"** is clear here, and is an example of the clarity that can be achieved elsewhere. \r\n1. Spend a line to explain the new feature **`kernelbuilder`** you import.\r\n2. In the **`PythonKernel()`** call, do the names belong to the arguments or to argument instances? To present the argument names like in the API manual, you could use a commented line before the call. As a learner, I want the example to continue at the same level of detail as the other snippet at the top of the page.\r\n\r\n#### 79 Run-time kernel selection in C++\r\n1. Using KT from **C++** has not been announced earlier and falls in like a completely new possibility. If I got this point right, this capability should be announced earlier among the general features of KT, while here you should explain in a few lines what one should take notice of in the slide.\r\n1. Who/what \"uses Kernel Laucher header-only C++ library\"? \r\n\r\n### Optimization strategies\r\n\r\n#### 81 Large search space of ...\r\n1. Same remark on the graph as in slide 10. That design space now becomes a search space, in my view.\r\n\r\n#### 82 Optimization strategies in Kernel Tuner\r\n1. This slide could be merged with slide 85 below. This looks like an open-ended list, while the implementations in KT, as expected from the title, are set and given, I presume.\r\n\r\n#### 83 Speeding up auto-tuning\r\n1. Is the time in the ordinates the time that each optimization strategy took to find the best performing configuration already found by the brute-force approach? \r\n1. In other words, do the GFLOPS/s refer to (a) the best performing configuration picked by each optimisation strategy?; (b) the time consumed by the optimisation strategy to find the brute-force configuration? The question arises insofar optimisation strategies approximate the outcome of brute-force auto-tuning.\r\n\r\n#### 84 Your mileage may vary\r\n1. Unravel GEMM please.\r\n\r\n#### 85 How to use a search strategy\r\n1. A **basinhopping** should be split basin hopping.\r\n1. Is **basin hopping** a local optimisation method as I glimpse here, or a global optimisation method as I glimpse in slide 82?  \r\n1. **`tune_kernel()`** with empty arguments will show it is a method.\r\n\r\n### Observers\r\n\r\n#### 87 Observers introduction\r\n1. Whose **behavior**? \r\n1. Is **benchmarking** here tuning or validating? Known linguistic vulnerability.\r\n\r\n#### 88 Observer base class\r\n1. Same potential ambiguity with **benchmarking** in `def get_results(self)`. I am afraid that this linguistic vulnerability may affect the software documentation.\r\n\r\n#### 90 NVMLObserver example\r\n1. See remark on ***`p`*** in slide 41.\r\n\r\n---\r\n## Closing Remarks\r\n\r\n#### 94 Learning objectives\r\n1. Same remarks as slide 6.","author":{"url":"https://github.com/wmotion","@type":"Person","name":"wmotion"},"datePublished":"2024-09-20T09:59:53.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/1/kernel_tuner_tutorial/issues/1"}