2011-03-12 11 views
7

Qual è il codice assembly x86 più veloce per sincronizzare l'accesso a un array in memoria?Codice assembly x86 più veloce per sincronizzare l'accesso a un array?

Per essere più precisi: Abbiamo un continuo singola regione di paging malloc'ed in memoria e il sistema operativo non sarà pagina-out questa regione per tutta la durata del nostro esperimento. Un thread scriverà nell'array, un thread leggerà dall'array. la matrice è piccola, ma è più grande della capacità di scrittura atomica della CPU (in modo che sia necessario un blocco separato)

"più veloce": la velocità effettiva: non solo supporre che la lunghezza del bytecode sia significativa ma in considerazione il comportamento di memorizzazione nella cache del comportamento di blocco e ramificazione in relazione al codice circostante.

Si deve lavorare su x86-32 e/o x86-64

Si deve lavorare on-top (o discendenti di) Windows a partire da XP, Linux dal kernel 2.2, o Maxos X (a utente -modalità).

Si prega di non "dipende" -responsabili: se dipende da qualcosa che non ho specificato qui basta creare il proprio esempio (s) e dichiarare ciò che è più veloce in quei/quei casi (s).

CAP! (Questo per evitare che le descrizioni vaghe)

Messaggio non solo il 2-line LOCK + CMPXCHG confrontare & di swap, ma ci mostrano come si integrano con le istruzioni di lettura in un thread e le rettifiche di istruzioni del altra.

Se si desidera, spiegare le modifiche apportate all'ottimizzazione della cache e come evitare le previsioni errate di ramo se il target di diramazione dipende da (1) se si ottiene il blocco o meno (2) quale è il primo byte di un più grande -read è.

Se ti piace distinguere tra multiprocessing e task-switching: come funzionerà il tuo codice se i thread non vengono eseguiti su 2 cpus ma ne prendi uno?

+0

@Ken Bianco: haha ​​divertente. o sei serio? In tal caso: dai un'occhiata alla terminologia che uso e alle domande a cui ho risposto. –

+0

@Ken - Sarei molto interessato alla scuola che assegna questo tipo di domande come compiti a casa. – linuxuser27

+0

@eznme, ho letto la terminologia utilizzata. Sembra qualcosa direttamente da un libro di testo. "Pubblica non solo la tua 2-line ... ma mostra". Nessuna offesa intesa - non sembrava qualcosa che una tipica domanda avrebbe potuto contenere. @ linuxuser27, hai visto uno dei corsi avanzati al MIT o al RIT? –

risposta

1

io non capisco. Il blocco del bus (prefisso di blocco o xchg mem, istruzione reg) e la velocità hanno poco a che fare l'uno con l'altro. Si tratta di sincronizzazione fisicamente la CPU con il dispositivo attivo più lento nel vostro sistema - che potrebbero essere collegati tramite il PCI 33 MHz o qualcosa del genere - e si può scommettere che sarà molto più lento di un accesso RAM che non era nella cache. Quindi aspettati 300-3000 cicli di clock della CPU a seconda di quanto tempo è necessario attendere per il dispositivo. Se nessun dispositivo è attivo, è necessario attendere che i rispettivi bus confermino il blocco.

codice più veloce? Dimenticalo. Devi accettare che questo è il modo in cui funzionano i blocchi del bus o trovare altri modi per sincronizzare che non richiedono il blocco del bus.

-1

Se le prestazioni di chiusura è importante, si sta facendo qualcosa di sbagliato.

+0

Sì, sono per lo più d'accordo. Se i pezzi di lavoro sono abbastanza grandi, ammortizza il costo di chiusura. –

2

In realtà, la risposta è "dipende". Qual è il modello di utilizzo del tuo array? È letto soprattutto? È l'aggiornamento, soprattutto, e puoi ottenere risultati imprecisi sulla lettura (usando array per-cpu)? Gli aggiornamenti sono così rari che RCU darebbe seri miglioramenti delle prestazioni?

Ci sono un sacco di compromessi qui, vedere il libro di Paul McKenney: Is Parallel Programming Hard, And, If So, What Can You Do About It?

Problemi correlati