Beste svaret
Spørsmål: Hvorfor blander programmerere alltid Halloween og jul?
A: Fordi 31. oktober == 25. des!
To byte møtes. Den første byten spør: «Er du syk?». Den andre byten svarer: «Nei, bare føler meg litt av.»
Spørsmål: hvor mange programmerere tar det å bytte lyspære?
A: ingen, det «sa maskinvareproblem
Spørsmål: Hvor mange Microsoft-programmerere skal til for å bytte lyspære?
A: ingen, de gjør bare mørke til en standard og forteller alle «denne oppførselen er etter design «
En informatikkstudent studerer under et tre, og en annen trekker opp på en prangende ny sykkel. Den første studenten spør:» Hvor fikk du det? «. Studenten på sykkelen svarer:» Mens jeg studerte ute, dro en vakker jente opp på sykkelen. Hun tok av seg alle klærne og sa: Du kan ha hva du vil. » Den første studenten svarer: «Bra valg! Klærne hennes ville sannsynligvis ikke passet deg.»
En fysiker, en ingeniør og en programmerer satt i en bil som kjørte over en bratt alpinpass da bremsene sviktet. Bilen ble raskere og raskere, de slet med å komme rundt hjørnene, og en eller to ganger reddet bare den svake krasjbarrieren dem fra å krasje ned langs fjellsiden. De var sikre på at de alle skulle dø, da de plutselig oppdaget en rømningsbane. De trakk seg inn i rømningsfilen og stoppet trygt. Fysikeren sa «Vi må modellere friksjonen i bremseklossene og den resulterende temperaturstigningen, se om vi kan finne ut hvorfor de mislyktes». ingeniøren sa «Jeg tror jeg har noen skiftenøkler i ryggen. Jeg vil ta en titt og se om jeg kan finne ut hva som er galt». Programmereren sa «Hvorfor kommer vi ikke i gang igjen og ser om det er reproduserbart?»
Spørsmål: «Hva er den objektorienterte måten å bli velstående på?»
A : Arv
En programmerer til vennene sine (også programmerere): «Jeg møtte en varm jente i går kveld. Jeg tok henne med hjem og vi begynte å kysse rasende. Jeg satte henne på tastaturet og …». Alle vennene sammen sa «Har du en datamaskin hjemme? Hva er RAM for det?
Et SQL-spørsmål går inn i en stolpe, går opp til to bord og spør: «Kan jeg bli med deg?»
Når hammeren din er C ++, alt begynner å se ut som en tommel.
Spørsmål: Hvor mange prolog-programmerere skal til for å bytte lyspære?
A: Ja.
A programmerer setter to briller på nattbordet sitt før han legger seg. En full, i tilfelle han blir tørst, og en tom, i tilfelle han ikke gjør det.
En fyr står på hjørnet av gaten og røyker den ene sigaretten etter den andre. En dame som går forbi, legger merke til ham og sier «Hei, vet du ikke at disse tingene kan drepe deg? Jeg mener, så du ikke den gigantiske advarselen på esken ?!» «Det er OK» sier fyren og puffer tilfeldig «jeg» en dataprogrammerer «.» Så? Hva har med noe å gjøre? » spurte damen. Han svarte «Vi bryr oss ikke om advarsler. Vi bryr oss bare om feil. «
Det er ti typer mennesker i verden. De som forstår binære og de som har vanlig sex.
Så denne programmereren går ut på en date med en hot chick
Svar
De er veldig dårlige.
De er slags folk som vil gå inn og modifisere et finjustert system med en «åpenbar» løsning, og skru opp alt forferdelig, med de absolutt beste intensjonene.
For å gi deg en ide, en annen utmerket ingeniør jeg kjenner , Jeffrey Hsu, jobbet i ClickArray (nå kjent som Array Networks), og fikk meg ansatt der inne fordi han trengte en annen “stor pistol” -type for å få gjort virkelig ytelseskritisk arbeid.
Og vi fikk det ble gjort.
På 1,3 GHz Pentium 4-systemer (det var 2001).
Vi fikk en omvendt proxy-cache opp til noe over 38.700 TCP-tilkoblinger i sekundet – noe som ikke er imponerende , til du innser at det bare er 16384 brukbare porter for INADDR\_ANY, med mindre du endrer vesentlig for TCP / IP-stakken, hvis det er et BSD- eller Linux-basert system.
Vi hadde ikke endret stakken – det var en BSD-stabel – så det betydde at vi også svarte på innledende sideinnlastingsforespørsler i den samme tidsramme.
Og så gikk vi videre til neste problem
Omtrent en halv måned inn i neste problem, tilsynelatende noen hadde endelig fått litt tid til å gjøre noen ytelsestester på endringene de hadde gjort i resten av koden i hurtigbufferen.
Vi fikk se litt økende panikk rundt kontoret for en noen dager, og spurte flere ganger hva problemet var, og fikk beskjed om ikke å bekymre oss for det, og fortsette å jobbe med det vi jobbet med.
Vi gjorde det fordi vi fikset den endelige statsmaskinen. å være en faktisk endelig maskin, og omstrukturere hurtigbufferkoden på den tiden. Det er faktisk en av tingene som fikk selskapet sin neste finansieringsrunde.
Til slutt ringte hotshots deres inn for å se om vi kunne løse problemet deres.
De fikk rundt 6300 tilkoblinger per sekund.
De hadde mistet omtrent en faktor 6X i ytelse, og de kunne ikke finne ut hvor.
Det tok oss et par timer, og vi sporet det endelig opp til en «make optimalization for multiple CPU machines» -forpliktelse.
Vi angret det, og vi var tilbake til omtrent 35 000 tilkoblinger per sekund, justerte en par hot code-baner, og på slutten av dagen var vi tilbake til de gamle tallene.
For å forstå “optimaliseringen” som “ hot shot programmer ”trodde han laget, må du forstå at tråding ikke egentlig var noe av den gangen.
Selv om det hadde vært, jobbet vi fremdeles gjennom statsmaskinen. , som måtte gjøres før den globale staten muligens kunne ha blitt flyttet til et enkelt «statitt» -objekt for å gjøre det per tråd, og forhindre forekomster fra å forstyrre hverandre.
Så skaleringsmodellen var å har flere “arbeid å gjøre” -motorer som s rocesses, og deretter en «gatekeeper» prosess som ville la en prosess gå til å fungere på en forespørsel etter hvert som den kom inn. Den så alle forespørsler, og deretter «la prosessen gå»; hvis det var flere forespørsler, ville kqueue i portvakten «la en annen prosess gå», og så videre.
Vårt «hot shot» hadde lagt merke til at en prosess utførte nesten all forespørsel som serveres, mens andre prosesser var (for det meste) inaktive.
Dette er fordi jeg med vilje hadde brukt en LIFO i stedet for en FIFO for prosessene som ventet på «arbeid å gjøre».
Så han «fikset ”Det ved å endre det til en FIFO.
Og forestillingen gikk til helvete.
Grunnen til at jeg hadde brukt en LIFO i det første stedet, selv om jeg visste at det ikke nødvendigvis ville dele belastningen mellom kjernene, var fordi jeg visste noen ting «hot shot» ikke visste.
Jeg visste at:
- Som et nettverksapparat skulle vi nesten alltid være I / O, i stedet for CPU, bundet med mindre vi lastet inn i en modul for å gjøre noe som fjerning av mellomrom eller omskriving av innhold for reklameformål
- Mer til poenget, jeg visste at den siste prosessen for å komme i kø var å gå g å ha alle sidene i kjernen, mens den som hadde sittet inaktiv lengst sannsynligvis ikke ville ha alle sidene i kjernen
- Videre er jeg ny på at det ville være TLB-hurtigbufferkollisjoner, siden alle brukerens plassprosesser ble kartlagt i samme adresseområde, noe som resulterte i spylinger
- Hvilket betydde at det måtte være hurtigbufferoppdateringer, noe som minimalt betydde å gå ut til minst L1, og sannsynligvis L2-hurtigbuffer
- Kombinert vil dette resultere i ytterligere instruksjonsrørledningsboder, fordi det ikke var L3-hurtigbuffer på P4-arkitekturen. kjerner for det jeg visste ville ha best I / O-bundet ytelse
Så jeg hadde med vilje valgt en LIFO-ordre og verifisert en ytelsesforbedring ved hjelp av en teknikk jeg først brukte i 1994 eller såkalt (av meg, siden jeg hadde oppfunnet teknikken) «hot engine scheduling».
Så dette «hot shot» hadde ødelagt pe ytelse på grunn av endringen.
Og etter den påståtte «optimaliseringen» klarte ikke å kjøre en ytelsestest for å bekrefte at det faktisk var en optimalisering.
Det eneste han d sjekket var at prosessene under belastning alle markerte omtrent samme CPU-bruk totalt over tid, og det er det han skjønt mente at han skulle få bedre flerkjernebruk.
De absolutt verste programvareingeniørene er de som er gode nok til å være farlige, men ikke gode nok til å gjenkjenne når de tar en dårlig beslutning.
De blir enda verre ved ikke å bekrefte at beslutningen faktisk var dårlig ved å måle resultatene av endringene deres ved hjelp av en upartisk hersker.