- Std::deque is really quite bad - 6 Updates
- "2 major reasons why modern C++ is a performance beast" - 5 Updates
| woodbrian77@gmail.com: Oct 04 11:01AM -0700 Around the 47 minutes and 40 seconds mark in this video https://www.youtube.com/watch?v=vElZc6zSIXM&spfreload=1 Chandler Carruth says: "the std::deque data type is really quite bad. I wouldn't recommend anyone use it for anything." Do you agree that std::deque should be added to std::junkpile? I've known about some of the problems with std::deque for years, but I have one place where I use it here: http://webEbenezer.net/misc/cmwAmbassador.cc . I'm not sure what would be a better alternative there. Tia. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net |
| JiiPee <no@notvalid.com>: Oct 04 07:13PM +0100 Performance reasons: "std::deque performs better than a std::vector for inserting at random positions (especially at the front, which is constant time)" http://baptiste-wicht.com/posts/2012/12/cpp-benchmark-vector-list-deque.html |
| Mr Flibble <flibble@i42.co.uk>: Oct 04 07:19PM +0100 > be added to std::junkpile? > I've known about some of the problems with std::deque > for years, but I have one place where I use it here: std::deque is no worse and no better than any other container and should be used where appropriate so Carruth is simply incorrect. When one fully understands the complexity and reference/iterator invalidation behaviour for each of a container's operations one can make an intelligent choice for which container to use for a specific task. /Flibble |
| Mr Flibble <flibble@i42.co.uk>: Oct 04 07:21PM +0100 On 04/10/2016 19:13, JiiPee wrote: > Performance reasons: "std::deque performs better than a std::vector for > inserting at random positions (especially at the front, which is > constant time)" False; the performance of std::deque insert in the middle is just as poor as for std::vector. /Flibble |
| "Öö Tiib" <ootiib@hot.ee>: Oct 04 12:28PM -0700 > really quite bad. I wouldn't recommend anyone use > it for anything." Do you agree that std::deque should > be added to std::junkpile? Container's performance does not care about opinions of whatever young googlers, youtubers or llvmers the internet keeps spitting at us. 'std::deque' is doing quite well in profile of several algorithms. > http://webEbenezer.net/misc/cmwAmbassador.cc > . I'm not sure what would be a better alternative there. > Tia. The standard library containers are all likely performing worse for FIFO of smart pointers that you seem to have there. 'std::queue' (adaptor) makes its usage likely slightly less verbose and also documents better that it is FIFO. From outside of standard library it may easily be that for example 'boost::circular_buffer_space_optimized' is performing better there. That needs profiling, if it matters. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 04 11:50PM +0100 On Tue, 4 Oct 2016 11:01:26 -0700 (PDT) > http://webEbenezer.net/misc/cmwAmbassador.cc > . I'm not sure what would be a better alternative there. > Tia. Your leaning towards authority figures like Chandler, and your willingness to give their views special validity, may explain why you are religious nutjob. You need to think for yourself. If you have a use case where you frequently insert or remove elements at the start and end of the container, std::deque is the first container to try unless profiling tells you that something else works better. std::vector may possibly do so for containers of built-in types where most operations are at the end and only some at the beginning, and the whole container frequently fits within a single cache line. |
| Mr Flibble <flibble@i42.co.uk>: Oct 04 12:56AM +0100 On 03/10/2016 19:13, David Brown wrote: > at least as fast as C, assuming you have an optimising compiler, and > sometimes C++ gives you ways to write code that is faster than C code if > you want code to be clear, flexible and maintainable.) You cannot inline the function pointer passed to qsort because qsort isn't inline function and has already been compiled as part of the CRT library so doesn't have sight of the comparison function's body for inlining. So std::sort will be faster than qsort as we can benefit from an inlining functor. /Flibble |
| Jerry Stuckle <jstucklex@attglobal.net>: Oct 03 09:24PM -0400 On 10/3/2016 7:56 PM, Mr Flibble wrote: > So std::sort will be faster than qsort as we can benefit from an > inlining functor. > /Flibble So? Who says you need to use qsort? Many times I've written replacements for generic functions like qsort for performance reasons. Of course, they're not needed now as much as they were in the 80's, but there are times when they are still needed. Nothing says you *have* to use *any* built-in function, including qsort. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Robert Wessel <robertwessel2@yahoo.com>: Oct 03 10:27PM -0500 On Tue, 4 Oct 2016 00:56:27 +0100, Mr Flibble <flibble@i42.co.uk> wrote: >function's body for inlining. >So std::sort will be faster than qsort as we can benefit from an >inlining functor. There's no requirement that qsort actually be pre-compiled into something like a traditional library, so its source *could* be visible in the translation unit (just include the function body in the header and make it static, for example). It could even be done as a built-in function (similar to how many (simpler) C library functions can be inlined). Second, with LTCG, if the library is distributed in the right form*, it's parse tree (or whatever) will be visible at link time (when the code is generated), and it could be inlined at that point. So that's more a limitation of current implementations, and not inherent in the language. *Note that I don't know of any cases where that's actually been done, but it's certainly possible. |
| David Brown <david.brown@hesbynett.no>: Oct 04 09:50AM +0200 On 04/10/16 01:56, Mr Flibble wrote: > has already been compiled as part of the CRT library so doesn't have > sight of the comparison > function's body for inlining. First, as Jerry says, you don't have to use the standard "qsort" function. Secondly, there is nothing in the standards that says qsort must be a separately compiled function in a "CRT" library. Options include: 1. An inline function in <stdlib.h> 2. A library function, but in a format for use with link-time optimisation so that it can be inlined across modules. 3. Code generated at compile-time by the compiler, optimised for the specific use-case. Compilers do that for simpler library functions like memcpy() and the str* functions, as well as many of the maths functions. 4. A series of library functions optimised for a variety of common sort functions or sort function patterns, with a method of matching up names (much like function overloading in C++). 5. Anything the toolchain likes - the only requirement is that it /looks/ like the code works in the way the C standards specify and your source code says. (Of those options, number 2 is certainly realistic.) |
| Mr Flibble <flibble@i42.co.uk>: Oct 04 04:56PM +0100 On 04/10/2016 04:27, Robert Wessel wrote: > inherent in the language. > *Note that I don't know of any cases where that's actually been done, > but it's certainly possible. My point is that C only has function pointers available so any C solution may not be able to inline however if we use templates in C++ inlining will always be available when using inlining functors. /Flibble |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment