c - pthread - set environment variable linux

¿Qué tan rápido es el hilo variable de acceso local en Linux

Question

¿Qué tan rápido es acceder a un hilo de variables locales en Linux. Del código generado por el compilador gcc, puedo ver que se utiliza el registro de segmento fs . Entonces, aparentemente, el acceso a la variable local del hilo no debería costar ciclos adicionales.

Sin embargo, sigo leyendo historias de horror sobre la lentitud del acceso a las variables locales. ¿Cómo? Claro, a veces, los compiladores diferentes utilizan un enfoque diferente al uso del registro de segmento fs , pero ¿el acceso a la variable local del subproceso a través del registro de segmento fs también es lento?

Answer 1

¿Qué tan rápido es acceder a las variables locales de un hilo en Linux?

Depende de muchas cosas.

Algunos procesadores ( i*86 ) tienen un segmento especial ( fs , o gs en modo x86_64 ). Otros procesadores no lo hacen (pero generalmente tendrán un registro reservado para acceder al subproceso actual, y es fácil encontrar el TLS utilizando ese registro dedicado).

En i*86 , utilizando fs , el acceso es casi tan rápido como el acceso directo a la memoria.

Sigo leyendo historias de terror sobre la lentitud del acceso a variables locales de subprocesos

Le hubiera ayudado si proporcionara enlaces a algunas de esas historias de horror. Sin los enlaces, es imposible saber si sus autores saben de qué están hablando.

Answer 2

Sin embargo, sigo leyendo historias de horror sobre la lentitud del acceso a las variables locales. ¿Cómo?

Permítame demostrar la lentitud de la variable local del hilo en Linux x86_64 con un ejemplo que he tomado de http://software.intel.com/en-us/blogs/2011/05/02/the-hidden-performance-cost-of-accessing-thread-local-variables .

1. No __thread variable __thread , no hay lentitud .

   Usaré el rendimiento de esta prueba como base.

       #include "stdio.h"
       #include "math.h"
   
       double tlvar;
       //following line is needed so get_value() is not inlined by compiler
       double get_value() __attribute__ ((noinline));
       double get_value()
       {
         return tlvar;
       }
       int main()
   
       {
         int i;
         double f=0.0;
         tlvar = 1.0;
         for(i=0; i<1000000000; i++)
         {
            f += sqrt(get_value());
         }
         printf("f = %f/n", f);
         return 1;
       }

   Este es el código ensamblador de get_value ()

   Dump of assembler code for function get_value:
   => 0x0000000000400560 <+0>:     movsd  0x200478(%rip),%xmm0        # 0x6009e0 <tlvar>
      0x0000000000400568 <+8>:     retq
   End of assembler dump.

   Esto es lo rápido que corre:

   $ time ./inet_test_no_thread
   f = 1000000000.000000
   
   real    0m5.169s
   user    0m5.137s
   sys     0m0.002s

2. Existe __thread variable __thread en un ejecutable (no en una biblioteca compartida), aún sin lentitud .

   #include "stdio.h"
   #include "math.h"
   
   __thread double tlvar;
   //following line is needed so get_value() is not inlined by compiler
   double get_value() __attribute__ ((noinline));
   double get_value()
   {
     return tlvar;
   }
   
   int main()
   {
     int i;
     double f=0.0;
   
     tlvar = 1.0;
     for(i=0; i<1000000000; i++)
     {
       f += sqrt(get_value());
     }
     printf("f = %f/n", f);
     return 1;
   }

   Este es el código ensamblador de get_value ()

   (gdb) disassemble get_value
   Dump of assembler code for function get_value:
   => 0x0000000000400590 <+0>:     movsd  %fs:0xfffffffffffffff8,%xmm0
      0x000000000040059a <+10>:    retq
   End of assembler dump.

   Esto es lo rápido que corre:

   $ time ./inet_test
   f = 1000000000.000000
   
   real    0m5.232s
   user    0m5.158s
   sys     0m0.007s

   Entonces, es bastante obvio que cuando __thread var está en el ejecutable es tan rápido como una variable global ordinaria.

