rdtsc, zu viele Zyklen

#include <stdio.h>
static inline unsigned long long tick() 
{
        unsigned long long d;
        __asm__ __volatile__ ("rdtsc" : "=A" (d) );
        return d;
}

int main()
{
        long long res;
        res=tick();

        res=tick()-res;
        printf("%d",res);
        return 0;
}

Habe ich kompiliert den code mit gcc -O0 -O1 -O2 -O3 Optimierungen. Und ich bekomme immer 2000-2500 Zyklen. Kann mir jemand erklären, warum diese Ausgabe? Wie verbringen Sie diese Zyklen?

~~Erste Funktion "tick" ist falsch. Dieses Recht ist~~.

Andere version der Funktion "tick"

static __inline__ unsigned long long tick()
{
  unsigned hi, lo;
  __asm__ __volatile__ ("rdtsc" : "=a"(lo), "=d"(hi));
  return ( (unsigned long long)lo)|( ((unsigned long long)hi)<<32 );
}

Dies ist Assembler-code, der für -O3

 .file  "rdtsc.c"
.section    .rodata.str1.1,"aMS",@progbits,1
.LC0:
    .string "%d"
    .text
    .p2align 4,,15
.globl main
    .type   main, @function
main:
    leal    4(%esp), %ecx
    andl    $-16, %esp
    pushl   -4(%ecx)
    pushl   %ebp
    movl    %esp, %ebp
    subl    $40, %esp
    movl    %ecx, -16(%ebp)
    movl    %ebx, -12(%ebp)
    movl    %esi, -8(%ebp)
    movl    %edi, -4(%ebp)
#APP
# 6 "rdtsc.c" 1
    rdtsc
# 0 "" 2
#NO_APP
    movl    %edx, %edi
    movl    %eax, %esi
#APP
# 6 "rdtsc.c" 1
    rdtsc
# 0 "" 2
#NO_APP
    movl    %eax, %ecx
    movl    %edx, %ebx
    subl    %esi, %ecx
    sbbl    %edi, %ebx
    movl    %ecx, 4(%esp)
    movl    %ebx, 8(%esp)
    movl    $.LC0, (%esp)
    call    printf
    movl    -16(%ebp), %ecx
    xorl    %eax, %eax
    movl    -12(%ebp), %ebx
    movl    -8(%ebp), %esi
    movl    -4(%ebp), %edi
    movl    %ebp, %esp
    popl    %ebp
    leal    -4(%ecx), %esp
    ret
    .size   main, .-main
    .ident  "GCC: (Debian 4.3.2-1.1) 4.3.2"
    .section    .note.GNU-stack,"",@progbits

Dies ist CPU -

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 15
model       : 4
model name  : Intel(R) Xeon(TM) CPU 3.00GHz
stepping    : 3
cpu MHz     : 3000.105
cache size  : 2048 KB
fdiv_bug    : no
hlt_bug     : no
f00f_bug    : no
coma_bug    : no
fpu     : yes
fpu_exception   : yes
cpuid level : 5
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss constant_tsc up pebs bts pni
bogomips    : 6036.62
clflush size    : 64

