CoW and reference counting in the STL
in [C++]
|
From: Öö Tiib on 18 Apr 2010 07:02 On 18 apr, 18:16, Mathias Gaunard <loufo...(a)gmail.com> wrote: > On 17 avr, 23:06, Andre Kaufmann <akfmn...(a)t-online.de> wrote: > > > I think COW addresses another problem than move semantics. > > COW addresses the problem of when you copy while you don't need to. > It's basically a fix for broken code. CoW is underlying mechanics of lazy copying. It copies only when someone writes into one of copies. It is odd that people claim it contradicts with threads. On the contrary, there are no need for locks when reading and that is good. For example POSIX fork() implementations are usually cheap thanks to CoW. CoW is difficult to do well with std::string, but that is more issue of cluttered up interface of string and not CoW being stupid and backward idea. > Move semantics allow you to not copy when you only need to move. Yes, that is different thing entirely. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Öö Tiib on 19 Apr 2010 15:37 On 19 apr, 21:57, Goran <goran.pu...(a)gmail.com> wrote: > On Apr 19, 12:02 am, �� Tiib <oot...(a)hot.ee> wrote: > > > CoW is underlying mechanics of lazy copying. It copies only when > > someone writes into one of copies. It is odd that people claim it > > contradicts with threads. > > Ah, but it does. Here's the problem: if you want to use CoW inter- > thread, the detection of forking must be done in a thread-safe manner. > This typically involves test-and-set instruction. That is quite heavy > on the hardware cache that it is possible, under heavy inter-thread > use, that just making a copy outperforms CoW. > > See http://www.gotw.ca/publications/optimizations.htm for a nice > better analysis. Yes, but this analysis displays problems exactly where i said they are (that you did cut): too lot of random access clutter in string interface. Anyone doing operator [] and bang, it is copied. So string is bad idea to CoW. CoW itself is fine and especially with threads. Let me explain. Someone usually needs threads when he has lot of data and lot of tasks for producing some new data. So somewhat simplified algorithm that perhaps makes sense: 1) copy portion of data relevant to a task and give that data together with task to some idle thread. 2) do 1) until you run out of idle threads or tasks that do not depend on output of previous tasks. 3) when a task is done put its output among available data and go back to 2) Only thing that costs here perhaps too lot is copying input for each task and it is not hard to see how profitable is CoW for that. Especially since tasks usually do not write into their input data, and CoW makes sure that no one writes without really copying it. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andre Kaufmann on 20 Apr 2010 04:45 Mathias Gaunard wrote: > On 17 avr, 23:06, Andre Kaufmann <akfmn...(a)t-online.de> wrote: > >> I think COW addresses another problem than move semantics. > > COW addresses the problem of when you copy while you don't need to. > It's basically a fix for broken code. > > Move semantics allow you to not copy when you only need to move. Yes, but it removes "only" temporaries, while COW also removes copying between multiple objects. Small example: string s1 = "abcdefghijklmnopqrstuvwxyz"; vector<string> list1; vector<string> list2; list1.push_back(s1); list2.push_back(s1); COW strings would reference the same string at >one< memory location, while non COW strings using move semantics would reference the same string at >multiple and different memory< locations. Anyways move semantics are a big plus for C++ regarding performance. Andre -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Öö Tiib on 20 Apr 2010 04:42 On Apr 20, 5:37 pm, Mathias Gaunard <loufo...(a)gmail.com> wrote: > On 18 avr, 23:02, Tiib <oot...(a)hot.ee> wrote: > > > For example POSIX fork() > > implementations are usually cheap thanks to CoW. > > Rather, the fork+execvp pattern requires COW with delayed allocation > (overcommit) to be efficient in both speed and memory usage. And > overcommit is obviously a serious problem that completely breaks the C > and C++ languages. Interesting. How it breaks C and C++ completely? I imagined that i anyway never know where my pointer with its virtual address points to. Things are done to me lazily first by processors cache and then by most successful operating systems out there with their swap files and overcommit. Possibly i oversimplify something? > It's a non-optimal solution upon which were added hacks to make it > acceptable, but that end up bringing more problems. But people like it > because it is simpler and more flexible than a single CreateProcess- > like function. Yes, possibly there are problems, but mostly that non-optimal fork() feels to work wonderfully. On the other hand trying to achieve same effect on Windows using CreateProcess is very inefficent and resource- consuming. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Mathias Gaunard on 19 Apr 2010 23:37
On 18 avr, 23:02, �� Tiib <oot...(a)hot.ee> wrote: > For example POSIX fork() > implementations are usually cheap thanks to CoW. Rather, the fork+execvp pattern requires COW with delayed allocation (overcommit) to be efficient in both speed and memory usage. And overcommit is obviously a serious problem that completely breaks the C and C++ languages. It's a non-optimal solution upon which were added hacks to make it acceptable, but that end up bringing more problems. But people like it because it is simpler and more flexible than a single CreateProcess- like function. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |