[ANNOUNCE] VDR developer version 1.3.49

  Hi,

On Sat, 29 Apr 2006 15:37:17 +0200 Klaus Schmidinger
<Klaus.Schmidinger@cadsoft.de> wrote:

> Did anybody else receive that posting?
> If so, can you please forward a copy to me?

I've attached it as it's smaller than other peoples' signatures :-)

> >> Or does this patch fix an actual problem?
> > 
> > Well, I don't think compiling too much code as PIC will cause
> > problems (apart from (minor) possible performance lost),
> > nevertheless it is unneeded.
> 
> Is that "compile time" or "runtime" performance?

Should be kind of "execution time", not exactly "runtime". It just adds
a few memory remappings on application startup by updating an address
lookup table. This may cause some additional memory lookups at runtime,
too. Albeit I'm interested in real numbers, I'm pretty sure it won't
affect performance too much.

> Apparently PIC is only available on special processors, especially
> *not* Intel, so I can't test this myself.

Hm, it should be available on intel.

> Let's wait with this until after version 1.4.

There are good reasons for doing it this way, yes.

-hwh
  

Am Samstag April 29 2006 15:50 schrieb Hans-Werner Hilse:
> Hi,
>
> On Sat, 29 Apr 2006 15:37:17 +0200 Klaus Schmidinger
>
> <Klaus.Schmidinger@cadsoft.de> wrote:
> > Did anybody else receive that posting?
> > If so, can you please forward a copy to me?
>
> I've attached it as it's smaller than other peoples' signatures :-)

Well that patch - as I stated in the updated post - missing one minor thing. 
Sorry for the confusion...

>
> > >> Or does this patch fix an actual problem?
> > >
> > > Well, I don't think compiling too much code as PIC will cause
> > > problems (apart from (minor) possible performance lost),
> > > nevertheless it is unneeded.
> >
> > Is that "compile time" or "runtime" performance?
>
> Should be kind of "execution time", not exactly "runtime". It just adds
> a few memory remappings on application startup by updating an address
> lookup table. This may cause some additional memory lookups at runtime,
> too. Albeit I'm interested in real numbers, I'm pretty sure it won't
> affect performance too much.

Not exactly. You have to distinguish: If you have the choice to load non-PIC 
or PIC shared libs (eg on x86):

PIC generally loads faster, as you don't need text relocations performed 
AFAIK. But PIC is generally slower on execution due to losing the ebx 
register (on x86) and gcc being pedantically dumb to not free it up when it 
could be used even in PIC mode. (There could also be security risks with 
non-PIC shared libs, IIRC.)

On x86-64 for example you have no choice: *shared* libs need to be PIC.

On the other hand *executables* and *static libs* (well it is a wrong term 
actually, they are just a little bit more than a conglomeration of object 
files) generally *don't* need to be PIC. But this is what current VDR 
Makefile does - thus (possibly) wasting performance.


I hope this clears it up. :-)