Wat zijn enkele goede grappen over software engineering?

Beste antwoord

V: Waarom verwarren programmeurs altijd Halloween en Kerstmis?

A: Omdat 31 oktober == 25 december!

Twee bytes ontmoeten elkaar. De eerste byte vraagt: “Ben je ziek?”. De tweede byte antwoordt: “Nee, ik voel me gewoon een beetje gek”.

V: hoeveel programmeurs zijn er nodig om een ​​gloeilamp te vervangen?

A: geen, dat is sa hardwareprobleem

V: hoeveel Microsoft-programmeurs zijn er nodig om een ​​gloeilamp te vervangen?

A: geen, ze maken gewoon van duisternis een standaard en vertellen iedereen “dit gedrag is inherent “

Een student informatica studeert onder een boom en een ander stopt op een flitsende nieuwe fiets. De eerste student vraagt:” Waar heb je dat vandaan? “. De student op de fiets antwoordt:” Terwijl ik buiten studeerde, stopte een mooi meisje op haar fiets. Ze trok al haar kleren uit en zei: Je mag alles hebben wat je wilt. ” De eerste student antwoordt: “Goede keuze! Haar kleren zouden je waarschijnlijk niet hebben gepast.”

Een natuurkundige, een ingenieur en een programmeur zaten in een auto die over een steile bergpas reden toen de remmen faalden. De auto werd steeds sneller, ze hadden moeite om de bochten te omzeilen en een of twee keer redde alleen de zwakke vangrail hen van een botsing langs de kant van de berg. Ze waren er zeker van dat ze allemaal zouden sterven, toen ze plotseling zagen een vluchtstrook. Ze reden de vluchtstrook op en kwamen veilig tot stilstand. De natuurkundige zei: “We moeten de wrijving in de remblokken en de resulterende temperatuurstijging modelleren, kijken of we kunnen achterhalen waarom ze faalden”. ingenieur zei: “Ik denk dat ik” een paar steeksleutels achterin heb. Ik zal eens kijken of ik kan uitzoeken wat er mis is “. De programmeur zei “Waarom gaan we niet weer aan de slag om te zien of het reproduceerbaar is?”

V: “Wat is de objectgeoriënteerde manier om rijk te worden?”

A : Inheritance

Een programmeur voor zijn vrienden (ook programmeurs): “Ik ontmoette gisteravond een hete meid. Ik bracht haar naar huis en we begonnen woedend te kussen. Ik zette haar op het toetsenbord en …”. Alle vrienden zeiden tegelijk: “Heb je thuis een computer? Wat is het RAM-geheugen ervan?

Een SQL-query gaat in een balk, loopt naar twee tafels en vraagt: “Mag ik met je meedoen?”

Wanneer je hamer is C ++, alles begint op een duim te lijken.

V: Hoeveel proloogprogrammeurs zijn er nodig om een ​​gloeilamp te vervangen?

A: Ja.

A programmeur zet twee glazen op zijn nachtkastje voordat hij gaat slapen. Een volle, voor het geval hij dorst krijgt, en een lege, voor het geval hij dat niet doet.

Een man staat op de hoek van de straat de ene sigaret na de andere te roken. Een dame loopt langs mededelingen hem en zegt “Hé, weet je niet dat die dingen je kunnen doden? Ik bedoel, zag je de gigantische waarschuwing niet op de doos ?!” “Dat is oké” zegt de man, nonchalant puffend “Ik” ma computerprogrammeur “.” Dus? Wat heeft dat met iets te maken? vroeg de dame. Hij antwoordde: “We geven niets om waarschuwingen. Wij geven alleen om fouten. “

Er zijn 10 soorten mensen in de wereld. Degenen die binair begrijpen en degenen die regelmatig seks hebben.

Dus deze programmeur gaat uit op een date met een hete meid

Antwoord

Ze zijn erg slecht.

Ze zijn de soort mensen die een fijn afgesteld systeem met een “voor de hand liggende” oplossing gaan aanpassen en alles vreselijk verpesten, met de absoluut beste bedoelingen.

Om je een idee te geven, nog een uitstekende ingenieur die ik ken , Jeffrey Hsu, werkte bij ClickArray (nu bekend als Array Networks), en kreeg me daar ingehuurd omdat hij een ander type groot geweer nodig had om echt prestatie-kritisch werk gedaan te krijgen.

En we kregen het is klaar.

Op 1,3 GHz Pentium 4-systemen (het was 2001).

We hebben een reverse proxy-cache tot iets meer dan 38.700 TCP-verbindingen per seconde – wat niet indrukwekkend is , totdat je je realiseert dat er slechts 16.384 bruikbare poorten zijn voor INADDR\_ANY, tenzij je substantieel wijzigt fy de TCP / IP-stack, als het een BSD- of Linux-gebaseerd systeem is.

We hadden de stack niet gewijzigd – het was een BSD-stack – dus het betekende dat we ook reageerden op initiële verzoeken om paginas te laden in dat hetzelfde tijdsbestek.

En toen waren we op weg naar het volgende probleem

