Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #26421

Re: Delayed "printf"

Show all headers | View raw

On Tue, 25 Apr 2017 10:44:38 +0200, David Brown
<david.brown@hesbynett.no> wrote:

>On 25/04/17 07:19, Robert Wessel wrote:
>> On Mon, 24 Apr 2017 19:42:30 -0500, Tim Wescott
>> <seemywebsite@myfooter.really> wrote:
>> 
>>> Sometimes it's necessary to float a notion just so that someone can 
>>> affirm your suspicion that yes, you really are an idiot.
>>>
>>> On the off chance that I'm a genius, though, here goes:
>>>
>>> I don't like putting "printf" in fast tasks for obvious reasons -- even 
>>> with infinite spooling, it can take time to process a format string.  In 
>>> my usual context, this can result in audible sounds from motors when I 
>>> print some bit of debugging information from a high-priority task.  The 
>>> problem can't be alleviated by spooling the output of the printf, because 
>>> it's the execution time of the printf itself that's the problem.
>>>
>>> Just how dumb is it to have "printf" queue up the format string AND the 
>>> parameters into a buffer, to be printed out in some low-priority task?  
>>> For a system with sufficient memory, this seems like an astonishingly 
>>> sensible thing to me.
>>>
>>> Clearly you'd have to wrap it up somehow so that if the buffer was full 
>>> no printf at all would happen -- but I'm kinda liking the notion.
>>>
>>> So -- whatcha think?
>> 
>> 
>> A problem is that finding all the input parameters, and copying them
>> someplace, may well be a considerable amount of work.  *Output*
>> parameters (%n, the return value), have already been mentioned, and
>> pose significant additional problems.
>> 
>> While copying something like an integer or float is going to be fairly
>> quick (assuming you have some place to put them already allocated),
>> and likely rather faster than than actually formatting them, you're
>> still going to have to do a non-trivial amount of parsing to actually
>> *find* those parameters.  And remember you have not just the
>> parameters, but the precision and min size can be specified as a
>> parameter ("*").  With strings, you have a worse allocation problem,
>> and copying the strings to a temporary area is going to be as much
>> work as actually processing them.
>> 
>> So at best, you're likely to only save a modest amount of CPU time in
>> the issuing thread formatting the output string, and quite possibly
>> that CPU usage in the main thread may be a non-trivial amount worse.
>> Overall CPU usage will certainly be worsened considerably.
>> 
>> OTOH, your real goal is to prevent the printf from blocking because it
>> lacks output space.
>> 
>> A simple way to do that is to perform an snprintf to a pre-allocated,
>> and fairly fixed size, buffer, and then pass *that* buffer to a
>> separate thread for output.  A better option may be to issue an
>> asynchronous I/O request (although you'll have to step outside of C
>> streams at that point).  If the available buffer is too small, you
>> have the choice of ignoring the output, or truncating it, and you have
>> several options for dealing with a new output request from the main
>> thread that happenes before the old buffer is disposed of (ignore,
>> block, have multiple available output buffers).
>> 
>> An advantage of doing the snprintf in the main thread, is that you
>> largely leave the semantics of printf unchanged.
>
>The problem with this approach is that snprintf is still doing most of
>the work that printf does - it is still a slow function.


My point was that the work of actually saving the parameters someplace
for another thread to use was also a substantial amount of work, and,
depending on how general you were being (for example, actually doing
that based on the variable input to a printf-like function), you might
well be doing *more* work on the issuing thread on many possible
printf calls.

While a front-end to printf might well be faster when parsing and
saving something like "xprintf("%f-%f", f1, f2)" compared to actually
executing the snprintf, it would almost certainly be *slower* than the
actual snprintf handing "xprintf("%s-%s", s1, s2)".

And that's ignoring all of the synchronization issues, and any work
involved in those.

Now if you had non-variable functions, where you didn't have to parse
the format string to find the parameters, and you then applied the
format only in the worker thread, that should help, but it's a much
less general solution, and will help only modestly in many cases.

In any event I thing I was reading the OPs message as being more
concerned with the possibility of the printf call blocking.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Delayed "printf" Tim Wescott <seemywebsite@myfooter.really> - 2017-04-24 19:42 -0500
  Re: Delayed "printf" Don Y <blockedofcourse@foo.invalid> - 2017-04-24 18:51 -0700
    Re: Delayed "printf" Tim Wescott <tim@seemywebsite.com> - 2017-04-24 21:54 -0500
      Re: Delayed "printf" Don Y <blockedofcourse@foo.invalid> - 2017-04-24 21:27 -0700
  Re: Delayed "printf" Paul Rubin <no.email@nospam.invalid> - 2017-04-24 19:53 -0700
  Re: Delayed "printf" Clifford Heath <no.spam@please.net> - 2017-04-25 13:01 +1000
    Re: Delayed "printf" Theo Markettos <theom+news@chiark.greenend.org.uk> - 2017-04-25 18:51 +0100
      Re: Delayed "printf" Clifford Heath <no.spam@please.net> - 2017-04-26 12:59 +1000
        Re: Delayed "printf" Theo Markettos <theom+news@chiark.greenend.org.uk> - 2017-04-26 13:24 +0100
  Re: Delayed "printf" Robert Wessel <robertwessel2@yahoo.com> - 2017-04-25 00:19 -0500
    Re: Delayed "printf" David Brown <david.brown@hesbynett.no> - 2017-04-25 10:44 +0200
      Re: Delayed "printf" Robert Wessel <robertwessel2@yahoo.com> - 2017-04-25 09:22 -0500
        Re: Delayed "printf" David Brown <david.brown@hesbynett.no> - 2017-04-25 16:37 +0200
    Re: Delayed "printf" Tim Wescott <tim@seemywebsite.com> - 2017-04-25 10:49 -0500
  Re: Delayed "printf" Jack <jack4747@gmail.com> - 2017-04-24 23:33 -0700
  Re: Delayed "printf" Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-04-25 08:09 +0100
  Re: Delayed "printf" John Devereux <john@devereux.me.uk> - 2017-04-25 08:14 +0100
  Re: Delayed "printf" David Brown <david.brown@hesbynett.no> - 2017-04-25 10:58 +0200
  Re: Delayed "printf" Stefan Reuther <stefan.news@arcor.de> - 2017-04-25 18:46 +0200
  Re: Delayed "printf" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2017-04-25 21:03 +0200
  Re: Delayed "printf" Tim Wescott <seemywebsite@myfooter.really> - 2017-04-25 16:11 -0500
    Re: Delayed "printf" Les Cargill <lcargill99@comcast.com> - 2017-04-25 17:28 -0500
    Re: Delayed "printf" Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2017-04-26 10:03 +0300
  Re: Delayed "printf" Dave Nadler <drn@nadler.com> - 2017-04-25 14:31 -0700
  Re: Delayed "printf" Les Cargill <lcargill99@comcast.com> - 2017-04-25 17:25 -0500
  Re: Delayed "printf" mac <acolvin@efunct.com> - 2017-04-26 17:22 +0000
    Re: Delayed "printf" Grant Edwards <invalid@invalid.invalid> - 2017-04-26 17:37 +0000
      Re: Delayed "printf" Grant Edwards <invalid@invalid.invalid> - 2017-04-26 17:38 +0000

csiph-web