Milyen jó poénok vannak a szoftvertervezéssel kapcsolatban?

A legjobb válasz

K: Miért keverik a programozók mindig a halloweenet és a karácsonyt?

V: Mert október 31. == december 25.!

Két bájt találkozik. Az első bájt megkérdezi: „Beteg vagy?”. A második bájt így válaszol: „Nem, csak kicsit érzem magam.”

K: Hány programozó kell egy villanykörte cseréjéhez?

V: nincs, ez “sa hardverprobléma

K: Hány Microsoft programozó kell egy villanykörte cseréjéhez?

V: nincs, csak a sötétséget teszik szabványossá és mindenkinek elmondják, hogy “ez a viselkedés tervezése szerint” “

Egy informatikus hallgató egy fa alatt tanul, egy másik pedig feltűnő, új biciklit húz fel. Az első hallgató azt kérdezi:” Ezt honnan szerezted? “. A kerékpáros hallgató így válaszol:” Amíg kint tanultam, egy gyönyörű lány húzta fel a biciklijét. Levette az összes ruháját és azt mondta: “Bármit megkaphatsz, amit csak akarsz.” Az első hallgató így válaszol: “Jó választás! Valószínűleg a ruhája nem illett volna hozzád.”

Egy fizikus, egy mérnök és egy programozó autóban ült egy meredek alpesi hágón, amikor a fékek nem működtek. Az autó egyre gyorsabb volt, küzdöttek a kanyarok megkerüléséért, és egyszer-kétszer csak a gyenge ütközésgátló mentette meg őket attól, hogy lezuhanjanak a hegy oldalán. Biztosak voltak benne, hogy mind meghalnak, amikor hirtelen észrevették menekülési sáv. Behajtottak a menekülési sávba, és biztonságosan leálltak. A fizikus azt mondta: “Meg kell modelleznünk a fékbetétek súrlódását és az ebből eredő hőmérséklet-emelkedést, hátha sikerül megoldani, hogy miért nem sikerült”. mérnök azt mondta: “Azt hiszem, hátul van néhány villáskulcs. Megnézem, hátha sikerül kideríteni, mi a baj. A programozó azt mondta: “Miért nem megyünk újra, és megnézzük, hogy reprodukálható-e?”

K: “Mi az az objektumorientált módszer, hogy meggazdagodjunk?”

A : Öröklés

Programozó barátainak (programozóknak is): “Tegnap este találkoztam egy dögös lánnyal. Hoztam haza, és hevesen csókolózni kezdtünk. Leültettem a billentyűzetre és …”. Minden barát egyhangúan azt mondta: “Van számítógépe otthon? Mi a RAM? “

Az SQL lekérdezés egy sávba megy, két táblához lép és megkérdezi:” Csatlakozhatok-e hozzád? “

Amikor a kalapácsod van C ++, minden hüvelykujjnak látszik.

K: Hány prolog programozó kell egy villanykörte cseréjéhez?

A: Igen.

A programozó két poharat tesz az éjjeliszekrényére, mielőtt lefekszik. Egy teljes, hátha megszomjazik, és egy üres, ha nem “t”

Egy srác az utca sarkán áll, és cigarettázik a másik után. Egy hölgy észreveszi és azt mondja: “Hé, nem tudod, hogy ezek a dolgok megölhetnek? Úgy értem, nem láttad az óriási figyelmeztetést a dobozon ?!” “Ez rendben van” – mondja a srác, és lazán pöfékel. ma számítógépes programozó “.” Szóval? Mi köze ennek bármihez? – kérdezte a hölgy. Azt válaszolta: “Nem érdekelnek a figyelmeztetések. Csak a hibák törődnek velünk. “

A világon 10 embertípus létezik. Akik értenek a binárisan, és akik rendszeresen szexelnek.

Tehát ez a programozó randevúra megy. dögös csajjal

Válasz

Nagyon rosszak.

Ők a olyan emberek, akik belemennek és finomra hangolt rendszert módosítanak egy „kézenfekvő” javítással, és mindent szörnyen elcsesznek, a legjobb szándékkal.

Hogy ötletet adjak neked, egy másik kiváló mérnök, akit ismerek , Jeffrey Hsu, a ClickArray-nél dolgozott (ma már Array Networks néven ismert), és felvett engem oda, mert szüksége volt egy másik „nagy fegyver” típusra, hogy valóban teljesítménykritikus munkát végezhessen.

És meg is kaptuk megtörtént.

1,3 GHz-es Pentium 4 rendszereken (2001 volt).

Fordított proxy gyorsítótárat kaptunk másodpercenként 38 700 TCP-kapcsolaton át – ami nem lenyűgöző , amíg rájön, hogy az INADDR\_ANY számára csak 16 384 használható port van, hacsak nem módosítja lényegesen vegye fel a TCP / IP-veremet, ha BSD vagy Linux alapú rendszerről van szó.

Nem módosítottuk a verem – ez egy BSD-verem volt -, tehát azt jelentette, hogy a kezdeti oldalbetöltési kérelmekre is válaszoltunk ugyanabban az időkeretben.

És akkor folytattuk a következő problémát. végül egy kis időt szánt arra, hogy elvégezzen néhány teljesítménytesztet a gyorsítótárban lévő többi kód módosításaival kapcsolatban.

