| Paavo Helde <myfirstname@osa.pri.ee>: Mar 26 06:32PM +0200 On 26.03.2019 16:53, Martijn van Buul wrote: >> std::unique_ptr<int[]> buffer(new int[n]); >> AFAIK this is the last use case for 'new' > ... that you're willing to consider. Yes, I should have clarified I meant application level programming. > Please show me an implementation of any of the containers, or any of the > "smart" pointers that does not rely on 'new'. Indeed, containers may use 'new' a lot, but this would then be placement new and not memory allocation. Memory is typically allocated through special allocator classes. Smartpointers don't allocate anything at all, they just encapsulate already allocated objects. |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 26 05:52PM +0100 > Please show me an implementation of any of the containers, > or any of the "smart" pointers that does not rely on 'new'. No, the containers rely on std::allocator and how this works is exchangeable. Unfortunately std::allocator works with new and not with some other kind of memory-allocation. The thing is simply that when you have very large allocations, the're not backed up by the internal heap but by contignous pages of the OS (i.e. allocated through mmap() or VirtualAlloc(). And when new indirectly allocates its memory with this means, you could often grow an allocation in-place without allocation a new memory-block at another location. If std::allocator would have a function that would enable f.e. vector to ask if a block could be grown in-place before moving it to another location a lot of overhead would be saved. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Mar 26 12:52PM -0400 On 3/26/19 12:02, Bonita Montero wrote: > If you have a expensive initialization of the elemens increasing > the size puts not much weight on that. But if you have a cheap > initialization, growing the size might have an essential share. I recommend doing careful profiling to confirm that this is a significant problem before expending a lot of effort to avoid it. I think you'll be surprised at just how little difference it makes - you might even find that it's infinitesimally faster doing it the way that seems like it should be slower. |
| Vir Campestris <vir.campestris@invalid.invalid>: Mar 26 09:26PM On 26/03/2019 14:35, Bonita Montero wrote: >> uninitialized buffer and emplace_back()s initialize values > > in it. > emplace_back increases the size for each enlargement. No. Or not in any way that matters. It's technically implementation dependent, but in all the ones I've looked at: reserve() calls new() which calls malloc() and gives you a load of memory. If it's big enough that comes from the operating system directly not the process local heap, and the OS may well zero all the pages it gives out for security between processes. You now have this big lump of memory. Each time you call emplace_back you construct a new object in the memory you already allocated. Even if you _don't_ call reserve the implementations tend not to grow the space by just one unit. They'll allocate a bunch - and the size of the bunch grows as the array grows. It might go 16,32, 64....1MB, 2MB, 3MB, 4MB. Andy |
| jameskuyper@alumni.caltech.edu: Mar 26 02:51PM -0700 On Tuesday, March 26, 2019 at 5:26:38 PM UTC-4, Vir Campestris wrote: > > > in it. > > emplace_back increases the size for each enlargement. > No. I think it does. > Or not in any way that matters. But I agree that it doesn't matter. > gives out for security between processes. > You now have this big lump of memory. Each time you call emplace_back > you construct a new object in the memory you already allocated. Which requires increasing the size. > the space by just one unit. They'll allocate a bunch - and the size of > the bunch grows as the array grows. It might go 16,32, 64....1MB, 2MB, > 3MB, 4MB. He said that it increases the size by 1. You're talking about increasing the capacity, which is a much more important issue. You're right - that issue is resolved by using reserve(). But he's convinced, in conflict with expert opinion and without any supporting evidence, that increasing the size by 1 for each emplaced object will have a significant detrimental effect on the speed. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Mar 26 10:21PM On Tue, 26 Mar 2019 14:51:41 -0700 (PDT) > He said ... Have you consider that Bonita may be a woman? Women can code as well. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Mar 26 10:21PM On Wed, 27 Mar 2019 09:19:26 +1300 > So you can't quote properly or cite an example where incrementing a > pointer is excessively expensive? > One is just plain rude, the other an inability to back your argument. The contest is between (a) unnecessarily incrementing the size integer or end pointer on each emplace_back() or (b) unnecessarily initializing each element to 0 at the outset. As she has said, the last is likely to be faster than the first. That seems like backing her argument to me. |
| Ian Collins <ian-news@hotmail.com>: Mar 27 11:26AM +1300 On 27/03/2019 11:21, Chris Vine wrote: > jameskuyper@alumni.caltech.edu wrote: >> He said ... > Have you consider that Bonita may be a woman? Women can code as well. But they not to be rude.. -- Ian. |
| Ian Collins <ian-news@hotmail.com>: Mar 27 11:34AM +1300 On 27/03/2019 11:21, Chris Vine wrote: > each element to 0 at the outset. > As she has said, the last is likely to be faster than the first. That > seems like backing her argument to me. Okay, I concede growing the size of the container with its elements uninitialised in one step would be faster, but it would also be an impractical thing to standardise given objects may not have a valid uninitialised state. So within the confines of standard C++, reserve() and emplace_back() is the optimal solution. -- Ian. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Mar 26 10:35PM On Wed, 27 Mar 2019 11:26:56 +1300 > >> He said ... > > Have you consider that Bonita may be a woman? Women can code as well. > But they not to be rude.. Could you recast that, as I can't parse it? (And if you are saying Bonita has been rude, can you reference the post in question? I didn't see it but it is possible I have missed it. But as I say I can't parse your sentence and you may have meant something else.) |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Mar 26 10:39PM On Wed, 27 Mar 2019 11:34:31 +1300 > uninitialised state. > So within the confines of standard C++, reserve() and emplace_back() is > the optimal solution. Actually, the optimal solution if using std::vector is probably to size it at the outset and take the hit of the unnecessary initialization, as I have said. I think that (b) is likely to be faster than (a). But measurement will reveal all. The optimum solution if not using std::vector where the size is fixed is probably to allocate a C array on the heap or use std::array. This of course is also "within the confines of standard C++. |
| Ian Collins <ian-news@hotmail.com>: Mar 27 11:42AM +1300 On 27/03/2019 11:35, Chris Vine wrote: > Bonita has been rude, can you reference the post in question? I didn't > see it but it is possible I have missed it. But as I say I can't > parse your sentence and you may have meant something else.) Deliberately sipping attributions despite being asked not to do so. Sipping attributions has always been a no-no on Usenet. -- Ian. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Mar 26 10:50PM On Wed, 27 Mar 2019 11:42:37 +1300 > > parse your sentence and you may have meant something else.) > Deliberately sipping attributions despite being asked not to do so. > Sipping attributions has always been a no-no on Usenet. What are you talking about? Firstly, snipping redundant material as here is entirely proper, and secondly no one has asked me to do anything. You attempt to imply Bonita is rude (I think) and then you attempt to imply something else in relation to me which seems unintelligible. |
| Ian Collins <ian-news@hotmail.com>: Mar 27 11:51AM +1300 On 27/03/2019 11:39, Chris Vine wrote: > it at the outset and take the hit of the unnecessary initialization, as > I have said. I think that (b) is likely to be faster than (a). But > measurement will reveal all. Yep, measure... If default initialisation is non-trivial, sizing at the outset wouldn't be a good idea. I probably should have said in the general case, reserve() and emplace_back() is the optimal solution. This is "fix" the clang-tidy performance-inefficient-vector-operation will perform when it detects default constructed vectors being filled with [push/emplace]_back(). -- Ian. |
| Ian Collins <ian-news@hotmail.com>: Mar 27 11:53AM +1300 On 27/03/2019 11:50, Chris Vine wrote: > anything. > You attempt to imply Bonita is rude (I think) and then you attempt to > imply something else in relation to me which seems unintelligible. I did no such thing, it is Bonita who snips attributions. -- Ian. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Mar 26 11:03PM On Wed, 27 Mar 2019 11:51:55 +1300 > emplace_back() is the optimal solution. This is "fix" the clang-tidy > performance-inefficient-vector-operation will perform when it detects > default constructed vectors being filled with [push/emplace]_back(). Sure, but option (b) would not involve filling with push_back/emplace_back(). Yes, option (a) - reserve/emplace_back() - would be better with element types with non-trivial default constructors. However, subject to measurement, I strongly suspect that is not the case with ints. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Mar 26 06:50PM On 26/03/2019 16:32, Paavo Helde wrote: > Smartpointers don't allocate anything at all, they just encapsulate > already allocated objects. Not true: std::shared_ptr may allocate a control block. /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| 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