2 ms·

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 s

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

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 :)