Re: is -fPIC needed? -- affects #ifdef(DYNAMIC_MODULES / Intel80x 86)

[Bruno H. <ha...@il...>]

Joerg wrote:

> > So in summary, omitting -fPIC here is a very bad idea, both for
> > performance and for portability.
> Why performance?

- For a library compiled without -fPIC, mapping the library requires fixing
  relocations in the text segment. This is done by the system, but it
  nevertheless means high startup times (or dlopen() times, depending on how
  the library is linked).

- When memory gets tight, these modified text segment pages must be swapped out
  explicitly; Linux doesn't just drop them (although some OSes, namely OS/2
  IIRC, do this: drop the memory page and later during swap-in re-apply the
  relocations).

> Quite to the contrary, not being able to use ebx as a register for
> STACK causes a 30% performance slowdown on Linux, as I recently
> reported.

My measurements (a few years ago, on a 486) were a 5% performance
slowdown for using STACK as a global variable versus a register
variable. Are you using an x86 without L1 cache, or what?

> Remember: if some modules are compiled with -fPIC, then a register
> variable cannot be used for STACK (because the modules's code will
> not preserve it).

Yes, and the only portable way to load dynamic modules after program startup
today is dlopen() [or libltdl if you want it slightly more general], and it
requires -fPIC.

> So IMHO, to support --with-dynamic-modules, if GNU_LD (which
> configure already detects) on x86 can help to get rid of the -fPIC
> requirement on the module's .o and, as a consequence, enable use of
> a register for STACK in all of CLISP, then I think it should be
> used.

I don't agree:
  1) The behaviour of dlopen() with libraries not compiled with -fPIC is undocumented.
     It may stop working with the next version of binutils or glibc.
  2) I believe a performance penalty of 5% on the general running times is more
     acceptable than a performance penalty of 1000% on startup times.

Bruno