Expected bytes per sloc (semicolons) performance

Expected bytes per sloc (semicolons) performance

[Mike Harrison]

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

Re: Expected bytes per sloc (semicolons) performance

[Jeff Creem]

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

Re: Expected bytes per sloc (semicolons) performance

[Robert Dewar]

"Jeff Creem" <jeff@thecreems.com> wrote in message news:<_hRp7.7630$ot.1153235@typhoon.ne.mediaone.net>...
> 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.

This is a misleading assessment. First of all most modern
RISC machines do not have mandatory nops etc, so you are
really talking about old style architectures here.

Second, these days CISC in practice means ia32 (and we
now include x86-64) and the code for this architecture 
is significantly more compact, not just slightly. And
the reasons are not the ones you gave above, but rather
that this architecture has many short instructions, e.g.
normal references to the local frame are 2-byte instructions instead
of 4-bytes, as are most conditional
jumps and normal register/register arithmetic. This can
add up to a big and significant difference, which can
translate into significant icache advantages. This is one
of the reasons that this architecture does "better than
expected" when compared to RISC designs.

Re: Expected bytes per sloc (semicolons) performance

[David B. Littell]

Robert Dewar wrote:
> 
> "Jeff Creem" <jeff@thecreems.com> wrote in message news:<_hRp7.7630$ot.1153235@typhoon.ne.mediaone.net>...
> > 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.
> 
> This is a misleading assessment. First of all most modern
> RISC machines do not have mandatory nops etc, so you are
> really talking about old style architectures here.
> 

Both MIPS (including MIPS32) and ARM processors provide a branch delay
slot which may or may not be useful to the compiler.  And the MIPS still
has all those nasty pipeline hazards which definitely require nops to
negate.

I guess I'm not sure what a "modern" RISC is - each of the "big three"
(MIPS, ARM, PowerPC) is haunted by legacy grodiness.  This seems
especially true of the MIPS - the canonical "drunken frat boy" 4th-year
student project. 

;-)


Dave

Re: Expected bytes per sloc (semicolons) performance

[Steffen Huber]

"David B. Littell" wrote:
> Robert Dewar wrote:
> > "Jeff Creem" <jeff@thecreems.com> wrote:
> > > 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.
> >
> > This is a misleading assessment. First of all most modern
> > RISC machines do not have mandatory nops etc, so you are
> > really talking about old style architectures here.
> >
> 
> Both MIPS (including MIPS32) and ARM processors provide a branch delay
> slot which may or may not be useful to the compiler.

I don't know much about the MIPS architecture, but are you sure about the
ARM? AFAIK, there is no such thing as a branch delay slot. Branches are
(after flushing the pipeline of course) taken directly.

[snip]
> I guess I'm not sure what a "modern" RISC is - each of the "big three"
> (MIPS, ARM, PowerPC) is haunted by legacy grodiness.

Oh come on. The ARM is surely the cleanest commercially available
processor architecture - at least until they added the THUMB extensions...

[snip]

Steffen

-- 
steffen.huber@gmx.de               steffen@huber-net.de
GCC for RISC OS  - http://www.arcsite.de/hp/gcc/
Private homepage - http://www.huber-net.de/

Re: Expected bytes per sloc (semicolons) performance

[Tarjei T. Jensen]

Steffen Huber wrote 
>I don't know much about the MIPS architecture, but are you sure about the
>ARM? AFAIK, there is no such thing as a branch delay slot. Branches are
>(after flushing the pipeline of course) taken directly.

When the ARM arrived the branch delay was published widely.

I know nothing about MIPS peculiarities.


greetings,

Re: Expected bytes per sloc (semicolons) performance

[Mike Harrison]

Thanks for the responses.  Sorry the thread turned into a RISC discussion.

So let me try to get back on track with a different question:
If you were bidding a 5K sloc estimated size program (algorithmic in 
nature) to go into a satellite with limited memory, what sort of 
bytes/per sloc estimate would you use, 5, 10, 20, 50, 100?  Our
experience is 50 or more.  Is this what others are seeing
with today's Ada compiler technology?

Mike

Re: Expected bytes per sloc (semicolons) performance

[Stephen Leake]

mike_harrison80@yahoo.com (Mike Harrison) writes:

> Thanks for the responses.  Sorry the thread turned into a RISC discussion.
> 
> So let me try to get back on track with a different question:
> If you were bidding a 5K sloc estimated size program (algorithmic in 
> nature) to go into a satellite with limited memory, what sort of 
> bytes/per sloc estimate would you use, 5, 10, 20, 50, 100?  Our
> experience is 50 or more.  Is this what others are seeing
> with today's Ada compiler technology?