Viel bedeutet Sie nicht zählen es. Verwenden viele statt.
oh, danke )
rdtsc schreibt in %edx:%eax`. Ihr tick() Funktion ist falsch.
mit der zweiten Funktion die gleiche Ausgabe
natürlich, mit =Einer wird zurückkehren unteren 32 bits auf x86_64 nur, und die unteren 32 bits sind genug für diesen test
Stellen Sie sicher, dass Sie verstehen, warum rdtsc ist nicht eine zuverlässige timer.
Sicher können Sie helfen, die OP auf, warum Sie dies sagen.
Bei mir läuft dein code, ich habe fast immer das bekommen, 42. Douglas Adams würde glücklich sein. 🙂
Welches Betriebssystem verwenden Sie für diesen test (die Distribution und kernel-version)?
Linux-version 2.6.26-2-686 (Debian 2.6.26-26lenny1) ([email protected]) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Thu Nov 25 01:53:57 UTC 2010

InformationsquelleAutor eXXXXXXXXXXX2 | 2011-11-30

assembly c rdtsc x86

10

Ich habe versucht deinen code auf mehrere Linux-Distributionen laufen auf verschiedenen Intel-CPUs (zugegeben, alle neuer als der Pentium 4 HT 630 Sie zu sein scheinen, verwenden). In all den tests, die ich bekam Werte zwischen 25 und 50 Zyklen.

Meine einzige Hypothese, die konsistent mit allen beweisen ist, dass Sie Ihr Betriebssystem in einer virtuellen Maschine, statt auf blankem Metall, und die TSC ist immer virtualisiert.

InformationsquelleAutor NPE
7

Es gibt viele Gründe, um eine große Anzahl:
- Das OS ein context-switch, und Ihren Prozess bekommen put, um zu schlafen.
- Eine Festplatte suchen, aufgetreten sind, und Ihren Prozess bekommen put, um zu schlafen.
- ..., jeder der eine ganze Reihe von Gründen, warum Sie Ihren Prozess bekommen könnte, ignoriert.
Beachten Sie, dass rdtsc ist nicht besonders zuverlässig für timing, ohne Arbeit, denn:
- Prozessor-Geschwindigkeiten ändern kann, und somit die Länge eines Zyklus (gemessen in Sekunden) verpasst.
- Verschiedenen Prozessoren können unterschiedliche Werte für die TSC für einen bestimmten Augenblick in der Zeit.
Meisten Betriebsystemen Systeme haben einen hochpräzisen Takt oder timing-Methode. clock_gettime auf Linux zum Beispiel, vor allem die monotonen Uhren. (Verstehen Sie auch den Unterschied zwischen eine Wand-Uhr und eine monotone Uhr: eine Wanduhr kann rückwärts zu bewegen — auch in UTC.) Auf Windows, ich denke, die Empfehlung ist QueryHighPerformanceCounter. In der Regel sind diese Uhren bieten mehr als genug Genauigkeit für die meisten Bedürfnisse.

Sich auch, einen Blick auf die Versammlung, wie es aussieht, sind nur 32-bit der Antwort: ich sehe nicht %edx gerettet, nachdem rdtsc.

Ihren code ausführen, bekomme ich die timings von 120-150 ns für clock_gettime mit CLOCK_MONOTONIC, und 70-90 Zyklen für rdtsc (~20 ns bei voller Geschwindigkeit, aber ich vermute, der Prozessor ist getaktet nach unten, und das ist wirklich über 50 ns). (Auf ein ~~laptop~~desktop (verdammt, SSH, vergaß die Maschine, die ich war!) das ist bei etwa konstant 20% CPU-Nutzung) Sicher, dass Ihre Maschine nicht verzetteln?
- struct timespec ts1,ts2; clock_gettime(CLOCK_MONOTONIC,&ts1); clock_gettime(CLOCK_MONOTONIC,&ts2); ts2.tv_nsec-ts1.tv_nsec ~8000 ist er zu groß.
- =A kopiert Werte von edx und eax.
- Wenn du das so sagst: vielleicht OP ist mis-kompilieren. Sehen Sie %edx gerettet in der Montage?
- Ich benutzte zweite Funktion, die assembly-code aktualisiert wurde
- nochmal: wenn zusammengestellt, für 32 bit, =A Einschränkung kopieren die beiden Register eax und edx zur angegebenen Position.
- Ich bekomme diffs in die ~130-Reihe, auf Intel Core i7.
- die Versammlung, die der OP gepostet. Zuvor hatte es sich nicht enthalten, etwas über %edx.
- schwer zu sagen, nun, vielleicht auch nur falschen code eingefügt. =Ein sicherlich produziert die korrekte Montage mit beiden Registern
- Tatsächlich, auf einem modernen Linux-kernel clock_gettime ausgeführt wird, im user-space (es ist ein VDSO statt einer richtigen syscall), so dass es sehr effizient ist. Der Hauptgrund, warum die Ebene rdtsc schneller ist, ist, dass es nicht die Hindernisse, die notwendig sind, um zu verhindern, dass der Prozessor vom hissen der rdtsc vor den Anweisungen man versucht, die Zeit.
InformationsquelleAutor Thanatos
4

Es sieht aus wie dein OS deaktiviert die Ausführung von RDTSC im user-space. Und Ihre Anwendung schalten auf kernel-und zurück, das eine Menge von Zyklen.

Dies ist von der Intel Software Developer ' s Manual:

Wenn in geschützten oder virtuellen 8086-Modus, den Zeitstempel zu deaktivieren (TSD) - flag in
register CR4 schränkt die Verwendung der RDTSC-Instruktion wie folgt. Wenn das TSD-flag
ist klar, die RDTSC-Instruktion kann ausgeführt werden in jeder Berechtigungsebene; wenn die fahne
gesetzt ist, wird die Anweisung kann nur ausgeführt werden, bei Privileg-Ebene 0. (Wenn in real-Adresse
mode, die RDTSC-Instruktion ist immer aktiviert.)

Edit:

Beantwortung aix Kommentar, ich erklären, warum TSD ist wahrscheinlich der Grund dafür ist hier.

Ich kenne nur diese Möglichkeiten für ein Programm zum ausführen einer einzelnen Anweisung mehr als üblich:
1. Unter einigen emulator,
2. mit selbst-modifizierten code
3. Kontext wechseln,
4. kernel wechseln.
Ersten 2 Gründe können in der Regel keine verzögerte Ausführung für mehr als ein paar hundert Zyklen. 2000-2500 Zyklen sind typisch für Kontext/kernel wechseln. Aber es ist praktisch unmöglich, zu fangen ein context-switch mehrere Male auf der gleichen Stelle. So sollte es sein, kernel wechseln. Was bedeutet, dass entweder das Programm läuft unter einem debugger oder RDTSC ist nicht erlaubt in den user-Modus.

Ist der wahrscheinlichste Grund für OS deaktivieren RDTSC kann Sicherheit sein. Es gab versuche, die RDTSC knacken von Verschlüsselungs-Programmen.
- Ich habe nicht die Abstimmung über die Antwort so oder so, aber ich denke, es wäre besser, wenn du sagtest: warum Sie dachte TSD könnten die Ursache sein.
- Ich habe erklärt dieser. Danke.
- Kluev und für clock_gettime ähnliche Erklärungen? Ich habe 8000 nsec mit CLOCK_MONOTONIC id. Es ist riesig=/
- clock_gettime ist wahrscheinlich erfolgt durch den kernel, also zumindest 2000 Zyklen erforderlich ist. Kann auch mehr sein. Aber 8000 EFF scheint zu hoch - ich kann es nicht erklären.
- Kluev d.h. ich kann in diesem Fall nicht zu Messen, z.B. Intervall von 100 Zyklen. Wahrscheinlich gibt es Möglichkeiten, um dieses problem zu vermeiden?
- Es kann in Bezug auf die Auflösung (Genauigkeit) von clock_gettime, aber dann sollten Sie 8000 nsec Abständen, vermischt mit null-Abständen.
- Kluev Laufen clock_gettime ~50 mal Ergebnisse 8000-11000 und 2 mal war 2000 und 3000. Das ist seltsam. CPU wurde nicht geladen
- Wahrscheinlich der einzige Weg, um zu Messen, in kurzen Abständen zu überzeugen, dass Ihr sysadmin zu ermöglichen RDTSC (da system hat nur einen core und somit keine Risiken bestehen, die auf dieses system).
- die Auflösung ist definitiv die Ergebnisse beeinflusst, noch immer kann ich nicht erklären, warum dem durchschnittlichen Intervall ist so hoch.
- Kluev Vielen Dank für die Erklärungen)
- glaubst du nicht, dass user-mode-Prozess wird nur getötet werden, wenn er versucht, die execute-Anweisung ist es nicht erlaubt?
- Nicht nötig. In diesem speziellen Fall-system kann sicher ausführen kann, ist es im kernel-Modus. Hacker-Programm kann nicht erraten, was passiert auf anderen hyperthreading-thread, wenn es gegeben ist, solche ungenauem timer.
- Nach diesem test-Programm mit dem kernel - mjmwired.net/kernel/Documentation/prctl/disable-tsc-test.c (und definiert PR_TSC_ENABLE PR_TSC_SIGSEGV in prctl.h) - es wird SIGSEGV.
- Kann sein, es gibt SIGSEGV nur zum testen auf und führt es im kernel-Modus im realen Leben... ich weiß nicht. Es wäre sinnvoll, nicht zu SIGSEGV in der Produktion code. Sonst viele nützliche Anwendungen werden ... unuseful 🙂
- was meinst du?? Kernel ist der gleiche immer, es kann nicht töten-app in eine Fall und nicht in anderen. Natürlich gibt es eine gewisse Wahrscheinlichkeit, dass dieses Programm und die Namen definiert werden, sind veraltet und etwas verändert.. Leider habe ich nicht die nicht-virtualisierten linux-box derzeit zu versuchen mich, aber ich werde versuchen, einen zu finden.
- Ich weiß nicht, die details. Nie versucht, irgendwelche Sicherheits-features. Ich sage nur, was möglich sein kann, Verhalten. Ich kann mich auch irren.
InformationsquelleAutor Evgeny Kluev
1

Instruction cache miss? (dies ist meine Vermutung)

Auch, möglicherweise,

Schalter hypervisor in einem virtualisierten system?
Reste der bootstrap-Programm (einschließlich Netzwerk-Aktivität auf der gleichen CPU)?

Zu Thanatos: Auf Systemen neuer als 2008, rdtsc() ist eine Wanduhr und variiert nicht mit der Frequenz Schritte.

Können Sie versuchen, diese wenig code?
```
int main()
{   
    long long res;

    fflush(stdout);           //chnage the exact timing of stdout, in case there is something to write in a ssh connection, together with its interrupts

    for (int pass = 0; pass < 2; pass++)
    {
    res=tick();
    res=tick()-res;
    }
    printf("%d",res);     //ignore result on first pass, display the result on second pass.
    return 0;
}
```
- Dieses technisch nicht eine Antwort, es ist mehr follow-up-engagement. Jedoch, Sie haben nicht genug rep Kommentar und es sieht aus wie du bist aktiv an die OP (und die scheinen zu wissen, um diese beantworten), so bin ich nicht entfernen, dieser Beitrag. Wenn Sie nicht bekommen, eine Antwort von der OP, bitte schalten Sie dies in eine Antwort, dass einfach davon ausgegangen, was Sie gesagt - oder es wird wahrscheinlich entfernt werden.
InformationsquelleAutor Perig
0

Nur eine Idee - vielleicht sind diese zwei rdtsc-Instruktionen werden ausgeführt auf verschiedenen Kernen? rdtsc Werte können leicht variieren über Kerne.
- nur der Kern, der nach /sys/devices/system/cpu/
InformationsquelleAutor pronvit

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.