ADSP Episode 124: Vectorizing std::views::filter

Sdílet
Vložit
  • čas přidán 6. 04. 2023
  • This is a video version of ADSP podcast Episode 124. We talk about vectorizing std::views::filter.
    ADSP Link: adspthepodcast.com/
    Follow me on Github: github.com/codereport
    Follow me on Twitter: / code_report
    Follow me on LinkedIn: / codereport
  • Věda a technologie

Komentáře • 14

  • @juliendebache4965
    @juliendebache4965 Před rokem +9

    "Forget that I said monad" should be the official motto of functional programmers :D

    • @pmcgee003
      @pmcgee003 Před rokem +2

      Specifically at 23:30 Bryce did not say 'monad' 🙂

  • @jamesb43
    @jamesb43 Před 7 měsíci

    The language proposal was worth the price of admission. The format was great for youtube! I appreciated the aim of not making the assembly anymore cognitively taxing than necessary.

  • @firesoul453
    @firesoul453 Před rokem

    Oh these are on CZcams!

  • @Roibarkan
    @Roibarkan Před rokem +1

    I think the various algorithms that end with _if might be a good approach for doing the types of operations that Bryce was talking about, I think something like transform_if(range, operation, predicate) would be a good approach for this specific case, and potentially one can also 'zip' a boolean with members in order to perhaps be more composable, so potentially one can imagine something like "range | zip_with_func(predicate) | transform([](auto pair) {return pair.second? Op(pair.first) : nulopt;})" to achieve what Bryce intended.
    zip_with_func(op) is a potential adapter that is something like "range | transform([](auto x) {return make_pair(x, op(x)) ;})"

  • @VincentZalzal
    @VincentZalzal Před rokem +2

    I have mixed feelings about C++ ranges, so I would have a tendency to be on Bryce's side and prefer vectorizable code. However, that motivating example was indeed not convincing, as it is not a filter, it is a transform, so I vote for Conor :) If I understand correctly, another way of summarizing Bryce's point is: to have vectorizable code, use masking instead of filtering.
    But I have to agree that there are problems where masking won't be enough. Let's say you want to do some operation on consecutive elements after filtering, like adjacent_difference, how would you do that with masking?

  • @Jswalden86
    @Jswalden86 Před rokem +1

    TIL by unavoidable necessity that there's a video feed for the podcast 😅

  • @VincentZalzal
    @VincentZalzal Před rokem +1

    Question for Conor: what's the array languages solution that you hinted at in the beginning? Is it masking, i.e. generating an array of 0s and 1s the same size as the original?
    Also, about the format: this is ok for CZcams, but not ok for a podcast.

  • @Roibarkan
    @Roibarkan Před rokem

    26:59 Being “a loop optimizer compiler person”, I wonder why Bryce doesn’t file bug reports for compiler implementers, asking for better loop-fusion code. After all, as far as I see it, the major programming paradigm innovation of nvidia is the notion of SIMT (instead of SIMD) - where code that looks like threads with if-statements got converted by compiler+runtime to SIMD with predicates.

  • @RishabhRD
    @RishabhRD Před rokem +4

    His for each filter_o example was really not motivating😂

  • @MiiaoTheFC
    @MiiaoTheFC Před rokem

    Still waiting for solution videos…

  • @bzboii
    @bzboii Před rokem

    lmaooo could use some motivating examples

  • @Roibarkan
    @Roibarkan Před rokem

    Arno schodl had a talk a while back about an “external iteration“ model for composable ranges, which I think might lend itself to vectorization in cases such as ones described here. czcams.com/video/P8VdPsLLcaE/video.html