3. Hay una variable __thread y está en una biblioteca compartida, hay lentitud .

   Ejecutable:

   $ cat inet_test_main.c
   #include "stdio.h"
   #include "math.h"
   int test();
   
   int main()
   {
      test();
      return 1;
   }

   Biblioteca compartida:

   $ cat inet_test_lib.c
   #include "stdio.h"
   #include "math.h"
   
   static __thread double tlvar;
   //following line is needed so get_value() is not inlined by compiler
   double get_value() __attribute__ ((noinline));
   double get_value()
   {
     return tlvar;
   }
   
   int test()
   {
     int i;
     double f=0.0;
     tlvar = 1.0;
     for(i=0; i<1000000000; i++)
     {
       f += sqrt(get_value());
     }
     printf("f = %f/n", f);
     return 1;
   }

   Este es el código ensamblador de get_value (), vea qué tan diferente es, llama a __tls_get_addr() :

   Dump of assembler code for function get_value:
   => 0x00007ffff7dfc6d0 <+0>:     lea    0x200329(%rip),%rdi        # 0x7ffff7ffca00
      0x00007ffff7dfc6d7 <+7>:     callq  0x7ffff7dfc5c8 <__tls_get_addr@plt>
      0x00007ffff7dfc6dc <+12>:    movsd  0x0(%rax),%xmm0
      0x00007ffff7dfc6e4 <+20>:    retq
   End of assembler dump.
   
   (gdb) disas __tls_get_addr
   Dump of assembler code for function __tls_get_addr:
      0x0000003c40a114d0 <+0>:     push   %rbx
      0x0000003c40a114d1 <+1>:     mov    %rdi,%rbx
   => 0x0000003c40a114d4 <+4>:     mov    %fs:0x8,%rdi
      0x0000003c40a114dd <+13>:    mov    0x20fa74(%rip),%rax        # 0x3c40c20f58 <_rtld_local+3928>
      0x0000003c40a114e4 <+20>:    cmp    %rax,(%rdi)
      0x0000003c40a114e7 <+23>:    jne    0x3c40a11505 <__tls_get_addr+53>
      0x0000003c40a114e9 <+25>:    xor    %esi,%esi
      0x0000003c40a114eb <+27>:    mov    (%rbx),%rdx
      0x0000003c40a114ee <+30>:    mov    %rdx,%rax
      0x0000003c40a114f1 <+33>:    shl    $0x4,%rax
      0x0000003c40a114f5 <+37>:    mov    (%rax,%rdi,1),%rax
      0x0000003c40a114f9 <+41>:    cmp    $0xffffffffffffffff,%rax
      0x0000003c40a114fd <+45>:    je     0x3c40a1151b <__tls_get_addr+75>
      0x0000003c40a114ff <+47>:    add    0x8(%rbx),%rax
      0x0000003c40a11503 <+51>:    pop    %rbx
      0x0000003c40a11504 <+52>:    retq
      0x0000003c40a11505 <+53>:    mov    (%rbx),%rdi
      0x0000003c40a11508 <+56>:    callq  0x3c40a11200 <_dl_update_slotinfo>
      0x0000003c40a1150d <+61>:    mov    %rax,%rsi
      0x0000003c40a11510 <+64>:    mov    %fs:0x8,%rdi
      0x0000003c40a11519 <+73>:    jmp    0x3c40a114eb <__tls_get_addr+27>
      0x0000003c40a1151b <+75>:    callq  0x3c40a11000 <tls_get_addr_tail>
      0x0000003c40a11520 <+80>:    jmp    0x3c40a114ff <__tls_get_addr+47>
   End of assembler dump.

   ¡Funciona casi dos veces más lento! :

   $ time ./inet_test_main
   f = 1000000000.000000
   
   real    0m9.978s
   user    0m9.906s
   sys     0m0.004s

   Y, finalmente, esto es lo que informa perf - __tls_get_addr - 21% de la utilización de la CPU:

   $ perf report --stdio
   #
   # Events: 10K cpu-clock
   #
   # Overhead         Command        Shared Object              Symbol
   # ........  ..............  ...................  ..................
   #
       58.05%  inet_test_main  libinet_test_lib.so  [.] test
       21.15%  inet_test_main  ld-2.12.so           [.] __tls_get_addr
       10.69%  inet_test_main  libinet_test_lib.so  [.] get_value
        5.07%  inet_test_main  libinet_test_lib.so  [.] get_value@plt
        4.82%  inet_test_main  libinet_test_lib.so  [.] __tls_get_addr@plt
        0.23%  inet_test_main  [kernel.kallsyms]    [k] 0xffffffffa0165b75

Entonces, como puede ver cuando una variable local de subproceso está en una biblioteca compartida (declarada estática y usada solo en una biblioteca compartida) es bastante lenta . Si rara vez se accede a una variable local de subproceso en una biblioteca compartida, entonces no es un problema para el rendimiento. Si se usa con bastante frecuencia como en esta prueba, la sobrecarga será significativa.

El documento akkadia.org/drepper/tls.pdf que se menciona en los comentarios habla sobre cuatro posibles modelos de acceso TLS. Francamente, no comprendo cuándo se usa el "Modelo de ejecución inicial TLS", pero en cuanto a los otros tres modelos, es posible evitar llamar a __tls_get_addr() solo cuando la variable __thread está en un ejecutable y se accede desde el ejecutable.