HackMD
  • Beta
    Beta  Get a sneak peek of HackMD’s new design
    Turn on the feature preview and give us feedback.
    Go → Got it
      • Create new note
      • Create a note from template
    • Beta  Get a sneak peek of HackMD’s new design
      Beta  Get a sneak peek of HackMD’s new design
      Turn on the feature preview and give us feedback.
      Go → Got it
      • Sharing Link copied
      • /edit
      • View mode
        • Edit mode
        • View mode
        • Book mode
        • Slide mode
        Edit mode View mode Book mode Slide mode
      • Note Permission
      • Read
        • Only me
        • Signed-in users
        • Everyone
        Only me Signed-in users Everyone
      • Write
        • Only me
        • Signed-in users
        • Everyone
        Only me Signed-in users Everyone
      • More (Comment, Invitee)
      • Publishing
        Please check the box to agree to the Community Guidelines.
        Everyone on the web can find and read all notes of this public team.
        After the note is published, everyone on the web can find and read this note.
        See all published notes on profile page.
      • Commenting Enable
        Disabled Forbidden Owners Signed-in users Everyone
      • Permission
        • Forbidden
        • Owners
        • Signed-in users
        • Everyone
      • Invitee
      • No invitee
      • Options
      • Versions and GitHub Sync
      • Transfer ownership
      • Delete this note
      • Template
      • Save as template
      • Insert from template
      • Export
      • Dropbox
      • Google Drive Export to Google Drive
      • Gist
      • Import
      • Dropbox
      • Google Drive Import from Google Drive
      • Gist
      • Clipboard
      • Download
      • Markdown
      • HTML
      • Raw HTML
    Menu Sharing Create Help
    Create Create new note Create a note from template
    Menu
    Options
    Versions and GitHub Sync Transfer ownership Delete this note
    Export
    Dropbox Google Drive Export to Google Drive Gist
    Import
    Dropbox Google Drive Import from Google Drive Gist Clipboard
    Download
    Markdown HTML Raw HTML
    Back
    Sharing
    Sharing Link copied
    /edit
    View mode
    • Edit mode
    • View mode
    • Book mode
    • Slide mode
    Edit mode View mode Book mode Slide mode
    Note Permission
    Read
    Only me
    • Only me
    • Signed-in users
    • Everyone
    Only me Signed-in users Everyone
    Write
    Only me
    • Only me
    • Signed-in users
    • Everyone
    Only me Signed-in users Everyone
    More (Comment, Invitee)
    Publishing
    Please check the box to agree to the Community Guidelines.
    Everyone on the web can find and read all notes of this public team.
    After the note is published, everyone on the web can find and read this note.
    See all published notes on profile page.
    More (Comment, Invitee)
    Commenting Enable
    Disabled Forbidden Owners Signed-in users Everyone
    Permission
    Owners
    • Forbidden
    • Owners
    • Signed-in users
    • Everyone
    Invitee
    No invitee
       owned this note    owned this note      
    Published Linked with GitHub
    Like BookmarkBookmarked
    Subscribed
    • Any changes
      Be notified of any changes
    • Mention me
      Be notified of mention me
    • Unsubscribe
    Subscribe
    --- title: P1348 Discussion description: Issues and discussion pulled from the P1348 working paper during its creation in order to preserve a record of the discussions that took place. --- P1348 Discussion and Issue Tracking =================================== Allowing shape type to be not `size_t`? --------------------------------------- > [name=H. Lee Howes] Don't we want the shape type as the return value rather than size_t? > [name=David Hollman] The `shape_t` of the polymorphic executor is `size_t`, and we didn't introduce anything that resembles a polymorphic wrapper for a more general shape type (I think actually `executor_shape_t` is even required to be `size_t` for now, even in the non-polymorphic case.) > [name=Jared Hoberock] Yes, I think that's correct that `executor_shape_t<polymorphic-executor>` is `size_t`, so it would make sense to make the `polymorphic_query_result_t` be either `size_t` or just `executor_shape_t<polymorphic-executor>`. > [name=H. Lee Howes] Even if it is fixed it seems cleaner to make it dependent to make the reason for the fixed type clear. > [name=David Hollman] The problem is that `execution::executor<>` is a template, it's not clear that `executor_shape_t<executor<>>` means much, and `executor_shape_t<executor<maximum_occupancy_shape_t>>` seems a bit circular (and not all that helpful) "Resident" vs. "Simultaneously unblocked" ----------------------------------------- > [name=H. Carter Edwards] Maybe use the phrase "simultaneously unblocked" somewhere? "Resident" is not a term in the draft IS. The term "Active" is used: "active handler" and "active execution". "Block" is defined in 3.6 as "wait for some condition (other than for the implementation to execute the execution steps of the thread of execution) to be satisfied before continuing execution past the blocking operation". Perhaps keep it simple as "*simultaneously executing execution agents*" or "*concurrently executing execution agents*". The term "concurrently executing threads" is used in 6.8.2.2. > [name=Christian Trott] How about scheduled or active? Does the current P0443 allow suspension of execution agents (i.e. the equivalent of suspending a CUDA block, to get another one swapped in?). > [name=Lee Howes] I don't think it precludes swapping out - but at the same time this query is to give an estimate, and it could be estimating the number without any swapping out. So simultaneously scheduled might be viable wording. > [name=Christian Trott] The main use case for Sandia is unique resource aquisition (i.e. stuff akin to pre allocate a buffer per active execution agent) where at a minimum I need to know how much I need to pre-allocate. After that I could use a lock/unlock mechanism. If stuff gets swapped out though, this won't work. I still could use this estimate to implement a persistent kernel thingy though, by (as you guys indicated above) only asking for as many execution agents as can run simultanteously and then schedule work myself. > [name=Jared Hoberock] My preference would be to tie the normative description of this property to *execution agent lifetime*, which we were careful to define in the introductory material of P0443. We may as well use that definition. > [name=Carter Edwards] Concern with "lifetime" is that a blocked or context-switched execution agent is considered "alive" and we don't want to include such agents in the count. More strongly leaning to "concurrently executing execution agents" because it (1) must be alive and (2) must be executing which (should) mean not-blocked and not-context-switched. > [name=Jared Hoberock] I don't think we can use the word "concurrently" at all if we want this property to apply to weaker agents, which we do. > [name=David Hollman] @Christian, what do you mean by lock/unlock mechanism? I don't think anything passed to `bulk_execute` can do things like acquire a lock, since they're not guaranteed to be concurrent. The intention is that you would ask for this number and call `bulk_execute` yourself with that number, doing the chunking manually. > [name=Michael Garland] I tend to prefer the characterization focused on "active" or "hardware" contexts. This keeps the description close in spirit to `std::thread::hardware_concurrency`, which is the analogous precedent for something like this in the existing IS. > [name=David Hollman] @Michael :+1: > [name=Carter Edwards] Bulk execution doesn't prohibit the execution agent and invoked function object from being context switched or blocking. Let "Active" == "actively executing" == not blocked and not context switched? Or "Active" == active execution == actively consuming/occupying/... a hardware execution context? > [name=Michael Garland] That seems like an argument for focusing on "hardware" contexts or "physical" contexts or something of that nature. > [name=Carter Edwards] Vocabulary "occupy" is used for objects occupying storage/memory. Perhaps carry that term over to execution: an active execution agent occupies a hardware context, or an execution agent that is actively occupying a hardware context. So the term for the property is *maximum_occupancy_shape_t maximum_occupancy();* So NVIDIA picked the best words years ago... > [name=Lee Howes] This is not a concurrency guarantee. It is perfectly fine to launch based on this number and then be context switched out. I don't think we should have any wording that implies anything stronger than that. All this is is a capacity clue - some value that could in principle execute at once, utilising the full set of hardware resources and maximising performance, or as close a guess to that as is reasonable. Who is Driving -------------- > [name=Michael Garland] The draft says "should be passed to `bulk_execute` in order to drive the number of tiles". This seems like an incorrect characterization. It is the algorithm calling `bulk_execute` that is picking the number of tiles, not `bulk_execute` itself. And thus the algorithm that needs to tell `bulk_execute` how many tiles it wants to create. > [name=David Hollman] Yes, we need a better way to say something about the tiling. I agree that what we're querying is a value used to derive the tiling approach, not the tiling itself. How about something like "in order to, for instance, allow the algorithm to tile the work in a function passed to `bulk_execute`"? > [name=Michael Garland] Are we focusing specifically on the needs of parallel algorithms with this, or also trying to address some need of concurrent algorithms? > [name=David Hollman] I was focusing on the needs of the parallel algorithms specifically. Concurrent algorithms have to many other concerns. > [name=Michael Garland] Then I think it is reasonable to motivate this in the following way: We know that a general need of parallel algorithms is to decompose their work into tiles/blocks/pieces/whatever and that the choice of the number of tiles is a potentially important performance concern. This number provides guidance to the parallel algorithm calling `bulk_execute` to make an informed choice of what number of tiles they might want to use. > [name=David Hollman] @Michael, does the updated line 37 and the added line 53 address this concern? > [name=Michael Garland] I suggest something like this instead for line 37: > > _The intention is that the result of querying this property should be used to drive the decomposition of work into parts and passed to `bulk_execute` to specify the number of parallel agents needed._ > [name=David Hollman] :+1:, maybe s/specify/express/? > [name=Michael Garland] Either is fine, although I think "specify" is reasonable, because you're telling `bulk_execute` precisely how many agents it will create. It has no discretion to launch any other number. "Occupancy" instead of "coresidency" ------------------------------------ > [name=Carter Edwards] Vocabulary "occupancy" of execution agents with respect to execution context, mirrors vocabulary used for objects occupying storage. > [name=David Hollman] Is this w.r.t. the title? Does that change make more sense? > [name=carter edwards] "occupancy" instead of "coresidency" to leverage existing vocabulary, :-) circling all the way back to the beginning of discussion about "filling execution contexts" --- > [name=carter edwards] ... maximum number of execution agents that can occupy available execution contexts > [name=David Hollman] s/available/associated/? What is still missing from this paper? -------------------------------------- > [name=David Hollman] [time=Wed, Nov 7, 2018 3:34 PM] I want to keep the paper short if possible, and I think it's pretty close to done. How close are we to a point where we want to stamp out a revision and upload it to the wiki? > [name=Jared Hoberock] (copied from comments) I think the paper could probably be shortened further. I'll add some inline notes, feel free to take them or ignore. > [name=David Hollman] (copied from comments) Sounds good. Didn't realize the comment feature (here) was separate from the inline comment feature... Cutting the original first paragraph ------------------------------------ > [name=Jared Hoberock] Is this paragraph necessary? > [name=David Hollman] No, I think we can cut it. Wording Discussion ------------------ > [name=Jared Hoberock] "An optional query-only property" is redundant with the definition of `maximum_occupancy_shape_t` above. I think we can strike it. > [name=Jared Hoberock] Likewise, I think the final sentence of the above paragraph is redundant with other wording about how property queries are supposed to work. > [name=David Hollman] Is the optional part also redundant? > [name=Jared Hoberock] Yes, the optional part is redundant. All properties are optional. > [name=David Hollman] The last sentence is intended to address the difference from `std::thread::hardware_concurrency()`, which returns 0 when this happens. Maybe this should just be part of the note? > [name=David Hollman] Should we also say that the return must be nonzero? > [name=Jared Hoberock] I think saying the result is nonzero is useful. For the last sentence, my thinking was that if an executor can't provide an estimate, then it's obvious that they would not provide this query, and therefore `can_query_v` will be false. Discussion of Title ------------------- > [name=Jared Hoberock] I think a shorter title like "An Executor Property for Occupancy of Execution Agents" might seem less defensive :-) > [name=David Hollman] :+1: Agreed, and done. Any other thoughts by other authors? (For posterity, the old title was: "An Almost Trivial (But Vital) Extension to P0443 Providing a Property for Occupancy of Execution Agents") Should this be phrased as a diff to P0443r9? -------------------------------------------- > [name=Jared Hoberock] It might be most useful to present the proposed wording as a diff to P0443R9. Since this proposal is purely additive, that would mean indicating where in the `<execution>` synopsis it could go, and underneath which section the wording would be introduced. > [name=David Hollman] I'll ask Olivier what he prefers in this respect. It seems procedural. > [name=David Hollman] Olivier suggested we make it its own thing. It can still be part of r10 of executors (which will need to exist for wording purposes at the very least) Done ---- (for now) > [name=David Hollman] **The paper has been attached to the wiki**

    Import from clipboard

    Advanced permission required

    Your current role can only read. Ask the system administrator to acquire write and comment permission.

    This team is disabled

    Sorry, this team is disabled. You can't edit this note.

    This note is locked

    Sorry, only owner can edit this note.

    Reach the limit

    Sorry, you've reached the max length this note can be.
    Please reduce the content or divide it to more notes, thank you!

    Import from Gist

    Import from Snippet

    or

    Export to Snippet

    Are you sure?

    Do you really want to delete this note?
    All users will lost their connection.

    Create a note from template

    Create a note from template

    Oops...
    This template is not available.


    Upgrade

    All
    • All
    • Team
    No template found.

    Create custom template


    Upgrade

    Delete template

    Do you really want to delete this template?

    This page need refresh

    You have an incompatible client version.
    Refresh to update.
    New version available!
    See releases notes here
    Refresh to enjoy new features.
    Your user state has changed.
    Refresh to load new user state.

    Sign in

    Forgot password

    or

    By clicking below, you agree to our terms of service.

    Sign in via Facebook Sign in via Twitter Sign in via GitHub Sign in via Dropbox

    New to HackMD? Sign up

    Help

    • English
    • 中文
    • Français
    • Deutsch
    • 日本語
    • Español
    • Català
    • Ελληνικά
    • Português
    • italiano
    • Türkçe
    • Русский
    • Nederlands
    • hrvatski jezik
    • język polski
    • Українська
    • हिन्दी
    • svenska
    • Esperanto
    • dansk

    Documents

    Tutorials

    Book Mode Tutorial

    Slide Mode Tutorial

    YAML Metadata

    Contacts

    Facebook

    Twitter

    Feedback

    Send us email

    Resources

    Releases

    Pricing

    Blog

    Policy

    Terms

    Privacy

    Cheatsheet

    Syntax Example Reference
    # Header Header 基本排版
    - Unordered List
    • Unordered List
    1. Ordered List
    1. Ordered List
    - [ ] Todo List
    • Todo List
    > Blockquote
    Blockquote
    **Bold font** Bold font
    *Italics font* Italics font
    ~~Strikethrough~~ Strikethrough
    19^th^ 19th
    H~2~O H2O
    ++Inserted text++ Inserted text
    ==Marked text== Marked text
    [link text](https:// "title") Link
    ![image alt](https:// "title") Image
    `Code` Code 在筆記中貼入程式碼
    ```javascript
    var i = 0;
    ```
    var i = 0;
    :smile: :smile: Emoji list
    {%youtube youtube_id %} Externals
    $L^aT_eX$ LaTeX
    :::info
    This is a alert area.
    :::

    This is a alert area.

    Versions

    Versions and GitHub Sync

    Sign in to link this note to GitHub Learn more
    This note is not linked with GitHub Learn more
     
    Add badge Pull Push GitHub Link Settings
    Upgrade now

    Version named by    

    More Less
    • Edit
    • Delete

    Note content is identical to the latest version.
    Compare with
      Choose a version
      No search result
      Version not found

    Feedback

    Submission failed, please try again

    Thanks for your support.

    On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?

    Please give us some advice and help us improve HackMD.

     

    Thanks for your feedback

    Remove version name

    Do you want to remove this version name and description?

    Transfer ownership

    Transfer to
      Warning: is a public team. If you transfer note to this team, everyone on the web can find and read this note.

        Link with GitHub

        Please authorize HackMD on GitHub

        Please sign in to GitHub and install the HackMD app on your GitHub repo. Learn more

         Sign in to GitHub

        HackMD links with GitHub through a GitHub App. You can choose which repo to install our App.

        Push the note to GitHub Push to GitHub Pull a file from GitHub

          Authorize again
         

        Choose which file to push to

        Select repo
        Refresh Authorize more repos
        Select branch
        Select file
        Select branch
        Choose version(s) to push
        • Save a new version and push
        • Choose from existing versions
        Available push count

        Upgrade

        Pull from GitHub

         
        File from GitHub
        File from HackMD

        GitHub Link Settings

        File linked

        Linked by
        File path
        Last synced branch
        Available push count

        Upgrade

        Danger Zone

        Unlink
        You will no longer receive notification when GitHub file changes after unlink.

        Syncing

        Push failed

        Push successfully