[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