Announcement

Collapse
No announcement yet.

Futhark: A Pure, Functional Language For GPU Computing

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Futhark: A Pure, Functional Language For GPU Computing

    Phoronix: Futhark: A Pure, Functional Language For GPU Computing

    Futhark was presented earlier this month at FOSDEM as a "purely functional array language" with its compiler able to "efficiently generate high-performance GPU code."..

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    See, this is what people should be working on - we need to see things that take advantage of existing languages and ABIs/APIs, rather than find a slightly varying (yet backward-incompatible) approaches that just add unnecessary fragmentation. If this was "yet another standalone language+compiler to write GPGPU applications" I'd be pretty annoyed.

    I'm tired of seeing languages pop up that could easily be replaced by a library for another language (like Vala), or languages that seem to have no advantage over any other except a well-made compiler (like Rust or Go), or languages that will likely never see any real-world adoption despite their ambitions (like Dart). I don't really like languages that are platform-specific either (like Swift) but at least they have specific benefits that other languages may not offer for their specified platform.
    The ideas and time spent developing these languages could've been used to improve existing ones. One of the reasons I like Python is because instead of people trying to create their own slightly tweaked version of it, people write their own interpreters for it instead. Different interpreters have different pros and cons over alternatives, so it allows people to stick with what they know and/or use the same code they've always been using, but can completely change the outcome of their programs. In other cases, some people write their own libraries that act as better or more advanced alternatives to the stock ones. This just makes life easier and keeps the community strong and growing.
    </rant>
    Last edited by schmidtbag; 15 February 2017, 11:38 AM.

    Comment


    • #3
      Originally posted by schmidtbag View Post
      See, this is what people should be working on - we need to see things that take advantage of existing languages and ABIs/APIs, rather than find a slightly varying (yet backward-incompatible) approaches that just add unnecessary fragmentation. If this was "yet another standalone language+compiler to write GPGPU applications" I'd be pretty annoyed.

      I'm tired of seeing languages pop up that could easily be replaced by a library for another language (like Vala), or languages that seem to have no advantage over any other except a well-made compiler (like Rust or Go), or languages that will likely never see any real-world adoption despite their ambitions (like Dart). I don't really like languages that are platform-specific either (like Swift) but at least they have specific benefits that other languages may not offer for their specified platform.
      The ideas and time spent developing these languages could've been used to improve existing ones. One of the reasons I like Python is because instead of people trying to create their own slightly tweaked version of it, people write their own interpreters for it instead. Different interpreters have different pros and cons over alternatives, so it allows people to stick with what they know and/or use the same code they've always been using, but can completely change the outcome of their programs. In other cases, some people write their own libraries that act as better or more advanced alternatives to the stock ones. This just makes life easier and keeps the community strong and growing.
      </rant>
      The existing approaches have failed. The market is dominated by proprietary CUDA and no, there is no way to get around it in so many cases. If there is anything new that may hopefully gain more traction to overcome to horrible current situation, then it is worth supporting it.

      Comment


      • #4
        Originally posted by Kemosabe View Post
        The existing approaches have failed. The market is dominated by proprietary CUDA and no, there is no way to get around it in so many cases. If there is anything new that may hopefully gain more traction to overcome to horrible current situation, then it is worth supporting it.
        I completely agree. Just to clarify, I'm in favor of Futhark, and the success of OpenCL.

        Comment


        • #5
          The headline is wrong. It is not a language that is pure and also functional, it is a language that is purely functional. There is a major difference between those two things: the first sounds good but doesn't mean anything, and the second means it's programs are entirely built from functions that have no side effects.

          Comment


          • #6
            Anyone who thinks CUDA has the momentum over OpenCL is blind to a fault. Remind yourselves all about Java and its current dominance. What? What's that? It's nearly extinct? Yep.

            Comment


            • #7
              Originally posted by Marc Driftmeyer View Post
              Anyone who thinks CUDA has the momentum over OpenCL is blind to a fault. Remind yourselves all about Java and its current dominance. What? What's that? It's nearly extinct? Yep.
              http://spectrum.ieee.org/computing/s...ming-languages

              http://blog.codeeval.com/codeevalblo...guages-of-2016

              I don't know if you're a troll or not, but Java doesn't look that extinct to me...

              Comment


              • #8
                Originally posted by schmidtbag View Post
                See, this is what people should be working on - we need to see things that take advantage of existing languages and ABIs/APIs, rather than find a slightly varying (yet backward-incompatible) approaches that just add unnecessary fragmentation. If this was "yet another standalone language+compiler to write GPGPU applications" I'd be pretty annoyed.

                I'm tired of seeing languages pop up that could easily be replaced by a library for another language (like Vala), or languages that seem to have no advantage over any other except a well-made compiler (like Rust or Go), or languages that will likely never see any real-world adoption despite their ambitions (like Dart). I don't really like languages that are platform-specific either (like Swift) but at least they have specific benefits that other languages may not offer for their specified platform.
                The ideas and time spent developing these languages could've been used to improve existing ones. One of the reasons I like Python is because instead of people trying to create their own slightly tweaked version of it, people write their own interpreters for it instead. Different interpreters have different pros and cons over alternatives, so it allows people to stick with what they know and/or use the same code they've always been using, but can completely change the outcome of their programs. In other cases, some people write their own libraries that act as better or more advanced alternatives to the stock ones. This just makes life easier and keeps the community strong and growing.
                </rant>
                It is another language/dsl whatever you like to call, there are plenty of that targenting gpus, cpus, some even promises MPI parallelization, many of them a lot more practical, better yet less inconvenient, to be used, for instance



                High-level framework for stencil computations. Contribute to naoyam/physis development by creating an account on GitHub.



                not to mention openMP/openACC and others vendor specific directives

                and the list goes on
                Last edited by defaultUser; 15 February 2017, 02:57 PM.

                Comment


                • #9
                  Originally posted by Kemosabe View Post

                  The existing approaches have failed. The market is dominated by proprietary CUDA and no, there is no way to get around it in so many cases. If there is anything new that may hopefully gain more traction to overcome to horrible current situation, then it is worth supporting it.
                  CUDA is dominant only on HPC/industrial sectors, for consumer oriented programming, think image/video editing/compositing , openCL is very common due to the need of supporting Apple computers and smartphones.

                  Comment


                  • #10
                    A bit of trivia for those that don't know: "Furthark" is a common name of the pseudo-alphabet of ancient germanic runes It's named that way because that's just the first few runes in it: "F" "U" "TH" "A" "R" "K"

                    Comment

                    Working...
                    X