[fpc-devel] Parallel processing in the compiler

Hans-Peter Diettrich DrDiettrich1 at aol.com
Mon Sep 6 21:09:12 CEST 2010


Florian Klaempfl schrieb:
> Am 06.09.2010 14:30, schrieb Michael Schnell:
>>> What's the problem with using threadvars
>> As discussed some days ago, the current implementation of Threadvars is
>> quite slow (doing a libc call on each access to a threadvar). 
> 
> And? Those variables aren't used very often. And if needed, it can be
> improved later.

Threadvars *are* used frequently, as long as almost all currently global 
variables have to become threadvars. When I moved the global scanner 
variables (c, token...) into the scanner object, every access to such a 
moved variable requirs access to the thread-local scanner object first.

When objects are used as containers for thread-local variables, these 
object references (to the thread-local objects) should be cached. This 
will have to be done inside every procedure, that makes use of a 
reasonable number of threadvars. E.g. current_scanner or current_module 
can be copied into local (stack) variables, for further use inside that 
procedure. That's at least better than having a huge number of 
references to individual threadvars.

I hope that it has become more clear now, why I want to remove as many 
global variables as possible.

DoDi




More information about the fpc-devel mailing list