comp.lang.ada
 help / color / mirror / Atom feed
From: "Jeff Creem" <jeff@thecreems.com>
Subject: Re: Expected bytes per sloc (semicolons) performance
Date: Wed, 19 Sep 2001 00:04:10 GMT
Date: 2001-09-19T00:04:10+00:00	[thread overview]
Message-ID: <_hRp7.7630$ot.1153235@typhoon.ne.mediaone.net> (raw)
In-Reply-To: 8f23da36.0109181403.52128d70@posting.google.com

This is one of those questions that comes up from time to time for which I
do
not think there is a great answer.

First to start off always be sure you are looking at just the resulting text
segment
(or perhaps text, data and const sections of the file) and not symbol
table/debug data.

Also be sure to at least know if you are including some run time overhead
that is
not impacted by the # of SLOC.

Now once you do this there is still the issue that code that looks like:

Some_Var := A ** 2 + B + C + D + E ;

will end up with very different results than code that looks like:

Some_Var := A ** 2;
Some_Var := Some_Var + B;
Some_Var := Some_Var + C;
.
.
.
And if one includes things like the constants segment  or initialized data
segment  then
of course all sorts of fun things crop up like the difference between

a : constant Some_Array(1 .. 10) := 0;
and
a : constant Some_Array(1 .. 100000) := 0;

(Ok boring constants like this are a bad example but you get the point).

The best one can hope for is some rough estimates for your code that perhaps
holds up over
some reasonable extrapolation as long as everyone writes code in the same
style.

As for RISC/CISC.... One sometimes ends up with slightly larger code on a
RISC than
CISC machine but this probably has almost as much to do with mandatory nops,
 missed delayed branch opportunities and alignment requirements as it does
with
the straight RISC/CISC issues.

One final point once you cross out of the target/compiler issues to
lang/target issues.
One should take into account the power of the language in trying to make a
comparison.
One could find that (totally hypothetical here) something like FORTRAN ends
up with half
of bytes per LOC as C++ but perhaps C++ is more expressive and can perform
the same
functionality in 1/3 of the lines of code.

"Mike Harrison" <mike_harrison80@yahoo.com> wrote in message
news:8f23da36.0109181403.52128d70@posting.google.com...
> Hello group,
>
> Using AdaMulti with a Sun/SPARC target I am seeing an average of 60 bytes
> per semicolon on a 5K project.
>
> Has anyone had a similar experience?
> Is this approximately what you should expect from an Ada compiler
> outputting to a RISC computer?
> If we moved from RISC to CISC would there be any difference?
> If we moved to GNAT would there be an improvement?
> Are there any resources out there with compiler/language/bytes-per-sloc
info?
>
> Thanks in advance.
> Mike





  reply	other threads:[~2001-09-19  0:04 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-18 22:03 Expected bytes per sloc (semicolons) performance Mike Harrison
2001-09-19  0:04 ` Jeff Creem [this message]
2001-09-19 10:13   ` Robert Dewar
2001-09-20  0:43     ` David B. Littell
2001-09-20 11:28       ` Steffen Huber
2001-09-20 13:10         ` Tarjei T. Jensen
2001-09-22 14:36           ` David B. Littell
2001-09-20 19:15   ` Mike Harrison
2001-09-21 14:02     ` Stephen Leake
2001-09-21 15:30       ` Mats Weber
2001-09-21 18:00         ` default
2001-09-24 17:03           ` Stephen Leake
2001-09-25 23:00             ` default
2001-09-25 16:08         ` tmoran
2001-09-25 16:44           ` Wes Groleau
2001-09-25 20:51             ` tmoran
2001-09-25 20:32           ` Stephen Leake
2001-09-25 21:04             ` Marin David Condic
2001-09-26 15:19               ` Stephen Leake
2001-09-26 16:58                 ` Marin David Condic
2001-09-21 16:22     ` Ted Dennison
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox