On 22/06/14 12:16 PM, SiegeLord wrote: > On 06/22/2014 11:32 AM, Benjamin Striegel wrote: >> This is a mistaken assumption. Systems programming exists on the extreme >> end of the programming spectrum where edge cases are the norm, not the >> exception, and where 80/20 does not apply. > > Even in systems programming not every line is going to be critical for > performance. There is still going to be a distribution of some lines > just taking more time than others. Additionally, in a single project, > there's a nontrivial cost in using Rust for the 20% of code that's fast > and using some other language for the remaining 80%. How are you going > to transfer Rust's trait abstractions to, e.g., Python?
Rust's design rejects this kind of reasoning about performance not being relevant to 80% of the code. The language forces you to deal with ownership and lifetimes throughout the code, even though it's not going to speed up most inner loops. It's there to improve the performance characteristics if the language as a whole. If you don't care about that, a high-level garbage collected language like F# is a better choice. >> If you don't require absolute speed, why are you using Rust? > > Because it's a nice, general purpose language? Systems programming > language is a statement about capability, not a statement about the sole > type of programming the language supports. Rust supports checked overflow. It has operator overloading and user-defined types. > C++ can be and is used effectively in applications where speed is of the > essence and in applications where speed doesn't matter. Is Rust going to > be purposefully less generally useful than C++? There's always this talk > of "C++ programmers won't use Rust because of reason X". Which C++ > programmers? In my experience the vast majority of C++ programmers don't > push C++ to its performance limits. Are they using the wrong language > for the job? I don't think so as there are many reasons to use C++ > beside its speed potential. If you're using C++ and you don't care about performance or code size, then you're using the wrong tool for the job. C++ doesn't have support for checked overflow anyway, and there's a significant difference between pushing the language to the performance limit and opting into a 50% performance hit. Checked overflow turns an overflow bug where the program continues running into the program exiting abnormally, so it's still a bug either way. We're not talking about a situation where performance is being lost for the sake of correctness. > Rust will never become popular if it caters to the tiny percentage of > C++ users who care about the last few percent of speed while alienating > everybody else (via language features or statements like yours). The > better goal is a) enable both styles of programming b) make the > super-fast style easy enough so that everybody uses it. The two choices here aren't 'fast' and 'super-fast'. We're not talking about the "last few percent of speed" here. Using checked overflow will reduce the performance of most code with non-trivial usage of integer arithmetic by 30-70%. The only saving grace is that many applications use floating point arithmetic, and this would still be unchecked. Even if the program is bounded by memory bandwidth, the stalls from all of the extra icache churn are going to have an impact. Supporting checked overflow well without changing the defaults is fine, but that hasn't been what I've seen proposed here. I think Rust is already providing a significant improvement over C by making signed integer overflow defined, and we do pay in terms of some missed optimizations from that alone. However, our pointer arithmetic was switched to being inbounds like C, and you can often just use pointers instead of relying on integer.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
