llvm dev - Nov 2017 - [RFC] lld: Dropping TLS relaxations in favor of TLSDESC

On Wed, Nov 8, 2017 at 9:33 AM, Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:
> Rui Ueyama <ruiu at google.com> writes:
>
> >> If you are creating an executable and if your executable is not
> >> > position-independent, you're using Initial Exec model by
default
> which is
> >> > as fast as variables accessed through GOT. If you really want
to use
> >> Local
> >> > Exec model, you can pass -ftls-model=local-exec to compilers.
> >>
> >> But then all the used variables have to be defined in the same
> >> executable. You can't have even one from a shared library
(think errno).
> >>
> >
> > Not really -- you can still use Local Exec per variable basis using
the
> > visibility attribute. I don't think that we can observe noticeable
> > difference in performance between Initial Exec and Local Exec except
an
> > synthetic benchmark though.
>
> There nothing that the linker can do that the compiler could not have
> done in the first place. The point is that if to switch to lld and keep
> performance users should not have to annotate all tls variables with
> tls-model.
>
> > The nice thing about linker relaxations is that they are very user
> >> friendly. The linker is the first point in the toolchaing where
some
> >> usefull fact is know, and it can optimize the result with no user
> >> intervention.
> >
> >
> > I think I agree with this point. Automatic linker code relaxation is
> > convenient and if it makes a difference, we should implement that. But
> I'd
> > doubt if TLS relaxation is actually effective. George implemented them
> > because there's a spec defining how to relax them, and I accepted
the
> > patches without thinking hard enough, but I didn't see a
convincing
> > benchmark result (or even a non-convincing one) that shows that these
> > relaxations actually make real-world programs faster. Do you know of
> > any? It is funny that even the creator of TLSDESC found that their
> > optimization didn't actually makes NPTL faster as it is mentioned
in the
> > "Conclusion" section in http://www.fsfla.org/~lxoliva/
> > writeups/TLS/RFC-TLSDESC-x86.txt.
> >
> > So I don't think I'm proposing we simplify code by degrading
user's code.
> > It feels more like we are making too much effort on something that
> doesn't
> > produce any measurable difference in real life.
>
> *PLEASE* let us keep it. It is bad enough that we are regressing
> performance in the name of having code that you find nicer. It would be
> really annoying to see us drop a working feature just to reduce our
> code a bit.
>
Please take it easy. :) I'm not saying that I'm going to remove it.
Instead, I'm bringing a (possibly crazy) idea to the table to discuss, and
that is IMO a good thing. Part of the reason why lld is successful is
because of its relatively radical design choice such as Windows-ish library
semantics, which might have been somewhat crazy idea. So, I think "stop,
think and re-evaluate what has traditionally been done" is what we are good
at, regardless of the conclusion of the assessment. And as you know we
(including you) have been making reasonable decisions on technical design
choices.

The code is working, please let it be!
>
> At the very least we should keep it until we are in a position to
> actually measure it. As is this is just guesswork. We would need a
> *much* bigger adoption before we could measure this.
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171108/81bead65/attachment.html>

So, looks like there are programs in where TLS relaxation actually matters.
It is interesting that both examples mentioned in this threads are
graphics-related (OpenGL and games). I wonder if it is a coincidence or it
is a common practice to use thread-local variables heavily in graphics. I
haven't wrote any games before, so it is likely that I don't know some
basics in that area.


On Wed, Nov 8, 2017 at 10:55 AM, Rui Ueyama <ruiu at google.com> wrote:
> On Wed, Nov 8, 2017 at 9:33 AM, Rafael Avila de Espindola <
> rafael.espindola at gmail.com> wrote:
>
>> Rui Ueyama <ruiu at google.com> writes:
>>
>> >> If you are creating an executable and if your executable is
not
>> >> > position-independent, you're using Initial Exec model
by default
>> which is
>> >> > as fast as variables accessed through GOT. If you really
want to use
>> >> Local
>> >> > Exec model, you can pass -ftls-model=local-exec to
compilers.
>> >>
>> >> But then all the used variables have to be defined in the same
>> >> executable. You can't have even one from a shared library
(think
>> errno).
>> >>
>> >
>> > Not really -- you can still use Local Exec per variable basis
using the
>> > visibility attribute. I don't think that we can observe
noticeable
>> > difference in performance between Initial Exec and Local Exec
except an
>> > synthetic benchmark though.
>>
>> There nothing that the linker can do that the compiler could not have
>> done in the first place. The point is that if to switch to lld and keep
>> performance users should not have to annotate all tls variables with
>> tls-model.
>>
>> > The nice thing about linker relaxations is that they are very user
>> >> friendly. The linker is the first point in the toolchaing
where some
>> >> usefull fact is know, and it can optimize the result with no
user
>> >> intervention.
>> >
>> >
>> > I think I agree with this point. Automatic linker code relaxation
is
>> > convenient and if it makes a difference, we should implement that.
But
>> I'd
>> > doubt if TLS relaxation is actually effective. George implemented
them
>> > because there's a spec defining how to relax them, and I
accepted the
>> > patches without thinking hard enough, but I didn't see a
convincing
>> > benchmark result (or even a non-convincing one) that shows that
these
>> > relaxations actually make real-world programs faster. Do you know
of
>> > any? It is funny that even the creator of TLSDESC found that their
>> > optimization didn't actually makes NPTL faster as it is
mentioned in the
>> > "Conclusion" section in http://www.fsfla.org/~lxoliva/
>> > writeups/TLS/RFC-TLSDESC-x86.txt.
>> >
>> > So I don't think I'm proposing we simplify code by
degrading user's
>> code.
>> > It feels more like we are making too much effort on something that
>> doesn't
>> > produce any measurable difference in real life.
>>
>> *PLEASE* let us keep it. It is bad enough that we are regressing
>> performance in the name of having code that you find nicer. It would be
>> really annoying to see us drop a working feature just to reduce our
>> code a bit.
>>
>
> Please take it easy. :) I'm not saying that I'm going to remove it.
> Instead, I'm bringing a (possibly crazy) idea to the table to discuss,
and
> that is IMO a good thing. Part of the reason why lld is successful is
> because of its relatively radical design choice such as Windows-ish library
> semantics, which might have been somewhat crazy idea. So, I think
"stop,
> think and re-evaluate what has traditionally been done" is what we are
good
> at, regardless of the conclusion of the assessment. And as you know we
> (including you) have been making reasonable decisions on technical design
> choices.
>
> The code is working, please let it be!
>>
>> At the very least we should keep it until we are in a position to
>> actually measure it. As is this is just guesswork. We would need a
>> *much* bigger adoption before we could measure this.
>>
>> Cheers,
>> Rafael
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171108/47937407/attachment.html>

On Wed, Nov 08, 2017 at 12:46:20PM -0800, Rui Ueyama via llvm-dev
wrote:
> So, looks like there are programs in where TLS relaxation actually matters.
> It is interesting that both examples mentioned in this threads are
> graphics-related (OpenGL and games). I wonder if it is a coincidence or it
> is a common practice to use thread-local variables heavily in graphics. I
> haven't wrote any games before, so it is likely that I don't know
some
> basics in that area.
In the OpenGL case it is primary an effect of retrofitting thread-safety
into existing APIs. Just like some systems retrofit many of the
non-reentrant libc functions by using thread-local storage for the
buffers.

Joerg