Poor tasking performance

Poor tasking performance

[Adrian Knoth]

Hi,

I wrote a small proof-of-concept-algorithm which should be implemented
in assembler for a DSP-based hardware solution. Actually it uses
blocking file IO to read and write data from/to named pipes.
(read input data, calculate it, write output data. rate is defined
by the external reading process).

More or less fine, 6% CPU consumption. Yesterday I expanded the
program by a commandline frontend to interactively changing
values (coeffs for the calculation). Therefore I defined the
old serial calculation job as a (one) task and the user interface
as another (the program only has two tasks).

While the calculation "always" runs the user interface shows a
prompt and waits for the completion of Get_Line. When the user
terminates his statement by enter his inputline is parsed and
internal variables are changed accordingly.

Nothing spectacular. In general, it's all the same. Result: 18% CPU.

Is that normal? Only by adding one task which hangs in Get_Line
increases the load so much?

Environment is Linux 2.6.7 with Debian gcc-3.3 (unstable).


-- 
mail: adi@thur.de  	http://adi.thur.de	PGP: v2-key via keyserver

Morgenstund hat Gold im Mund, und Gold im Mund ist ungesund

Re: Poor tasking performance

[Robert I. Eachus]

Adrian Knoth wrote:

> Is that normal? Only by adding one task which hangs in Get_Line
> increases the load so much?
> 
> Environment is Linux 2.6.7 with Debian gcc-3.3 (unstable).

First, let me say you are lucky to get working results with that 
combination. Most Ada users have skipped gcc-3.3.  (I haven't switched 
from 3.15p to gcc-3.4 yet, but that is my intent at some point.)

But I don't think that your question can be answered in an Ada context. 
  This is definitely an area where the underlying OS implementation of 
reading from the console is going to account for most of the overhead.

If you are using Get_Immediate in Text_IO, you could switch to line at a 
time reading and see if that helps.  But I suspect that it won't--the OS 
needs to poll the UART that buffers keyboard input at a certain rate to 
avoid losing characters. With a different keyboard, or keyboard driver, 
you might get very different results.


-- 

                                           Robert I. Eachus

"Reason and experience both forbid us to expect that national morality 
can prevail in exclusion of religious principles." -- George Washington

Re: Poor tasking performance

[Adrian Knoth]

Robert I. Eachus <rieachus@comcast.net> wrote:

>> Is that normal? Only by adding one task which hangs in Get_Line
>> increases the load so much?
>> Environment is Linux 2.6.7 with Debian gcc-3.3 (unstable).
> First, let me say you are lucky to get working results with that 
> combination.

Ok, I can give gcc-cvs a try, let's see if it helps.

>   This is definitely an area where the underlying OS implementation of 
> reading from the console is going to account for most of the overhead.

I don't think the overhead is caused by Get_Line, but by tasks.

Get_Line can sleep until the OS wakes the thread up by a signal.
But I don't know if my runtime environment uses threads and
if they are wakeup-able ;)

> If you are using Get_Immediate in Text_IO, you could switch to line at a 
> time reading and see if that helps.  But I suspect that it won't--the OS 
> needs to poll the UART that buffers keyboard input at a certain rate to 
> avoid losing characters. 

Keyboard is interrupt driven.

I'll remove the Get_Line and see how much a serial program,
written as a task, will consume. If it's equal to the non-tasking
implementation I'll create a null-task to achieve some switching.


-- 
mail: adi@thur.de  	http://adi.thur.de	PGP: v2-key via keyserver

Natuerlich benutze ich Windows...$#��A NO CARRIER

Re: Poor tasking performance

[Björn Persson]

Robert I. Eachus wrote:

> the OS 
> needs to poll the UART that buffers keyboard input at a certain rate to 
> avoid losing characters.

What kind of hardware doesn't use interrupts for keyboard input?

-- 
Björn Persson

jor ers @sv ge.
b n_p son eri nu

Re: Poor tasking performance

[Robert I. Eachus]

Bj�rn Persson wrote:

> What kind of hardware doesn't use interrupts for keyboard input?

It is amazing the way hardware goes around in circles. ;-) Once upon a 
time, computers used polling for some input devices because the overhead 
of interrupts was too high, and there were only a few interrupts available.

Then as the hardware got smarter, and interrupt overhead was reduced, 
interrupt-driven IO was popular.

Then came DMA (direct memory access) with interrupts only used for 
signalling.

And finally we are back to polling for some devices because the overhead 
is lower than using interrupts...

For keyboard input most systems, most of the time, use a protocol where 
_some_ keys cause interrupts, and others just place the data in a 
buffer.  When the carriage return or whatever occurs, the entire buffer 
is read.

However, sometimes you want to read every keystroke immediately.  On 
some systems this is done by polling rather than changing hardware 
settings.  That is why I asked if he was using Get_Line, or 
Get_Immediate.  On some hardware and OS combinations, Get_Line has very 
low overhead, but Get_Immediate does polling.


-- 

                                           Robert I. Eachus

"Reason and experience both forbid us to expect that national morality 
can prevail in exclusion of religious principles." -- George Washington

Re: Poor tasking performance

[Adrian Knoth]

Robert I. Eachus <rieachus@comcast.net> wrote:

> settings.  That is why I asked if he was using Get_Line, or 
> Get_Immediate.  On some hardware and OS combinations, Get_Line has very 
> low overhead, but Get_Immediate does polling.

I clearly stated that I'm using Get_Line.


-- 
mail: adi@thur.de  	http://adi.thur.de	PGP: v2-key via keyserver

Laut Statistik ist die Ehe die Hauptursache aller Scheidungen

Re: Poor tasking performance

[Björn Persson]

Robert I. Eachus wrote:

> And finally we are back to polling for some devices because the overhead 
> is lower than using interrupts...

I can imagine that, but I doubt the keyboard is one of those devices.

> For keyboard input most systems, most of the time, use a protocol where 
> _some_ keys cause interrupts, and others just place the data in a 
> buffer.  When the carriage return or whatever occurs, the entire buffer 
> is read.

When I press a key, in most cases either a character shows up on the 
screen or some action is triggered. I suppose modifier keys (Shift, 
Ctrl, ...) and "dead" accents could be buffered. Right now I can only 
come up with one case when letters don't have to be read immediately: 
when the user is typing a password and characters are neither echoed nor 
indicated with asterisks.

-- 
Björn Persson

jor ers @sv ge.
b n_p son eri nu

Re: Poor tasking performance

[Robert I. Eachus]

Bj�rn Persson wrote:

> When I press a key, in most cases either a character shows up on the 
> screen or some action is triggered. I suppose modifier keys (Shift, 
> Ctrl, ...) and "dead" accents could be buffered. Right now I can only 
> come up with one case when letters don't have to be read immediately: 
> when the user is typing a password and characters are neither echoed nor 
> indicated with asterisks.

Ah, but look at it this way--which is what the computer actually does. 
The effect of generating a new screen image to be displayed has to be 
done once per screen refresh, which is typically today in the range of 
60 to 100 times per second.  There is no need for an additional 
interrupt to read the keyboard in between screen refreshes most of the time.

Of course, the Get_Immediate call in Ada should support exactly that. 
Why?  Lots of random number seed generators use the number of 
microseconds between keypresses to generate secret keys.  If the times 
measured are multiples of the screen refresh clock, your secret key may 
not be all that secret.  (Most algorithms do detect how much entropy 
they are getting per keypress, so the real cost is that you have to type 
for a lot longer.)

-- 

                                           Robert I. Eachus

"Reason and experience both forbid us to expect that national morality 
can prevail in exclusion of religious principles." -- George Washington