in reply to Re: Perl Threads and multi-core CPUs
in thread Perl Threads and multi-core CPUs

This is because they copy every data structure except the ones you mark as shared

Only if the data structures exist before the threads are spawned. So don't do that. Spawn your threads before you load or create your large data structures. It ain't rocket science.

And, as has been mentioned before, most forked perl processes do not benefit from COW much either:

And that's just a few of the apparently read-only operations that will cause COW to trigger. Doing anything non-readonly, like adding or deleting an element to a hash or array and you induce wholesale copying. Increment or decrement a variable. Modify it 'in-place' with s/// or tr or substr.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^3: Perl Threads and multi-core CPUs
by perrin (Chancellor) on Sep 10, 2008 at 05:36 UTC
    If you don't load the data until after the threads are spawned, isn't it the same deal, i.e. you mark it shared or else it's per-thread? I don't see the advantage in waiting, unless you know you only need the data in some of your threads.

    COW works. It's not perfect, and less will be shared over time, but it provides a huge benefit, as anyone running a forking mod_perl or FastCGI server can see. It would be great if threads could take advantage of COW, but at the moment they don't.

[reply]
      If you don't load the data until after the threads are spawned, isn't it the same deal, i.e. you mark it shared or else it's per-thread? I don't see the advantage in waiting, unless you know you only need the data in some of your threads.

      If you have readonly data that is needed by many/all threads, mark it shared and you only get one copy (plus a few shared references).

      If the data is globally modifyiable, mark it shared and have one copy.

      If the data is locally modifiable, you need to have 1 copy per thread and it is far faster to clone it on mass than piecemeal via COW.

      It would be great if threads could take advantage of COW, but at the moment they don't.

      It doesn't make sense to use COW with threads, they can already share a single copy in memory.

      COW only 'saves' if individual threads need to be able to modify local copies of small portions of large datasets. In this rare case, it is easy enough to a) share the large dataset (having set it readonly) and then b) copy the required portion to a thread-local non-shared storage during the process of modification.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
        The mechanism for sharing, threads::shared, doesn't look very practical for sharing a complex 1GB AI model. It looks like the code constructing the model would have to be modified a fair amount to construct things in the right order and mark every variable shared. Maybe you know a higher-level way to do this though.

        For read-write data, I do think threads would use less memory if the vast majority of the program is the shared AI model. For read-only data, COW will do pretty well at sharing with no changes to the code and will share things that are outside of the AI model as well if they don't get modified.

        COW with threads would help with all the variables that you don't have an easy way to mark shared but don't need separate copies of, e.g. all of the data used by all of the CPAN modules you load.

[reply]

In Section Seekers of Perl Wisdom