in reply to Re^5: Module for transparently forking a sub?
in thread Module for transparently forking a sub?

Nothing too fancy - it's a Core 2 Duo T7200 @ 2GHz running Fedora 8. It was top-o-the-line when I bought it 1.75 years ago, but time marches on...

Frankly, I couldn't figure out what you were doing with dividing the time by $N-1, but I decided not to care since I could just do the same for threads and forks and they should be affected equally. Also, sleep(1) in a benchmark could create some interesting problems - the OS generally doesn't guarantee how long that will take, only that it will take at least 1 second.

-sam

  • Comment on Re^6: Module for transparently forking a sub?

Replies are listed 'Best First'.
Re^7: Module for transparently forking a sub?
by BrowserUk (Patriarch) on Feb 14, 2009 at 21:32 UTC
    it's a Core 2 Duo

    Okay. That explains it. Two cores versus one.

    I couldn't figure out what you were doing with dividing the time by $N-1,

    Actually, I'm dividing by $N and then subtracting one.

    The total time will be N*1 + N*(time of interest); so dividing by N gives 1 + (time of interest); -1 leaves (time of interest).

    The idea of the sleep was to simulate doing something else in the interim--there being no point in multitasking it, if all your going to do is wait for the results.

    Not a great benchmark I admit, but it did get me a set of numbers to consider, rather than just anecdotal "forks are faster than threads on *nix". Thanks :)

    ps. Suggesting that win32 is "DOS" is very tacky. 'sides, even if it was DOS, it'd still be a decade newer than that Multics derivitive that you seem to like :)

    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]

In Section Seekers of Perl Wisdom