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!.POSTED!not-for-mail
From: Paul Rubin <no.email@nospam.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Large number of tasks slows down my program (using debian) - any
 fix?
Date: Fri, 30 Mar 2018 13:46:10 -0700
Organization: A noiseless patient Spider
Message-ID: <87h8ox1ect.fsf@nightsong.com>
References: <1aa8f536-250d-4bef-9392-4d936f916e5f@googlegroups.com>
	<9377f941-31d0-4260-818a-8e189aac8c19@googlegroups.com>
	<p9kuig$lq8$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: h2725194.stratoserver.net;
 posting-host="01aa9928abe6518b15b8a387973873bf";
	logging-data="22689"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+VSUtndzTJV9xuJ8Wmuoo8"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
Cancel-Lock: sha1:OAfbmgAVQvnBpqCpzwybWwHUm4Y=
	sha1:d+503L/RgkoVz+neHLlQhWFAWsk=
Xref: reader02.eternal-september.org comp.lang.ada:51255
Date: 2018-03-30T13:46:10-07:00
List-Id: <comp.lang.ada>

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> It is a simple calculation. Assuming a context switch were around
> 1000ns. x 500 tasks / 4 cores = 125ms if all tasks are busy. 125ms is
> a long time.

It's 125 microseconds or 1/8th of a millisecond, not that bad at all.  I
assume that's what you meant by ms.  I'm used to ms denoting
milliseconds while microseconds are written us.

Also keep in mind that 4-core Intel boxes typically have 8 hardware
threads ("hyperthreads" or logical cores) and there is basically no
context switch time between hyperthreads on a core.  They speed up total
cpu throughput because they allow another thread to run during the time
that the first thread is blocked on a hardware cache miss waiting for a
RAM operation.

> ...  Assuming the time quant is 10ms...: 10 x 500 / 4 = 1.25s [+125ms]
> is the time a task gets back to a core. 1.3s is an eternity.

Sure, if all 500 tasks are cpu-busy then things are in a dreadful state,
but usually the reason to use so many tasks is concurrent i/o, i.e. most
of the threads are blocked awaiting input.