5 ms·

The make errors are a bit weird because the programs build on my machine no problem. In parts haskells slowness seems to be because no one cares enough to work

by Tarean 9y ago

The make errors are a bit weird because the programs build on my machine no problem. In parts haskells slowness seems to be because no one cares enough to work on it. Can't say for sure, though, so maybe I just should try a task and implement it to see how fast it'd be without amazing optimization foo. Although of course these benchmarks aren't really representative of the real world because they'd just end up as a c ffi call in most languages if they actually were that performance critical.

delhanty 9y ago
I agree with all that, particularly the bit about the c ffi call. It's more relevant to compare Rust with C and C++, as Rust is a language that could reasonably display C for the ffi call. But then remember that @wyager is claiming >80% as fast as hand-optimized C for only 10% of the effort of hand-optimized C If it's really only 10% of the effort then one shouldn't really have "to work on it" to get semi-decent performance. A more modest claim of say: 50% as fast as hand-optimized C for only 20% of the effort of hand-optimized C would have been more credible and still a big win for many use cases.
- Tarean 9y ago
  Tried my hand at the knucleotide[1] one. Lifted the algorithm from the fastest rust solution. As optimization I dropped some Unpack pragmas and strictness annotations, used Data.Hashtable.Cuckoo for in-place updating hash tables because that seemed necessary for the task, and added naive parallelization via let outputs = map (exec content) tasks `using` parList rseq That got around 24 seconds which seems acceptable for a fairly straightforward solution that is around half the size of the rust one I copied. Might try to optimize later. [1]: http://benchmarksgame.alioth.debian.org/u64q/knucleotide.html http://benchmarksgame.alioth.debian.org/u64q/knucleotide.htm...
  - igouy 9y ago
    http://benchmarksgame.alioth.debian.org/play.html http://benchmarksgame.alioth.debian.org/play.html
igouy 9y ago
That pi-digits program does not "build on [your] machine no problem". It cannot. The line "main = putStr.pidgits.read.head =<< getArgs" has been commented out because the program author has optimised-away some of the work that must be done.
- Tarean 9y ago
  Fair enough, I only checked the two knucleotide programs which both failed because of missing dependencies.
igouy 9y ago
>> The make errors are a bit weird because the programs build on my machine no problem. << My fault (except for pi-digits and regex-redux). I neglected to work-through the force-reinstalls that inevitably follow my update of the GHC compiler. Done.

by Tarean 9y ago

delhanty 9y ago

I agree with all that, particularly the bit about the c ffi call. It's more relevant to compare Rust with C and C++, as Rust is a language that could reasonably display C for the ffi call. But then remember that @wyager is claiming >80% as fast as hand-optimized C for only 10% of the effort of hand-optimized C If it's really only 10% of the effort then one shouldn't really have "to work on it" to get semi-decent performance. A more modest claim of say: 50% as fast as hand-optimized C for only 20% of the effort of hand-optimized C would have been more credible and still a big win for many use cases.

Tarean 9y ago
Tried my hand at the knucleotide[1] one. Lifted the algorithm from the fastest rust solution. As optimization I dropped some Unpack pragmas and strictness annotations, used Data.Hashtable.Cuckoo for in-place updating hash tables because that seemed necessary for the task, and added naive parallelization via let outputs = map (exec content) tasks `using` parList rseq That got around 24 seconds which seems acceptable for a fairly straightforward solution that is around half the size of the rust one I copied. Might try to optimize later. [1]: http://benchmarksgame.alioth.debian.org/u64q/knucleotide.html http://benchmarksgame.alioth.debian.org/u64q/knucleotide.htm...
- igouy 9y ago
  http://benchmarksgame.alioth.debian.org/play.html http://benchmarksgame.alioth.debian.org/play.html

igouy 9y ago

That pi-digits program does not "build on [your] machine no problem". It cannot. The line "main = putStr.pidgits.read.head =<< getArgs" has been commented out because the program author has optimised-away some of the work that must be done.

Tarean 9y ago
Fair enough, I only checked the two knucleotide programs which both failed because of missing dependencies.

igouy 9y ago

>> The make errors are a bit weird because the programs build on my machine no problem. << My fault (except for pi-digits and regex-redux). I neglected to work-through the force-reinstalls that inevitably follow my update of the GHC compiler. Done.