L'incorporamento all'interno del C++ è accettabile?

Question

Se si scrive un'applicazione che è molto latenza sensibile quali sono i limiti per l'incorporamento assemblatore all'interno di funzioni C++ (e utilizzando la funzione di C++ chiamate normalmente), in questo modo:

inline __int64 GetCpuClocks() 
{ 

    // Counter 
    struct { int32 low, high; } counter; 

    // Use RDTSC instruction to get clocks count 
    __asm push EAX 
    __asm push EDX 
    __asm __emit 0fh __asm __emit 031h // RDTSC 
    __asm mov counter.low, EAX 
    __asm mov counter.high, EDX 
    __asm pop EDX 
    __asm pop EAX 

    // Return result 
    return *(__int64 *)(&counter); 

} 

(La funzione di cui sopra è venuto da un altro post SO visto)

È possibile trattare funzioni integrate assembler come una scatola nera ? Potresti recuperare facilmente un risultato dai calcoli eseguiti nell'assemblatore? Ci sono pericoli che non sai quali variabili sono attualmente nei registri, ecc.? Fa più problemi che a risolvere, o è accettabile per compiti specifici?

(dove l'architettura sta per essere fissato, e conosciuto)

EDIT Ho appena trovato questo, questo è quello che sto suggerendo:

http://www.codeproject.com/Articles/15971/Using-Inline-Assembly-in-C-C

EDIT2 questo è più rivolto verso Linux e x86 - è solo una domanda generale C++/assemblatore (o almeno così pensavo).

Answer 1

Se l'asm in questione sta spingendo tutti i registri che utilizza in alto, poi li fa apparire in basso, penso che tu sia sicuro di non preoccuparti.

Nel tuo esempio, queste sono le istruzioni __asm push EAX e __asm pop EAX.

La vera risposta, suppongo, è che è necessario conoscere abbastanza ciò che fa il asm per essere sicuri di poterlo trattare come una scatola nera. :)

Answer 2

mi piacerebbe rispondere sul subquestion:

vuol causare più problemi di risolvere, o è accettabile per specifiche attività di piccole dimensioni?

Lo fa sicuramente! Usando l'assemblatore in linea, si prende l'abilità dal compilatore per ottimizzare il codice. Non può eseguire la substizione di espressione parziale o qualsiasi altra ottimizzazione di fantasia. È davvero molto difficile produrre codice che sia migliore di quello che il compilatore emette con -O3. E come bonus, il codice diventa ancora migliore con la prossima versione del compilatore (presumendo che la prossima versione del compilatore non la romperà;)).

I compilatori di solito afferrano uno scopo più ampio di quello che il cervello umano potrebbe mai (o dovrebbe, per garantire la sanità mentale), essere in grado di allineare la funzione giusta al posto giusto, di eseguire una sostituzione di espressione parziale che renda il codice più efficiente. Cose che non faresti mai in ASM perché il tuo codice diventa illeggibile da morire.

Come riferimento aneddotico, vorrei scrivere su this post di Linus Torvalds, relativo all'implementazione git di SHA1, che supera la SHA1 ottimizzata a mano in libcrypt.

In effetti, penso che l'unico uso ragionevole dell'assemblatore inline oggigiorno stia chiamando le istruzioni del processore che non sono disponibili altrimenti (quello che hai citato è disponibile, su linux ad esempio come clock_gettime, almeno se sei solo dopo un contatore di tempo ad alta risoluzione) o se si devono fare cose in cui è necessario ingannare il compilatore (ad esempio durante l'implementazione di interfacce di funzioni esterne).

---

Sul frammento e su ciò che altri hanno detto. Soprattutto con tali funzioni otterrai una penalità sulle prestazioni. In linea asm, devi essere super-attento che i registri siano mantenuti nello stato che il compilatore presume che siano (push/pop, come sopra). Mentre se si scrive il codice normalmente, il compilatore può fare attenzione e mantenere esattamente quelle variabili per le quali ha senso nei registri e quelli che non si adattano allo stack.

Fidati del tuo compilatore. È intelligente La maggior parte delle volte. Investi il ​​tempo risparmiato evitando di utilizzare l'assemblatore in linea nel pensare a algoritmi intelligenti e veloci e ad apprendere i relativi switch del compilatore (ad esempio per abilitare le ottimizzazioni SSE, ecc.).