- Why does vector::reserve() not grow exponentially ? - 16 Updates
- differential reference counting... - 1 Update
- good reference on threads - 8 Updates
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 10 04:51PM -0700 On 6/10/2021 1:00 PM, Bo Persson wrote: > memory allocator is pooled and works in certain chunks. > For example, if you ask for size = 1 * sizeof(char), you will never get > a single byte. You will get 16 bytes. Fwiw, I have created efficient pooled multi-threaded memory allocators in the past where an allocation of a single char returns the user a block of memory that is equal to the size of a pointer. So it over allocates on anything requested that is less than the size of a pointer. I can show examples if you are interested... If the user request memory that is equal to the size of a pointer or greater, then there is no over allocation.... |
| Paavo Helde <myfirstname@osa.pri.ee>: Jun 11 09:23AM +0300 10.06.2021 23:35 Alf P. Steinbach kirjutas: > pointer to it via `data`, and index that pointer. > You'd need the legendary perverse implementation with phat pointers, to > detect that. Mr Spook wrote: "allowing a valid [] access into the reserved but uninitialised indexes". The operator[] is easy to check for an implementation. Indeed, VS2019 in Debug mode with default options pops up a "Debug assertion failed" dialog with choices to abort the program or attach a debugger, when running this program: #include <vector> int main() { std::vector<int> vv; vv.resize(10); vv.reserve(20); vv[15] = 43; } |
| David Brown <david.brown@hesbynett.no>: Jun 11 09:52AM +0200 On 10/06/2021 16:47, Bonita Montero wrote: > want size = n * sizeof(type) memory and it gives you the memory and > the allocator-API doesn't give you the opportunity to get the size > actually allocated. So you're wrong. The allocator API may not tell you when an allocator actually gets more memory than you ask for. But containers like std::vector are part of the standard library - they are not restricted to the public API. A C++ standard library implementation can quite happily have undocumented features that allow std::vector to see how much memory it has /actually/ been allocated, and let it set "capacity" a little higher. Equally, there may be no such extra information available, and no way for the vector to learn of extra memory. Or when you call "reserve" for a size "x", the implementation could round "x" up to the nearest multiple of 16 - or whatever it likes. The implementation has a lot of freedom here. |
| MrSpook_3dnim@5ooodqy.co.uk: Jun 11 09:19AM On Thu, 10 Jun 2021 22:40:03 +0300 >> types is IMO something that should be flagged as Use With Extreme Caution. >Do you realize that calling reserve() and capacity() is fully optional? >If you do not like them, just don't use these functions. Thanks for the heads. My point however is that the difference is confusing to new devs and frankly a lot of older devs who don't use them very often. I don't see the point of having an allocated array with no objects in it anyway unless memory is really tight because what else will you do with it other than use the objects? >And from where did you get the idea that accessing the vector beyond its >size is valid for POD types? It's definitely UB and I bet there are If I reserve 10 integers and try and access one why would it crash? Its simply an area of memory defined as an integer, unlike an object that will have complex interactions with default or user methods that could easily cause a crash if you try and use any of them when uninitialised. Yes, it'll probably be some random value but it won't crash. |
| MrSpook_0sk4i3p@b1km5k73i1.edu: Jun 11 09:24AM On Fri, 11 Jun 2021 09:23:54 +0300 > vv.reserve(20); > vv[15] = 43; >} I have no idea why VS thinks thats a reason to assert. This works fine with gcc: #include <iostream> #include <vector> using namespace std; int main() { vector<int> v; v.reserve(100000); for(int i=0;i < v.capacity();++i) { v[i] = i; cout << v[i] << endl; } return 0; } |
| Bo Persson <bo@bo-persson.se>: Jun 11 11:59AM +0200 > complex interactions with default or user methods that could easily cause a > crash if you try and use any of them when uninitialised. Yes, it'll probably > be some random value but it won't crash. If you want to access the values, you could just do resize(10) instead of reserve(10). What is the problem? |
| Bo Persson <bo@bo-persson.se>: Jun 11 12:02PM +0200 > } > return 0; > } You mean "seems to work", which is one possible effect of UB. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 11 03:05AM -0700 On 6/11/2021 3:02 AM, Bo Persson wrote: > You mean "seems to work", which is one possible effect of UB. Knock on wood! https://youtu.be/XKuJUxGntRI?list=RDGMEMQ1dJ7wXfLlqCjwV0xfSNbA ;^) |
| MrSpook_jyc2xeWf9@aw55u6.gov: Jun 11 10:17AM On Fri, 11 Jun 2021 11:59:46 +0200 >If you want to access the values, you could just do resize(10) instead >of reserve(10). >What is the problem? Why does it need both? What is the point of reserve() is my point. |
| MrSpook_4bkzrb03@tu45utvus6nuc.tv: Jun 11 10:17AM On Fri, 11 Jun 2021 12:02:27 +0200 >> return 0; >> } >You mean "seems to work", which is one possible effect of UB. Does work. There's no reason why it wouldn't unless you can think of one. |
| MrSpook_3wcC2u9@cns8.net: Jun 11 10:18AM On Fri, 11 Jun 2021 03:05:52 -0700 >Knock on wood! >https://youtu.be/XKuJUxGntRI?list=RDGMEMQ1dJ7wXfLlqCjwV0xfSNbA >;^) Sadly not all of us have an insight into the subtext of 1970s disco tracks. Care to explain? |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 11 03:22AM -0700 >> ;^) > Sadly not all of us have an insight into the subtext of 1970s disco tracks. > Care to explain? If your software is infested with UB, better knock on wood! |
| "Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Jun 11 12:25PM +0200 On 11 Jun 2021 12:05, Chris M. Thomasson wrote: > Knock on wood! > https://youtu.be/XKuJUxGntRI?list=RDGMEMQ1dJ7wXfLlqCjwV0xfSNbA > ;^) My favourite song of this kind for playing on the guitar (in A with one note on open B string) is the Beatles' "Norwegian wood". Then there is, of course, ZZ Top's "Woke up with wood", which makes it rather explicit what it's all about. Except, I don't understand why Amii Stewart was /knocking/ on it. - Alf (baffled) |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 11 03:27AM -0700 >> You mean "seems to work", which is one possible effect of UB. > Does work. There's no reason why it wouldn't unless you can think of one. size vs capacity... |
| Sam <sam@email-scan.com>: Jun 11 06:55AM -0400 Bonita Montero writes: > want size = n * sizeof(type) memory and it gives you the memory and > the allocator-API doesn't give you the opportunity to get the size > actually allocated. So you're wrong. Memory allocators are written by smart people. They have tons of use data that documents optimal allocations strategy. That data would show that even if you request to reserve 8388492 bytes of memory, it's better to allocate an even 8388608 bytes. If so, it makes perfect sense to adjust the number of reserved values to reflect reality. |
| Sam <sam@email-scan.com>: Jun 11 06:57AM -0400 Bonita Montero writes: > https://en.cppreference.com/w/cpp/named_req/Allocator > Where's the interface that supplies the container the real > size of an allocated memory-block ? Just because something isn't specified for a library class, doesn't mean that the implementation is prohibited from having it. If you look at your header files for the methods of, say, std::unordered_map, you will recoil in horror at seeing all sorts of class methods that are nowhere to be found in the C++ specification. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 11 02:18AM -0700 On 1/27/2021 9:23 PM, Chris M. Thomasson wrote: > think I can create it from scratch using pure C++17 without going to the > way back machine... > However... I thank Bonita for making me want to do this. Hey at least my name is still in here: https://www.1024cores.net/home/lock-free-algorithms/object-life-time-management/differential-reference-counting/implementation ;^) |
| "Öö Tiib" <ootiib@hot.ee>: Jun 10 05:58PM -0700 On Friday, 11 June 2021 at 01:49:31 UTC+3, Öö Tiib wrote: > from "how to make multiple threads to concurrently use same > data?" to "how to make seamless I/O between threads that all > have their own data?". Forgot to give link to brief introduction to it: <https://theboostcpplibraries.com/boost.asio> It is always viewed as some kind of networking, multiprocessing and/or RPC tool in books. You can indeed do all that great with it. For example you can use separate process for writing that binary file with it. But you can also use just one thread, communicated with through Boost.Asio without separate process. It is likely one of safest ways of introducing multithreading into single-threaded legacy code. |
| Lynn McGuire <lynnmcguire5@gmail.com>: Jun 10 08:31PM -0500 On 6/10/2021 5:49 PM, Öö Tiib wrote: > from "how to make multiple threads to concurrently use same > data?" to "how to make seamless I/O between threads that all > have their own data?". I already have threads that have their own data. I guess that I should have mentioned that. I want multiple threads to share the massive dataset that we use. Very tricky, I have tried sharing data between the threads and it was a disaster. Lynn |
| Lynn McGuire <lynnmcguire5@gmail.com>: Jun 10 10:03PM -0500 On 6/10/2021 4:59 PM, Lynn McGuire wrote: > being used for dialogs and such. > Thanks, > Lynn I found "C++ Concurrency in Action, 2nd Edition" by Williams, Anthony. Has anyone read this and found it to be a good education on threads ? https://www.amazon.com/C-Concurrency-Action-Anthony-Williams/dp/1617294691/ Thanks, Lynn McGuire |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 10 08:08PM -0700 On 6/10/2021 8:03 PM, Lynn McGuire wrote: > I found "C++ Concurrency in Action, 2nd Edition" by Williams, Anthony. > Has anyone read this and found it to be a good education on threads ? > https://www.amazon.com/C-Concurrency-Action-Anthony-Williams/dp/1617294691/ I used to converse with Anthony way back. He knows his threads! :^) |
| "Öö Tiib" <ootiib@hot.ee>: Jun 10 08:31PM -0700 On Friday, 11 June 2021 at 04:32:04 UTC+3, Lynn McGuire wrote: > have mentioned that. > I want multiple threads to share the massive dataset that we use. Very > tricky, I have tried sharing data between the threads and it was a disaster. It is about philosophy what you do. I prefer not to share data. Several threads taking their turns to do something with data (X) is obviously equivalent to just one thread (XMaster) accessing X and rest of the threads telling to XMaster what they want from X in asynchronous manner (for that I suggest asio). It is easier that way to solve when too lot of work is needed to be done with X so work queue of XMaster keeps growing. XMaster can then split X into parts and delegate managing of those parts to its own workers. Once all computing power is occupied and queue full then it is time to buy more hardware. And now if you used asio then it is all easy as asio is meant for networking and RPC and your software has grown into networking and RPC thanks to more hardware you bought. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 10 09:32PM -0700 On 6/10/2021 8:31 PM, Öö Tiib wrote: > On Friday, 11 June 2021 at 04:32:04 UTC+3, Lynn McGuire wrote: >> On 6/10/2021 5:49 PM, Öö Tiib wrote: >>> On Friday, 11 June 2021 at 00:59:52 UTC+3, Lynn McGuire wrote: [...] > It is about philosophy what you do. I prefer not to share data. Only share data when you have to! That is a decent mantra to learn. [...] |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 10 09:33PM -0700 On 6/10/2021 9:32 PM, Chris M. Thomasson wrote: >> It is about philosophy what you do. I prefer not to share data. > Only share data when you have to! That is a decent mantra to learn. > [...] http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=54795fe0246af4b9532e60e9ac34f9456c16a663dbb5904d2f7806299b9a705d9e21f176ebabf0a96acdfb157bd3e6f59a4343d33915547955ef34c1436db905f4791c8c383d5e020f609ddad25852ee706b93ae145d44a34145e06e758d6c2fbd3cbc502beca8f048d9942e3e2d955126e6df10eb388ac2e1359035183974d9c19939b8748e89b1213b15b774fbb55a13de |
| Ian Collins <ian-news@hotmail.com>: Jun 11 08:17PM +1200 On 11/06/2021 13:31, Lynn McGuire wrote: > have mentioned that. > I want multiple threads to share the massive dataset that we use. Very > tricky, I have tried sharing data between the threads and it was a disaster. Well it very much depends on whether you have multiple writers. If you have a more readers than writers, std::shared_mutex is worth a look. -- Ian. |
| 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