3 ms·

You've made several comments here suggesting that GHC - pretty widely considered an extremely powerful compiler - is inferior to what Miranda offers. Can you su

by wk_end 7y ago

You've made several comments here suggesting that GHC - pretty widely considered an extremely powerful compiler - is inferior to what Miranda offers. Can you substantiate your claim that Miranda is faster than Haskell/GHC? FWIW, I just tried doing a very quick dumb benchmark - the classic functional pseudo-quicksort. GHC spit out a binary that can sort 10,000,000 numbers in a few seconds on my laptop. Miranda (after cranking up the heap size a couple orders of magnitude) took noticeably more time to sort only 1,000,000.

kick 7y ago
I promise I'll respond to this in the morning, I'm very tired right now and don't want to give a good and reasonable question an answer that hasn't been thought out well, especially given that my responses have been getting less detailed and concise as I've gotten more tired.
fanf2 7y ago
Oh wow, Miranda is still using an SK combinator reduction evaluator dating from 1986, in K&R C. It isn't even using supercombinators, which I read about in https://www.microsoft.com/en-us/research/publication/the-implementation-of-functional-programming-languages/ https://www.microsoft.com/en-us/research/publication/the-imp... Combinators are fun, but not very fast :-) https://dl.acm.org/doi/10.1145/800087.802798 https://dl.acm.org/doi/10.1145/800087.802798 http://ioccc.org/years.html#1998_fanf http://ioccc.org/years.html#1998_fanf
ncmncm 7y ago
Just for comparison, C++ running the shortest, simplest possible quicksort does 100,000,000 32-bit ints in 8s. Three more lines, and it's 3.4s. That's 1.3ns each time it looks at an element. So when you are already giving up an order of magnitude or two, another doesn't matter so much. It pays then to steer the conversation toward other merits.
- yatac42 7y ago
  > C++ and the shortest, simplest possible quicksort wk_end was talking about "functional pseudo-quicksort" on immutable linked lists. You're presumably talking about a proper quicksort on mutable arrays. That's comparing apples to oranges. And even if you weren't, how is that an argument? Person A says "X is faster than Y", then person B says "Actually I just ran X and it took 10x longer than Y" and then you say "Well Z, which isn't even part of this discussion, is 1000x faster than both X and Y, so your argument is invalid". How does that follow?
  - ncmncm 7y ago
    It means that speed is not a very interesting basis for comparing them. If you cared much about speed, you would look elsewhere.
    - kick 7y ago
      Their criticism is fair: I have been making a performance argument. I do think they've misinterpreted my performance argument, though, which I'll get to. (There's a lot of backlog I need to catch up with; this thread is very large and my typing speed is significantly faster than the speed at which I can think.)
    - yatac42 7y ago
      Again I want to emphasize that you were comparing different algorithms on different data structures. It's like someone made a benchmark using the naive recursive Fibonacci definition and then you implemented the iterative version in another language and concluded from that that the other language must be much faster. The different algorithm is what gave you (most of) the speed up, not the language. I mean, I don't doubt that C++ is in fact faster than Haskell, just not by that much.

by wk_end 7y ago

kick 7y ago

I promise I'll respond to this in the morning, I'm very tired right now and don't want to give a good and reasonable question an answer that hasn't been thought out well, especially given that my responses have been getting less detailed and concise as I've gotten more tired.

fanf2 7y ago

Oh wow, Miranda is still using an SK combinator reduction evaluator dating from 1986, in K&R C. It isn't even using supercombinators, which I read about in https://www.microsoft.com/en-us/research/publication/the-implementation-of-functional-programming-languages/ https://www.microsoft.com/en-us/research/publication/the-imp... Combinators are fun, but not very fast :-) https://dl.acm.org/doi/10.1145/800087.802798 https://dl.acm.org/doi/10.1145/800087.802798 http://ioccc.org/years.html#1998_fanf http://ioccc.org/years.html#1998_fanf

ncmncm 7y ago

Just for comparison, C++ running the shortest, simplest possible quicksort does 100,000,000 32-bit ints in 8s. Three more lines, and it's 3.4s. That's 1.3ns each time it looks at an element. So when you are already giving up an order of magnitude or two, another doesn't matter so much. It pays then to steer the conversation toward other merits.

yatac42 7y ago
> C++ and the shortest, simplest possible quicksort wk_end was talking about "functional pseudo-quicksort" on immutable linked lists. You're presumably talking about a proper quicksort on mutable arrays. That's comparing apples to oranges. And even if you weren't, how is that an argument? Person A says "X is faster than Y", then person B says "Actually I just ran X and it took 10x longer than Y" and then you say "Well Z, which isn't even part of this discussion, is 1000x faster than both X and Y, so your argument is invalid". How does that follow?
- ncmncm 7y ago
  It means that speed is not a very interesting basis for comparing them. If you cared much about speed, you would look elsewhere.
  - kick 7y ago
    Their criticism is fair: I have been making a performance argument. I do think they've misinterpreted my performance argument, though, which I'll get to. (There's a lot of backlog I need to catch up with; this thread is very large and my typing speed is significantly faster than the speed at which I can think.)
  - yatac42 7y ago
    Again I want to emphasize that you were comparing different algorithms on different data structures. It's like someone made a benchmark using the naive recursive Fibonacci definition and then you implemented the iterative version in another language and concluded from that that the other language must be much faster. The different algorithm is what gave you (most of) the speed up, not the language. I mean, I don't doubt that C++ is in fact faster than Haskell, just not by that much.