Re^5: Sharing XS object?

[ELISHEVA]

You are just guessing. I benchmarked.

I hardly call making a reasoned guess "just guessing". When a reasoned guess and experimental evidence conflict, one of three things can be happening: the reasoned guess was logically flawed, the reasoned guess failed to include key information and so was wrong no matter how perfect the logic, or the experimental design is wrong. Those are important questions and they can't just be swept under the rug.

No matter what the answer there is something to learn. True learning in my experience comes from reguarly checking experience with logic and logic with experience. Inductive and deductive reasoning need to work in tandem. I hardly need to tell you that.

Secondly, with all due respect, your "benchmark" is comparing apples and oranges. The OP said he wanted to share an object and not just any object but a pre-initialized tree. This is exactly the kind of object threads::shared says it can't handle well. According to the perl docs, sharing a pre-initialized object will wipe out all of the data (see 5.10 and 5.12 bugs on threads::shared). Additionally, share can only do shallow sharing. If you have a complex deeply nested data structure you have to share each component bottom up and of course you have to reinitialize them all as well because sharing will wipe out their data.

In short, given the current status of threads::shared a true benchmark is simply not possible. Either you level the playing field by applying a server/client solution to a situation where it is clearly overkill. Alternatively, you apply the client/server solution to an complex pre-initialized object, but then you wouldn't be able to use shared.

Where I will agree with you is that, threads::shared is clearly not nearly as inefficient as I first believed. If they ever do clear up the intialization wipe-out bug, it will be a very powerful thing indeed.

The very first line of my post (reply 1) made an assertion that is almost certainly false along with a disclaimer that I'm not a threads expert (implication I may be wrong). Given that you are an expert, why didn't you just come out and say:

threads::shared may not be applicable to the kind of object the OP wants to share, but it isn't nearly as inefficient as you think. In fact in some cases it even uses less memory than a single thread. Here's why ...

It would have been a lot more helpful to me and like to others as well. Further, your answer would have been right up there in reply 2 where it would be much more likely to be read and gotten exposure.

I was intrigued by your performance observations and I threw together a few additional benchmarks of my own comparing scripts using three different scenarios: single thread, multi-thread w/o share and shared.

What is really clear from the results below is that there is simply no way that thread::shared is keeping per-thread copies of data - i.e. unshared threads with a lot of behind-the-scenes automated copying. The unshared multi-threaded script used up so much memory it froze my whole system. Furthermore, the shared multi-threaded script used less memory than a single threaded script. Care to explain what is going on? It certainly isn't what I thought.

              hash    memory          runtime    
              keys   sz    vsz   wall    user    sys         
ThreadShared  1K   22.6   90.1   0:02.6  0:01.6  0:00.1
ThreadCopy    1K   23.2   93.0   0:02:9  0:01.4  0:00.8
No Threads    1K    0.9    3.5   0:00.8  0:00.7  0:00.01

ThreadShared  1M   41.5  166.3   0:12.2  0:10.7  0:00.9
ThreadCopy    1M   untestable - froze up my system
No Threads    1M   45.0  180.0   0:06.9  0:04.8  0:02.1

*these numbers and their relationships are stable through
 multiple runs so they are unlikely to be artifacts of
 some sort of transient system state.

[BrowserUk]

I hardly call making a reasoned guess "just guessing".

Sorry. But when the "reasoning" is nothing more than unfounded, unverified, 'pluck it out of thin air' speculation, there is no difference.

Care to explain what is going on? It certainly isn't what I thought.

No need. You just did.

• You guessed at what the problem might be. You made no attempt to verify your guess.
• You wrote a mountain of horribly complicated and convoluted code, with a frankly horrible interface.
• You used an architecture that could never address the stated problem, and that could never be implemented efficiently.

  Your current implementation uses 100% of one core when doing absolutely nothing at all.

• And then you threw it out there as a "solution", without having made even the most basic of tests that it met its stated goals.

And now you're going to make a big issue of the way I choose to bring these matters to your attention to divert from the real problem.

Oh! And BTW. There is no "intialization wipe-out bug". There is a clearly documented breach of new user expectations, that is easy to understand, and that has a documented solution. See shared_clone().

Albeit that, once you've written a few real applications, you'll find that it is rarely ever necessary to clone a non-shared data structure into a shared copy.

[ELISHEVA]

From perldocs 5.10.0 and 5.12.2

BUGS AND LIMITATIONS

When share is used on arrays, hashes, array refs or hash refs, any data they contain will be lost.

I also noticed it with my own eyes, testing some code last night.

[menth0l]

Check out shared_clone().

[BrowserUk]

AND LIMITATIONS.... Therefore, populate such variables after declaring them as shared.

[Anonymous Monk]

I hardly call making a reasoned guess "just guessing"

What is the difference? Esp when you don't preface your guesses as such? And they're frequently wrong?