Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re^3: Is Using Threads Slower Than Not Using Threads?

by BrowserUk (Pope)
on Nov 07, 2010 at 10:19 UTC ( #869889=note: print w/ replies, xml ) Need Help??


in reply to Re^2: Is Using Threads Slower Than Not Using Threads?
in thread Is Using Threads Slower Than Not Using Threads?

Oh dear. Think context!

To be more explicit. Think of the context in which I said what I said. Think of the purpose of that.

Just as newbies don't need to be appraised up front with the details of the inner working of the regex engine, they don't need to be appraised of the inner workings of threads. The point was simply that without having been shared, each thread will get an independent, unshared copy of the array.

Your interjection is:

  1. unhelpful;

    to the OP;

  2. unwarranted;

    My understanding of the internals of the iThreads is:

    1. perfectly sound thanks;
    2. irrelevant in the context of the assistance I was trying to give the OP.

    You don't need to be Jeff Friedl to help people with their regex problems. And if you were him, it wouldn't be useful to go into the all the DFA/NFA blah blah details of the internals when responding.

    And it seems to me that if you aren't aware of the semantic differences between the copying of non-shared arrays; and the sharing of shared arrays, you're the one lacking understanding. But, I know you almost certainly are aware of those differences, which just confirms that your interjection is ...

  3. therefore, politically motivated.

    Not intended to help the OP, but simply to come out in support of an untenable position.

Your time might be better spent where it would be most valuable. Eg. correcting some of the unnecessary extravagances of the current implementation.


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.


Comment on Re^3: Is Using Threads Slower Than Not Using Threads?
Re^4: Is Using Threads Slower Than Not Using Threads?
by ysth (Canon) on Nov 07, 2010 at 22:13 UTC

    In our last disagreement you would not even so much as recognize my arguments about context, just completely ignoring anything I said. And there you were taking one phrase out of its qualifying context. Here I am making an objection to a complete thought that was part of your reply to the OP; yes, not one pertinent to your main point.

    Why am I doing so? Because you seem to have elected yourself defender of ithreads to the point where you attack even true and reasonable cautionary points about them with a variety of shenanigans designed more to conceal than expose truth. The truth is that ithreads are a very different beast than people coming from other languages may expect. They are slow to start and tend to cause memory bloat. Anywhere there is support for copy-on-write fork, fork and some variety of IPC is almost always a better choice.

    If that's politics, so be it. Don't bother responding, I'm not going to read it.

    --
    A math joke: r = | |csc(θ)|+|sec(θ)|-||csc(θ)|-|sec(θ)|| |
    Online Fortune Cookie Search
    Office Space merchandise
      Don't bother responding, I'm not going to read it.

      Shame. You might have learnt a little history. It is all about the context in which something is said; and why it is said in that context.


      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.

        BrowserUk from 2003:

        The result is the only way to approach a 'safe' and cross-platform implementation of threads in perl is to emulate forking.

        and from 2005:

        Though I think if [Perl] threads did not try to emulate fork

        (underlining added by me). Then tye from 2010:

        Perl's "threads" came to be because no Perl porter was able to remove the race conditions from trying to use real threads with Perl. So they switched to using threads to emulate fork() but much less efficiently in both memory and CPU required.

        and a short time later:

        Perl protects its internals by making full copies of its internals (the interpreter state and all data) -- emulating fork but less efficiently.

        BrowserUk spawned multiple extended threads and subthreads railing against my stating that iThreads "emulate fork". Including such quotes as:

        iThreads do not emulate fork.

        (from Re^12: Utter FUD!, original emphasis preserved) and

        [Perl] Threads do not emulate fork

        (from Re^6: Utter FUD!) and

        But neither are [iThreads] new processes--forks defining characteristic--so any allusion to that is simplistic, inaccurate and deliberately misleading.

        (from Re^12: Utter FUD!). Plus lots of other complaining about people daring to mention "fork emulation".

        Unfortunately, I have no idea what motivated BrowserUk to so vehemently contradict himself. Nor what he has dreamed up that leads him to claim "Tye's statement has [...] a lot of political intent" nor why he considers it "simplistic, inaccurate", and (especially) "deliberately misleading" nor what makes him say "I may have my suspicions about his reasoning" and "I am wilfully understanding Tye's motivation".

        I have not seen even a solid hint as to what this "motivation" that BrowserUk has dreamed up is. Just the above extremely vague alluding to some secret motivation that I am hiding but that BrowserUk has sleuthed out but refuses to mention.

        Perhaps the strong reaction is BrowserUk (in part) reacting to his previously being "simplistic, inaccurate and deliberately misleading"? Maybe that was the point of linking to the "history lesson". If so, that certainly wasn't clear to me.

        I don't know. Note that I used quotations because, not understanding what BrowserUk is going on about, trying to paraphase would surely lead to worse mischaracterization (than the deliberate mischaracterization that will likely be claimed via willfully taking the quotes out of context). Well, I made it trivial to view the context in many cases, in case one is curious, and made the literal parts clear enough that super search can be used for the others.

        - tye        

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (6)
As of 2014-10-22 03:19 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (112 votes), past polls