Hi,
On Sat, 7 Dec 2019, Christian Jullien wrote:
2) slower code: most of the time the indirection through a pointer
variable (the state) in comparison to a direct access to a static
variable doesn't matter.
In fact, I experimented the opposite. When moving all global variables
to a struct, my Lisp was around 1% faster because globals are now close
together and more often accessible from L1 cache.
They are equally close in the .data section/segment, as long as you put
_all_ global data into that struct (which is what was proposed). I do
believe you that it was faster, merely pointing out that it probably had
other reasons.
Either way, I measured with TCC itself, not some other program with
completely different behaviour. Specifically the accesses to the token
hash table from the pre-processor (tokenization is the slowest part in
TCC, as it should be) currently needs only one register, because the
address of that table is an immediate. Just changing this to be a pointer
(cached in a register), with otherwise similar code made the inner loop of
tokenization measurably slower (though I don't remember the percentage
anymore, but I was thinking "meeh"). The effect is that on x86-64 the
computation either needs a slow addressing mode, or multiple instructions
(which are dependend then), which alone caused this slowdown.
Of course, we could decide that a (say) 2% slowdown in compilation speed
is acceptable for the feature of multiple compiler states that don't have
to interact.
Or we could think long and hard about what we really want/need from our
APIs and try to get both. E.g. it's not clear that the token hash table
really needs to become a non-singleton, even _if_ we'd allow multiple
TCCState objects. It's just that the update to the token hash must not be
done concurrently.
So, we could for instance allow and support multiple TCCStates but
_without_ multi-threading. Or (like grischka said) allow multi-threading,
but only on the API level (and serialize internally).
So, I think the latter is the solution with the most bang for the buck:
allow multiple TCCStates, but don't necessarily move all global data into
the state, under the assumption that at its core TCC remains
single-threaded.
We'd also still have to decide what multiple TCCStates really mean: e.g.
I'd say this is only for compiling to memory. That would mean that it's
not really necessary for the code from different states to be generated
into different sections. Though finalization needs to be per state, so
maybe it's unavoidable, but that needs to be tried. There might be other
global data (e.g. the memory allocator) that also could remain shared
between different states. (Again, all with the assumption that
multi-threading is serialized high in the API level).
Ciao,
Michael.
It has of course no effect when global is a pointer which introduces the
same indirection. It is true for aggressive optimizers which are likely
to put struct pointer to a register. So it may be faster for tcc
compiled by gcc, clang or vc++ but slower when tcc is compiled by tcc.
C.
-----Original Message-----
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=address@hidden] On
Behalf Of Michael Matz
Sent: Friday, December 06, 2019 16:42
To: TCC mailing list
Subject: Re: [Tinycc-devel] make tcc reentrant
Hello,
On Tue, 3 Dec 2019, Ulrich Schmidt wrote:
i try to write a lua binding for tcc. To work out propperly, the tcc lib
needs to be reentrant.
As demonstrated down-thread, that isn't correct. It doesn't _need_ to be,
it would be an feature. As usual with features it needs to be measured
against the downsides. The downsides for your proposed changes are the
following at least:
1) more complicated/boiler-platy source code of TCC (a TCCState
argument almost everywhere)
2) slower code: most of the time the indirection through a pointer
variable (the state) in comparison to a direct access to a static
variable doesn't matter. But it does matter for the symbol/token
table (and potentially for the register/evaluation stack). I have
measured this years ago for the token table, so this might or might not
still be the case.
So, while I can see the wish for this feature, I don't necessarily see
that tcc should be changed to accomodate.
If anything I would expect a _complete_ transition to exist, in order to
measure the impact. The worst thing that could happen is if someone added
TCCState arguments everywhere, moved some static variables to that state,
and then leaves: none of the features of this whole excercise would be
had, but all the downsides would be there.
And yes, this is a big project. I really think it would be better
if you simply write a wrapper for libtcc that ensures single-threadedness
and that regards TCCState as a singleton. I think such thing would be
well-suited in the TCC sources itself.
(In a way it seems prudent for a tiny C compiler to only be usable as a
singleton)
Ciao,
Michael.
I took a look into the sources and found some comments (XXX:...) and
started with removing
the static var tcc_state. As a result allmost all lib functions needs a
1st parameter of
type TCCState*. I did this in my own local branch and tcc is still
running :).
But this is a really HUGE change. in addition most of the local vars in
tccpp, tccgen, ... needs
to be moved to TCCState. I can do that but at some points i will have
some questions and i
can only test on windows and probably on linux.
My 1st question is: Are you interested in these changes or should i do
this locally?
I would like to this together with you.
Greetings.
Ulrich.
_______________________________________________
Tinycc-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
_______________________________________________
Tinycc-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
_______________________________________________
Tinycc-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
_______________________________________________
Tinycc-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel