Nejlepší odpověď
Otázka: Proč programátoři vždy míchají Halloween a Vánoce?
A: Protože 31. října == 25. prosince!
Setkávají se dva bajty. První bajt se zeptá: „Jste nemocní?“. Druhý bajt odpovídá: „Ne, cítím se trochu mimo.“
Otázka: Kolik programátorů je potřeba k výměně žárovky?
Odpověď: Žádný, to je hardwarový problém
Otázka: Kolik programátorů Microsoftu je potřeba k výměně žárovky?
Odpověď: Žádný, pouze z temnoty udělají standard a řeknou všem „toto chování je záměrné „
Student informatiky studuje pod stromem a další se postaví na honosném novém kole. První student se zeptá:„ Odkud to máte? „Student na kole odpoví:„ Když jsem studoval venku, krásná dívka si přitáhla kolo. Sundala si všechno oblečení a řekla: „Můžeš mít cokoli, co chceš.“ “ První student odpoví: „Dobrá volba! Její oblečení by vám asi nesedělo.“
Fyzik, inženýr a programátor seděli v autě a jeli přes prudký alpský průsmyk, když selhaly brzdy. Vůz byl stále rychlejší a rychlejší, snažili se obejít zatáčky a jednou nebo dvakrát je zachránila jen slabá svodidla, aby nespadli z boku hory. Byli si jisti, že všichni zemřou, když najednou zahlédli úniková dráha. Zatáhli do únikové dráhy a bezpečně se zastavili. Fyzik řekl: „Musíme modelovat tření v brzdových destičkách a výsledný nárůst teploty, abychom zjistili, zda dokážeme zjistit, proč selhaly.“ inženýr řekl: „Myslím, že mám vzadu několik klíčů. Podívám se a uvidím, jestli zjistím, co je špatně.“ Programátor řekl: „Proč to nejde znovu a uvidíme, jestli je to reprodukovatelné?“
Otázka: „Jaký je objektově orientovaný způsob, jak zbohatnout?“
A : Dědičnost
Programátor svým přátelům (také programátorům): „Včera večer jsem potkal horkou dívku. Přivedl jsem ji domů a začali jsme zuřivě líbat. Posadil jsem ji na klávesnici a …“. Všichni přátelé unisono řekli: „Máte doma počítač? Co je to RAM?
Dotaz SQL přejde do pruhu, projde až ke dvěma stolům a zeptá se: „Mohu se k vám připojit?“
Když je vaše kladivo C ++, všechno začíná vypadat jako palec.
Otázka: Kolik programátorů prologů je potřeba ke změně žárovky?
A: Ano.
A programátor si před spaním položí dvě sklenice na noční stolek. Plný, pro případ, že by měl žízeň, a prázdný, pro případ, že nemá.
Na rohu ulice stojí chlap, který kouří jednu cigaretu za druhou. ho a říká: „Hele, ty nevíš, že tě ty věci mohou zabít? Chci říct, nevidíš na krabici varovné varování ?!“ „To je v pořádku,“ říká ten chlap a nedbale nafukuje. počítačový programátor „.“ Takže? Co to má s čím společného? zeptala se dáma. Odpověděl: „Nestaráme se o varování. Záleží nám jen na chybách. „
Na světě je 10 typů lidí. Ti, kteří rozumějí binárním a ti, kteří mají pravidelný sex.
Takže tento programátor chodí na rande s horkým kuřátkem
Odpovědět
Jsou velmi špatní.
Jsou to druh lidí, kteří vstoupí a upraví jemně vyladěný systém s „zjevnou“ opravou a příšerně to všechno zkomplikují s naprosto nejlepšími úmysly.
Abych vám dal nějakou představu, další vynikající inženýr, kterého znám , Jeffrey Hsu, pracoval v ClickArray (nyní známém jako Array Networks) a nechal mě tam najmout, protože potřeboval další typ „velké zbraně“, aby zvládl opravdu výkonnou práci.
A dostali jsme to je hotovo.
Na systémech Pentium 4 s frekvencí 1,3 GHz (bylo to v roce 2001).
Máme reverzní mezipaměť proxy až na něco přes 38 700 připojení TCP za sekundu – což není působivé , dokud si neuvědomíte, že pro INADDR\_ANY existuje pouze 16 384 použitelných portů, pokud to podstatně nezměníte fy TCP / IP stack, pokud je to systém založený na BSD nebo Linuxu.
Neupravili jsme stack – byl to BSD stack – takže to znamenalo, že jsme také reagovali na počáteční požadavky na načtení stránky stejný časový rámec.
A pak jsme se dostali k dalšímu problému
Asi půl měsíce do dalšího problému, zřejmě někdo konečně udělal nějaký čas provést nějaké testování výkonu u změn, které provedli ve zbytku kódu v mezipaměti.
Musíme se setkat s rostoucí panikou kolem kanceláře několik dní, a několikrát se zeptal, v čem je problém, a bylo mi řečeno, že si s tím nedělejte starosti a pokračujte v práci na tom, na čem jsme pracovali.
Udělali jsme to, protože jsme opravovali konečný stavový stroj být skutečným strojem s konečným stavem a restrukturalizace kódu mezipaměti v té době. Je to jedna z věcí, která společnosti ve skutečnosti poskytla další kolo financování.
Nakonec nás jejich hotshots zavolali, abychom zjistili, zda dokážeme vyřešit jejich problém.
Získávali kolem 6 300 připojení za sekundu.
Ztratili zhruba šestinásobný výkon a nemohli přijít na to, kde.
Trvalo nám to pár hodin a nakonec jsme to vystopovali k potvrzení „provést optimalizaci pro více procesorů CPU“.
Zrušili jsme to a byli jsme zpět na přibližně 35 000 připojeních za sekundu, přeladili jsme pár cest horkého kódu a do konce dne jsme se vrátili ke starým číslům.
Abychom pochopili „optimalizaci“, kterou „ hot shot programátor ”, myslel si, že vyrábí, musíte pochopit, že threading v té době nebyl nic moc.
I kdyby to bylo, stále jsme pracovali přes státní stroj , což muselo být provedeno dříve, než by globální stav mohl být přesunut do jediného „statitového“ objektu, aby byl vytvořen na vlákno, a zabránit tomu, aby se instance vzájemně ovlivňovaly.
Takže měřítkový model měl být mít více motorů „práce na práci“ jako str rocesy a poté proces „vrátného“, který by umožnil procesu přejít k práci na požadavku tak, jak přišel. Viděl všechny požadavky a pak „nechal proces jít“; pokud by bylo více požadavků, kqueue v vrátném by „nechal další proces jít“ atd.
Náš „hot shot“ si všiml, že jeden proces zpracovává téměř všechny požadavky, zatímco ostatní procesy byly (většinou) nečinné.
Je to proto, že jsem záměrně použil LIFO místo FIFO pro procesy čekající na „práci dělat“.
Takže on „opravil „Změnou na FIFO.
A výkon šel do pekla.
Důvod, proč jsem použil LIFO v první místo, i když jsem věděl, že to nemusí nutně sdílet zátěž mezi jádry, bylo proto, že jsem věděl některé věci, které „hot shot“ neznal.
Věděl jsem, že:
- Jako síťové zařízení jsme téměř vždy měli být vázáni na vstupy a výstupy, nikoli na CPU, pokud jsme nenačítali v modulu něco jako odstranění mezer nebo přepisování obsahu pro reklamní účely
- Přesněji řečeno, věděl jsem, že posledním procesem, který se dostal do řady, byl goin g mít všechny své stránky v jádru, zatímco ta, která seděla nečinně nejdelší, by pravděpodobně neměla všechny své stránky v jádru
- Dále jsem nový, že by došlo ke kolizím TLB mezipaměti, protože všechny procesy uživatelského prostoru byly mapovány na stejný rozsah adres, což mělo za následek vyprázdnění
- Což znamenalo, že by muselo dojít k opětovnému načtení mezipaměti, což minimálně znamenalo jít alespoň na L1 a pravděpodobně do mezipaměti L2
- V kombinaci by to mělo za následek další zastavení kanálu instrukcí, protože na architektuře P4 nebyla žádná mezipaměť L3
- A tak jsem úmyslně obchodoval s tím, co jsem věděl, že pravděpodobně budou nečinné cykly CPU na další jádra pro to, co jsem věděl, že budou mít nejlepší výkon vázaný na I / O
Takže jsem záměrně vybral objednávku LIFO a ověřil zlepšení výkonu pomocí techniky, kterou jsem poprvé použil v roce 1994 nebo tak zvané (mnou, protože jsem vynalezl tuto techniku) „plánování horkých motorů“.
Takže tento „horký výstřel“ zničil lidi z důvodu změny.
A poté po údajné „optimalizaci“ neprovedl test výkonu, aby ověřil, že se ve skutečnosti jedná o optimalizaci.
Jediná věc, kterou Zkontrolováno bylo, že při zatížení všechny procesy značily přibližně stejné celkové využití CPU v průběhu času, což však myslel tím, že bude mít lepší využití více jader.
Absolutně nejhorší softwaroví inženýři jsou ti, kteří jsou dost dobří na to, aby byli nebezpeční, ale nejsou dost dobří na to, aby rozpoznali, kdy dělají špatné rozhodnutí.
O to horší je, že po ověření skutečnosti, že rozhodnutí bylo ve skutečnosti špatné, nebylo ověřeno měření výsledků jejich změn pomocí nějakého nestranného pravítka.