From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!gegeweb.org!news.ecp.fr!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: What exactly is the licensing situation with GNAT? Date: Thu, 20 Nov 2014 15:23:14 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <87389olqie.fsf@ixod.org> <19fa65d4-72c9-44ab-b44b-4ea0929c18f2@googlegroups.com> <25731193-c0b5-4ab7-87ff-ba8c6a42cdbd@googlegroups.com> <1se4bvo6gaqft.16cfjaiketlz0$.dlg@40tude.net> <13efsbp4ynti1.1qsb6buqa4a60.dlg@40tude.net> <1lxkqa97hflr0.1c0bm39tzl8ty$.dlg@40tude.net> <2k62zlcocx1l$.1cg687ltl85l9.dlg@40tude.net> NNTP-Posting-Host: 24-196-82-226.static.mdsn.wi.charter.com X-Trace: loke.gir.dk 1416518595 15265 24.196.82.226 (20 Nov 2014 21:23:15 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 20 Nov 2014 21:23:15 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:23577 Date: 2014-11-20T15:23:14-06:00 List-Id: "Dmitry A. Kazakov" wrote in message news:2k62zlcocx1l$.1cg687ltl85l9.dlg@40tude.net... > On Wed, 19 Nov 2014 17:59:11 -0600, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" wrote in message >> news:1lxkqa97hflr0.1c0bm39tzl8ty$.dlg@40tude.net... >>> On Tue, 18 Nov 2014 16:25:03 -0600, Randy Brukardt wrote: >>> >>>>> Depends on how you measured it. Latencies may increase for obvious >>>>> reason >>>>> of context switching. The rest should have no influence. >>>> >>>> I probably mispoke; I think I was mainly concerned about server load >>>> than >>>> raw performance (the public Internet, after all, is relatively slow >>>> compared >>>> to a computer). And it made the web server use 10 times the CPU (or >>>> something in that range) compared to "smart" busy-waiting using >>>> blocking >>>> sockets. The resulting server load made the server unusable (it would >>>> have >>>> taken 100-150% of the available CPU to provide decent performance). >>> >>> I see. However measuring load under Windows is a tricky part. You might >>> have 10% visible load and 100% real load, because the performance >>> counters >>> count only fully used time quants. So, I would guess, that polling, >>> which >>> does not actually switches, threads would show system load close to the >>> reality, while in the case of blocking it could be much lesser than >>> actual. >> >> True, server load could be undercounted because of that Windows bug. But >> it >> can't be anywhere near 100%, since the mail filter and the various >> monitors >> and tools all use their share of CPU as well (the monitors and especially >> the spam reviewing tool were near unusable with the non-blocking >> implementation, they couldn't get enough CPU time). >> >> Remember, there isn't much blocking going on with a Janus/Ada program. >> The >> runtime will only block if all tasks are blocked or waiting on delays (in >> the web server case, 20 worker tasks plus a couple management tasks) [and >> only if the delays are long enough that the OS will usually wake up the >> program with plenty of time to spare]. You might get some blocking from >> reading in files (web pages in this case) or from reading from a socket >> that >> is already ready, but the latter makes little sense and the former also >> should happen infrequently (if caching and pre-reads are working as they >> should). So I wouldn't expect a vast difference caused by truncated time >> slices in a Janus/Ada (GNAT might be very different). > > The difference appears when a worker task gets blocked before it spent its > quant. The shorter wake-up intervals are, and the more worker tasks exist, > the bigger is the error. If individual filtering action is not time > consuming (does not spread across hundreds of quants) the error might be > considerable. But you seem to have missed my point: in Janus/Ada, task blocking is irrelevant. If a task blocks in an Ada sense, that just causes the task supervisor to select a different task to run. The OS is not involved unless there is *no* task ready to run. So, in general, a Janus/Ada program will use full quants. Specifically for the web server, there are three possible reasons for the a worker task to block: (1) No data is ready on the socket. A delay will be executed in that case, and some other worker task will run. Only if NO worker is ready to run will Sleep be called (and the quant given up). (I'm assuming that checking for data on a socket doesn't block the application at all, because if it did, it would completely defeat the purpose of the operation.) [Note that originally, Janus/Ada *never* gave up it's slice. That's a relatively recent change intended to make Claw programs better citizens when sitting in the background doing nothing. They used to use 10% of the CPU even then.] (2) The socket reports it has data to read, and it blocks for some reason in returning that data. This is possible, I suppose, but it makes no sense to me. (3) The socket is not ready for writing. This is the same as (1). (4) A socket write blocks when it reports that it can accept data. This should be rare (it would mainly occur if some buffering issue came up, and we write relatively small amounts of data at a time to reduce the likelyhood of overfilling buffers). (5) Input of a web page blocks. Since that's file I/O, whether or not it blocks will depend on caching and pre-reading; clearly it will block sometimes. So, the primary reason that the Janus/Ada-compiled webserver would block and give up part of its timeslice is from file input (5). That is going to be the same whether blocking or non-blocking sockets are used. The cost difference suggests that polling is cheaper (for Janus/Ada, which doesn't give up its slice easily) than waiting for Windows to send a notification that data is ready, even though the basic mechanism is pretty similar. (After all, Claw polls Windows for notifications, so the effect is essentially the same at the low level.) I had to assume that there was some massive expense associated with the non-blocking sockets notifications inside of Windows -- profiling showed that the CPU load wasn't in the Ada code (not even in the interface code). I gave up at that point and switched back to basic polling with blocking sockets. As I said, the situation would be very different for GNAT, where each worker task is a different thread. That would most likely block each worker task early for a polling implementation, so hardly anything would be counted. In which case your concern would have been justified. But I didn't run this test with GNAT. Randy.