3 ms·

> It's inflammatory because his main point -- that abstractions come at a cost It's also not always correct. See the Rust benchmarks posted here. Someone seei

> It's inflammatory because his main point -- that abstractions come at a cost It's also not always correct. See the Rust benchmarks posted here. Someone seeing this article might think it is correct, though, and thusly misinformed, they might avoid "functional-style" programming in the future when in fact many languages manage to provide FP idioms with no performance penalty. It's irresponsible, really. If he wants to state his opinions on FP, that's all well and good, but he should make it clear that they are his opinions and that the performance penalty he saw in the fold case is Swift-specific.

nkurz 10y ago
Given that the title is "Don’t assume that safety comes for free: a Swift case study", I don't think he's being particularly misleading. "Don't assume" usually just means that one should not take something for granted, not that it is never true. And doesn't appending "a Swift case study" makes it fairly clear that he is talking specifically about this case in Swift? Also, he does point out in this paragraph that there is nothing inherently slower about the functional approach: "All these functions achieve nearly the same best performance if you disable safety checks at build time (swift build --configuration release -Xswiftc -Ounchecked). This means, in particular, that we get the fancy abstraction (the reduce approach) for free, as long as we disable safety checks. That makes performance a lot easier to understand." See the Rust benchmarks posted here. Send him a pull request, and I'd bet he'd be happy to include them for comparison and mention them in an addendum: https://github.com/lemire/Code-used-on-Daniel-Lemire-s-blog/tree/master/2016/12/05 https://github.com/lemire/Code-used-on-Daniel-Lemire-s-blog/...
- caconym_ 10y ago
  Someone who hasn't used simple "functional idioms" (map, fold, ...) in half a dozen different programming languages could easily come away from this post with some idea that they are slow and/or "unsafe", when in fact they don't have to be slow and they don't really have anything to do with safety. This guy has a theory that this slowness without `-Ounchecked` is just a bug: https://news.ycombinator.com/item?id=13118405 https://news.ycombinator.com/item?id=13118405 It's been my experience that people who have used just a couple of programming languages tend to project what they "know" about those languages onto programming languages in general. Oh, and the snarky comments suggesting that a trivial functional idiom is gee-whiz "obfuscated" code that's good for impressing interviewers doesn't help. I mean, I've read worse things on the internet. But I think his conclusions about the performance and safety of the fold abstraction require some clarification.
  - nkurz 10y ago
    I work with the author regularly, and am inclined to a more charitable reading. I was serious when I suggested that he'd love to receive your Rust benchmark showing that it has no slowdown, and would happily include a note about them. I'm not sure of the the purpose of the "obfuscation" comments. I'd guess that they were intended as jokes, but missed the target. Rather than mocking the use of reduce, I think his goal was probably to defend the utility of the humble for loop. On a larger level, both he and I have a concern that people often assume "a sufficiently clever compiler" without checking to see that they actually have one. Here's the sort of thing I've been working on him with: https://arxiv.org/abs/1611.07612 https://arxiv.org/abs/1611.07612. It's shows how to count number of set bits with SIMD in a way that is faster than the using the builtin POPCNT instruction. This is a different level of optimization than concerns most programmers, but if you are trying to get that last 50% of maximum performance out of an implementation, it's likely that (at this point) Swift shouldn't be your top choice.
    - the_af 10y ago
      To me his jokes read as very unprofessional, unworthy of a CS professor. I understand his post was informal and not a peer-reviewed paper, but still: if you want to be taken seriously, maybe try not to irritate your audience with sarcastic quips unrelated to your main point? > people often assume "a sufficiently clever compiler" without checking to see that they actually have one. In many situations this is a reasonable assumption. Of course, checking is always warranted if you actually have a performance problem. In this particular case there's obviously something wrong going on with Swift. This is genuinely interesting -- though I think it doesn't merit being called a "case study" -- and could have been presented in a less confrontational way. edit: I've read some more of Lemire's blog and I tend to find it interesting and reasonably written. I'm willing to think in this case he just misjudged the tone :)

nkurz 10y ago

Given that the title is "Don’t assume that safety comes for free: a Swift case study", I don't think he's being particularly misleading. "Don't assume" usually just means that one should not take something for granted, not that it is never true. And doesn't appending "a Swift case study" makes it fairly clear that he is talking specifically about this case in Swift? Also, he does point out in this paragraph that there is nothing inherently slower about the functional approach: "All these functions achieve nearly the same best performance if you disable safety checks at build time (swift build --configuration release -Xswiftc -Ounchecked). This means, in particular, that we get the fancy abstraction (the reduce approach) for free, as long as we disable safety checks. That makes performance a lot easier to understand." See the Rust benchmarks posted here. Send him a pull request, and I'd bet he'd be happy to include them for comparison and mention them in an addendum: https://github.com/lemire/Code-used-on-Daniel-Lemire-s-blog/tree/master/2016/12/05 https://github.com/lemire/Code-used-on-Daniel-Lemire-s-blog/...

caconym_ 10y ago
Someone who hasn't used simple "functional idioms" (map, fold, ...) in half a dozen different programming languages could easily come away from this post with some idea that they are slow and/or "unsafe", when in fact they don't have to be slow and they don't really have anything to do with safety. This guy has a theory that this slowness without `-Ounchecked` is just a bug: https://news.ycombinator.com/item?id=13118405 https://news.ycombinator.com/item?id=13118405 It's been my experience that people who have used just a couple of programming languages tend to project what they "know" about those languages onto programming languages in general. Oh, and the snarky comments suggesting that a trivial functional idiom is gee-whiz "obfuscated" code that's good for impressing interviewers doesn't help. I mean, I've read worse things on the internet. But I think his conclusions about the performance and safety of the fold abstraction require some clarification.
- nkurz 10y ago
  I work with the author regularly, and am inclined to a more charitable reading. I was serious when I suggested that he'd love to receive your Rust benchmark showing that it has no slowdown, and would happily include a note about them. I'm not sure of the the purpose of the "obfuscation" comments. I'd guess that they were intended as jokes, but missed the target. Rather than mocking the use of reduce, I think his goal was probably to defend the utility of the humble for loop. On a larger level, both he and I have a concern that people often assume "a sufficiently clever compiler" without checking to see that they actually have one. Here's the sort of thing I've been working on him with: https://arxiv.org/abs/1611.07612 https://arxiv.org/abs/1611.07612. It's shows how to count number of set bits with SIMD in a way that is faster than the using the builtin POPCNT instruction. This is a different level of optimization than concerns most programmers, but if you are trying to get that last 50% of maximum performance out of an implementation, it's likely that (at this point) Swift shouldn't be your top choice.
  - the_af 10y ago
    To me his jokes read as very unprofessional, unworthy of a CS professor. I understand his post was informal and not a peer-reviewed paper, but still: if you want to be taken seriously, maybe try not to irritate your audience with sarcastic quips unrelated to your main point? > people often assume "a sufficiently clever compiler" without checking to see that they actually have one. In many situations this is a reasonable assumption. Of course, checking is always warranted if you actually have a performance problem. In this particular case there's obviously something wrong going on with Swift. This is genuinely interesting -- though I think it doesn't merit being called a "case study" -- and could have been presented in a less confrontational way. edit: I've read some more of Lemire's blog and I tend to find it interesting and reasonably written. I'm willing to think in this case he just misjudged the tone :)