Re: ThreadPool Questions

Tech-Archive recommends: Speed Up your PC by fixing your registry

reeset wrote:
I think it would be helpful to step back and state some goals. What is it that you expect to gain by multi-threading this code?

I can tell you what I hope to gain -- I'm looking for a performance increase. The process works fine as it is -- but I'm starting to deal with multiple gigabyte files where the process use to take a handful of minutes is now taking 15-20 to process. The goal with attempting to thread the data processing step was to find a way to reduce the processing time. Since there's no gui involved, the user experience is less of an issue.

Okay, so the goal is improved performance. The next question is: in what way is your processing parallelizable? That is, why is it that using multiple threads _should_ improve performance?

If you are computationally bound (that is, it takes longer to process the data than to read it), _and_ you have more than one CPU to use (real CPUs, not Hyperthreading), then additional threads should help for sure.

Alternatively, if you can read the data from multiple sources at once and can use threading to parallelize the data retrieval, that could improve performance as well. In this case however, it's possible (probable, even) that you could achieve the same improvement without explicitly using the thread pool, and instead simply using the asynchronous i/o methods (Stream.BeginRead(), for example).

More theoretically, there is some possibility that you could even eliminate (or nearly so) the processing cost, if you are i/o bound. That is, you could put the processing in one thread and the i/o in another, with the processing thread pulling data from a queue the i/o thread feeds, dealing with it as fast as, and in parallel with, the i/o thread.

You wouldn't go any faster than the i/o restricts you to, but at least you would not have the cost of the processing added to the cost of the i/o.

In all of these scenarios, there's an upper limit to how many threads would actually be useful. In the CPU-bound case, it won't do you much good to have more threads than you have CPUs. In the i/o-bound cases, it will depend on the exact scenario. The latter design, in which i/o and processing are done in separate threads, would only require two threads, for example, and there'd be no benefit from additional threads.

Note that in none of those cases have I suggested that you assign a new thread per record. I don't believe that design would be _better_ performance-wise than something above, and because of the thread context switching, it could be much worse, depending on other costs.

If you believe that assigning a new worker queue item to each record, as in the design you've posted here, would improve performance then it would be helpful for you to explain why it is you feel that should improve performance. I don't think it should, but maybe there's something I'm missing regarding the overall design that explains that.

(Actually, the shared counter is intended to allow you to know when _all_ of the processing has been completed, not just one set; you haven't explained the need for processing data in "sets", so I haven't made an attempt to include that behavior in the discussion)

Well, the need is an artificial one, but one that I have to acommodiate.

What is the need for processing the data in sets? That is, the code you posted processes five at a time, halting all further processing until a single set of five has completed.

Essentially, users will expect the record order in the output file to match the order of input file for no other reason than that's how it's always been done. Ultimately, both individuals and the tools that can work with these datasets will need to make use of these output files will need to process the data sequentially so preserving order is unfortunately necessary.

The requirement that the data remain in order isn't surprising, and isn't related to my question about doing the processing in sets. Keeping the records in order won't be hard, no matter what you do, but that's not the question I was asking.

Pete
.

Relevant Pages

  • Re: Fast embedded architectures.
    ... >chips are all about. ... The design is fscked. ... can do a web server, custom I/O ... ip2k (and maybe the ip3k, ...
    (comp.arch.embedded)
  • Re: So, Poll is not scalable... what to do?
    ... >> where a specified number of threads handle many sockets? ... as I usually use somthing like epoll. ... > Blocking I/O is unavoidable for things like opening files, though, ... Is this a bad design? ...
    (Linux-Kernel)
  • Re: need a board automotive
    ... > Bob Stephens wrote: ... >>>design a control system for one of the parts. ... > voltages on power and I/O lines. ... and thermal management. ...
    (comp.arch.embedded)
  • Re: WriteFile()
    ... whether the I/O is synchronous or asynchronous doesn't change anything. ... With a direct-access storage device file, one can expect that WriteFile ... Again, when a timeout concept is NOT part of the design, a BLOCK call can ... let's apply your argument to ReadFile. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: WriteFile()
    ... It changes everything at the Win32 design consideration level. ... > With a direct-access storage device file, one can expect that WriteFile ... > if your program may perform I/O on a generic file handle, ...
    (microsoft.public.win32.programmer.kernel)