nordsieck (lesprit.d@gmail.com) on 3/2/08 wrote:
>
>Precisely, but that is the whole point, isn't it? There
>is no payoff to have performance that isn't in the critical
>path.

Only very simplistic problems tend to have a well-specified
"critical path".

Quite often the performance profile is not at all a matter
of one clear core operation that can be abstracted out and
rewritten in some more efficient language. At some point in
the optimization game those nice profiles just look like a
muddle of spread-out costs, and then you're stuck.

And sometimes those spread-out costs are simply things like
cache misses and memory allocation and the cost of GC (or
even the startup costs of the environment). And when that's
part of the basic language and the fundamental model you've
chosen, you're kind of screwed.

So there are definitely cases where it doesn't matter one
whit that you can do your performance-critical parts in
some more optimizable language.

Latency-critical near-RT code tends to fall into this kind
of situation. The latency of garbage collection may simply
not be acceptable, even if it may not affect performance
"on average".

Sometimes low-level languages are simply better in the
long run, and any "prototyping" in a higher-level one
should literally be considered a throw-away stage.

But you seldom know up-front whether it's worth it (or even
what the problems will be), and from a practical perspective
you may well end up being stuck with your initial choice
(even if you intended for it to be a throw-away, you
might not be able to afford to rewrite it all).

Quite frankly, anybody who says that HLL's are always the
right choice is a moron. So is anybody who says that C is
always the right choice. It depends a lot on the target,
and probably even more so on the programmers involved.

Linus