3 ms·
If there are big differences in where you don't expect them (e.g. printf in a for loop being very slow), then it usually is a difference in implementation and p
by blattimwind 8y ago
If there are big differences in where you don't expect them (e.g. printf in a for loop being very slow), then it usually is a difference in implementation and possibly contract. E.g. I wouldn't be surprised if println! in Rust is synchronous, which tends to be slow on both terminals and redirections (i.e. file I/O).
For these simple examples an strace may be enlightening in this regard.
Edit: Indeed this seems to be the case from the library source code (println! -> _eprint -> stdout -> LineWriter).
- ah- 8y agoYes, this benchmark would be much more interesting if it didn't do any println on the hot path and just accumulated the results and wrote them out once in the end. Edit: I've tried (println! vs a single io::stdout::lock() and writeln!), and it doesn't seem to make any difference, at least for the range.rs example. Hmm.
- steveklabnik 8y agoSometimes, the trick there is that compilers can be really good at compile time stuff, and the whole computation may just be computed at compile time. In this case? Probably not. But it's not always the right way to do a benchmark, or at least, without some tweaks.
- burntsushi 8y agoIt's because println! isn't in the hot path. So it's fine to use it here.
- steveklabnik 8y agoprintln will lock stdout for the duration of its work, yes. You can lock once before and use write! instead.
- ape4 8y agoMight be interesting if all the tests used the same library for output. After all both D and Rust can use C libraries.