| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 16 03:09PM -0800 On 11/15/2020 12:28 AM, Bonita Montero wrote: >> So as you notice it has to atomically increment and decrement , so i >> don't think C++ reference counting is scalable. > If it would be MT-safe, the reference-counters have to be atomic. Fwiw, there is a special form where the counters do not have to use RMW. Its not meant to be a general solution. Its kind of like a poor mans RCU. Think of something along the lines of a split counter. |
| Lynn McGuire <lynnmcguire5@gmail.com>: Nov 16 04:25PM -0600 On 11/13/2020 6:54 PM, olcott wrote: > In all these years I have only used encapsulation and the standard > template library. I think of C++ as if it was OOP improvement over C. > I think of C as a third generation language portable assembly language. In our Windows user interface approaching 500K lines of code, we have 617 classes. Works well. And we only use the STL also. Lynn |
| Philipp Klaus Krause <pkk@spth.de>: Nov 16 09:33AM +0100 Am 15.11.20 um 20:06 schrieb David Brown: > Custom swap and move constructors are definitely a help here. Implementing a custom swap (that just invokes std::swap on all members) indeed made std::sort faster than qsort for the example. And implementing a move constructor and amove assignment operator imporved it a little bit more. > obvious choice is that you should not use "valarray" when you know the > size of the array - use "std::array" which has the convenience of > working like a C++ container, but the efficiency of a fixed-size C array. I made the example for performance testing. In the code I really want to optimize, the size of the valarray is small most of the time, but can change at runtime. Also the use of valarray instead of vector is a previously applied optimization, as profiling showed an |= on valarray to be faster than iterating through the std::vector that was used before. |
| Juha Nieminen <nospam@thanks.invalid>: Nov 16 09:00AM > Why does std::sort need to allocate and deallocate memory that often? As others have pointed out, it doesn't. It's your own class that's allocating and deallocating memory each time elements are being copied or swapped around. |
| Philipp Klaus Krause <pkk@spth.de>: Nov 16 10:11AM +0100 Am 16.11.20 um 09:33 schrieb Philipp Klaus Krause: > indeed made std::sort faster than qsort for the example. And > implementing a move constructor and amove assignment operator imporved > it a little bit more. The custom swap and implementing moves did speed up the simplified example, but slowed down the case I really want to optimize. I'll try sorting an array of pointers next, to see if the possible speed up on sorting is worth the cost of the extra indirection on access. |
| David Brown <david.brown@hesbynett.no>: Nov 16 10:31AM +0100 On 16/11/2020 09:33, Philipp Klaus Krause wrote: > change at runtime. Also the use of valarray instead of vector is a > previously applied optimization, as profiling showed an |= on valarray > to be faster than iterating through the std::vector that was used before. If the size of the array is limited by a small compile-time known value, then it will be more efficient to use a std::array of the maximum size than a variable sized array. A valarray is easily going to have an overhead of a hundred bytes or more, with the indirection, handling of the memory allocation, minimum block size of the heap allocator, etc. And if you really have an array of bools, you can have a rather large fixed-size array before the valarray leads to any savings. |
| Philipp Klaus Krause <pkk@spth.de>: Nov 16 10:58AM +0100 Am 16.11.20 um 10:31 schrieb David Brown: > the memory allocation, minimum block size of the heap allocator, etc. > And if you really have an array of bools, you can have a rather large > fixed-size array before the valarray leads to any savings. Performance numbers on that question look clear: Going back from std:.valarry to std::vector increases runtime of the whole algorithm by about 80%. That is much more than what could be compensated by faster sorting. |
| David Brown <david.brown@hesbynett.no>: Nov 16 11:04AM +0100 On 16/11/2020 10:11, Philipp Klaus Krause wrote: > example, but slowed down the case I really want to optimize. > I'll try sorting an array of pointers next, to see if the possible speed > up on sorting is worth the cost of the extra indirection on access. This is always worth doing when you have big objects, even if they don't need constructing and destructing. The extra indirection is negligible compared to the big blocks you are copying, and the indirection you already have for your valarray's. The beauty of C++ is you can wrap things in classes so that the inconvenience of the indirection is hidden from the code that uses it. |
| David Brown <david.brown@hesbynett.no>: Nov 16 11:07AM +0100 On 16/11/2020 10:58, Philipp Klaus Krause wrote: > std:.valarry to std::vector increases runtime of the whole algorithm by > about 80%. That is much more than what could be compensated by faster > sorting. No one is suggesting using std::vector. I am suggesting std::array, which is a /completely/ different beast. And if your array really is just holding booleans (I don't know if that's just the simplified example code or from the real code), then you can use a single uint of appropriate size. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 16 01:27PM +0100 > https://sourceforge.net/p/sdcc/code/HEAD/tree/branches/lospre-vs-mcpre/sdcc/src/SDCClospre.hpp) > are structs containing three members: An boost::tuple<float, float>, an > std::valarray<bool> and a comparison function. I'm not going to analyze your code. But there must be allocations you made on your own. std::sort-implementations usually don't allocate any memory. |
| "Öö Tiib" <ootiib@hot.ee>: Nov 16 04:28AM -0800 On Monday, 16 November 2020 at 12:07:42 UTC+2, David Brown wrote: > just holding booleans (I don't know if that's just the simplified > example code or from the real code), then you can use a single uint of > appropriate size. For compile-time-sized array of truth values the std::bitset can be best. Doing std:qsort with something that is not array of TrivialType the behavior is undefined so I do not understand how OP compared std::sort with std::qsort. |
| David Brown <david.brown@hesbynett.no>: Nov 16 01:59PM +0100 On 16/11/2020 13:28, Öö Tiib wrote: > best. Doing std:qsort with something that is not array of > TrivialType the behavior is undefined so I do not understand > how OP compared std::sort with std::qsort. I guess a std::bitset will be as efficient as a uint of the same size, with the convenience of access operators and members as a container. As far as I can tell, using "to_ulong" will let him do the ordering function as a single comparison. |
| Bo Persson <bo@bo-persson.se>: Nov 16 02:01PM +0100 On 2020-11-16 at 10:58, Philipp Klaus Krause wrote: > std:.valarry to std::vector increases runtime of the whole algorithm by > about 80%. That is much more than what could be compensated by faster > sorting. Here you run into another special case (which C++ seems full of :-)). std::vector<bool> is optimized for space (by storing bits instead of bools), so it is expected to be slower, but possibly use fewer bytes. Bo Persson |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 16 04:32PM +0100 Your objects are not only compared but actually also copied or moved. Depending on if you've defined a proper move-constructor and move -assignment-operator or there aren't any copy-constructors od copy assingment-operators that override the default-implementations there won't be any allocations. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 16 08:03PM On Sun, 2020-11-15, David Brown wrote: > On 15/11/2020 19:32, Philipp Klaus Krause wrote: ... >> boost::tuple<float, float> s; >> std::valarray<bool> global; >> int size; ... >> }; ... > Custom swap and move constructors are definitely a help here. I probably should know this, but doesn't the default move constructor move the members one by one, if possible? /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Vir Campestris <vir.campestris@invalid.invalid>: Nov 16 09:49PM On 16/11/2020 09:00, Juha Nieminen wrote: > As others have pointed out, it doesn't. It's your own class that's > allocating and deallocating memory each time elements are being copied > or swapped around. ... and the way to speed it up is to make a vector of pointers to the structs, and sort that. _Then_ move the objects into their new locations. Andy |
| 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