Hmm. I've never had to actually do such a bid, but I am a Rocket
Scientist, and I've been on the receiving end of such bids, so I'll
venture an opinion :).

I'd do a prototype on the target processor, and measure it. Second
best is to find similar code on a similar processor, and measure that.

If I was on your bid review committee, that's what I'd look for. 

If you don't have a working target processor yet, and you don't have a
simulator, and there is no "similar" processor - pick another
processor!

Rules about n bytes per sloc are just too processor, compiler, and
coding style dependent to be useful.

I guess I need to say I am _not_ speaking for NASA here, just me.

-- 
-- Stephe

Re: Expected bytes per sloc (semicolons) performance

[Mats Weber]

>Rules about n bytes per sloc are just too processor, compiler, and
>coding style dependent to be useful.

I would put a big emphasis on coding style here. If you use a lot of
generics, the code will be generated once for each instance in most
implementations.

Re: Expected bytes per sloc (semicolons) performance

[Ted Dennison]

In article <8f23da36.0109201115.2f708535@posting.google.com>, Mike Harrison
says...
>
>Thanks for the responses.  Sorry the thread turned into a RISC discussion.
>
>So let me try to get back on track with a different question:
>If you were bidding a 5K sloc estimated size program (algorithmic in 
>nature) to go into a satellite with limited memory, what sort of 
>bytes/per sloc estimate would you use, 5, 10, 20, 50, 100?  Our
>experience is 50 or more.  Is this what others are seeing
>with today's Ada compiler technology?

I'm not sure I'd want to use a random number from a newsgroup in such a
calculation. A lot of folks here don't work in such constricted memory
environments, and are apt to go "hog wild" on memory from time to time. To give
you an idea, on my last job, I inadverntantly ended up needing a data buffer of
> 100MB. I offered to recode the thing, but was told that it would be easier (and cheaper) to just respec the system using newer motherboards loaded with 1GB of RAM! (Which they promptly did). We run in a non-embedded real-time environment (simulations), so speed and regularity is much more important to us than memory usage.

Also, I'd expect the count to be affected by style factors such as how large
subprograms tend to be and how many subprograms and declarations are placed in
one package, how extensively generics are used, use of tagged types and dynamic
dispatch, optimization, etc.

For the record, on the project I just mentioned there are currently 79K SLOC
(according to ada_count) generating an executable of 12.5MB. That would work out
to very roughly 150 bytes/SLOC. If you throw in the debug symbol file, that
number would more than double. However, this includes a few things linked in,
such as the GreenHills ada library which is about 900K by itself. But factoring
that stuff out doesn't change the final number much.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Expected bytes per sloc (semicolons) performance

[default]

Mats Weber wrote:
> 
> >Rules about n bytes per sloc are just too processor, compiler, and
> >coding style dependent to be useful.
> 
> I would put a big emphasis on coding style here. If you use a lot of
> generics, the code will be generated once for each instance in most
> implementations.

I agree there is a relation between coding style and bytes/sloc.

But I don't understand the specific denigration of generics, which I've
heard occasionally. It seems to me the alternative to generics is
nearly-duplicate packages and procedures, usually created by brute-force
cut-and-paste in a text editor. You end up with the same amount of
object code, but with the disadvantage that it is harder to maintain
than if you had used generics.

Is there a flaw in my reasoning?

-- Joel

Re: Expected bytes per sloc (semicolons) performance

[David B. Littell]

"Tarjei T. Jensen" wrote:
> 
> Steffen Huber wrote
> >I don't know much about the MIPS architecture, but are you sure about the
> >ARM? AFAIK, there is no such thing as a branch delay slot. Branches are
> >(after flushing the pipeline of course) taken directly.
> 
> When the ARM arrived the branch delay was published widely.
> 
> I know nothing about MIPS peculiarities.
> 

Steffen was quite right - the ARM doesn't implement delayed branches. 
My mistake.

He's also right in that the ARM is probably the cleanest of all the
commonly used architectures.  But I still think all those special
exception-time mode registers are pretty grody.  ;-)

Sorry to derail the semicolon performance thread.  We now return you to
the regularly scheduled AdaOS feature dreams...


Dave

Re: Expected bytes per sloc (semicolons) performance

[Stephen Leake]

default <joel_seidman.NOESPAME@yahoo.com> writes:

