Re: Bloated file size?
From: Gordon Sande (g.sande_at_worldnet.att.net)
Date: 11/09/04
- Next message: Athanasios Migdalas: "Re: g95 wish list"
- Previous message: Richard E Maine: "Re: IMSL:how to put extra parameters into objective funtion when solving nonlinear equations system?"
- In reply to: Richard E Maine: "Re: Bloated file size?"
- Next in thread: Dave Weatherall: "Re: Bloated file size?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 09 Nov 2004 21:28:55 GMT
Richard E Maine wrote:
> nessie235@aol.com (Aleph Mobius) writes:
>
>
>>I meant that if we compiled
>>Hello, World programs, this should give us about the base size of each
>>program. In other words, I don't think I will be able to produce any
>>program file less than 26k.
>
>
> Probably... though not quite provably from the data at hand. See below.
>
>
>>I understand that these file sizes are
>>really irrelevant of what will happen as more code is added. I am just
>>curious as to why there is so much more overhead.
>
>
> One thing to realize, as hinted to by one other reply here, is that
> formatted I/O is pretty complicated. Most people don't tend to think
> about it a lot because the compiler does it for them so they don't have
> to worry much about it. Fortran formatting has an awful lot of options.
> One could almost think of "format" as a whole language to itself, and
> it is one that has to be interpreted at run-time in general - or at
> least the capability has to be there for run-time interpretation.
Perhaps 10 years ago there was a magazine for programmers (really C
programmers on PCs) called Computer Languages which had an article
on the amazingly powerful legacy language and some of its features that
the authors had discovered.
What they had discovered was that one could produce nicely formatted
output from (hold your breath) Fortran using its feature of (hold
your breath again) formatted i/o with very little effort. For this
newsgroup it sounds a bit corny but those folks were deadly earnest
as they seemed to have been overworked in trying to get nice output
from C's printf.
Truth is always stranger than fiction as I could not make up such a
story.
All of this is intended to reinforce the point that the run time
formatting support in Fortran is providing a lot of capability that
it is easy to miss.
> It is possible for the user to build formats at run-time in character
> variables, so in general the compiler has to include support for
> all formatting options. Perhaps in some common special cases, the
> compiler could deduce that portions of the formatting support will
> not be needed... but I'd guess that to be a pretty complicated deduction
> with limited payoff in real programs.
>
> Printing out a literal string is perhaps the simplest case, but
> consider what you would have to do to write the code to parse a format
> and use it to convert the I/O list to the appropriate character form
> (considering just output for now). It's not at all a simple task, but
> it doesn't involve any actual system interfacing, so you "ought" to be
> able to do something at least comparable in ordinary old Fortran code
> (without using Fortran I/O). I don't recommend seriously trying
> unless you have a year or so of time to throw away on the experiment,
> though;; that's about what I'd think it would take to do a good job...
> and I coulld be low. And that's just the formatting part - without
> getting into the actual I/O.
>
> Compilers probably vary as to how much they separate out parts of
> the run-time formatting support code. Some compilers probably bring
> in absolutely everything if the code has any I/O at all (and maybe
> even otherwise in order to support system error messages). Others
> might separate out some major parts so that you can avoid loading
> parts that aren't used. This is probably why someone was asking
> about differences between various ways of writing the "hello, world"
> program; for example, if the program had no explicit formats, it
> is posssible that the run-time support for parsing formats might not
> get loaded.
>
> I guess a summary is that, simple though it may look, "Hello, world"
> under the covers can be pretty complicated. That's part of why its
> actually a pretty decent first test that you have a compiler correctly
> installed and working - a lot of things have to be right.
>
> It is rare to have useful programs with no I/O at all... though such
> animals do exist (mostly in embedded systems where leaving an answer
> in the right memory location is sufficient). Programs that have no
> formatted I/O are more common - still pretty rare, but into the range
> of things that I've actually seen (and written) quite a few times. A
> program without formatted I/O *MIGHT* be smaller than your "hello,
> world". But it is mostly just an academic point.
>
> Oh, and all of this doesn't even touch on the question of shared
> libraries. Some implementations of some languages (including Fortran)
> may put much of the run-time support in a shared library (by any of
> several names). There are good reasons for this - sometimes it is
> a big "win" (particularly when there are lots of programs using the
> same shared library). But it can be misleading if you compare just
> the size of the "executable file", because the program actually
> requires both its executable file plus the shared libraries to
> run. Whenever you see an unusually small executable file, that is
> an almost certain sign that most of the run-time support code is in
> a shared library somewhere else - this applies across languages, not
> just to Fortran. There is some language dependence in that a system
> is more likely to come with shared run-time support libraries for
> languages that the system was implemented in.
>
- Next message: Athanasios Migdalas: "Re: g95 wish list"
- Previous message: Richard E Maine: "Re: IMSL:how to put extra parameters into objective funtion when solving nonlinear equations system?"
- In reply to: Richard E Maine: "Re: Bloated file size?"
- Next in thread: Dave Weatherall: "Re: Bloated file size?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
