On Thu, May 6, 2010 at 7:34 PM, Jonas Maebe <jonas.ma...@elis.ugent.be> wrote: > > On 06 May 2010, at 23:28, Werner Van Belle wrote: > >> In 'human' (haha) terms: >> >> - global variable access: write data into 'ds+constant' >> - local variables: write data into 'ss+bp+constant'. >> >> Since the latter involves a term more I assume it is bound to take more >> time. > > That was true in the days of the 8086 (the former took 6 cycles while the > latter took 9 cycles). On the i386 and i486, both expressions were already > calculated in a single cycle; they only suffered an extra single cycle > penalty in case the address expression used an index (your example only > contains a base). On the Pentium, address expressions containing an index > were also evaluated in a single cycle. On today's deeply pipelined processors > it is extremely unlikely that there is any difference whatsoever in the > number of steps used to evaluate both address expressions (even if the time > required by the i386/i386/Pentium wasn't documented). > > If you wish to read the outdated details of the old Intel processors: > * http://www.inf.puc-rio.br/~inf1018/material/intel.txt (search for > "8088/8086 Effective Address (EA) Calculation") > * http://www.gamedev.net/reference/articles/article205.asp (search for > "Choice of Index Versus Base Register") > > Moreover, the first instruction takes up 10 bytes while the second one takes > up only 7 bytes, which means that the "global array instruction" takes up > more space in the icache (and that's something which actually /is/ very bad > from a performance point-of-view). Combined with how global variables require > indirection (as in "an extra memory load instruction") on RISC processors and > if position-independent code is used (except under some specific > circumstances on the x86-64), often slow down program startup (when the > dynamic linker has to relocate them), and often behave very badly in terms of > data locality (they are often surrounded by unrelated data, as opposed to > local variables where the surrounding data will probably also be used by the > same function), in general my bias would be much more against than in favour > of global variables from a speed perspective (and when not talking about > arrays, an additional advantage of local variables is that they often can be > kept in registers rather than in memory, which is seldom the case for global > variables). > > > Jonas_______________________________________________
Now that's a fantastic explanation, and I guess the OP will be satisfied :-) -Flávio _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
