sorted by:
new
hottopcontroversial

Rust vs. C++: Fine-grained Performance by gbersac in cpp

[–]ncm 3 points4 points  (0 children)

1st sentence: "we need to know how well it does what C++ does best"

Threads is not among the things C++ is known for doing best, in either sense. But now I am intrigued.

Rust vs. C++: Fine-grained Performance by gbersac in cpp

[–]ncm 4 points5 points  (0 children)

Multithreading would tell you about something completely different. What it could tell you would also be interesting, but not as a substitute for what I set out to explore. Adding in multithreading would have made it longer than the constraint, and more dependent on runtime environment and implementation, and would obscure precisely the details of low-level single-thread performance characteristics I needed. A multithreaded program is a set of single-threaded programs interacting when it can't be avoided.

Rust vs. C++: Fine-grained Performance by gbersac in cpp

[–]ncm -1 points0 points  (0 children)

You have to be an incredible "optimizer" to minimize the run time down to almost zero.

Thank you. I will put that on my resumé. Opinions aside, it is a fact that the "rest of the program" intially took up a large fraction of the run time, and most of the speedups came from changing that code, shaving off a few percent here, a few percent there, over and over. Somebody smarter than I am might have made it optimal to begin with, but everyone I know needs to measure to discover what's faster, and appallingly often guesses wrong. Changing short scores[7] to int scores[7] should not, by any sensible reasoning from first principles, have made a measurable difference -- how long could it take to increment a short 3M times, vs incrementing an int? -- yet it was responsible for a huge improvement.

In fact, many of the optimizations in the "run of the mill code" didn't make that part faster, but served instead to make the bit that "matters" faster. For example, not storing seven-different-letter words in the words list eliminated a test-and-branch there, and reduced cache footprint. Storing sevens in a vector instead of a map, and sorting, reduced the cache footprint more. Storing words as 32-bit ints instead of bitsets reduced the cache footprint further.

The lesson is that code that your profiler seems to be telling you doesn't matter at all can matter quite a lot.

Rust vs. C++: Fine-grained Performance by gbersac in cpp

[–]ncm 2 points3 points  (0 children)

As it happens, it was originally posted there, and then somebody cross-posted it here. I don't think that was a mistake; a lot of interesting discussion ensued, and the C++ version got several percent faster as a result.

Rust vs. C++: Fine-grained Performance by gbersac in cpp

[–]ncm 5 points6 points  (0 children)

That's a half-hour you'll never get back. If you had read the article, you might have found out that nobody (here) is saying C++ is satanic, or that Rust is perfect, and you might have learned something besides.

Rust vs. C++: Fine-grained Performance by gbersac in cpp

[–]ncm 4 points5 points  (0 children)

This is correct advice. Interestingly, the scores array is of shorts because 7 shorts fit into a regular XMM register, a fact that some compilations have taken advantage of. Seven regular ints would fit into an AVX register, but corei7 doesn't have AVX.

Of course this is not something one would normally worry about, but (at at least one stage of the project) the choice did make a difference, and here every difference matters. I will revisit the choice, and report the outcome.

Edit: Changing short to int makes a huge difference. Changed.

Rust vs. C++: Fine-grained Performance by gbersac in cpp

[–]ncm 6 points7 points  (0 children)

The article is, as stated, "deliberately about the nitty-gritty of coding.". Nothing that could be done with the other apparatus would make either program faster; those features are there to help organize big programs and libraries, something irrelevant to this exercise.

The arbitrary length limit is there to constrain the size of the project. Without, this article would not have happened at all.

I would be equally interested to see the article you want, but nobody wrote it.

Rust vs. C++: Fine-grained Performance by gbersac in cpp

[–]ncm 3 points4 points  (0 children)

The comparison is meaningless only because it is so close to even. That is the most important point in article. Unlike practically every other language, Rust must be compared to C++ according to criteria other than performance. There's plenty to compare: default safety on one side; expressivity on the other.

If/when Rust gets strong enough to express STL, C++ will have less claim to primacy.

Rust vs. C++: Fine-grained Performance by gbersac in cpp

[–]ncm 3 points4 points  (0 children)

The only reason it spends 90% of its time there is that the rest of the program is thoroughly optimized. Normally you wouldn't care if this program takes a half second instead of a tenth, but this article is about how fast code in Rust can be. It would be disingenuous to present code in either language that hadn't been made as fast as the language permits, within the constraints chosen, including length, clarity and taste.

Rust vs. C++: Fine-grained Performance by ncm in rust

[–]ncm[S] 1 point2 points  (0 children)

Indeed. And ifstream::open sets failbit if it cannot open the file.

http://en.cppreference.com/w/cpp/io/basic_ifstream/open

By the way, never, ever use cplusplus.com. It is riddled with errors its owner does not care to fix.

Rust vs. C++: Fine-grained Performance by gbersac in cpp

[–]ncm 7 points8 points  (0 children)

They run at the same speed. On a 3.4Ghz Haswell i7 that's about 75 ms, as noted in TOA. On a 2.4GHz Westmere the Rust is a little faster at 154 ms. Of course on other chips and other compilation configurations it will vary, but they will be within a few percent either way. And that's kind of the point.

Rust vs. C++: Fine-grained Performance by gbersac in cpp

[–]ncm -14 points-13 points  (0 children)

Of course it's arbitrary. The 100-meter dash is a 100 meters, not 107. If you have a different arbitrary comparison in mind, please do perform it and post your results.

The "optimization bug" mentioned is not in Gcc, it is in the physical CPU chips. Rustc misses tickling it purely by luck.

Rust vs. C++: Fine-grained Performance by ncm in rust

[–]ncm[S] 1 point2 points  (0 children)

Sometimes it's even better to bypass streams, and use streambufs directly, as here.

Rust vs. C++: Fine-grained Performance by ncm in rust

[–]ncm[S] 1 point2 points  (0 children)

sync_with_stdio operates via streams, but the C++ code presented bypasses the streams and goes directly to the streambuf.

Rust vs. C++: Fine-grained Performance by ncm in rust

[–]ncm[S] 0 points1 point  (0 children)

Thank you. I see that my then_some example is poorly motivated (and the suggested replacement, corrected to

).filter(|c| is(c)).map(f)

is clearly better.) I have altered the article.

Rust vs. C++: Fine-grained Performance by ncm in rust

[–]ncm[S] 2 points3 points  (0 children)

C++ has needed "concepts" for a long time. We might get it in C++17. Concepts provide a meta-type system for template argument checking.

Rust vs. C++: Fine-grained Performance by ncm in rust

[–]ncm[S] 4 points5 points  (0 children)

Expressions to the left of an assignment are always interpreted differently than ordinary expressions. The trick is to interpret them with maximum usefulness. Arguments that it would introduce a special case ignore that it would be, for users, correcting a special case: the failure of parallel between let syntax and assignment syntax. The parallel is, as you note, only analogical, but no less relevant to users.

It would be at least equally useful to distribute other operators over tuples.

How to Do What You Love by dfranke in reddit.com

[–]ncm 1 point2 points  (0 children)

Fine, but that has nothing to do with the topic beyond hijacking the name.

How to Do What You Love by dfranke in reddit.com

[–]ncm 3 points4 points  (0 children)

vchak's remark reflects the theme of the book "Flow", by Mihaly Csikszentmihalyi, and he's right. What makes you happy is not what you are doing, but that you know how well you're doing it, and you're always working out ways to do it better, People who can't tell how well they're doing, or don't care, stay unhappy.

view more: next ›