in reply to Re^10: how to split huge file reading into multiple threads
in thread how to split huge file reading into multiple threads

Lets say he has split the huge file into 10 parts and he runs 10 threads. Using your schema, he would require one pipe for each of the 600 output files in each of the 10 threads; and another 600 threads running select loops to coalesce the records and write them to the 600 output files. So 610 threads and 6000 pipes!

That is not how I see it being done, and you clearly misunderstand what the pipes are doing, and as usual you use incorrect math to make the problem seem worse, somehow hoping it will prove your point. Not today, my man.

First there would only be 10 pipes, if there were 10 threads. The main thread can open as many disk files as it wants, and as the data comes into the select loop, some logic can be applied to determine which of his 600 output files it gets written to. The select loop would act as a central collection point/filter, allowing one piece of logic to decide where any thread output should be ultimately be written.

Its simple: the threads write to the select loop, the select loop decides where the particular data should be written. Otherwise he would need to incorporate the logic for which file to output to, into each thread, AND THEN have to worry about flocking those files. My method avoids that flocking problem by making the select loop the master disk writer and filter.

I'm not really a human, but I play one on earth.
Old Perl Programmer Haiku ................... flash japh
  • Comment on Re^11: how to split huge file reading into multiple threads

Replies are listed 'Best First'.
Re^12: how to split huge file reading into multiple threads
by BrowserUk (Patriarch) on Sep 02, 2011 at 16:32 UTC
    My method avoids that flocking problem...

    There was no flocking problem until you created it.

    Its simple:

    Simple? Take 1 big input file and split it into N bits.

    Run N thread reading those N bits (concurrently, causing the disk head to dance all over the disk), and then write all the records read down N pipes.

    Then have a select loop that brings all the records from all the pipes back together in a single thread before deciding what to do with them.

    You really don't see that all you've achieved with those 10 threads and 10 pipes is the equivalent of:

    while( <HUGEFILE> ) {
    ...
}

    [download]

    Except it will run at least 10 times more slowly, regardless of how many cores your processor has!

    That really isn't just glaringly obvious to you?

    This is simple. And fast. And platform independent.

    No threads. No pipes. No pointless select loop (which doesn't work with pipes on some platforms anyway)...

    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]
[d/l]
[reply]

In Section Seekers of Perl Wisdom