Re: Splash Screens , how could something so basic still be hard?
- From: "Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx>
- Date: Thu, 23 Apr 2009 10:22:25 -0700
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
.
- Follow-Ups:
- Re: Splash Screens , how could something so basic still be hard?
- From: Ben Voigt [C++ MVP]
- Re: Splash Screens , how could something so basic still be hard?
- References:
- Splash Screens , how could something so basic still be hard?
- From: RvGrah
- Re: Splash Screens , how could something so basic still be hard?
- From: Michael B. Trausch
- Re: Splash Screens , how could something so basic still be hard?
- From: Peter Duniho
- Re: Splash Screens , how could something so basic still be hard?
- From: Michael B. Trausch
- Re: Splash Screens , how could something so basic still be hard?
- From: Peter Duniho
- Re: Splash Screens , how could something so basic still be hard?
- From: Michael B. Trausch
- Re: Splash Screens , how could something so basic still be hard?
- From: Ben Voigt [C++ MVP]
- Re: Splash Screens , how could something so basic still be hard?
- From: Peter Duniho
- Re: Splash Screens , how could something so basic still be hard?
- From: Ben Voigt [C++ MVP]
- Re: Splash Screens , how could something so basic still be hard?
- From: Peter Duniho
- Re: Splash Screens , how could something so basic still be hard?
- From: Ben Voigt [C++ MVP]
- Splash Screens , how could something so basic still be hard?
- Prev by Date: Re: Newbie: When to use typeof() function
- Next by Date: Re: Newbie: When to use typeof() function
- Previous by thread: Re: Splash Screens , how could something so basic still be hard?
- Next by thread: Re: Splash Screens , how could something so basic still be hard?
- Index(es):
Relevant Pages
|