Re: [MiNT] rpm

[Eero Tamminen <oak@helsinkinet.fi>]

Hi,

On perjantai 19 joulukuu 2014, Mark Duckworth wrote:
> While this would work I think you are not thinking in a fined grained
> enough manner.  The unix libraries get pretty nitty gritty and your
> approach would have a copy of ncurses for instance loaded with each
> shell application that uses it, which is many.  I'm not sure how the
> static linking works but this may already be a problem.

How much more memory program uses with static linking depends on how
large the libraries are, how many functions program uses from them, how
interlinked the code in the library is, and how much it uses other
libraries.  And of course it depends on how many processes using given
library you typically have running at the same time.

I think statically linked library can be smaller and use less memory
than dynamically linked one, but that would be pretty exceptional.
Statically linked binary is normally faster, but whether difference
is even measurable depends on the case.

The reasons why statically linked binary can be faster:
- no extra register needed for position independed library code
- function calls addresses are resolved at build linking time, so
  they don't need to go through library offset table at run-time
- unused functions/data is left out from the binary, so remaining
  (smaller amount of binary) code is more likely to be in cache when needed.

I.e. difference would be largest in register starved code with lot
of small functions calling across library boundaries (=bad code :)).


> I know some of
> the unix stuff uses a ton of RAM.  I think with virtual memory and
> dynamic linking, the object gets loaded and future executables just
> reference the mapped library.  Easy(ish).

If library (and relevant pages in it) are already in memory, startup
with dynamically linked library can be faster.  It depends on how
many library symbols need to be relocated when library is loaded.
With large C++ libraries which don't hide their internal symbols,
it can be a clear perf issue (nowadays this shouldn't anymore be
a problem for commonly used libraries, they've been fixed).


	- Eero

> On 12/19/2014 03:29 PM, Peter Slegg wrote:
> > Despite being M$ I gather that .Net or C# is quite good, there are
> > a lot of such developers in my office but I think you might find more
> > open source devs on the mintlist ;-)
> > 
> > Whaever the technology, a central system that can quickly build the rpm
> > and report errors would be a great advantage.
> > 
> > 
> > 
> > It keeps coming back to the virtual memory issue in trying to maintain
> > and build on an extensive set of libs.
> > 
> > I have suggested we try to find a "quick" solution that makes a small
> > step in that direction to try to eliminate this obstacle.
> > 
> > I did once suggest loaded but non-shared libs but I don't have enough
> > knowledge of mint internals to know if it could work.
> > 
> > It would be a little slower to load than static linked apps but no
> > worse in memory usage and after all just how many apps would the
> > average user run simultaneously that will be using the same libs ?
> > 
> > If I had 3 apps, 1st uses libs A and B, 2nd uses B and C, and the
> > 3rd just C
> > 
> > Then each would load it's own copy of the libs so there would be
> > A, B, B, C and C in memory. Each app can call it's own copy just
> > like static linked versions.
> > 
> > I haven't been able to find if this has ever been tried.
> > 
> > 
> > http://compilers.iecc.com/comparch/article/02-06-017
> > 
> > What was Apple's solution in the M68k era ?
> > What did the Amiga do ?
> > 
> > 
> > Regards,
> > 
> > Peter