MSDN "Writing Faster Managed Code: Know What Things Cost" è molto carino, ma è stato scritto per CLR v1 nel 2003. Esiste una versione aggiornata di questo da qualche parte?Esiste una versione aggiornata di "Scrittura di un codice gestito più veloce: sapere quali sono le spese"?
Non so di quello che sostituisce quello ma il libro CLR via C# ti fornirà molte conoscenze approfondite e pertinenti su come funziona il CLR e dove consuma un sacco di tempo e risorse.
Io non la penso così, e non penso che una versione aggiornata sarebbe molto diversa.
I dati di temporizzazione sarebbero diversi in quanto la macchina di prova sarebbe probabilmente più recente e più veloce, ma la relazione tra i test sarebbe praticamente la stessa.
L'articolo riguarda gli effetti di basso livello delle operazioni comuni nel codice gestito e ciò non è cambiato molto da quando è stato scritto l'artice. Le nuove versioni del framework hanno aggiunto molte funzionalità, ma sono tutte basate sulle primitive disponibili dal C# 1.0.
No. Non l'ho mai aggiornato, ma penso che sia stato scattato con i granelli di sale appropriati, il consiglio generale e la maggior parte delle regole generali nell'articolo ancora oggi reggono bene.
(Detto questo, sarebbe interessante ripetere l'esperimento di oggi per vedere come i tempi primitivi sono cambiati, come il codice generato è cambiato, e come i microprocessori sono cambiati.)
Le spese generali relative della maggior parte dei primitivi vinto Sono cambiati molto, ma alcuni sono cambiati radicalmente. Ad esempio, le prestazioni mediocri di invocazione di delegati non statici sono state notevolmente migliorate (in .NET 2.0, se ricordo correttamente). Mi dispiacerebbe pensare che un praticante oggi farebbe di tutto per evitare il richiamo del delegato perché nel 2003 lo ho segnalato come molto costoso.
Da .NET 1.1, mi aspetto che molte sequenze di codice compilate siano cambiate; ci sarebbero nuove ottimizzazioni del compilatore JIT (che non appaiono così bene nei microbenchmarks); diversi mix di codice JIT'D e NGEN (e NGEN non è stato esplorato nel mio articolo); e sottosistemi chiave come il garbage collector sono stati continuamente perfezionati nel corso degli anni.
Riprendo il mio consiglio di cautela circa il potenziale degli effetti del sistema di memoria per attutire i costi di un numero qualsiasi di operazioni primitive con codice gestito singolo - e di nuovo notare che molto è cambiato. Ad esempio, una grande quantità di prestazioni CLR funzionano in 03-04 in un migliore comportamento del set di lavoro (come la riduzione al minimo delle pagine private sporche) degli assembly di sistema NGEN.
Naturalmente il tema dell'articolo è l'imperativo di misurare attentamente e con attenzione l'esecuzione del codice e il tema è senza tempo.
A proposito, ho sempre voluto fare un articolo di follow-up sui costi previsti di tempo e spazio delle prime centinaia di metodi .NET BCL più utilizzati, e per mostrare alcuni racconti di cautela alcuni dei storie horror che abbiamo trovato lavorando sulle prestazioni .NET. Ciò ha portato ad alcune considerazioni molto interessanti su come caratterizzare la performance empirica di una libreria/quadro di classe come effettivamente utilizzata dai veri praticanti allo stato brado ...
Grazie per averlo letto, e grazie per il vostro costante interesse .
p.s.Vedo Vance Morrison successivamente ha scritto un grande due parti serie MSDN su questo argomento - se ti è piaciuto il mio articolo vi innamorerete di queste:
Vorrei aggiungere che i microprocessori sono cambiati. Ovviamente offrono più thread e/o core. E i progettisti di CPU sono stati in grado di masticare tracce di esecuzione di app OOP e JVM/CLR per mettere a punto e modificare le loro microarchitetture. Ad esempio, una previsione delle filiali molto migliore nel contesto delle chiamate di metodi virtuali e dei richiami di metodo brevi consente di eseguire parte del codice che il JIT non è in grado di ottimizzare per eseguire immediatamente out-of-order con meno rischi, rollback o stalli. Alcuni costi generali sono ottimizzati completamente. Ciò rende il microbenchmarking molto più problematico e pericoloso! –
Anche se alcuni microprocessori hanno iniziato a muoversi nella direzione opposta, tornando ad essere più in ordine e con registri letterali (ad esempio PPC, Larabee), il che rende più dolorose molte condanne alle condutture. – Crashworks
Così vero! Penso che la tendenza dell '"efficienza energetica di un calcolo supera la velocità di un calcolo" continua a prendere slancio (supponendo che il mix di "software di throughput" parallelizzato diventi più economicamente interessante), vedremo più di queste microarchitetture più semplici, o forse anche un mix di complessi e semplici chip multiprocessore eterogenei. È interessante notare che, mentre il pendolo dell'hardware oscilla, potrebbe riflettersi in tempo con i cambiamenti nel codice e nell'organizzazione della VM! Il software modella l'hardware e viceversa. –