On Sun, 11 Nov 2007 19:47:45 +0100 Benno Schulenberg <[EMAIL PROTECTED]> wrote:
> Patrick Baggett wrote: > > I noticed that there are notes about removing data segment > > variables and moving them into text-segment (in the form of > > push/pop). I don't think that is faster than directly loading the > > values. > > Using two pushes and a move is certainly slower than a single move, The speed calculation is not so simple a calculation. For example, the push/pop approach uses the instruction stream, so you get the data cheaper from the instruction pre-fetch, and on loops it comes from the instruction cache instead of the data cache (which can be a pro or a con). In addition the immediate area around the stack pointer is typically very fast to access, compared to random memory addresses. Indeed, over a short push/push/pop sequence the data may exist solely in the fastest part of on-chip CPU memory, which is almost no different than having data in registers. I'm not saying that my version is faster, just that it's not obvious that it's slower, either. Only real timing measurements will show what difference it makes. > but this is done to make the code position-independent, so the > segment becomes a truly sharable object. Mesalibs won't often be > shared, though, so the real reason may be something else, and the > comment should probably mention this. Yes; "proper" PIC is why I proposed the change. The pros and cons of making shared objects truly PIC are several and well documented elsewhere; whether they matter or not depends on what is important to you (i.e. it's subjective). In addition to the more generic issues, we (Gentoo Hardened) have a particular interest in that correctly-PIC code never needs write permission to the text segment in user-mode (since there are no relocations to be resolved), which eliminates whole classes of potential vulnerabilities. I would note that in many cases we have been surprised ourselves at the speed differences introduced by making code properly PIC - sometimes there's the expected penalty, but many times it can actually speed things up, which shows how complex the timing issue can be in practice. If the non-PIC method is demonstrated to be faster and hence desirable for some users (ok, most users!) it could be managed via a configure option. I would urge that actual speed measurements be determined first, however - it probably varies considerably from one type of x86 cpu to another, as well... > Let's ask the author of the change. Kevin? > > > > diff --git a/src/mesa/x86/read_rgba_span_x86.S > > > /* Kevin F. Quinn 2nd July 2006 > > > - * Replace data segment constants with text-segment > > > instructions > > Benno > Kev.
signature.asc
Description: PGP signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
