7 comments

  • 6r1724 minutes ago
    My heard hurts - i was stupid enough to think that SIMD was a CPU only thing - I don't understand why it would be ported to GPU - huge kudos to managing to surprise me
    • chlorion1 minute ago
      GPUs work on vectors and matrices very often, that's what they are good at, so it makes a lot of sense that they can operate with SIMD I think!
    • hingler3615 minutes ago
      Welcome to the lucky 10,000! SIMD is actually a pretty integral part of how GPUs are able to work efficiently, it's part of why there's such a strong focus on branchless programming in the field.
  • LegNeato43 minutes ago
    Author here, AMA.
    • lbhdc16 minutes ago
      What is vectorware's business model? Are you planning to sell support/consulting to companies using your stack? Or are you looking to sell licenses to your tool? Or something else?
    • jcranmer36 minutes ago
      The post is kind of vague on the IR you're targeting. Can you give some examples of what the SIMD-ized IR looks like, and how it maps to the target PTX?
      • the__alchemist32 minutes ago
        I&#x27;m confused too. How does this fit between these approaches for paraellization:<p><pre><code> - CUDA kernels and Tiles (e.g. Cudarc, cuda-oxide, rust-gpu etc) - SIMD on the GPU. (E.g. as in the title...) - CPU SIMD using avx or SSE instructions (And probably thin wrappers for vectors so you can have sane syntax). Or the maybe-upcoming core simd which should abstract over architecture-specific instructions. Magic floats etc which do 4-16 computations at once, but are a bit clumsy to work with - Rayon thread pools - arbitrary parallel computations, including SIMD, one per CPU core. </code></pre> It looks like from the code samples like maybe a cleaner syntax for writing code on the GPU than CUDA kernels? E.g. without mucking with serialization, host and device by abstracting over it? And inspired by core::simd. (Good choice if so, in the interest of standardizing on syntax; I did this for my x86 SIMD vector&#x2F;quaternion lib as well)
    • lbhdc20 minutes ago
      This is really cool! It sounds like y&#x27;all have a compiler fork that you are using to make this work. I wanna tinker with this, is your compiler available?
    • guess__who41 minutes ago
      [flagged]
  • efnx59 minutes ago
    Congrats to the Rust-GPU folks! Nice to see the good work flowing.
  • rust-lang13 minutes ago
    Good job!
  • the__alchemist22 minutes ago
    Hey - this is probably off-topic&#x2F;meta, but what is going on with the comments here? Is it bots?
    • dev_l1x_be16 minutes ago
      No idea, but it seems HN needs POW challenges.
  • lx-user17 minutes ago
    [flagged]
  • guess__who41 minutes ago
    [flagged]
    • LegNeato37 minutes ago
      We never mention anything about superiority nor compare with other languages or programming models. This post is about making existing Rust CPU code work on the GPU.
      • guess__who34 minutes ago
        I can read between the lines and the sentiment is just to &#x27;show them the right way&#x27;.<p>HN people are too nice to acknowledge this. But deep down you know this is true.
    • extrem-RAM-shor21 minutes ago
      Rust is the best. No other language is fun enough to program.
    • kooi27 minutes ago
      Useless blabbering.<p>If you have real feedback, great, but it&#x27;s useless to rip on the hard work of others without it.
      • fire_wheel24 minutes ago
        I am rewriting some components in rust - I dont like such sentiment. It negatively impacts the community.<p>Rust is better in so many ways.
    • throwaway89434524 minutes ago
      I&#x27;m not a Rust user apart from an occasional toy program here and there, but you seem really triggered about a language that other people use. What&#x27;s the issue?
    • the__alchemist29 minutes ago
      I care because it means I can use this in a Rust program without a FFI barrier. Regrettably, we have built computing infrastructure as a society with many barriers; programming language is one.