Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Popular Myths about C++, Part 3

isocpp.org

Post reply on HN
Print view View original

31–40 of 114 posts

Re: Popular Myths about C++, Part 3

#31

Post by lomnakkus »

ridiculous_fish wrote: post #28
pavanky wrote: post #12

Earlier quoted context omitted.

You are right. He was really careful in picking double instead of int for this example.

Actually I would say it was rather careless, because it mishandles NaNs: vector v = {0, nan(""), 1}; sort(v.begin(), v.end(), [](double x, double y) { return x>y; }); In my test this leaves the vector unchanged, which is definitely not in decreasing order.

">" does not form a total order on doubles if you include NaN, so that's not really suprising. That is, you're providing a comparison function which is invalid, you should (at best) expect invalid results.

Re: Popular Myths about C++, Part 3

#32

Post by lomnakkus »

cageface wrote: post #20
cheepin wrote: post #10

Earlier quoted context omitted.

"C++ sucks" has become a bit of a meme around here. The upsides outweigh the downsides for a surprising number of cases. Every alternative is either immature, doesn't solve the use case that needs C++ or doesn't have the required libraries/tools.

There are people that sit back and bash C++ and then there are people that just roll up their sleeves and build really cool things with it. I'd certainly rather be in the second camp. I wouldn't mind having a simpler, more elegant language with the same design tradeoffs but that language doesn't yet exist.

False dichotomy. Plenty of people who "build really cool things with it" also bash C++, and rightfully so.

Re: Popular Myths about C++, Part 3

#33

Post by yongjik »

ridiculous_fish wrote: post #21

> I have never seen qsort beat sort Well, here you go: https://gist.github.com/ridiculousfish/bb511993deba1d148317 qsort: 674 ms std::sort: 1104 ms qsort only requires one invocation of the comparator to determine the order, while std::sort often requires two. So qsort ought to be faster when comparisons are expensive.

I'm not sure why std::sort should require two comparisons. It's not required to be stable (neither is qsort), so when comparing a and b gives (a >= b), std::sort can just assume (a > b) and the array will be sorted just fine.

Re: Popular Myths about C++, Part 3

#34

Post by btmorex »

chisophugis wrote: post #23

What Bjarne doesn't mention is the enormous difference in code size between qsort and std::sort. The flexibility of having the compiler generate a sorting routine from std::sort is convenient but enormously redundant in many cases. In LLVM, we have array_pod_sort which is just a thin wrapper around qsort in order to avoid the code bloat of std::sort: http://llvm.org/docs/doxygen/html/namespacellvm.html#ae5788f... For…

As long as std::sort can fit in the instruction cache, who cares? (outside the embedded world obviously) It will always be faster unless you're getting regular instruction cache misses.

Re: Popular Myths about C++, Part 3

#35

Post by btmorex »

ridiculous_fish wrote: post #25
agwa wrote: post #22

Earlier quoted context omitted.

Under what compiler? On GCC 4.9 they're neck-and-neck:: qsort: 6727 ms std::sort: 6718 ms (CPU is Core i7-950)

qsort wins by 2x with clang++ on OS X, 10x with g++-4.9 on OS X, and by about 14% with gcc 4.8 on Linux. This may be a pathological case for either implementation, since the array is already sorted. Still the point about std::sort requiring up to twice as many comparisons is valid.

fwiw, on linux with g++-4.8.2:

qsort: 4415 ms std::sort: 4413 ms

Some comments:

1.) std::sort doesn't require twice as many comparisons

2.) You not only have a vector with equal items, you have a vector of the same item repeated. That removes all data cache issues which I think is generally unrealistic and unfair.

3.) An already sorted vector is not only pathological, it's something that you usually need to optimize for (probably both qsort and std::sort are bad choices)

Re: Popular Myths about C++, Part 3

#36

Post by btmorex »

jayvanguard wrote: post #3

In 1995 C++ it wasn't a good choice. In 2000 it was a poor decision in most cases. In 2005 it was a bad decision in almost every case. In 2010 it was completely indefensible. It is almost 2015, why are we even talking about it? C++ was a mistake. A bad detour on the highway of computing.

You're wrong, but I think you just don't have the right kind of experience to understand why.

Re: Popular Myths about C++, Part 3

#37

Post by gsg »

chisophugis wrote: post #23

What Bjarne doesn't mention is the enormous difference in code size between qsort and std::sort. The flexibility of having the compiler generate a sorting routine from std::sort is convenient but enormously redundant in many cases. In LLVM, we have array_pod_sort which is just a thin wrapper around qsort in order to avoid the code bloat of std::sort: http://llvm.org/docs/doxygen/html/namespacellvm.html#ae5788f... For…

Yep. I remember seeing a presentation by one of the graphics engine shops that indicates they did the same thing. (I'll see if I can dig it up...)

Edit: it was DICE, see http://www.slideshare.net/DICEStudio/executable-bloat-how-it... - skip to page 14.

Re: Popular Myths about C++, Part 3

#38

Post by _RPM »

cheepin wrote: post #10
adamnemecek wrote: post #5

Earlier quoted context omitted.

So what's an alternative?

"C++ sucks" has become a bit of a meme around here. The upsides outweigh the downsides for a surprising number of cases. Every alternative is either immature, doesn't solve the use case that needs C++ or doesn't have the required libraries/tools.

Another meme / idiom seems to be "Why use C/C++ when you can use Rust?"

Re: Popular Myths about C++, Part 3

#39

Post by AlexeyBrin »

ridiculous_fish wrote: post #21

> I have never seen qsort beat sort Well, here you go: https://gist.github.com/ridiculousfish/bb511993deba1d148317 qsort: 674 ms std::sort: 1104 ms qsort only requires one invocation of the comparator to determine the order, while std::sort often requires two. So qsort ought to be faster when comparisons are expensive.

Let's try again, with a more C++14 like solution:

     sort(v.begin(),v.end(),[](const auto x, const auto y) { return *x > *y; });
instead of your line 39:

     sort(v.begin(),v.end(),[](const string *x, const string *y) { return *x > *y; });
Some results:

• g++ 4.9.2 with O3 qsort 545ms, sort 7289ms

• clang with O3 and libc++ qsort 551ms, sort 844ms

I've used:

   clang++ -std=c++1y -stdlib=libc++ -O3 test.cpp
and

    g++-4.9.2 -std=c++14 -O3 test.cpp

Re: Popular Myths about C++, Part 3

#40

Post by pubby »

AlexeyBrin wrote: post #39
ridiculous_fish wrote: post #21

> I have never seen qsort beat sort Well, here you go: https://gist.github.com/ridiculousfish/bb511993deba1d148317 qsort: 674 ms std::sort: 1104 ms qsort only requires one invocation of the comparator to determine the order, while std::sort often requires two. So qsort ought to be faster when comparisons are expensive.

Let's try again, with a more C++14 like solution: sort(v.begin(),v.end(),[](const auto x, const auto y) { return *x > *y; }); instead of your line 39: sort(v.begin(),v.end(),[](const string *x, const string *y) { return *x > *y; }); Some results: • g++ 4.9.2 with O3 qsort 545ms, sort 7289ms • clang with O3 and libc++ qsort 551ms, sort 844ms I've used: clang++ -std=c++1y -stdlib=libc++ -O3 test.cpp and g++-4.9.2 -std=…

The first is comparing pointers, not strings. I wouldn't call this a fair comparison.
Post reply on HN