Re: Committing Resources to Win32

Joshua D. Drake wrote:

> Marsh wrote:
>
>> I would think that you could probably get 80% of the performance with
>> ordinary threads and ordinary blocking IO, and without the great
>> increase in complexity required to implement asynchronous IO. If
>> someone then wants to go after a possible 25% performance gain, they
>> could submit a working set of modifications, or wait a few months for
>> the hardware to catch up.
>>
> This argument doesn't work for several reasons:
>
> 1. Hardware generally does not catch up because:
>       A. Users demand increases and thus the load on the hardware
> increases.
>       B. Users don't purchase new hardware every couple of months.
> 2. If we were talking about a 5% performance gain that "might" be
> acceptable but
> the 20% gain you are talking about is huge. Think about it:
>
>    I have several customers right now that push over 250,000 (some as
> high as 750,000)
> transactions an hour. They are pushing the hardware hard as it is,
> especially with the
> limitations of Vacuum. If they were to move to the Win32 version (it
> doesn't matter why),
> they would loose 50,000 transactions an hour based on your argument.
>
>    That is completely illegitamate and would make PostgreSQL look like
> a toy on Windows.
> We already have PostgreSQL as a toy on Windows, it uses Cygwin.

OK, but are you using asych IO on any platform now?

Note that the original poster proposed it as a possible performance
enhancement, and I'm not claiming that a threaded blocking-IO
implementation on Windows is going to be slower than the current model
on Unix.

The hypothetical 25% gain really is a WAG that would probably only be
achievable for some current worst-case scenarios, but the point is it
represents a few months of hardware advance. If somebody's servers are
really that saturated, they will be looking at hardware upgrades sooner
rather than later, and a similar effect might achieved by throwing RAM
at the problem.

Ideally you would have a single process with exactly as many threads as
there are CPUs (maybe x2 for Intel HyperThreading chips). Each thread
would have affinity to a specific processor. All IO would be done
asynchronously and use coroutines/fibers for task switching.

Due to the complexity involved in implementing an app this way, it's
usually not done. Process- or thread-per-connection with blocking IO is
conceptionally much simpler and usually not that much slower. Efficient
CPU scheduling is one of the main functions of the mainstream OS, right?

- Marsh