On Mon, Aug 04, 2008, Russell Coker wrote: > > Based on my memory of the discussions, it seemed to me that there is a > > performance hit in all cases if you use PIC instead of non-PIC on i386 > > because a register is used for the relocations; > > It is only a performance hit in cases where you actually need the register.
I think it's hard to find real CPU bound applications where additional registers don't help performance. > > I think this impacts > > both assembly and compiled languages, however I could imagine cases > > where custom assembly wont build at all if PIC is used (as it might > > require more registers than PIC mode provide). > > Custom built assembly can require the extra register, which is what happens > with the code in question. The code does build with PIC, it just happens to > not be position independent. Thus the reserving of a register in all the > other code in the shared object has all been wasted. Then this is another case; there is custom assembly which wont build at all in PIC mode because gcc doesn't have enough registers to offer when entering this code and needs to do some relocations. > > > I expected that the probability of you including my patch to disable the > > > assembler was low (although a similar patch is in the Fedora tree for > > > libtheora), but if nothing else it clearly illustrates where the problem > > > is for anyone who wants to have a go at writing some assembler. > > > > Well, it's interesting to note that Fedora favors SELINUX support > > before speed; perhaps something you can bring up in a wider discussion > > of this policy decision. > > It's not just SE Linux, it's anything that tries to prevent writable and > executable memory. Are you suggesting Fedora added the patch for other reasons than SELINUX support? Could you expand on these reasons? > > > If the performance critical code is going to be handling data from > > > sources of low integrity (EG playing video downloaded from youtube etc) > > > then I think that we want all the available security features enabled! > > > > I'm not sure I agree with the rationale; certainly having SELINUX > > properly working in apps playing remote contents is a laudable goal, > > but I understand SELINUX doesn't make any difference if the libs are > > secure already, and we do want the libs to be secure. > > If you care about security then you assume that all code gets broken > eventually. The question is whether you have a safety net when the first > layer gets broken or whether you just lose. Sure, and if you care about security, you don't connect your computer to the internet, or you don't use a computer at all. Perhaps we want Debian packages to favor performance, or perhaps we want them to favor security features; this decision doesn't belong to the two of us but to the project as a whole. > > However > > performance is useful in all cases. So I still think it's a compromise > > which needs wider consensus. > > How much performance are we talking about? > > Performance is not of such great use if the system is already fast enough. > If > you run a task that performs well on an 800MHz P3 system (such as playing AVI > files in 800*600 resolution) on a faster machine (EG any P4 system) then a > small amount of performance loss isn't going to be noticed. In fact in that > example you could halve the performance and not notice it! > > #if 1 //is faster only if multiplies are reasonably fast (FIXME figure out on > which CPUs this is faster, on Athlon it is slightly faster) > > Also there are comments such as the above near the assembly code. > I gave pointers on this already; it can be 10%. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
