Migliore risposta
D: Perché i programmatori mescolano sempre Halloween e Natale?
R: Perché 31 ottobre == 25 dicembre!
Due byte si incontrano. Il primo byte chiede: “Sei malato?”. Il secondo byte risponde: “No, mi sento solo un po fuori”.
D: quanti programmatori ci vogliono per cambiare una lampadina?
A: nessuno, quello “sa problema hardware
D: quanti programmatori Microsoft servono per cambiare una lampadina?
R: nessuno, fanno semplicemente delloscurità uno standard e dicono a tutti “questo comportamento è previsto dalla progettazione “
Uno studente di informatica sta studiando sotto un albero e un altro si ferma su una nuova bicicletta appariscente. Il primo studente chiede:” Dove lhai preso? “. Lo studente sulla bicicletta risponde:” Mentre studiavo fuori, una bella ragazza si è fermata sulla sua bicicletta. Si è tolta tutti i vestiti e ha detto: “Puoi avere tutto quello che vuoi”. ” Il primo studente risponde: “Ottima scelta! I suoi vestiti probabilmente non ti sarebbero stati adatti”.
Un fisico, un ingegnere e un programmatore erano in macchina su un ripido valico alpino quando i freni si sono guastati. La macchina stava diventando sempre più veloce, stavano lottando per aggirare le curve e solo una o due volte solo la debole barriera di sicurezza li ha salvati dallo schiantarsi sul fianco della montagna. Erano sicuri che sarebbero morti tutti, quando allimprovviso hanno visto una corsia di fuga. Entrarono nella corsia di fuga e si fermarono sani e salvi. Il fisico disse: “Dobbiamo modellare lattrito nelle pastiglie dei freni e il conseguente aumento di temperatura, vediamo se riusciamo a capire perché hanno fallito”. lingegnere ha detto: “Penso di avere un paio di chiavi nella parte posteriore. Dò unocchiata e vedrò se riesco a capire cosa” non va “. Il programmatore ha detto: “Perché non andiamo di nuovo a vedere se è riproducibile?”
D: “Qual è il modo orientato agli oggetti per diventare ricchi?”
A : Eredità
Un programmatore per i suoi amici (anche programmatori): “Ho incontrato una ragazza sexy ieri sera. Lho portata a casa e abbiamo iniziato a baciarci furiosamente. Lho fatta sedere sulla tastiera e …”. Tutti gli amici allunisono hanno detto “Hai” un computer a casa? Qual è la RAM?
Una query SQL entra in una barra, si avvicina a due tavoli e chiede: “Posso unirmi a te?”
Quando il tuo martello è C ++, tutto comincia a sembrare un pollice.
D: Quanti programmatori di prolog servono per cambiare una lampadina?
R: Sì.
A il programmatore mette due bicchieri sul comodino prima di andare a dormire. Uno pieno, nel caso abbia sete, e uno vuoto, nel caso non lo faccia.
Un ragazzo è in piedi allangolo della strada fumando una sigaretta dopo laltra. Una signora che cammina accanto a dei cartelli. lui e dice “Ehi, non sai che quelle cose possono ucciderti? Voglio dire, non hai visto il gigantesco avvertimento sulla scatola ?!” “Va tutto bene” dice il ragazzo, sbuffando casualmente “Io” un programmatore di computer “.” Allora? Cosa ha a che fare con qualcosa? chiese la signora. Ha risposto “Non ci preoccupiamo degli avvertimenti. Ci preoccupiamo solo degli errori. “
Ci sono 10 tipi di persone al mondo. Quelli che capiscono il binario e quelli che fanno sesso regolare.
Quindi questo programmatore esce per un appuntamento con una ragazza sexy
Risposta
Sono molto cattivi.
Sono i tipo di persone che entreranno e modificheranno un sistema finemente sintonizzato con una correzione “ovvia” e rovineranno tutto orribilmente, con le migliori intenzioni in assoluto.
Per darti unidea, un altro eccellente ingegnere che conosco , Jeffrey Hsu, lavorava presso ClickArray (ora noto come Array Networks) e mi ha assunto lì perché aveva bisogno di un altro tipo “grande pistola” per portare a termine un lavoro davvero critico per le prestazioni.
E abbiamo ottenuto è stato fatto.
Su sistemi Pentium 4 a 1,3 GHz (era il 2001).
Abbiamo una cache del proxy inverso fino a qualcosa che supera le 38.700 connessioni TCP al secondo, il che non è impressionante , finché non ti rendi conto che ci sono solo 16.384 porte utilizzabili per INADDR\_ANY, a meno che tu non modifichi sostanzialmente fy lo stack TCP / IP, se si tratta di un sistema basato su BSD o Linux.
Non avevamo modificato lo stack – era uno stack BSD – quindi significava che stavamo rispondendo anche alle richieste di caricamento della pagina iniziale in quello stesso lasso di tempo.
E poi eravamo al problema successivo
Circa mezzo mese dopo linizio del problema successivo, apparentemente qualcuno aveva finalmente avuto del tempo per fare alcuni test delle prestazioni sulle modifiche che stavano apportando al resto del codice nella cache.
Abbiamo avuto modo di vedere un po di panico crescente in ufficio per un un paio di giorni e abbiamo chiesto più volte quale fosse il problema, e gli è stato detto di non preoccuparti e di continuare a lavorare su ciò su cui stavamo lavorando.
Labbiamo fatto, perché stavamo riparando la macchina a stati finiti essere una vera macchina a stati finiti e ristrutturare il codice della cache in quel momento. È una delle cose che ha portato allazienda il prossimo round di finanziamenti, infatti.
Infine, i loro hotshots ci hanno chiamato per vedere se potevamo risolvere il loro problema.
Ottenevano circa 6.300 connessioni al secondo.
Avevano perso circa un fattore 6 volte in termini di prestazioni e non riuscivano a capire dove.
Ci sono volute un paio dore e alla fine siamo riusciti a rintracciarlo a un commit di “ottimizzazione per più macchine CPU”.
Lo abbiamo annullato e siamo tornati a circa 35.000 connessioni al secondo, un paio di percorsi di codice attivi e alla fine della giornata eravamo tornati ai vecchi numeri.
Per capire l “ottimizzazione” che il ” programmatore hot shot “pensava di voler realizzare, devi capire che il threading non era una gran cosa in quel momento.
Anche se lo fosse stato, stavamo ancora lavorando tramite la macchina a stati , che doveva essere fatto prima che lo stato globale potesse essere spostato in un singolo oggetto “statite” per farlo per thread e impedire alle istanze di interferire tra loro.
Quindi il modello di ridimensionamento doveva hanno più motori di “lavoro da fare” come p rocesses, e quindi un processo “gatekeeper” che avrebbe consentito a un processo di funzionare su una richiesta non appena arrivata. Ha visto tutte le richieste, quindi “ha lasciato andare il processo”; se cerano più richieste, la kqueue nel gatekeeper “lasciava andare un altro processo” e così via.
Il nostro “hot shot” aveva notato che un processo stava eseguendo quasi tutte le richieste, mentre il altri processi erano (per lo più) inattivi.
Questo perché avevo intenzionalmente utilizzato un LIFO invece di un FIFO per i processi in attesa di “lavoro da fare”.
Quindi ha “corretto “Cambiandolo in FIFO.
E le prestazioni andarono a puttane.
Il motivo per cui avevo usato un LIFO in il primo posto, anche se sapevo che non avrebbe necessariamente condiviso il carico tra i core, era perché sapevo alcune cose che l “hot shot” non sapeva.
Lo sapevo:
- Come dispositivo di rete, saremmo quasi sempre I / O, piuttosto che CPU, vincolati a meno che non stessimo caricando in un modulo per fare qualcosa come la rimozione degli spazi bianchi o la riscrittura dei contenuti per scopi pubblicitari
- Più precisamente, sapevo che lultimo processo per mettersi in fila stava per iniziare g per avere tutte le sue pagine in core, mentre quella che era rimasta inattiva più a lungo probabilmente non avrebbe tutte le sue pagine in core
- Inoltre, ho scoperto che ci sarebbero state collisioni di cache TLB, poiché tutti i processi dello spazio degli utenti sono stati mappati allo stesso intervallo di indirizzi, risultando in svuotamenti
- Il che significava che ci sarebbero stati ricaricamenti della cache, il che significava almeno uscire almeno alla cache L1 e probabilmente L2
- Combinato, ciò comporterebbe un ulteriore stallo della pipeline di istruzioni, perché non cera cache L3 sullarchitettura P4
- E così ho intenzionalmente scambiato ciò che sapevo sarebbero stati probabilmente cicli di CPU inattivi sul core per quello che sapevo avrebbero avuto le migliori prestazioni di I / O bound
Quindi avevo scelto intenzionalmente un ordine LIFO e verificato un miglioramento delle prestazioni, utilizzando una tecnica che avevo usato per la prima volta nel 1994 o così chiamato (da me, da quando avevo inventato la tecnica) “programmazione del motore caldo”.
Quindi questo “colpo caldo” aveva distrutto il pe prestazioni a causa del cambiamento.
E poi, dopo la presunta “ottimizzazione”, non è riuscito a eseguire un test delle prestazioni per verificare che si trattasse effettivamente di unottimizzazione.
Lunica cosa che lui d controllato era che, sotto carico, i processi stessero tutti segnando circa lo stesso utilizzo totale della CPU, nel tempo, che è ciò che pensava intendesse ottenere un migliore utilizzo multicore.
I peggiori ingegneri del software sono quelli che sono abbastanza bravi da essere pericolosi, ma non abbastanza bravi da riconoscere quando stanno prendendo una decisione sbagliata.
Sono resi ancora peggiori dal non verificare dopo il fatto che la decisione è stata effettivamente sbagliata misurando i risultati dei loro cambiamenti usando un righello imparziale.