4 ms·

A glance at the source quickly reveals an unsafe implementation.

• codygman 12y ago
  I didn't see an import for unsafe or foreign in: fannkuch-redux pidigits binary-trees
  • jakevn 12y ago
    fannkuch-redux heavily utilizes unsafe operations on a mutable vector. binary-trees uses artificial strictness for the sake of the benchmark. Nine of the ten Haskell implementations are demonstrations of writing C in Haskell (without reaching C's performance).
    • imanaccount247 12y ago
      >fannkuch-redux heavily utilizes unsafe operations on a mutable vector. They are just not bounds checked. That is not "writing C in Haskell". >binary-trees uses artificial strictness for the sake of the benchmark What on earth is "artificial strictness"? Forcing evaluation when you need something to be evaluated immediately is not artificial, not unidiomatic, and not "writing C in Haskell". >Nine of the ten Haskell implementations are demonstrations of writing C in Haskell And end up shorter than rust? The idea that writing lower level code is "writing C in haskell" is nonsense, the ability to write more verbose but faster code is not harmful, it is useful. But the fact that lower level haskell is still shorter than rust and yet you want to act like it is some sort of horrible thing makes it hard to believe that you are really concerned about the horrors of writing slightly more verbose code.
      • jakevn 12y ago
        The Rust code is both safer and faster at the cost of more keystrokes. I'm not certain the point of writing unsafe code in Haskell when there are better tools for the job. Haskell is fast enough as is and using it to hammer screws just reeks of wrong tool for the job.
        • imanaccount247 12y ago
          Your comment says absolutely nothing, and that appears to be the goal. What is the point of writing any code in any language? It is a benchmark, the point of it is to write the fastest code you can. You aren't obligated to write lower level code in haskell, nobody has a gun to your head. So why do you pretend it is a problem, and claim other languages are "better tools" for that job despite haskell clearly being very good at that job?
          • igouy 12y ago
            >>It is a benchmark, the point of it is to write the fastest code you can.<< The point of it is to show the performance differences, but that doesn't exclude a program like -- http://benchmarksgame.alioth.debian.org/u64q/program.php?test=meteor&lang=ghc&id=4 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... -- or like -- http://benchmarksgame.alioth.debian.org/u64q/program.php?test=spectralnorm&lang=ghc&id=2 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... etc
            • imanaccount247 12y ago
              It doesn't exclude "idiomatic" versions, but the data is presented so as to make them useless. How do I compare "idiomatic" rust to "idiomatic" haskell? All you can get is "here's the fastest versions from each language". If you want to compare any other version you have to do it on an individual basis, one at a time. So there's absolutely no reason for people to bother adding "idiomatic" versions.
              • igouy 12y ago
                "Idiomatic" in whose opinion? "Idiomatic" is a slogan not a well-defined property. The reason for people to bother adding "idiomatic" versions, is that other people really do work through looking at the source code "on an individual basis, one at a time."
                • platz 12y ago
    • codygman 12y ago
      > binary-trees uses artificial strictness for the sake of the benchmark Using strict evaluation when appropriate is most certainly idiomatic Haskell code. > Nine of the ten Haskell implementations are demonstrations of writing C in Haskell (without reaching C's performance). This (C in Haskell accusation) is debatable, though I'm not sure there's much to be gained even given a totally successful discussion where we both communicate our points 100% effectively.
      • jakevn 12y ago
        There probably isn't a point to it, as we're likely trying to argue different points. I posit that using Haskell in such a way is a disservice to the language. If you want to code in such a way, why use Haskell? Haskell is plenty fast as is and doesn't need to resort to unsafe code. What's the point?
        • tel 12y ago
          Mutability and strictness aren't a disservice to Haskell. They're both considered to be things which are available as choices and should be taken when needed. In particular, the entire ST monad is all about mutability and is very well behaved. Furthermore, even if you write nearly everything in the IO monad Haskell you'll gain a lot from the type system and from easily peeling out small, meaningful pure segments.