5 ms·

Rarely do I ever manage memory in C++. As much as I adore Haskell there's a bunch of stuff you cannot do fast enough in any of the languages described above, as

Rarely do I ever manage memory in C++. As much as I adore Haskell there's a bunch of stuff you cannot do fast enough in any of the languages described above, as easily as you can do it in C++. Try writing a fast A* (without any pointers and memory management, easily done in C++), maybe a travelling salesman problem -- simple 2-opt heuristic (easily done without memory management). If you find these suitable for libraries, and not something you would write on your own, there's not a single fast matrix library implementation in Java or Haskell. If something that "simple" can't be done, then, in my case, I cannot use these languages as easily as I can use C++. A simple principle, a simple idea of copy and move semantics enabled me to write C++ code without worrying much about memory at all. When allocations become a problem, I just move the container out of that heavy loop, or change my malloc implementation with a simple flag, and it's still 10x if not 100x faster than what Haskell/Scala/Java could accomplish in the same amount of time it took me to write the C++ code.

claudius 11y ago
Came here to say this. "Modern" C++ with move semantics may still be fairly verbose in some cases, but claiming that you need to manually care about memory management (i.e. call new/delete/malloc/free) is a bit weird. It becomes especially weird when the post somehow implies that “paying client[s]” have arbitrary amounts of CPU time and memory available and that you can hence squander their resources as you please. Having said that, I can easily agree with the remainder of the post that the existing languages/ecosystems aren’t alternatives, and that statement does not change if you correct Scala’s “great performance” to “mediocre performance”.
lucian1900 11y ago
That's precisely why I find Rust so interesting: you can get the same results as with C++, but without accidental memory unsafety.
lmm 11y ago
On the matrix algebra side I use breeze, i.e. backed by netlib-java and ultimately by the native LAPACK (probably FORTRAN), but with a nice Scala interface on top. It reads very nicely, and performs well.
- skimpycompiler 11y ago
  Yes, it performs well, but not as well as it could. Would a matrix expression in breeze be matched by one of the fused functions of LAPACK (performing A*B+C in one pass)? I'm not sure of that. If you needed to squeeze the last bits out of your hardware you would have to waste more time. That's my main complaint. As verbose as C++ is I still can't make stuff perform as best as it could in Haskell/Scala/Java without spending more time (much more than it would take me to fix in C++). All of the languages are nice to work with but for some reason the more you distance yourself from the data representation in your memory (with references, boxes etc.) larger the time you have to spend to makes things fast, and all of those abstractions that saved you time, now turn out to be the overhead you don't want, and all of those abstractions now need to go away. I guess value types might change the thing for Java and other JVM languages. Can't wait to see how successful it'll be.
  - lmm 11y ago
    > Would a matrix expression in breeze be matched by one of the fused functions of LAPACK (performing AB+C in one pass)? The function's certainly there. I don't think it will automatically collapse an AB+C operation (though there's no reason that can't be implemented), but you wouldn't get that in C++ either (or rather, the template-fu needed to achieve it there would be harder than doing it in Scala). > All of the languages are nice to work with but for some reason the more you distance yourself from the data representation in your memory (with references, boxes etc.) larger the time you have to spend to makes things fast, and all of those abstractions that saved you time, now turn out to be the overhead you don't want, and all of those abstractions now need to go away. Yes and no. I'll grant that it's very rare to find a language that's better than another in every conceivable circumstance. But there's no law that abstractions have to be expensive (I guess that's part of the point of Rust). And even when they do come with a cost, computers get cheaper and programmers get more expensive.
eru 11y ago
I agree, especially for mere mortals. However, a talented writer, like Don Stewart and a few others, can write high performance Haskell code. The high performance part of your Haskell code might not look much like idiomatic Haskell in the end, but you can write abstractions around that. (The holy grail is high performance idiomatic code. If you befriend the compiler just right, it's possible for many problems.) Text.Bytestring is a good example in Haskell land.
- Patient0 11y ago
  small correction: Don StewarT not Steward
  - eru 11y ago
    Hah, I even looked it up, because I wasn't sure, but forgot to change it. Edited now.
- skimpycompiler 11y ago
  Data.Bytestring is still not as fast as it could be. Just try counting the number of eol characters in the bytestring (or any kind of character). Now do the same with `wc -l`. They did make the library perform well, but there are tiny details that squeeze the most out of your hardware and they seem to be a nuisance to do, even when you're thinking about performance. Despite that, fusion is beautiful and happens without all of that verboseness that makes the same thing in C++ work.

claudius 11y ago

Came here to say this. "Modern" C++ with move semantics may still be fairly verbose in some cases, but claiming that you need to manually care about memory management (i.e. call new/delete/malloc/free) is a bit weird. It becomes especially weird when the post somehow implies that “paying client[s]” have arbitrary amounts of CPU time and memory available and that you can hence squander their resources as you please. Having said that, I can easily agree with the remainder of the post that the existing languages/ecosystems aren’t alternatives, and that statement does not change if you correct Scala’s “great performance” to “mediocre performance”.

lucian1900 11y ago

That's precisely why I find Rust so interesting: you can get the same results as with C++, but without accidental memory unsafety.

lmm 11y ago

On the matrix algebra side I use breeze, i.e. backed by netlib-java and ultimately by the native LAPACK (probably FORTRAN), but with a nice Scala interface on top. It reads very nicely, and performs well.

skimpycompiler 11y ago
Yes, it performs well, but not as well as it could. Would a matrix expression in breeze be matched by one of the fused functions of LAPACK (performing A*B+C in one pass)? I'm not sure of that. If you needed to squeeze the last bits out of your hardware you would have to waste more time. That's my main complaint. As verbose as C++ is I still can't make stuff perform as best as it could in Haskell/Scala/Java without spending more time (much more than it would take me to fix in C++). All of the languages are nice to work with but for some reason the more you distance yourself from the data representation in your memory (with references, boxes etc.) larger the time you have to spend to makes things fast, and all of those abstractions that saved you time, now turn out to be the overhead you don't want, and all of those abstractions now need to go away. I guess value types might change the thing for Java and other JVM languages. Can't wait to see how successful it'll be.
- lmm 11y ago
  > Would a matrix expression in breeze be matched by one of the fused functions of LAPACK (performing AB+C in one pass)? The function's certainly there. I don't think it will automatically collapse an AB+C operation (though there's no reason that can't be implemented), but you wouldn't get that in C++ either (or rather, the template-fu needed to achieve it there would be harder than doing it in Scala). > All of the languages are nice to work with but for some reason the more you distance yourself from the data representation in your memory (with references, boxes etc.) larger the time you have to spend to makes things fast, and all of those abstractions that saved you time, now turn out to be the overhead you don't want, and all of those abstractions now need to go away. Yes and no. I'll grant that it's very rare to find a language that's better than another in every conceivable circumstance. But there's no law that abstractions have to be expensive (I guess that's part of the point of Rust). And even when they do come with a cost, computers get cheaper and programmers get more expensive.

eru 11y ago

I agree, especially for mere mortals. However, a talented writer, like Don Stewart and a few others, can write high performance Haskell code. The high performance part of your Haskell code might not look much like idiomatic Haskell in the end, but you can write abstractions around that. (The holy grail is high performance idiomatic code. If you befriend the compiler just right, it's possible for many problems.) Text.Bytestring is a good example in Haskell land.

Patient0 11y ago
small correction: Don StewarT not Steward
- eru 11y ago
  Hah, I even looked it up, because I wasn't sure, but forgot to change it. Edited now.
skimpycompiler 11y ago
Data.Bytestring is still not as fast as it could be. Just try counting the number of eol characters in the bytestring (or any kind of character). Now do the same with `wc -l`. They did make the library perform well, but there are tiny details that squeeze the most out of your hardware and they seem to be a nuisance to do, even when you're thinking about performance. Despite that, fusion is beautiful and happens without all of that verboseness that makes the same thing in C++ work.