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@xxxxxxxxxx> 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. :-) -- (?= =?) //\ Prakash Punnoor /\\ V_/ \_V -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available Url : http://www.linuxtv.org/pipermail/vdr/attachments/20060429/f6ea0e92/attachment.pgp
