Pregunta

Según los docs gcc , memcmp no es una función intrínseca de GCC. Si usted quiere acelerar memcmp de glibc bajo gcc, se tendría que usar las funciones intrínsecas de nivel inferior definidos en la documentación. Sin embargo, cuando se busca en todo el Internet, parece que mucha gente tiene la impresión de que memcmp es una función incorporada. ¿Es para algunos compiladores y no para otros?

¿Fue útil?

Solución

Su enlace parece ser para la arquitectura x86-específica funciones integradas, de acuerdo con la esta memcmp se implementa como una arquitectura independiente integrada por gcc.

Editar:

Compilar el código siguiente con la versión de Cygwin gcc 3.3.1 para i686, O2:

#include <stdlib.h>

struct foo {
    int a;
    int b;
} ;

int func(struct foo *x, struct foo *y)
{
    return memcmp(x, y, sizeof (struct foo));
}

produce la siguiente salida (tenga en cuenta que la llamada a memcmp () se convierte en un 8-byte "REPZ CMPSB"):

   0:   55                      push   %ebp
   1:   b9 08 00 00 00          mov    $0x8,%ecx
   6:   89 e5                   mov    %esp,%ebp
   8:   fc                      cld    
   9:   83 ec 08                sub    $0x8,%esp
   c:   89 34 24                mov    %esi,(%esp)
   f:   8b 75 08                mov    0x8(%ebp),%esi
  12:   89 7c 24 04             mov    %edi,0x4(%esp)
  16:   8b 7d 0c                mov    0xc(%ebp),%edi
  19:   f3 a6                   repz cmpsb %es:(%edi),%ds:(%esi)
  1b:   0f 92 c0                setb   %al
  1e:   8b 34 24                mov    (%esp),%esi
  21:   8b 7c 24 04             mov    0x4(%esp),%edi
  25:   0f 97 c2                seta   %dl
  28:   89 ec                   mov    %ebp,%esp
  2a:   5d                      pop    %ebp
  2b:   28 c2                   sub    %al,%dl
  2d:   0f be c2                movsbl %dl,%eax
  30:   c3                      ret    
  31:   90                      nop    

Otros consejos

Tenga en cuenta que la rutina REPZ CMPSB podría no ser más rápido que memcmp de glibc. En mis pruebas, de hecho, es no más rápido, incluso cuando se comparan sólo unos pocos bytes.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052

Ahora en 2017, GCC y Clang parece tener algunas optimizaciones para tampones de tamaños 1, 2, 4, 8 y algunos otros, por ejemplo 3, 5 y múltiple de 8.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top