RE: [Firebird-devel] Re: Jdbc interface

[Samofatov, N. <Nic...@Br...>]

Hi!

> >Ugh, it was a lot of work I suppose. :) Major rewrite. :)
> >
> >In fact, this code was written before we made any decision about=20
> >handling of TLS in our code.
> >TLS handling (aka GET_THREAD_DATA) is my tree (and possibly in Alex'=20
> >one
> >too) works faster then passing single parameter to a function.
> >ISO standard syntax for TLS (__thread keyword) is usually=20
> very fast and=20
> >and on most platforms evaluates to 2 simple assembler instructions.
> >
> Really?  I've been through the Linux pthread implementation,=20
> and it's more like 500 not-at-all-simple instructions.  How=20
> does thread data get resolved in two instructions? =20
> Can you explain how you determined that thread globals were=20
> faster than arguments?

Here is how it works on Linux/x86. Other platforms are simular.
OS uses processor LDT (local descriptor table) to load fs or gs register
with selector pointing to TLS area.
Since LDT has only 8192 entries this requires some work from kernel
thread/process scheduler to reload LDT on some context switches if
process has more than 8192 threads. Accessing value from TLS translates
to read or write of some fixed offset (calculated at link time or by
dynamic linker) in the area pointed by fs or gs selector.
This doesn't require many instructions to work and is slightly faster
than doing stack manipulations needed to carry argument with x86 ABI.

> >We did a series of measurements and overall outcome was that=20
> using TLS=20
> >variables is globally faster than passing thread structure=20
> pointer as a=20
> >parameter on platforms where TLS variables are supported by the=20
> >compiler and environment, especially if we make most=20
> functions receive=20
> >real arguments, not thread structure pointer.
> >
> Oh, do tell!  Can you share your results?  I'm all ears. =20
> I've been playing fairly close attention to the dev list, but=20
> I apparently napped through the entire discussion.

Alex posted various Linux and Win32/MSVC6 results. I tested VS2003 and
Intel Compiler 8 in various modes. I may CC them to you if you need.

> >Current decision (not final) is that in Firebird we combine this=20
> >approaches and use GET_THREAD_DATA for various error handling and=20
> >synchronization purposes and switch to normal function arguments in=20
> >other cases. This will make code clean, simple and more-or-less=20
> >efficient in both cases - fast and slow TLS.
> >
> > =20
> >
> I'm delighted to hear that there is a decision making process=20
> in Firebird 2.  It always seemed to me to be anarchy with=20
> people with checkin privilege (like you) overriding people=20
> without (like me) based on whim.

Well, I already told that most discussions between developers moved to
private mail exchanges or ad-hoc shortlists such as (Claudio Valderrama
C.; Dmitry Yemanov; Alexander Peshkov; Dimitry Sibiryakov; Arno
Brinkman).

Nickolay