Greg London Wrote:
[> John Redford wrote:]
> > you have a call stack, and you want code to execute "quickly" in order to
> > meet a time constraint (hard or not),
>
> > Now, checking every next() call to see if it
> > returns EOF (or sets some EOF flag variable) is inefficient,
>
> You're not thinking like an embedded controller engineer.
>
> You're trying to make your "best case" run faster.
...I think something has been lost here. You seem to be implying that writing
"fast" code does not matter for "embedded" code, because it runs against a
fixed clock. But that sounds wrong to me. I think of examples like graphics
display hardware. There are hard clock points in the process of going from
"ASCII" to "text on screen" or "vectors" to "rendered 3d graphics"; but that
does not mean that the code does not benefit from being "fast" -- it permits
higher resolutions, fancier graphics processing, and other dimensions of work
to be accomplished within that clock period.
I am saying that using exceptions as non-local-goto is one technique that can
make stuff fast. Sometimes makes sense; sometimes not; not a cure-all. And
fast is important in some code (but not all code or even most code).
More precisely, I am saying that the opposing (yet very popular) position --
exceptions should only represent unrecoverable error conditions and should be
very rare and should be implemented inefficiently -- is wrong.
> An embedded guy has to get their code to run at some frame rate.
> Say 30 hz. His code has to run one frame of data every 33 milliseconds.
> and then the processor goes to sleep until the timer wakes it up
> for the next frame.
>
> What does it mean if you're code is more "efficient" but still
> runs at 30 hz?
It means you can do more. Higher res, higher sampling, more complex
algorithms, etc. No?
> You're talking about the problem like someone used to programming
> for desktops. Make things run as fast as possible and slow things
> down as needed to get done. For example, you'd never read a file
> of unknown length in avionics or any kind of embedded controller
> application like an engine controller. At least not on a per-frame
> basis. You might dedicate so many clock cycles per frame to read
> some fixed number of bytes per frame, but you wouldn't have code
> that says "read until EOF" and then code it with an exception so
> that you respond to EOF more "efficiently".
I did say it was a classic example, not a claim about embedded controllers.
The point it is there to make is that one can avoid testing & branching (with
all the CPU-design-specific performance benefits (or not) that may entail).
> You're trying to make your best case better, and you worst case
> is how ever long it takes till you read EOF.
>
> Embedded controller guys have to make their worst case meet some minimum.
> And no open-ended processes are allowed per frame.
But.... Nothing about throwing exceptions is open-ended. It "simply" pops the
stack & starts to execute some other code. It's just a code path.
One could argue that such code paths are problematic to trace when overused;
but one could probably say the same about simple 'if' statements being used.
If you have 40 'if's in a function that depends on finishing in less time than
it would take to execute the heavy side of every branch, then you still have a
difficult static analysis problem. In some cases, exceptions could simply such
problems; in others they'd make them harder -- again, not a cure-all.
_______________________________________________
Boston-pm mailing list
[email protected]
http://mail.pm.org/mailman/listinfo/boston-pm