Egyre növekvő pánikot láttunk az irodában egy pár napig, és többször megkérdeztem, mi a probléma, és megkapták, hogy ne aggódjon miatta, és folytassa a munkát, amin dolgoztunk.

Megtettük, mert javítottuk a véges állapotú gépet hogy tényleges véges állapotú gép legyen, és az akkori gyorsítótár-kódot átszervezze. Ez az egyik dolog, ami miatt a vállalat megkapta a következő finanszírozási kört.

Végül forró felvételeik felhívtak minket, hogy meg tudjuk-e oldani a problémájukat.

Körülbelül 6300 kapcsolatot kaptak másodpercenként.

Körülbelül 6-szoros veszteséget szenvedtek el a teljesítményükben, és nem tudták kideríteni, hogy hol.

Pár órába telt, és végül egy „több CPU-gép optimalizálása érdekében” elkövetett feladatra bukkantunk.

Visszavontuk, és másodpercenként kb. 35 000 kapcsolatra álltunk vissza, hangoltunk egy néhány forró kód elérési út, és a nap végére visszatértünk a régi számokhoz.

Az „optimalizálás” megértéséhez, hogy a „ forró lövés programozó ”- gondolta, hogy készít – meg kell értenie, hogy a menetfűzés akkoriban valójában nem sok dolog.

Még ha volt is, akkor is az állami gépen dolgoztunk , amelyet el kellett végezni, mielőtt a globális állapotot egyetlen „statit” objektumba lehetett volna áthelyezni, hogy az szálanként legyen, és hogy a példányok ne zavarjanak egymást.

Tehát a méretezési modell több „elvégzendő” motorja van, mint p folyamatokat, majd egy „kapuőr” folyamatot, amely lehetővé tette egy folyamat működését egy kérésnél, amikor bejött. Meglátta az összes kérést, majd „elengedte a folyamatot”; ha több kérés érkezne, akkor a kapus őrzője „elengedne egy másik folyamatot”, és így tovább.

„Forró felvételünk” észrevette, hogy az egyik folyamat szinte az összes kérést kiszolgálja, míg a más folyamatok (többnyire) tétlenek voltak.

Ez azért van, mert szándékosan LIFO-t használtam FIFO helyett a „munka elvégzésére” váró folyamatokhoz.

Tehát „kijavította FIFO-ra változtatásával.

És az előadás a pokolba került.

Az ok, amiért LIFO-t használtam Az első hely, bár tudtam, hogy nem feltétlenül osztja meg a terhelést a magok között, az azért volt, mert tudtam néhány dolgot, amelyet a „forró lövés” nem tudott.

Tudtam, hogy:

  • Hálózati eszközként szinte mindig I / O-k leszünk, nem pedig processzorok, hacsak nem töltünk be egy modulba valami olyasmit, mint a szóköz eltávolítása vagy a tartalom átírása hirdetési célokra
  • Pontosabban szólva tudtam, hogy a sorba kerülés utoljára folyamatban van g, hogy az összes oldala legyen a magban, míg annak, amelyik a legtovább tétlenül ült, valószínűleg nem az összes oldala lenne a magban
  • Továbbá újnak mondom, hogy a TLB gyorsítótár ütközései lesznek, mivel az összes felhasználói térfolyamat azonos címtartományban került feltérképezésre, ami flush-okat eredményezett
  • Ami azt jelentette, hogy cache-eket kell újratölteni, ami minimálisan azt jelentette, hogy legalább L1, és valószínűleg L2 cache-re mentünk ki
  • Ez együttesen további utasítás-leállásokat eredményez, mert a P4 architektúrán nem volt L3 gyorsítótár.
  • Ezért szándékosan kereskedtem azzal, amiről tudtam, hogy valószínűleg tétlen CPU-ciklusok lesznek a további magok, amelyekről tudtam, hogy a legjobb I / O kötött teljesítményt nyújtanák

Tehát szándékosan választottam egy LIFO-sorrendet, és egy teljesítményjavulást ellenőriztem egy olyan technikával, amelyet először 1994-ben használtam vagy úgynevezett (általam, mivel én találtam ki a technikát) „forró motor ütemezése”.

Tehát ez a „forró lövés” elpusztította a pe teljesítmény a változás miatt.

És az állítólagos „optimalizálás” után nem sikerült futtatnia egy teljesítménytesztet annak igazolására, hogy valójában optimalizálásról van szó.

Az egyetlen dolog, amit ő d azt ellenőrizték, hogy terhelés alatt a folyamatok körülbelül ugyanolyan CPU-felhasználást jelentettek-e az idő múlásával, bár ő arra gondolt, hogy jobb többmagos kiaknázást fog elérni.

A legrosszabb szoftvermérnökök azok, akik elég jóak ahhoz, hogy veszélyesek legyenek, de nem elég jók ahhoz, hogy felismerjék, amikor rossz döntést hoznak.

Még rosszabbá teszi őket, ha nem ellenőrizték azt a tényt, hogy a döntés valójában rossz volt, oly módon, hogy valamilyen pártatlan uralkodóval mértük meg változásaik eredményeit.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük