Re: No call for Ada (was Re: Announcing new scripting/prototyping

From: Jerry Coffin (jcoffin_at_taeus.com)
Date: 02/17/04 

Date: Tue, 17 Feb 2004 02:19:52 -0700

In article <402F7EFC.9070304@noplace.com>, nobody@noplace.com says...
> Well, from my experience with benchmarking for realtime systems, we
> generally drew on sample code that was typical of our control systems.

That doesn't sound like anything I'd depend on for a realtime system --
to be meaningful in a realtime context, you normally need to look at a
worst case, not a typical one.

> We never attempted language-to-language benchmarking because we pretty
> much figured it was pointless.

I agree that it usually is -- I didn't intend to advocate comparing
languages at all, but merely to offer my opinion that the method being
advocated would render the results definitely pointless instead of only
probably pointless.

[ ... ]

> I'd offer again my observation that for probably 90% of the software
> development that goes on in the world, relative compiler/language
> inefficiency is a total non-issue and people ought not to sweat over it.

Quite true.

> Even if there was any truth to the "Ada is slow..." rumor (and a given
> compiler is twice as slow as some highly optimized C example?) you'll
> never even see it in most applications.

I suppose that depends on the applications you spend your time writing.
I agree that with the typical office applications (for example) a factor
of 2 (or even 10) in speed will rarely be noticed. OTOH, I've worked on
code for doing MPEG encoding. Back when I was working on it, a 1 GHz
(or so) Pentium III was about the state of the art, and with that my
code took around 3 to 3 1/2 hours to encode one hour of video. Most of
the other code I was aware of at the time was closer to 5 hours on the
same hardware. I suspect even with today's faster hardware this is
still over an hour -- and in a case like this, a factor of 2 is clearly
quite a big win.

I'm the first to admit that most applications aren't this compute-
intensive, but I'll also point out that MPEG encoding isn't exactly
unheard-of either, and there are a number of other tasks that are even
more so (e.g. cryptanalysis in many cases).

> One ought to then focus in on
> other important factors that go along with language selection such as
> available compilers, reliable implementations, improvements in error
> rates and/or productivity, available tools, available libraries,
> time-to-market issues, etc.

Generally quite true. 

-- 
    Later,
    Jerry.
The universe is a figment of its own imagination.

Relevant Pages

  • Re: No call for Ada (was Re: Announcing new scripting/prototyping
    ... > Well, from my experience with benchmarking for realtime systems, we ... > much figured it was pointless. ... > development that goes on in the world, relative compiler/language ... I suppose that depends on the applications you spend your time writing. ...
    (comp.lang.c)
  • Re: No call for Ada (was Re: Announcing new scripting/prototyping
    ... > Well, from my experience with benchmarking for realtime systems, we ... > much figured it was pointless. ... > development that goes on in the world, relative compiler/language ... I suppose that depends on the applications you spend your time writing. ...
    (comp.lang.ada)
  • Re: No call for Ada (was Re: Announcing new scripting/prototyping
    ... > Well, from my experience with benchmarking for realtime systems, we ... > much figured it was pointless. ... > development that goes on in the world, relative compiler/language ... I suppose that depends on the applications you spend your time writing. ...
    (comp.lang.cpp)