in reply to Re: Sun Solaris (SPARC processor) + Threads + performance/optimization
in thread Sun Solaris (SPARC processor) + Threads + performance/optimization

see below the number of threads wanting for IO, its irrelevant...

Your test is bogus.

You cannot speed up IO to a single file by writing to it from multiple threads. The bottleneck is the disk transfer rate, not the CPU. By adding threads to the equation, you are adding unnecessary context switches and locking to the problem, which will slow things down, not speed them up

Your statistics are meaningless in the context of your original question. And your interpretation of them even more meaningless.


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.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."
  • Comment on Re^2: Sun Solaris (SPARC processor) + Threads + performance/optimization

Replies are listed 'Best First'.
Re^3: Sun Solaris (SPARC processor) + Threads + performance/optimization
by gulden (Monk) on Apr 16, 2009 at 21:59 UTC

    As you said, what I've said above is bogus, I'm not writing to a single file, but to one different file per Thread.

    You're also right in the remaining comment. I'm not taking advantage of the CPU because I serialize the processing.
    Because all the threads are competing for a lock on the same single data structure, so only one thread will ever doing anything useful at any given time. There are simple ways of avoiding this problem, but which is applicable depends upon what you are doing in your program.
    Your comment in this node is quite clear. Tomorrow I will change the code and do some more tests...
      I'm not writing to a single file, but to one different file per Thread.

      There is no way to know that from the code snippet you posted. And if each thread is writing to a different file, why are you mutexing? lock($x); $fh->print("$record\n"); Even your choice of mutex name seems calculated to obscure your real purpose.

      I'm not taking advantage of the CPU because I serialize the processing.

      Even if you weren't serialising, you still won't gain anything by throwing threads at an IO-bound process unless you can overlap the IO. If, for example, you needed to communicate with several remote servers, then assuming sufficient bandwidth, you can reduce the overall program time by overlapping the IO to those servers. Using 1 thread per concurrent server is an effective means of doing that.

      But, on the basis of your descriptions such as they are, and the code snippets you posted, removing the locking is unlikely to produce any substantial gain. The reason is that--unless your files are all on different drives--all your threads will be competing for throughput and latency of one disk drive.

      Ie. Even if you remove your serialisation, your concurrent writes will be serialised by the disk drive itself. The read head can only be in one place at one time, and so you can only be writing to one file at one time.

      There may be some small (tiny..you know, really, really small) gains as a result of filesystem write caching and DD-based write-extent re-ordering, but it's unlikely to be something you would be able to measure on a general purpose system with other concurrent activities. You'd have to use a laboratory conditions system to detect it. And those kind of gains are useless in real-world scenarios.


      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.
        I've started a new node related to this issue.