Cel mai bun răspuns
Î: De ce programatorii amestecă întotdeauna Halloweenul și Crăciunul?
A: Pentru că 31 oct == 25 dec!
Se întâlnesc doi octeți. Primul octet întreabă: „Ești bolnav?”. Al doilea octet răspunde: „Nu, doar mă simt puțin dezamăgit.”
Î: câți programatori este nevoie pentru a schimba un bec?
A: niciunul, asta este problemă hardware
Î: câți programatori Microsoft este nevoie pentru a schimba un bec?
R: niciunul, ei fac din întuneric un standard și spun tuturor „acest comportament este prin design „
Un student la informatică învață sub un copac, iar altul se ridică pe o bicicletă nouă și strălucitoare. Primul student întreabă:„ De unde ai luat asta? ”. Studentul de pe bicicletă răspunde:„ În timp ce studiam afară, o fată frumoasă s-a oprit pe bicicletă, și-a scos toate hainele și a spus: „Poți avea orice vrei”. ” Primul student răspunde: „Bună alegere! Probabil că hainele ei nu ți s-ar fi potrivit.”
Un fizician, un inginer și un programator se aflau într-o mașină care conducea peste o trecere abruptă alpină când frânele au eșuat. Mașina devenea din ce în ce mai rapidă, se străduia să ocolească colțurile și o dată sau de două ori doar slaba barieră de protecție îi scutea de prăbușirea pe partea de munte. Erau siguri că vor muri cu toții, când brusc au văzut au tras în banda de evacuare și s-au oprit în siguranță. Fizicianul a spus „Trebuie să modelăm fricțiunea din plăcuțele de frână și creșterea temperaturii rezultată, să vedem dacă putem afla de ce au eșuat”. inginerul a spus „Cred că am câteva chei în spate. Voi arunca o privire și voi vedea dacă pot afla ce este greșit”. Programatorul a spus „De ce nu mergem din nou și vedem dacă este reproductibil?”
Î: „Care este modalitatea orientată obiect de a deveni bogat?”
A : Inheritance
Un programator pentru prietenii săi (de asemenea, programatori): „Am întâlnit o fată fierbinte aseară. Am adus-o acasă și am început să ne sărutăm cu furie. Am așezat-o pe tastatură și …”. Toți prietenii la unison au spus „Ai” un computer acasă? Care este memoria RAM?
O interogare SQL intră într-un bar, merge până la două mese și întreabă „Pot să mă alătur?”
Când ciocanul este C ++, totul începe să arate ca un deget mare.
Î: Câți programatori de prolog este nevoie pentru a schimba becul?
A: Da.
A programatorul pune două pahare pe noptieră înainte de a merge la culcare. Una plină, în caz că îi este sete și una goală, în cazul în care nu o face.
Un tip stă la colțul străzii fumând o țigară după alta. îl spune și „Hei, nu știi că acele lucruri te pot ucide? Adică, nu ai văzut avertismentul uriaș de pe cutie ?!„ „E în regulă”, spune tipul, pufăind dezinvolt „Eu” un programator de computer „.” Deci? Ce legătură are asta cu ceva? a întrebat doamna. El a răspuns „Nu ne pasă de avertismente. Ne pasă doar de erori. „
Există 10 tipuri de oameni în lume. Cei care înțeleg binare și cei care fac sex regulat.
Deci, acest programator iese la o întâlnire cu un pui fierbinte
Răspuns
Sunt foarte răi.
Ei sunt un fel de oameni care vor intra și vor modifica un sistem reglat fin cu o remediere „evidentă” și vor înșela totul oribil, cu cele mai bune intenții.
Pentru a vă face o idee, un alt inginer excelent pe care îl cunosc , Jeffrey Hsu, lucra la ClickArray (acum cunoscut sub numele de Array Networks) și m-a angajat acolo pentru că avea nevoie de un alt tip de „armă mare” pentru a face o muncă cu adevărat critică de performanță.
s-a făcut.
Pe sistemele Pentium 4 de 1,3 GHz (era 2001).
Avem o cache proxy inversă cu până la ceva peste 38.700 de conexiuni TCP pe secundă – ceea ce nu este impresionant , până când vă dați seama că există doar 16.384 de porturi utilizabile pentru INADDR\_ANY, cu excepția cazului în care modificați substanțial fy stiva TCP / IP, dacă este un sistem bazat pe BSD sau Linux.
Nu am modificat stiva – era o stivă BSD – așa că a însemnat că răspundem și solicitărilor inițiale de încărcare a paginii în acel același interval de timp.
Și apoi am trecut la următoarea problemă
Aproximativ o jumătate de lună după următoarea problemă, aparent cineva în cele din urmă a făcut ceva timp pentru a face unele teste de performanță cu privire la modificările pe care le făcuseră în restul codului din cache.
Trebuie să vedem o panică crescândă în jurul biroului pentru o câteva zile și am întrebat de mai multe ori care este problema și mi s-a spus să nu ne facem griji și să continuăm să lucrăm la ceea ce lucram.
Am făcut-o, pentru că reparam mașina cu stări finite să fie o mașină de stări finite reale și să restructureze codul cache în acel moment. De fapt, este unul dintre lucrurile care au determinat compania următoarea rundă de finanțare.
În cele din urmă, momentele lor ne-au chemat pentru a vedea dacă le putem rezolva problema.
Obțineau aproximativ 6.300 de conexiuni pe secundă.
Pierduseră aproximativ un factor de 6X în performanță și nu puteau afla unde.
Ne-au luat câteva ore și, în cele din urmă, l-am urmărit până la o comisie „face optimizare pentru mai multe mașini CPU”.
Am anulat-o și ne-am întors la aproximativ 35.000 de conexiuni pe secundă, am reglat un câteva căi de coduri fierbinți, iar până la sfârșitul zilei am revenit la vechile numere.
Pentru a înțelege „optimizarea” pe care „ programator hot shot ”a crezut că face, trebuie să înțelegeți că threading-ul nu era prea mult la momentul respectiv.
Chiar dacă ar fi fost, încă lucram prin mașina de stat , care trebuia făcut înainte ca statul global să poată fi mutat într-un singur obiect „statit” pentru a-l face pe fir și pentru a împiedica instanțele să se interfereze unul cu celălalt.
Deci, modelul de scalare era să au mai multe motoare „de lucru” ca p roci, și apoi un proces de „gatekeeper” care ar lăsa un proces să funcționeze la o cerere pe măsură ce a intrat. A văzut toate cererile și apoi „a lăsat procesul să meargă”; dacă ar exista mai multe solicitări, kqueue-ul din gatekeeper ar „lăsa un alt proces să plece” și așa mai departe.
„Hot shot-ul” nostru a observat că un proces efectuează aproape toate cererile, în timp ce alte procese erau (în mare parte) inactive.
Acest lucru se datorează faptului că am folosit intenționat un LIFO în loc de un FIFO pentru procesele care așteaptă „munca de făcut”.
”O schimbând într-un FIFO.
Și performanța s-a dus în iad.
Motivul pentru care am folosit un LIFO în primul loc, chiar dacă știam că nu va împărți neapărat sarcina între nuclee, a fost pentru că știam unele lucruri pe care „hot shot” nu le știa.
Știam că:
- Ca un dispozitiv de rețea, aproape întotdeauna aveam să fim I / O, mai degrabă decât CPU, cu excepția cazului în care încărcam într-un modul pentru a face ceva precum eliminarea spațiului alb sau rescrierea conținutului în scopuri publicitare
- Mai exact, știam că ultimul proces pentru a intra în linie a fost începutul g să aibă toate paginile sale în nucleu, în timp ce cea care stătuse cel mai mult timp inactiv nu ar avea probabil toate paginile sale în nucleu. toate procesele de spațiu ale utilizatorilor au fost mapate la același interval de adrese, rezultând flush-uri
- Ceea ce însemna că ar trebui să existe reîncărcări de cache, ceea ce înseamnă minim ieșirea la cel puțin L1, și probabil L2 cache
- Combinat, acest lucru ar avea ca rezultat blocuri suplimentare de conducte de instrucțiuni, deoarece nu exista cache L3 în arhitectura P4
- Și așa am schimbat intenționat ceea ce știam că va fi probabil cicluri de procesare inactivă în plus nuclee pentru ceea ce știam că vor avea cea mai bună performanță legată de I / O
Așa că am ales în mod intenționat o comandă LIFO și am verificat o îmbunătățire a performanței, folosind o tehnică pe care am folosit-o prima dată în 1994 sau așa numit (de mine, de când inventasem tehnica) „programarea motorului fierbinte”.
Deci, acest „hot shot” a distrus pe rformanța din cauza modificării.
Și după presupusa „optimizare”, nu a reușit să execute un test de performanță pentru a verifica dacă a fost de fapt o optimizare.
Singurul lucru S-a verificat că, sub sarcină, toate procesele au marcat aproximativ aceeași utilizare totală a procesorului, de-a lungul timpului, ceea ce a însemnat, totuși, că va avea o utilizare mai bună a mai multor nuclee.
Cei mai răi ingineri software sunt cei care sunt suficient de buni pentru a fi periculoși, dar nu suficient de buni pentru a recunoaște când iau o decizie proastă.
Acestea sunt înrăutățite și mai mult prin faptul că nu verifică faptul că decizia a fost de fapt una proastă prin măsurarea rezultatelor modificărilor lor folosind un conducător imparțial.