Ongeveer een halve maand in het volgende probleem, blijkbaar iemand eindelijk wat tijd vrijgemaakt om wat prestatietests uit te voeren op de wijzigingen die ze hadden aangebracht in de rest van de code in de cache.

We kregen te maken met toenemende paniek op kantoor gedurende een een paar dagen, en verschillende keren gevraagd wat het probleem was, en kreeg te horen dat we ons er geen zorgen over moesten maken en blijven werken aan waar we aan werkten.

Dat deden we, omdat we de eindige-toestandsmachine aan het repareren waren om een ​​werkelijke eindige-toestandsmachine te zijn, en de cachecode op dat moment te herstructureren. Het is een van de dingen die het bedrijf in feite de volgende financieringsronde hebben bezorgd.

Ten slotte hebben hun hotshots ons gebeld om te kijken of we hun probleem konden oplossen.

Ze haalden ongeveer 6.300 verbindingen per seconde.

Ze hadden ongeveer een factor 6x aan prestatie verloren en ze konden niet achterhalen waar.

Het kostte ons een paar uur, en we hebben het uiteindelijk opgespoord tot een make optimization for multiple CPU machines-commit.

We hebben het ongedaan gemaakt en we waren terug bij ongeveer 35.000 verbindingen per seconde, opnieuw afgesteld een paar hotcodepaden, en tegen het einde van de dag waren we weer terug bij de oude nummers.

Om de “optimalisatie” te begrijpen die de ” hot shot programmeur ”dacht dat hij aan het maken was, je moet begrijpen dat threading destijds niet echt een ding was.

Zelfs als het zo was, werkten we nog steeds via de state-machine , wat moest worden gedaan voordat de globale status mogelijk naar een enkel “statite” -object kon worden verplaatst om het per thread te maken, en om te voorkomen dat instanties met elkaar interfereerden.

Dus het schaalmodel was om heb meerdere “werk te doen” engines zoals p rocesses, en vervolgens een “poortwachter” -proces dat een proces aan het werk zou laten gaan op een verzoek zoals het binnenkwam. Het zag alle verzoeken en vervolgens “liet het proces gaan”; als er meer verzoeken waren, zou de wachtrij in de poortwachter “een ander proces laten gaan”, enzovoort.

Onze “hot shot” had gemerkt dat één proces bijna al het verzoek deed, terwijl de andere processen waren (meestal) inactief.

Dit komt omdat ik opzettelijk een LIFO had gebruikt in plaats van een FIFO voor de processen die wachtten op “werk om te doen”.

Dus hij “repareerde ”Door het te veranderen in een FIFO.

En de uitvoering ging naar een hel.

De reden dat ik een LIFO had gebruikt in de eerste plaats, hoewel ik wist dat het niet noodzakelijkerwijs de belasting tussen de kernen zou verdelen, was omdat ik sommige dingen wist die de hot shot niet wist.

Ik wist dat:

  • Als netwerktoepassing waren we bijna altijd I / O, in plaats van CPU, gebonden, tenzij we een module laadden om iets te doen als het verwijderen van witruimte of het herschrijven van inhoud voor reclamedoeleinden
  • Sterker nog, ik wist dat het laatste proces om in de rij te komen aan de gang was g om al zijn paginas in de kern te hebben, terwijl degene die het langst inactief was geweest waarschijnlijk niet alle paginas in de kern zou hebben
  • Verder wist ik dat er TLB-cache-botsingen zouden zijn, aangezien alle gebruikersruimteprocessen werden in hetzelfde adresbereik in kaart gebracht, wat resulteerde in flushes
  • Wat betekende dat er cache-herlaadbeurten moesten zijn, wat minimaal betekende dat we naar ten minste L1, en waarschijnlijk L2-cache moesten gaan
  • Gecombineerd zou dit resulteren in extra instructiepijplijnblokkades, omdat er geen L3-cache op de P4-architectuur was
  • En dus ruilde ik opzettelijk wat ik wist dat waarschijnlijk inactieve CPU-cycli zouden zijn op de extra kernen waarvan ik wist dat ze de beste I / O-gebonden prestaties zouden hebben

Dus ik had opzettelijk een LIFO-order gekozen en een prestatieverbetering geverifieerd, met behulp van een techniek die ik voor het eerst had gebruikt in 1994 of zo genoemd (door mij, aangezien ik de techniek had uitgevonden) “hot engine scheduling”.

Dus deze “hot shot” had de pe prestatie vanwege de wijziging.

En daarna, na de vermeende “optimalisatie”, slaagde hij er niet in een prestatietest uit te voeren om te verifiëren dat het in feite een optimalisatie was.

Het enige dat hij d gecontroleerd was dat, onder belasting, de processen in de loop van de tijd allemaal ongeveer hetzelfde CPU-gebruik totaal opleverden, wat hij echter bedoelde dat hij een beter gebruik van meerdere kernen zou krijgen.

De absoluut slechtste software-ingenieurs zijn degenen die goed genoeg zijn om gevaarlijk te zijn, maar niet goed genoeg om te herkennen wanneer ze een slechte beslissing nemen.

Ze worden nog erger door niet achteraf te verifiëren dat de beslissing in feite een slechte was door de resultaten van hun veranderingen te meten met een onpartijdige liniaal.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *