Re: aws vs ruby rails or php? how much faster?

["Randy Brukardt" <randy@rrsoftware.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2357 bytes --]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> wrote in message 
news:op.wvzrlknsule2fv@cardamome...
Le Tue, 23 Apr 2013 12:08:15 +0200, Dmitry A. Kazakov
<mailbox@dmitry-kazakov.de> a écrit:

>> On Tue, 23 Apr 2013 09:10:39 +0200, Yannick Duchêne (Hibou57) wrote:
>>
>>> Asynchronous I/O can be achieved with Ada too, and that does not implies
>>> tasking, just wrapping what the OS provides for that.
>>
>> Oh, it does. I don't know what you guys are talking about, but 
>> asynchronous
>> I/O is intimately related to tasking.
>
>Yes it is, but as you said, it save tasks. The application doing 
>asynchronous I/O, does not even need to run multiple tasks, just only one 
>which is its own task, as the second may be required task can be provided 
>by the OS (and may be just interrupts, depending on the kind of I/O). When 
>I said "does not implies tasking", I wanted to underline the same as you 
>did, that it does not cost tasks.

True enough, but the *implementation* of asynchronous I/O matters just as 
much.

A bit of background: Janus/Ada uses it's own task management, so all tasks 
run inside of a single OS process/thread. In our web server running on 
Windows 2K, we tried to use asynchonrous socket I/O to prevent unintended 
blocking from socket calls. But the effect was that the server ran 10 times 
slower than using busy-waited socket I/O; effectively W2K used only a single 
OS thread to implement then asynchronous sockets and that effectively 
serialized everything going in and out of the server. So we had to remove 
that and return to the busy-waited sockets. [Two notes: the program uses Ada 
tasks; we just have to use the busy-waited sockets to avoid blocking the 
entire server if nothing is ready; the busy-wait loop contains a delay to 
allow other tasks to run if there is nothing to do. Tuning these loops to 
the way sockets I/O works (either the data is available immediately, or it 
is going to take a bunch of milleseconds before it will show up) keeps the 
overhead to a minimum. Second, I don't know if this is true on newer 
versions of Windows, I've never had reason to test it. The web server still 
runs on the 900 MHZ W2K server (soon to be retired in favor of a new Debian 
machine - with 3GHZ with 8 virtual cores - a rather different environment).

                                        Randy.