* Expected bytes per sloc (semicolons) performance @ 2001-09-18 22:03 Mike Harrison 2001-09-19 0:04 ` Jeff Creem 0 siblings, 1 reply; 21+ messages in thread From: Mike Harrison @ 2001-09-18 22:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Expected bytes per sloc (semicolons) performance 2001-09-18 22:03 Expected bytes per sloc (semicolons) performance Mike Harrison @ 2001-09-19 0:04 ` Jeff Creem 2001-09-19 10:13 ` Robert Dewar 2001-09-20 19:15 ` Mike Harrison 0 siblings, 2 replies; 21+ messages in thread From: Jeff Creem @ 2001-09-19 0:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Expected bytes per sloc (semicolons) performance 2001-09-19 0:04 ` Jeff Creem @ 2001-09-19 10:13 ` Robert Dewar 2001-09-20 0:43 ` David B. Littell 2001-09-20 19:15 ` Mike Harrison 1 sibling, 1 reply; 21+ messages in thread From: Robert Dewar @ 2001-09-19 10:13 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Expected bytes per sloc (semicolons) performance 2001-09-19 10:13 ` Robert Dewar @ 2001-09-20 0:43 ` David B. Littell 2001-09-20 11:28 ` Steffen Huber 0 siblings, 1 reply; 21+ messages in thread From: David B. Littell @ 2001-09-20 0:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Expected bytes per sloc (semicolons) performance 2001-09-20 0:43 ` David B. Littell @ 2001-09-20 11:28 ` Steffen Huber 2001-09-20 13:10 ` Tarjei T. Jensen 0 siblings, 1 reply; 21+ messages in thread From: Steffen Huber @ 2001-09-20 11:28 UTC (permalink / raw) "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/ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Expected bytes per sloc (semicolons) performance 2001-09-20 11:28 ` Steffen Huber @ 2001-09-20 13:10 ` Tarjei T. Jensen 2001-09-22 14:36 ` David B. Littell 0 siblings, 1 reply; 21+ messages in thread From: Tarjei T. Jensen @ 2001-09-20 13:10 UTC (permalink / raw) 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, ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Expected bytes per sloc (semicolons) performance 2001-09-20 13:10 ` Tarjei T. Jensen @ 2001-09-22 14:36 ` David B. Littell 0 siblings, 0 replies; 21+ messages in thread From: David B. Littell @ 2001-09-22 14:36 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Expected bytes per sloc (semicolons) performance 2001-09-19 0:04 ` Jeff Creem 2001-09-19 10:13 ` Robert Dewar @ 2001-09-20 19:15 ` Mike Harrison 2001-09-21 14:02 ` Stephen Leake 2001-09-21 16:22 ` Ted Dennison 1 sibling, 2 replies; 21+ messages in thread From: Mike Harrison @ 2001-09-20 19:15 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Expected bytes per sloc (semicolons) performance 2001-09-20 19:15 ` Mike Harrison @ 2001-09-21 14:02 ` Stephen Leake 2001-09-21 15:30 ` Mats Weber 2001-09-21 16:22 ` Ted Dennison 1 sibling, 1 reply; 21+ messages in thread From: Stephen Leake @ 2001-09-21 14:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Expected bytes per sloc (semicolons) performance 2001-09-21 14:02 ` Stephen Leake @ 2001-09-21 15:30 ` Mats Weber 2001-09-21 18:00 ` default 2001-09-25 16:08 ` tmoran 0 siblings, 2 replies; 21+ messages in thread From: Mats Weber @ 2001-09-21 15:30 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Expected bytes per sloc (semicolons) performance 2001-09-21 15:30 ` Mats Weber @ 2001-09-21 18:00 ` default 2001-09-24 17:03 ` Stephen Leake 2001-09-25 16:08 ` tmoran 1 sibling, 1 reply; 21+ messages in thread From: default @ 2001-09-21 18:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Expected bytes per sloc (semicolons) performance 2001-09-21 18:00 ` default @ 2001-09-24 17:03 ` Stephen Leake 2001-09-25 23:00 ` default 0 siblings, 1 reply; 21+ messages in thread From: Stephen Leake @ 2001-09-24 17:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Expected bytes per sloc (semicolons) performance 2001-09-24 17:03 ` Stephen Leake @ 2001-09-25 23:00 ` default 0 siblings, 0 replies; 21+ messages in thread From: default @ 2001-09-25 23:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Expected bytes per sloc (semicolons) performance 2001-09-21 15:30 ` Mats Weber 2001-09-21 18:00 ` default @ 2001-09-25 16:08 ` tmoran 2001-09-25 16:44 ` Wes Groleau 2001-09-25 20:32 ` Stephen Leake 1 sibling, 2 replies; 21+ messages in thread From: tmoran @ 2001-09-25 16:08 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Expected bytes per sloc (semicolons) performance 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 1 sibling, 1 reply; 21+ messages in thread From: Wes Groleau @ 2001-09-25 16:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Expected bytes per sloc (semicolons) performance 2001-09-25 16:44 ` Wes Groleau @ 2001-09-25 20:51 ` tmoran 0 siblings, 0 replies; 21+ messages in thread From: tmoran @ 2001-09-25 20:51 UTC (permalink / raw) > > 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Expected bytes per sloc (semicolons) performance 2001-09-25 16:08 ` tmoran 2001-09-25 16:44 ` Wes Groleau @ 2001-09-25 20:32 ` Stephen Leake 2001-09-25 21:04 ` Marin David Condic 1 sibling, 1 reply; 21+ messages in thread From: Stephen Leake @ 2001-09-25 20:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Expected bytes per sloc (semicolons) performance 2001-09-25 20:32 ` Stephen Leake @ 2001-09-25 21:04 ` Marin David Condic 2001-09-26 15:19 ` Stephen Leake 0 siblings, 1 reply; 21+ messages in thread From: Marin David Condic @ 2001-09-25 21:04 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Expected bytes per sloc (semicolons) performance 2001-09-25 21:04 ` Marin David Condic @ 2001-09-26 15:19 ` Stephen Leake 2001-09-26 16:58 ` Marin David Condic 0 siblings, 1 reply; 21+ messages in thread From: Stephen Leake @ 2001-09-26 15:19 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Expected bytes per sloc (semicolons) performance 2001-09-26 15:19 ` Stephen Leake @ 2001-09-26 16:58 ` Marin David Condic 0 siblings, 0 replies; 21+ messages in thread From: Marin David Condic @ 2001-09-26 16:58 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Expected bytes per sloc (semicolons) performance 2001-09-20 19:15 ` Mike Harrison 2001-09-21 14:02 ` Stephen Leake @ 2001-09-21 16:22 ` Ted Dennison 1 sibling, 0 replies; 21+ messages in thread From: Ted Dennison @ 2001-09-21 16:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2001-09-26 16:58 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-09-18 22:03 Expected bytes per sloc (semicolons) performance Mike Harrison 2001-09-19 0:04 ` Jeff Creem 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox