in reply to ithreads weren't the way.. still searching

If as you say you _need_ to get pages sequentially then threading appears pointless as the vast majority of the time will be taken getting the data, not processing it. It usually takes 2-4 seconds to get a page. The quantity of processing you can do in this sort of time is huge. I would be extremely suprised if the processing time was more than a few % of the total runtime with the rest of the time simply waiting on the socket for data. You are into much more fruitful territory if you can avoid a sequential get and do at least part of the getting in parallel. Or to put it another way the bottleneck is almost certainly the getting, not the processing. Optimisation that does not affect bottleneck points is pretty much a waste of time.

I suggest you prove that there is any benefit to be gained ie processing takes a significant % of the runtime before you waste your time producing the right solution to the wrong problem.

cheers

tachyon

  • Comment on Re: ithreads weren't the way.. still searching

Replies are listed 'Best First'.
Re^2: ithreads weren't the way.. still searching
by hlen (Beadle) on Oct 01, 2004 at 04:29 UTC
    You're right, of course.. I'm trying to make the best out of this, but there's definitely not too much to gain - profiling the code showed about 2 secs of processing in 18 of execution. But it seemed like an interesting situation. The ithreads limitations found *seemed* real (BrowserUk) =), and I wondered how to do what I set myself to at first, should I find myself in a similar position where real gain was at stake. Thanks

      If you use a machine gun to beat the enemy over the head...


      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "Think for yourself!" - Abigail
      "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon