5 ms·

I'm no expert on these matters, but it seems a bit ridiculous to call out entire swaths of the programming/computer science world while referencing the JVM as a

by yzzxy 12y ago

I'm no expert on these matters, but it seems a bit ridiculous to call out entire swaths of the programming/computer science world while referencing the JVM as a benchmark.

cantankerous 12y ago
I think the critique is with the implied (but not always understood) overhead of some of FP's common types of abstraction.
yummyfajitas 12y ago
I'm (author here) not "calling them out" - most people doing research in FP are well aware of these issues. This is aimed at people like me who merely implement stuff in those languages. Also, most of the Scala code I'm describing compiles down to very straightforward instructions that would be the same on almost any compiler. If you can show me any other language which will handle a linked list as rapidly as the JVM handles an array, I'll be extremely impressed.
- dons 12y ago
  > handle a linked list as rapidly as the JVM handles an array A linked list is not an array. Particular operations will have different complexities. One data structure is not "more rapid" than another.
  - kasey_junk 12y ago
    This is precisely the kind of thinking people need to be careful about. Some data structures are more rapid than others even with more complex operations, because they conform to the reality of the underlying hardware better.
    - codygman 12y ago
      Can you please provide some examples? It would be much appreciated.
      - noblethrasher 12y ago
        http://youtu.be/YQs6IC-vgmo http://youtu.be/YQs6IC-vgmo Stroustrup describes why –on modern hardware– vectors are faster than linked list for insertion and deletion.
- comex 12y ago
  But your post makes more claims than merely computers not being able to arbitrage data structures. In your first example, while I don't have any experience with Scala, any competent compiler for C++, Haskell, Rust, etc. will inline a function like "map", so there is no "function call overhead" whatsoever. (This example is too simple to benefit from stream fusion as such.) The resulting machine code will look fairly similar; if there is a performance difference, it would be far more subtle than your 10x, and would probably have to do with whether the map implementation in question is specialized for the Array->Array case. One that is will allocate the right number of elements up front and perhaps even skip bounds checks that the compiler might or might not be able to optimize out from the explicit version, but one that isn't will not only include bounds checks but repeatedly have to grow the result array and copy the elements so far to the new allocation.
  - yummyfajitas 12y ago
    Yes, in the conclusion I remark that a Sufficiently Smart Compiler can do all of this. I don't know that either Haskell or C++ compilers will inline your maps, but if so, that's very cool. And yes, specializing for the Array -> Array case and eliminating bounds checks will be necessary to get real performance.

by yzzxy 12y ago

I'm no expert on these matters, but it seems a bit ridiculous to call out entire swaths of the programming/computer science world while referencing the JVM as a benchmark.

cantankerous 12y ago

I think the critique is with the implied (but not always understood) overhead of some of FP's common types of abstraction.

yummyfajitas 12y ago

I'm (author here) not "calling them out" - most people doing research in FP are well aware of these issues. This is aimed at people like me who merely implement stuff in those languages. Also, most of the Scala code I'm describing compiles down to very straightforward instructions that would be the same on almost any compiler. If you can show me any other language which will handle a linked list as rapidly as the JVM handles an array, I'll be extremely impressed.

dons 12y ago
> handle a linked list as rapidly as the JVM handles an array A linked list is not an array. Particular operations will have different complexities. One data structure is not "more rapid" than another.
- kasey_junk 12y ago
  This is precisely the kind of thinking people need to be careful about. Some data structures are more rapid than others even with more complex operations, because they conform to the reality of the underlying hardware better.
  - codygman 12y ago
    Can you please provide some examples? It would be much appreciated.
    - noblethrasher 12y ago
      http://youtu.be/YQs6IC-vgmo http://youtu.be/YQs6IC-vgmo Stroustrup describes why –on modern hardware– vectors are faster than linked list for insertion and deletion.
comex 12y ago
But your post makes more claims than merely computers not being able to arbitrage data structures. In your first example, while I don't have any experience with Scala, any competent compiler for C++, Haskell, Rust, etc. will inline a function like "map", so there is no "function call overhead" whatsoever. (This example is too simple to benefit from stream fusion as such.) The resulting machine code will look fairly similar; if there is a performance difference, it would be far more subtle than your 10x, and would probably have to do with whether the map implementation in question is specialized for the Array->Array case. One that is will allocate the right number of elements up front and perhaps even skip bounds checks that the compiler might or might not be able to optimize out from the explicit version, but one that isn't will not only include bounds checks but repeatedly have to grow the result array and copy the elements so far to the new allocation.
- yummyfajitas 12y ago
  Yes, in the conclusion I remark that a Sufficiently Smart Compiler can do all of this. I don't know that either Haskell or C++ compilers will inline your maps, but if so, that's very cool. And yes, specializing for the Array -> Array case and eliminating bounds checks will be necessary to get real performance.