> Mats Weber wrote:
> > 
> > >Rules about n bytes per sloc are just too processor, compiler, and
> > >coding style dependent to be useful.
> > 
> > I would put a big emphasis on coding style here. If you use a lot of
> > generics, the code will be generated once for each instance in most
> > implementations.
> 
> I agree there is a relation between coding style and bytes/sloc.
> 
> But I don't understand the specific denigration of generics, which I've
> heard occasionally. It seems to me the alternative to generics is
> nearly-duplicate packages and procedures, usually created by brute-force
> cut-and-paste in a text editor. You end up with the same amount of
> object code, but with the disadvantage that it is harder to maintain
> than if you had used generics.
> 
> Is there a flaw in my reasoning?

I didn't get a "denigration of generics" from this. Mats is merely
pointing out that a style that uses generics will have a _much_ higher
number for bytes/sloc than a style that doesn't. This is neither bad
nor good; it's just a fact. It does argue that "bytes/sloc" is not a
useful measure.

It could also be that a particular application domain will lend itself
more to generics than some other domain, independent of programmer
style.

The one reason I have sometimes not used a generic was when the
debugger did not support them. This was true for Alsys Ada, and is
still true for Tartan Ada (both Ada 83). The GNAT debugger supports
generics; I'm not sure of other current compilers.

-- 
-- Stephe

Re: Expected bytes per sloc (semicolons) performance

[tmoran]

Just glancing at a few things, 50 bytes/sloc doesn't seem unreasonable.

>>Rules about n bytes per sloc are just too processor, compiler, and
>>coding style dependent to be useful.
>
>I would put a big emphasis on coding style here. If you use a lot of
>generics, the code will be generated once for each instance in most
>implementations.
  But those implementations that share generic code would show the opposite
effect.

Re: Expected bytes per sloc (semicolons) performance

[Wes Groleau]

tmoran@acm.org wrote:
>   But those implementations that share generic code would show the opposite
> effect.

How many such exist?

Note that even if generics are not shared,
there are sometimes ways to make the generic
small and depending on (shared) non-generic
packages.  (Further complicating the original
question)

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Expected bytes per sloc (semicolons) performance

[Stephen Leake]

tmoran@acm.org writes:

> Just glancing at a few things, 50 bytes/sloc doesn't seem unreasonable.
> 
> >>Rules about n bytes per sloc are just too processor, compiler, and
> >>coding style dependent to be useful.
> >
> >I would put a big emphasis on coding style here. If you use a lot of
> >generics, the code will be generated once for each instance in most
> >implementations.
>   But those implementations that share generic code would show the opposite
> effect.

Yes. So once again, bytes/sloc is a non-useful measure.

-- 
-- Stephe

Re: Expected bytes per sloc (semicolons) performance

[tmoran]

> >   But those implementations that share generic code would show the opposite
> > effect.
>
> How many such exist?
  I've been using RR Software's Janus for many years and it does shared
generics.  I'm told that's because its original target platform was
a 640K PC so code size mattered.
  Just looking at a few programs on my disk, I see:
half dozen small DOS *.com programs in Janus Ada 83 lie close to:
  com file bytes = 56 * source_lines + 19500
modest Ada95 program
  3180 sloc->192000 exe,  60 bytes/sloc
more substantial Ada 95 program
  13088 sloc->537600 exe, 41 bytes/sloc

Re: Expected bytes per sloc (semicolons) performance

[Marin David Condic]

Wellllll........ Maybe not *totally* useless. In the early phases of a
project you need to get some half-way reasonable grasp on what you think
you're going to need in the way of memory. So maybe you've got experience
with a similar application and you can run some or all of its code through a
known compiler and see what you get in terms of bytes/sloc. The next step
would be to come up with some WAG about what you think you'll have in SLOCs
and use your bytes/sloc as a very crude yardstick to give you something only
*slightly* better than a WAG at how much memory you'll need. Now its a SWAG
instead of a WAG.

Its probably better than consulting an ouiji board or tarot cards - just not
by a whole lot. If you understand the limitations of what you're doing, you
might not be an order of magnitude off when you design the hardware memory
limitations.

It does raise an interesting problem. If you have to commit to certain
parameters early on in the project (such as memory or processor speed) how
do you estimate how much you'll need when you don't have the software yet?
Even assuming you've got prior experience with similar systems, you really
have no good basis in measurement to make estimates until there is some
actual software available. Maybe this suggests that software development
should start way in advance of hardware decisions. But that has its own
problems with respect to time-to-market and other considerations.

