Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re^2: Perl Threads and multi-core CPUs

by BrowserUk (Patriarch)
on Sep 10, 2008 at 04:57 UTC ( [id://710267]=note: print w/replies, xml ) Need Help??


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:

  • If you take a reference, the data is modified and therefore copied.
  • If you bless or re-bless the data, magic is added and it get copied.
  • If you perform math on data that was loaded as text, it gets converted to numeric representation, therefore is modified, and hence copied.
  • Interpolate a numeric scalar into a string, it gets copied.
  • int a real or string value, it gets copied.
  • chomp a scalar, it gets copied.
  • study a scalar, it gets copied.
  • Change a variable from readonly to readwrite, it gets copied.
  • Iterate a hash, or reset the iterator, stuff gets copied.
  • Even just searching a scalar could cause the Boyer Moore tables to be generated.

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.

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.

      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.
        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.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://710267]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others rifling through the Monastery: (7)
As of 2024-03-28 08:02 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found