From: Hibou57 (Yannick Duchêne) on
Hello once again,

Here is a new quote about Ada, in another interesting context (no more LP
this time) :
http://gmarceau.qc.ca/blog/2009/05/speed-size-and-dependability-of.html

Lanny wrote (2009 dated, so let suppose it was Ada 2005):
> Several years ago, I was doing a one-programmer job to move a large
> medical-laboratory instrumentation control from DIBOL to Ada. I was
> using the open-source GNAT Ada compiler and the DIBOL compiler from
> Synergex, as I had to maintain the old DIBOL program while writing
> its replacement in Ada. Unfortunately, the project was canceled
> after three months of work when the laboratory was sold, but I was
> able to compare DIBOL and Ada with respect to the time needed to
> find and fix a bug, and Ada was a huge win. Most DIBOL bugs took a
> full day to run down, and the worst-case bugs required 4 days to run
> down. During the same three months, the large majority of Ada bugs
> were found and fixed in 15 minutes or less, and the most difficult
> one took 4 hours.

The interesting context, is that this comment was one after an article
containing interesting graphic charts comparing some measurable language
characteristics. Unfortunately, Ada is not part of any of these charts,
but there is this comment, and the charts which may be nice for your own
knowledge anyway.

--
No-no, this isn't an oops ...or I hope (TM) - Don't blame me... I'm just
not lucky
From: Georg Bauhaus on
On 2/13/10 11:04 PM, Hibou57 (Yannick Duch�ne) wrote:
> Hello once again,
>
> Here is a new quote about Ada, in another interesting context (no more
> LP this time) :
> http://gmarceau.qc.ca/blog/2009/05/speed-size-and-dependability-of.html

> The interesting context, is that this comment was one after an article
> containing interesting graphic charts comparing some measurable language
> characteristics. Unfortunately, Ada is not part of any of these charts,
> but there is this comment, and the charts which may be nice for your own
> knowledge anyway.


There is a chart "Ada 2005 GNAT" on the linked page, though.

*

The Shootout GCC compiler appears to have been updated to version 4.4,
recently.
- The good news:
As a consequence, the chameneos-redux Ada program is working
again.
- The bad news:
As a consequence, the chameneos-redux Ada program is working
again. It runs 16 times slower than the best Java
entry. Apparently Ada's median has moved from 1.xx to 2.xx.
I believe this is related.
(I'm not criticising, the program has been present for
a long time. It obviously is performing better than its
compiler :-)

The Ada solution uses full tasking and this seems to be showing
overhead here:
Each task in chameneos-redux does *very* little, but communicates
a *lot* with via POs, delays execution in a selective accept,
the POs have entries, ..., so I think it is Ada's tasking overhead.
I have tried using Ravenscar profile facilities instead (i.e. just
suspension objects entry-less tasks) but rewriting this requires
care (and skills, and time, and looking at different solutions...
and possibly the resulting code is helped by a run-time
that produces faster code if pragma Profile (Ravenscar)
is in effect).
From: Georg Bauhaus on
On 2/13/10 11:04 PM, Hibou57 (Yannick Duch�ne) wrote:
> Hello once again,
>
> Here is a new quote about Ada, in another interesting context (no more
> LP this time) :
> http://gmarceau.qc.ca/blog/2009/05/speed-size-and-dependability-of.html


Do you think source text size, not weighted, is a meaningful measure?
What is its meaning?

OCaml is remarkably close to (short, fast) there. Looking at the OCaml
Shootout programs, the OCaml cultr sms t favr sqizn vwls o of pgms,
nst funs a l+, & uz mth w.

I'm curious if OCaml will perform closer to Ada regarding source
size in case programs use full words for functions, most variables,
constants and so on, fewer embedded lambdas, etc.
(The measurement procedure for code size at the Shootout seems to
be this:
"We started with the source-code markup you can see, removed comments,
removed duplicate whitespace characters, and then applied minimum GZip
compression. The Code-used measurement is the size in bytes of that
GZip compressed source-code file."
http://shootout.alioth.debian.org/help.php#gzbytes )

From: Hibou57 (Yannick Duchêne) on
Le Sun, 14 Feb 2010 02:09:48 +0100, Georg Bauhaus
<rm-host.bauhaus(a)maps.futureapps.de> a écrit:
> Do you think source text size, not weighted, is a meaningful measure?
> What is its meaning?
The corner at the bottom-left, labelled “ Perfect language ”, was so at
the sole discretion of the author of this paper ;)
This kept apart, you're right to notice that there are measurements, there
are interpretations, and these are different things.
I have personally noticed memory consumption during runtime is also
missing (three dimensions would have been needed).

--
No-no, this isn't an oops ...or I hope (TM) - Don't blame me... I'm just
not lucky
From: Simon Clubley on
On 2010-02-13, Hibou57 <yannick_duchene(a)yahoo.fr> wrote:
> Hello once again,
>
> Here is a new quote about Ada, in another interesting context (no more LP
> this time) :
> http://gmarceau.qc.ca/blog/2009/05/speed-size-and-dependability-of.html
>
> Lanny wrote (2009 dated, so let suppose it was Ada 2005):
>> Several years ago, I was doing a one-programmer job to move a large
>> medical-laboratory instrumentation control from DIBOL to Ada. I was
>> using the open-source GNAT Ada compiler and the DIBOL compiler from
>> Synergex, as I had to maintain the old DIBOL program while writing
>> its replacement in Ada. Unfortunately, the project was canceled
>> after three months of work when the laboratory was sold, but I was
>> able to compare DIBOL and Ada with respect to the time needed to
>> find and fix a bug, and Ada was a huge win. Most DIBOL bugs took a
>> full day to run down, and the worst-case bugs required 4 days to run
>> down. During the same three months, the large majority of Ada bugs
>> were found and fixed in 15 minutes or less, and the most difficult
>> one took 4 hours.
>

I actually use DIBOL (along with other more traditional languages) as
part of my day job and there are times when I dream about replacing
it with Ada after tripping up over yet another language feature or not
been able to model a problem in the way I can in Ada.

Unfortunately, he doesn't say what features of the Synergex toolkit
he uses as it's more than just a compiler. Given it's intended use in
business applications, it contains, amongst other things, a forms toolkit
which will run on a character cell terminal and a file toolkit
which implements support for ISAM files with multiple and segmented keys.

The forms toolkit is actually quite advanced given it's character cell
requirements, containing the ability to define a form in terms of fields
containing different types of data (alpha, numeric, dates, etc) and
containing support for callback routines for custom field level validation.

I would love to find an open source equivalent of the forms and ISAM
toolkits which could be called from Ada.

Simon.

--
Simon Clubley, clubley(a)remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980's technology to a 21st century world