Re:Why I Prefer Functional Programming
by spekcular on Saturday October 31, 2020 @09:55PM
(#24956700)
Certainly, algebraic topology is a huge win for algebraization!
> Yes, parallelizing a program is about making it run faster; but parallelism is also a base fact of many problem domains, where you have multiple agents (up to and including humans) collaborating and interacting simultaneously.
Maybe I should say what I meant more clearly. The claim "one can achieve a 7x speedup on 8 cores by adding a handful of lines to a program" implicitly has a "and this is good because being fast is good" at the end. Why care about a speedup if you don't care about speed in the first place?
It follows that when evaluating a language's ability to gain speed through parallelization, we should also evaluate how fast that language is in the first place. If you can get a 7x speedup on 8 cores from a few lines of code, but the original algorithm is, say, 10x slower than a similar implementation in C/Rust/Go on one core, then who cares? The ultimate criterion is always absolute speed, not relative improvement.
I agree that being able to deal with concurrency is important, but as the Go people always remind me, concurrency and parallelism are distinct concepts.
> Yes, parallelizing a program is about making it run faster; but parallelism is also a base fact of many problem domains, where you have multiple agents (up to and including humans) collaborating and interacting simultaneously.
Maybe I should say what I meant more clearly. The claim "one can achieve a 7x speedup on 8 cores by adding a handful of lines to a program" implicitly has a "and this is good because being fast is good" at the end. Why care about a speedup if you don't care about speed in the first place?
It follows that when evaluating a language's ability to gain speed through parallelization, we should also evaluate how fast that language is in the first place. If you can get a 7x speedup on 8 cores from a few lines of code, but the original algorithm is, say, 10x slower than a similar implementation in C/Rust/Go on one core, then who cares? The ultimate criterion is always absolute speed, not relative improvement.
I agree that being able to deal with concurrency is important, but as the Go people always remind me, concurrency and parallelism are distinct concepts.