Everyone can criticize just about any attempt to make measurements and
estimates for lots of good reasons. Who could suggest a better alternative
for how to make these estimates early on in a project when critical
decisions must be made?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:uy9n31060.fsf@gsfc.nasa.gov...
>
> Yes. So once again, bytes/sloc is a non-useful measure.
>

Re: Expected bytes per sloc (semicolons) performance

[default]

Stephen Leake wrote:
> 
> default <joel_seidman.NOESPAME@yahoo.com> writes:
> 
> > Mats Weber wrote:
> > >
> > > >Rules about n bytes per sloc are just too processor, compiler, and
> > > >coding style dependent to be useful.
> > >
> > > I would put a big emphasis on coding style here. If you use a lot of
> > > generics, the code will be generated once for each instance in most
> > > implementations.
> >
> > I agree there is a relation between coding style and bytes/sloc.
> >
> > But I don't understand the specific denigration of generics, which I've
> > heard occasionally. It seems to me the alternative to generics is
> > nearly-duplicate packages and procedures, usually created by brute-force
> > cut-and-paste in a text editor. You end up with the same amount of
> > object code, but with the disadvantage that it is harder to maintain
> > than if you had used generics.
> >
> > Is there a flaw in my reasoning?
> 
> I didn't get a "denigration of generics" from this. Mats is merely
> pointing out that a style that uses generics will have a _much_ higher
> number for bytes/sloc than a style that doesn't. This is neither bad
> nor good; it's just a fact. It does argue that "bytes/sloc" is not a
> useful measure.

OK, Stephe, I may have misread the intention. I've heard it stated as a
complaint in the past, so I jumped to a conclusion. My apologies to
Mats. 
-- Joel

Re: Expected bytes per sloc (semicolons) performance

[Stephen Leake]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> <snip>
> 
> It does raise an interesting problem. If you have to commit to certain
> parameters early on in the project (such as memory or processor speed) how
> do you estimate how much you'll need when you don't have the software yet?

Exactly. Pretending this problem doesn't exist is _not_ an acceptable
solution. 

> Even assuming you've got prior experience with similar systems, you
> really have no good basis in measurement to make estimates until
> there is some actual software available. Maybe this suggests that
> software development should start way in advance of hardware
> decisions. 

Exactly. That's what "phase A"/prototypes are for. You can't commit
significant resources to a project until you know what you are doing.

> But that has its own problems with respect to time-to-market and
> other considerations.

Well, building satellites for NASA is certainly different than getting
out the next cell phone. But I think the same principles apply; you
have to experiment and prototype before you commit the final design. 

> Everyone can criticize just about any attempt to make measurements
> and estimates for lots of good reasons. Who could suggest a better
> alternative for how to make these estimates early on in a project
> when critical decisions must be made?

I did just that; get a similar processor or simulator, write some
prototype code. 

Or, agree that you will only make evolutionary changes from the
previous release. That's really the same thing; the previous release
is a good prototype.

-- 
-- Stephe

Re: Expected bytes per sloc (semicolons) performance

[Marin David Condic]

I think my point was that in many cases, prototype code and/or prior
experience with similar systems is a luxury that many, if not most projects
don't have. I've been on projects where we did have prior experience with
very similar systems and could quickly cobble together something that would
roughly approximate the new system and use that to gain some reasonably good
estimates of timing and sizing. Great if you can do that. What about when
you can't?

In software, we generally don't build the same thing more than once. While
there are systems with incremental improvements or spiral development
enhancements, those aren't typically the kind of things where the hardware
is being built from bottom dead center and desparately needs some kind of
information on what the software is going to require. When it is all brand
new is when you most desparately need quality estimates and this is
paradoxically when its hardest to make them. In both military and commercial
developments, this sort of situation arises often enough and there are a
variety of pressures that make it difficult or impossible to build a
prototype before you have to commit to hardware decisions.

Software development is not quite like most other sorts of engineering
development & it has a very hard time with measurement & prediction as a
result. Ask a civil engineer to estimate the design and construction time
for a building based on some sketches & dimensions and he stands a pretty
good chance of doing that pretty well because any one building is
sufficiently similar to others that you can base costs on the number of
square feet, etc. Us software guys don't get the same luxury because the
instant it becomes sufficiently similar to something done before, it gets
turned into a subprogram/subsystem with some parameters and the duplication
cost is pretty close to zero.

MDC

--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:ug09a0ykj.fsf@gsfc.nasa.gov...
>
> I did just that; get a similar processor or simulator, write some
> prototype code.
>
> Or, agree that you will only make evolutionary changes from the
> previous release. That's really the same thing; the previous release
> is a good prototype.
>