Bedste svar
Q: Hvorfor blander programmører altid Halloween og jul?
A: Fordi 31. oktober == 25. december!
To bytes mødes. Den første byte spørger: “Er du syg?”. Den anden byte svarer: ”Nej, bare føler dig lidt slukket.”
Q: hvor mange programmører tager det for at skifte en pære?
A: ingen, at “sa hardwareproblem
Sp .: hvor mange Microsoft-programmører skal der til for at skifte en pære?
A: ingen, de gør bare mørke til en standard og fortæller alle “denne adfærd er efter design “
En studerende i datalogi studerer under et træ, og en anden trækker op på en prangende ny cykel. Den første studerende spørger:” Hvor fik du det? “. Den studerende på cyklen svarer,” Mens jeg studerede udenfor, trak en smuk pige op på sin cykel. Hun tog alt sit tøj af og sagde: Du kan få hvad du vil. ” Den første elev svarer: “Godt valg! Hendes tøj ville sandsynligvis ikke have passet dig.”
En fysiker, en ingeniør og en programmør sad i en bil, der kørte over en stejl alpepass, da bremserne svigtede. Bilen blev hurtigere og hurtigere, de kæmpede for at komme rundt om hjørnerne og en eller to gange reddede kun den svage crashbarriere dem fra at styrte ned ad siden af bjerget. De var sikre på, at de alle skulle dø, da de pludselig så dem en flugtbane. De trak sig ind i flugtbanen og stoppede sikkert. Fysikeren sagde “Vi er nødt til at modellere friktionen i bremseklodser og den deraf følgende temperaturstigning, se om vi kan finde ud af, hvorfor de mislykkedes”. ingeniør sagde “Jeg tror, jeg har fået et par skruenøgler i ryggen. Jeg vil se og se, om jeg kan finde ud af, hvad der er galt”. Programmøren sagde “Hvorfor går vi ikke i gang igen og ser, om det er reproducerbart?”
Q: “Hvad er den objektorienterede måde at blive rig på?”
A : Arv
En programmør til sine venner (også programmører): “Jeg mødte en varm pige i går aftes. Jeg bragte hende hjem, og vi begyndte at kysse rasende. Jeg satte hende på tastaturet og …”. Alle venner i fællesskab sagde “Har du en computer derhjemme? Hvad er RAMet for det? “
En SQL-forespørgsel går ind i en bjælke, går op til to tabeller og spørger:” Kan jeg slutte mig til dig? “
Når din hammer er C ++, alt begynder at ligne en tommelfinger.
Q: Hvor mange prolog-programmører skal der til for at skifte en pære?
A: Ja.
A programmør sætter to briller på sengebordet, inden han går i seng. En fuld, hvis han bliver tørstig, og en tom, hvis han ikke gør det.
En fyr står på hjørnet af gaden og ryger den ene cigaret efter den anden. En dame, der går forbi, bemærker ham og siger “Hej, ved du ikke, at disse ting kan dræbe dig? Jeg mener, så du ikke den kæmpe advarsel på kassen ?!” “Det er OK” siger fyren og puffer afslappet “jeg” en computerprogrammerer “.” Så? Hvad har det med noget at gøre? spurgte damen. Han svarede “Vi bryr os ikke om advarsler. Vi er kun interesserede i fejl. “
Der er ti typer mennesker i verden. De, der forstår binære og dem, der har regelmæssigt sex.
Så denne programmør går ud på en date med en varm kylling
Svar
De er meget dårlige.
De er de slags folk, der vil gå ind og ændre et finjusteret system med en “indlysende” løsning og skrue alt forfærdeligt op med de absolut bedste intentioner.
For at give dig en idé, en anden fremragende ingeniør, jeg kender , Jeffrey Hsu, arbejdede hos ClickArray (nu kendt som Array Networks) og fik mig ansat derinde, fordi han havde brug for en anden “stor pistol” -type for at få udført noget virkelig ydeevnekritisk arbejde.
Og vi fik det blev gjort.
På 1,3 GHz Pentium 4-systemer (det var 2001).
Vi fik en omvendt proxy-cache op til noget over 38.700 TCP-forbindelser i sekundet – hvilket ikke er imponerende , indtil du er klar over, at der kun er 16.384 anvendelige porte til INADDR\_ANY, medmindre du i det væsentlige ændrer fy TCP / IP-stakken, hvis det er et BSD- eller Linux-baseret system.
Vi havde ikke ændret stakken – det var en BSD-stak – så det betød, at vi også reagerede på indledende sideindlæsningsanmodninger i det samme tidsramme.
Og så fortsatte vi med det næste problem
Omkring en halv måned ind i det næste problem, tilsyneladende nogen havde endelig gjort noget tid til at udføre nogle præstationstest på de ændringer, de havde foretaget i resten af koden i cachen.
Vi fik se en stigende panik omkring kontoret for en par dage og spurgte flere gange, hvad problemet var, og fik at vide, at vi ikke skulle bekymre os om det, og fortsætte med at arbejde med, hvad vi arbejdede med.
Det gjorde vi, fordi vi fik ordnet den endelige statsmaskine at være en egentlig finite state-maskine og omstrukturere cache-koden på det tidspunkt. Det er faktisk en af de ting, der fik virksomheden til deres næste finansieringsrunde.
Endelig ringede deres hotshots os ind for at se, om vi kunne løse deres problem.
De fik omkring 6.300 forbindelser pr. sekund.
De havde mistet en faktor 6X i ydeevne, og de kunne ikke finde ud af, hvor.
Det tog os et par timer, og vi spurgte det endelig til en “make optimization for multiple CPU machines” -forpligtelse.
Vi fortryder det, og vi var tilbage til ca. 35.000 forbindelser pr. Sekund, genindstillet en par hot code-stier, og ved slutningen af dagen var vi tilbage op til de gamle numre.
At forstå “optimeringen”, som “ hot shot programmer ”troede, han lavede, skal du forstå, at trådning ikke rigtig var meget af en ting på det tidspunkt.
Selv hvis det havde været, arbejdede vi stadig igennem statsmaskinen. , som skulle gøres, før den globale stat muligvis kunne have været flyttet til et enkelt “statitisk” objekt for at gøre det pr. tråd og forhindre forekomster i at blande sig.
Så skaleringsmodellen skulle har flere “arbejde at gøre” -motorer som s rocesses, og derefter en “gatekeeper” -proces, der lader en proces gå i gang med en anmodning, da den kom ind. Den så alle anmodninger og derefter “lad processen gå”; hvis der var flere anmodninger, ville kqueue i portvagten “lade en anden proces gå” og så videre.
Vores “hot shot” havde bemærket, at en proces udførte næsten hele anmodningen, mens andre processer var (for det meste) inaktive.
Dette skyldes, at jeg med vilje havde brugt en LIFO i stedet for en FIFO til de processer, der ventede på “arbejde at gøre”.
Så han “fikset ”Det ved at ændre det til en FIFO.
Og forestillingen gik til helvede.
Årsagen til, at jeg havde brugt en LIFO i det første sted, selvom jeg vidste, at det ikke nødvendigvis ville dele belastningen ud mellem kernerne, var fordi jeg vidste nogle ting, som “hot shot” ikke vidste.
Jeg vidste, at:
- Som et netværksapparat skulle vi næsten altid være I / O snarere end CPU, bortset fra at vi indlæste i et modul for at gøre noget som fjernelse af mellemrum eller omskrivning af indhold til reklameformål
- Mere til det punkt vidste jeg, at den sidste proces for at komme i kø var at gå g at have alle sine sider i kernen, mens den der havde siddet inaktiv længst sandsynligvis ikke ville have alle sine sider i kernen
- Desuden er jeg ny på, at der ville være TLB-cache-kollisioner, da alle brugernes pladsprocesser blev kortlagt i det samme adresseområde, hvilket resulterede i skylninger
- Hvilket betød, at der skulle være cache-genindlæsninger, hvilket minimalt betød at gå ud til mindst L1 og sandsynligvis L2-cache
- Kombineret ville dette resultere i yderligere instruktionsrørledningsbod, fordi der ikke var nogen L3-cache på P4-arkitekturen
- Og så handlede jeg med vilje det, jeg vidste, sandsynligvis ville være inaktive CPU-cyklusser på den ekstra kerner for hvad jeg vidste ville have den bedste I / O-bundne ydeevne
Så jeg havde med vilje valgt en LIFO-ordre og verificeret en præstationsforbedring ved hjælp af en teknik, jeg først havde brugt i 1994 eller såkaldt (af mig, da jeg havde opfundet teknikken) “hot engine scheduling”.
Så dette “hot shot” havde ødelagt pe rformance på grund af ændringen.
Og derefter efter den påståede “optimering” kunne ikke køre en præstationstest for at bekræfte, at det faktisk var en optimering.
Det eneste han d kontrolleret var, at processerne under belastning alle markerede det samme CPU-forbrug i alt over tid, hvilket han dog mente, at han ville få en bedre multicore-udnyttelse.
De absolut værste softwareingeniører er dem, der er gode nok til at være farlige, men ikke gode nok til at genkende, når de tager en dårlig beslutning.
De gøres endnu værre ved ikke at efterprøve, at beslutningen faktisk var dårlig ved at måle resultaterne af deres ændringer ved hjælp af en upartisk hersker.