Re: Splash Screens , how could something so basic still be hard?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance



On Thu, 23 Apr 2009 07:26:22 -0700, Ben Voigt [C++ MVP] <rbv@xxxxxxxxxxxxx> wrote:

Peter Duniho wrote:
On Tue, 21 Apr 2009 10:12:34 -0700, Ben Voigt [C++ MVP]
<rbv@xxxxxxxxxxxxx> wrote:

[...]
That's not true. In fact, for i/o use of threading can be the best
way to provide a scalable program. For example, using IOCP, which
in turn necessarily uses threading, is the most efficient way to
handle Socket i/o.

No. It's the most efficient way to do significant CPU-bound
processing triggered by socket I/O. I said "programs which are I/O
bound", which includes most database interfaces, many 3D
games/applications which are limited by GPU streaming, etc.

I suppose that depends on your definition of "CPU-bound". My
definition: more time is spent using the CPU than the i/o resource.

It means that throughput is limited by CPU performance.

Your definition is very confusing. How do you measure "time spent using the
I/O resource"?

That's the time the computer sits without any work to do, because it's waiting on the i/o resource.

The problem with writing "throughput is limited by CPU performance" is that you can turn an i/o bound problem into a CPU bound problem simply by adding unnecessary overhead to the implementation, creating a CPU bottleneck when there wasn't any need to have one. The phrase isn't specific enough to differentiate between a problem that is truly CPU-bound (i.e. there's simply no way to avoid using the CPU) and a problem that's limited by CPU performance simply because it's not using the CPU in the most efficient way.

But, even in a scenario where the i/o takes longer than the CPU cost,
using IOCP can benefit, due to efficiently managing the threads
processing the i/o. The classic example being a high-connection
network server. A single thread can be sufficient to handle hundreds
of thousands of active connections, but only if that single thread
isn't the only thread in your application.

Exactly what does having an additional thread buy you? I contend that on a
single core system, the optimum solution is single-threaded, for any
definition of optimum/cost function you care to use.

Great. We should let all those folks using IOCP for their high-volume servers that they can forget about that, and go back to a single thread solution when running on single-core CPU (and I assume from your statement they can also strictly limit their number of threads to the number of CPU cores generally).

The problem with your simplistic analysis is that there is overhead associated with trying to manage multiple sockets on a single thread that simply doesn't exist when you use IOCP. At the same time, if you're using only a single thread, it means that all of your i/o winds up serialized, which is a big problem if part of the handling of i/o operations on one resource (e.g. a network socket) involves doing some i/o on another resource (e.g. a file).

By introducing a threaded implementation, one can take advantage of IOCP and ensure that there is always a thread ready to handle an i/o operation that's completed, even while some other thread is stuck dealing with handling a previously completed i/o operation.

With respect to sockets, the particularly important part for the purposes of this question is that there simply is no efficient way to manage hundreds of thousands of sockets on a single thread, unless one is using IOCP, which necessarily requires writing threaded code. The alternatives simply have too much CPU overhead to be practical.

Pete
.



Relevant Pages

  • Re: Threading NOT working as expected
    ... doesn't mean a single thread is doing work at any time. ... Most of the time in a modern system is spent waiting for I/O and memory ... There are some very special cases where the CPU is actually ...
    (comp.lang.perl.misc)
  • IO WAIT Information From IBM
    ... the I/O wait metric in AIX. ... AIX scheduler, the CPU "queues", the CPU states, and the idle or wait ... To summarize it in one sentence, 'iowait' is the percentage ...
    (AIX-L)
  • userland starvation with 2.4.25-rc2
    ... I am trying to load the SCSI disk by doing in parallel: ... The upper graph is the CPU load, the lower graph is the I/O load. ... you can see, at certain points the kernel will take all available CPU, ...
    (Linux-Kernel)
  • Re: IO WAIT Information From IBM
    ... >understanding of how the I/O wait value is collected and calculated. ... >of the CPU resource. ... The wait processes only job is to increment the counters that report ... >Each CPU can be in one of four states: user, sys, idle, iowait. ...
    (AIX-L)
  • Re: IO WAIT Information From IBM
    ... >understanding of how the I/O wait value is collected and calculated. ... >of the CPU resource. ... The wait processes only job is to increment the counters that report ... >Each CPU can be in one of four states: user, sys, idle, iowait. ...
    (AIX-L)