2 ms·

Sure, I understand the inertia, but can you show me any demo where a FP language outperforms C for parallel tasks? People in the deep learning field care a lo

by p1esk 10y ago

Sure, I understand the inertia, but can you show me any demo where a FP language outperforms C for parallel tasks? People in the deep learning field care a lot about speed, and if someone demonstrated a factor of x speedup with FP language, they would use it.

oldmanjay 10y ago
You want proof of a claim that only you have made. That doesn't seem like a terribly fair criticism of the OP.
- p1esk 10y ago
  Well, this discussion started when someone suggested the speed increases fueled by Moore's law held FP back. This is what I've been questioning. If it's not about speed, then what does it have to do with Moore's law?
nickpsecurity 10y ago
"but can you show me any demo where a FP language outperforms C for parallel tasks?" That's not a fair comparison. C proponents should ask, "Is there a demo where (alternative) outperforms C for (application domain) when C has (alternative)'s safety-checks enabled, too?" Memory and dataflow safety in C, using checks instead of exotic stuff, easily adds 20-500% overhead depending on application. Whereas, these safer or more functional languages are usually within 200% with some Common LISP's and Schemes matching or outperforming C in a few benchmarks. Concurrent Haskell wouldn't be giving me a performance reduction: I'd be getting more capabilities in development and reliability with a performance sacrifice. One that goes down every year for at least one implementation of each language or style.
- wmf 10y ago
  The question didn't even mention safety; maybe FP people are tying their own hands by insisting on safety features that users don't value. And if you're comparing N-way parallel FP code against serial C, maybe 500% overhead still leaves room for FP to win.
  - nickpsecurity 10y ago
    It's implied in the correctness argument. Is a speedup over C fine if it gives incorrect results? In that case, I'll demolish C myself by optimizing away any parts of the user program that dont map to fastest instructions and the registers. :P
    - bitL 10y ago
      Elephant in the room of having provable algorithms is in real numbers representation limitations in any imaginable hardware (hello irrational numbers!). You simply can't make complete proofs for most math-intense problems. Combinatorics should be fine though.
      - nickpsecurity 10y ago
        Huh? I might have missed your point but I'm talking about how C makes no effort toward correctness of results. The rest that do to varying degrees sacrifice some performance to get that. Can't speak on the proofs as it's not my specialty. Far as real numbers, that's what analog computers do with some models for making it more general purpose.
        bitL 10y ago
        I was just going one step further due to my experience in proving correctness of algorithms in functional languages. You probably had on mind usual array safety checks and control flow stuff for which aspects were invented, I raised the bar a bit by pointing out that there are some fundamental issues which even super functional purists can't overcome, so the overall talk about code safety is kinda funny ;-) You will still crash Space Shuttle if you are running on Haskell, just in a different fashion than with C.
        nickpsecurity 10y ago
        I've rarely seen what you're describing although I know plenty work remains go be done. So, could you give examples of code injections or mission-ending errors at code level that Haskell toolchains or Isabelle/HOL couldnt handle?
nickbauman 10y ago
I'm not sure this is a worthwhile comparison. Because the idiom of parallel programming is the same as the idiom for sequential programming in FP. It's completely different (and more difficult to make correct) in imperative languages. Which means it will be harder to maintain and harder to evolve even though it might be slightly faster in certain situations.
srean 10y ago
> but can you show me any demo where a FP language outperforms C for parallel tasks? Modulo rewriting your C so that it does exactly what the FP language (runtime) does, such examples are not difficult to come by. Stalin, Stalingrad and Roger Fateman would be good starting points. Regarding rewriting your C to match what the FP compiles into (or executes on the fly), the point is its very hard to write such _correct_ C unaided. So you use the higher level constructs to write that machine code / assembly / C.

by p1esk 10y ago

oldmanjay 10y ago

You want proof of a claim that only you have made. That doesn't seem like a terribly fair criticism of the OP.

p1esk 10y ago
Well, this discussion started when someone suggested the speed increases fueled by Moore's law held FP back. This is what I've been questioning. If it's not about speed, then what does it have to do with Moore's law?

nickpsecurity 10y ago

"but can you show me any demo where a FP language outperforms C for parallel tasks?" That's not a fair comparison. C proponents should ask, "Is there a demo where (alternative) outperforms C for (application domain) when C has (alternative)'s safety-checks enabled, too?" Memory and dataflow safety in C, using checks instead of exotic stuff, easily adds 20-500% overhead depending on application. Whereas, these safer or more functional languages are usually within 200% with some Common LISP's and Schemes matching or outperforming C in a few benchmarks. Concurrent Haskell wouldn't be giving me a performance reduction: I'd be getting more capabilities in development and reliability with a performance sacrifice. One that goes down every year for at least one implementation of each language or style.

wmf 10y ago
The question didn't even mention safety; maybe FP people are tying their own hands by insisting on safety features that users don't value. And if you're comparing N-way parallel FP code against serial C, maybe 500% overhead still leaves room for FP to win.
- nickpsecurity 10y ago
  It's implied in the correctness argument. Is a speedup over C fine if it gives incorrect results? In that case, I'll demolish C myself by optimizing away any parts of the user program that dont map to fastest instructions and the registers. :P
  - bitL 10y ago
    Elephant in the room of having provable algorithms is in real numbers representation limitations in any imaginable hardware (hello irrational numbers!). You simply can't make complete proofs for most math-intense problems. Combinatorics should be fine though.
    - nickpsecurity 10y ago
      Huh? I might have missed your point but I'm talking about how C makes no effort toward correctness of results. The rest that do to varying degrees sacrifice some performance to get that. Can't speak on the proofs as it's not my specialty. Far as real numbers, that's what analog computers do with some models for making it more general purpose.
      - bitL 10y ago
        I was just going one step further due to my experience in proving correctness of algorithms in functional languages. You probably had on mind usual array safety checks and control flow stuff for which aspects were invented, I raised the bar a bit by pointing out that there are some fundamental issues which even super functional purists can't overcome, so the overall talk about code safety is kinda funny ;-) You will still crash Space Shuttle if you are running on Haskell, just in a different fashion than with C.
        nickpsecurity 10y ago
        I've rarely seen what you're describing although I know plenty work remains go be done. So, could you give examples of code injections or mission-ending errors at code level that Haskell toolchains or Isabelle/HOL couldnt handle?

nickbauman 10y ago

I'm not sure this is a worthwhile comparison. Because the idiom of parallel programming is the same as the idiom for sequential programming in FP. It's completely different (and more difficult to make correct) in imperative languages. Which means it will be harder to maintain and harder to evolve even though it might be slightly faster in certain situations.

srean 10y ago

> but can you show me any demo where a FP language outperforms C for parallel tasks? Modulo rewriting your C so that it does exactly what the FP language (runtime) does, such examples are not difficult to come by. Stalin, Stalingrad and Roger Fateman would be good starting points. Regarding rewriting your C to match what the FP compiles into (or executes on the fly), the point is its very hard to write such _correct_ C unaided. So you use the higher level constructs to write that machine code / assembly / C.