Najlepsza odpowiedź
P: Dlaczego programiści zawsze mylą Halloween i Boże Narodzenie?
O: Ponieważ 31 października == 25 grudnia!
spotykają się dwa bajty. Pierwszy bajt zawiera pytanie „Czy jesteś chory?”. Drugi bajt odpowiada „Nie, po prostu czuję się trochę źle”.
P: ilu programistów potrzeba, aby wymienić żarówkę?
O: żaden, to jest problem ze sprzętem
P: Ilu programistów firmy Microsoft potrzeba, aby wymienić żarówkę?
O: żadnych, po prostu uczynili ciemność standardem i mówią wszystkim: „to zachowanie jest zgodne z projektem „
Student informatyki uczy się pod drzewem, a inny podjeżdża na nowy, efektowny rower. Pierwszy student pyta:„ Skąd to masz? ”. Uczeń na rowerze odpowiada:„ Kiedy uczyłem się na świeżym powietrzu, piękna dziewczyna zajechała na rower, zdjęła wszystkie ubrania i powiedziała: „Możesz mieć wszystko, co chcesz”. Pierwsza uczennica odpowiada: „Dobry wybór! Jej ubranie prawdopodobnie by na Ciebie nie pasowało”.
Fizyk, inżynier i programista jechali samochodem po stromej alpejskiej przełęczy, gdy zawiodły hamulce. Samochód stawał się coraz szybszy, starali się ominąć zakręty i raz czy dwa tylko słaba bariera ochronna uchroniła ich przed uderzeniem w zbocze góry. Byli pewni, że wszyscy zginą, gdy nagle zauważyli pas ewakuacyjny. Zjechali na pas ewakuacyjny i bezpiecznie się zatrzymali. Fizyk powiedział: „Musimy modelować tarcie klocków hamulcowych i wynikający z tego wzrost temperatury, zobaczyć, czy możemy ustalić, dlaczego zawiodły”. Inżynier powiedział: „Myślę, że mam kilka kluczy z tyłu.” Rzucę okiem i zobaczę, czy uda mi się ustalić, co jest „nie tak”. Programista powiedział: „Dlaczego nie wrócimy do pracy i nie sprawdzimy, czy to się da odtworzyć?”
P: „Jaki jest zorientowany obiektowo sposób na wzbogacenie się?”
A : Dziedziczenie
Programista do swoich przyjaciół (także programistów): „Wczoraj w nocy spotkałem gorącą dziewczynę. Przyprowadziłem ją do domu i zaczęliśmy się wściekle całować. Posadziłem ją na klawiaturze i …”. Wszyscy znajomi zgodnie powiedzieli „Masz komputer w domu? Jaka jest jego pamięć RAM?
Zapytanie SQL trafia do paska, podchodzi do dwóch stołów i pyta „Czy mogę do ciebie dołączyć?”
Kiedy twój młotek jest C ++, wszystko zaczyna wyglądać jak kciuk.
P: Ilu prologów potrzeba, aby zmienić żarówkę?
O: Tak.
A programista przed pójściem spać stawia dwie szklanki na stoliku nocnym. Pełny, na wypadek, gdyby poczuł pragnienie, i pusty, na wypadek, gdyby nie.
Facet stoi na rogu ulicy i pali jednego papierosa za drugim. Kobieta idąca obok ostrzeżeń i mówi „Hej, czy nie wiesz, że te rzeczy mogą cię zabić? To znaczy, czy nie widziałeś gigantycznego ostrzeżenia na pudełku ?!” „W porządku” mówi facet, sapiąc niedbale „ja” mam programista komputerowy „.” Więc? Co to ma wspólnego z czymkolwiek? – zapytała pani. Odpowiedział: „Nie obchodzą nas ostrzeżenia. Dbamy tylko o błędy. ”
Na świecie jest 10 typów ludzi. Ci, którzy rozumieją binarność i ci, którzy uprawiają regularny seks.
Więc ten programista wychodzi na randkę z gorącą laską
Odpowiedź
Są bardzo źli.
Oni są ludzie, którzy wejdą i zmodyfikują dobrze dostrojony system za pomocą „oczywistej” poprawki i okropnie wszystko schrzanią, z absolutnie najlepszymi intencjami.
Aby dać ci jakiś pomysł, inny doskonały inżynier, którego znam , Jeffrey Hsu, pracował w ClickArray (obecnie znanym jako Array Networks) i zatrudnił mnie tam, ponieważ potrzebował innego typu „wielkiego pistoletu”, aby wykonać naprawdę krytyczną pracę.
I dostaliśmy zrobione.
W systemach Pentium 4 1,3 GHz (to było w 2001 roku).
Otrzymaliśmy pamięć podręczną odwrotnego proxy do około 38 700 połączeń TCP na sekundę – co nie jest imponujące , dopóki nie zorientujesz się, że jest tylko 16 384 użytecznych portów dla INADDR\_ANY, chyba że znacznie zmodyfikujesz fy stos TCP / IP, jeśli jest to system oparty na BSD lub Linux.
Nie modyfikowaliśmy stosu – był to stos BSD – więc oznaczało to, że odpowiadaliśmy również na początkowe żądania ładowania strony w tym w tym samym przedziale czasowym.
A potem przeszliśmy do następnego problemu
Około pół miesiąca do następnego problemu, najwyraźniej ktoś w końcu poświęciło trochę czasu na przetestowanie wydajności zmian, które wprowadzili w pozostałej części kodu w pamięci podręcznej.
Widzieliśmy narastającą panikę w biurze z powodu kilka dni i kilka razy zapytałem, na czym polega problem, i powiedziano mi, żeby się tym nie przejmować i dalej pracować nad tym, nad czym pracujemy.
Zrobiliśmy, ponieważ naprawialiśmy maszynę skończoną być rzeczywistą maszyną o skończonych stanach i restrukturyzację kodu pamięci podręcznej w tym czasie. W rzeczywistości jest to jedna z rzeczy, która zapewniła firmie kolejną rundę finansowania.
W końcu ich hotshot wezwał nas, aby sprawdzić, czy możemy rozwiązać ich problem.
Uzyskiwali około 6300 połączeń na sekundę.
Stracili około 6-krotny współczynnik wydajności i nie mogli dowiedzieć się, gdzie.
Zajęło nam to kilka godzin, a w końcu wyśledziliśmy to, aby wykonać zobowiązanie „optymalizacja dla wielu maszyn CPU”.
Cofnęliśmy to i wróciliśmy do około 35 000 połączeń na sekundę, ponownie dostroiliśmy kilka gorących ścieżek kodu i pod koniec dnia wróciliśmy do starych numerów.
Aby zrozumieć „optymalizację”, którą „ programista na gorąco ”myślał, że robi, musisz zrozumieć, że wątki nie były wtedy czymś szczególnie ważnym.
Nawet gdyby tak było, nadal pracowaliśmy przez maszynę stanów , co musiało być zrobione, zanim stan globalny mógł zostać przeniesiony do pojedynczego obiektu „statite”, aby utworzyć go w wątku i zapobiec wzajemnemu zakłócaniu się instancji.
Zatem model skalowania miał mają wiele silników „do zrobienia”, jak na str proces, a następnie proces „strażnika”, który pozwoliłby procesowi działać zgodnie z żądaniem w momencie jego nadejścia. Widział wszystkie żądania, a następnie „odpuszczał proces”; gdyby było więcej żądań, kolejka w strażniku „odpuściłaby inny proces” itd.
Nasz „gorący strzał” zauważył, że jeden proces obsługiwał prawie wszystkie żądania, podczas gdy inne procesy były (w większości) bezczynne.
Dzieje się tak, ponieważ celowo użyłem LIFO zamiast FIFO dla procesów oczekujących na „pracę do wykonania”.
Więc on „naprawił ”, Zmieniając go na FIFO.
A występ poszedł do diabła.
Powód, dla którego użyłem LIFO w pierwsze miejsce, mimo że wiedziałem, że niekoniecznie podzieli obciążenie między rdzenie, było to, że wiedziałem o pewnych rzeczach, których nie wiedział „gorący strzał”.
Wiedziałem, że:
- Jako urządzenie sieciowe prawie zawsze byliśmy związani we / wy, a nie CPU, chyba że ładowaliśmy moduł, aby wykonać coś takiego jak usunięcie białych znaków lub przepisanie treści w celach reklamowych
- Co więcej, wiedziałem, że trwa ostatni proces, aby ustawić się w kolejce g mieć wszystkie swoje strony w rdzeniu, podczas gdy ta, która była bezczynna najdłużej, prawdopodobnie nie miałaby wszystkich swoich stron w rdzeniu
- Ponadto, wiem, że wystąpią kolizje pamięci podręcznej TLB, ponieważ wszystkie procesy w przestrzeni użytkownika były mapowane w tym samym zakresie adresów, co skutkowało opróżnianiem
- Co oznaczało konieczność przeładowania pamięci podręcznej, co minimalnie oznaczało wyjście na co najmniej L1 i prawdopodobnie L2 cache
- W połączeniu, skutkowałoby to dodatkowymi blokadami potoku instrukcji, ponieważ nie było pamięci podręcznej L3 w architekturze P4
- I dlatego celowo wymieniłem to, co wiedziałem, że prawdopodobnie będzie bezczynnymi cyklami procesora na dodatkowe rdzenie, o których wiedziałem, że będą miały najlepszą wydajność związaną z I / O
Więc celowo wybrałem zamówienie LIFO i zweryfikowałem poprawę wydajności, używając techniki, której użyłem po raz pierwszy w 1994 roku lub tak zwane (przeze mnie, ponieważ wynalazłem tę technikę) „planowanie gorącego silnika”.
Więc ten „gorący strzał” zniszczył pe rformance z powodu zmiany.
A potem, po rzekomej „optymalizacji”, nie udało się przeprowadzić testu wydajności, aby zweryfikować, czy w rzeczywistości była to optymalizacja.
Jedyne, co powiedział d sprawdził, czy pod obciążeniem wszystkie procesy zaznaczały mniej więcej takie samo całkowite użycie procesora w czasie, co, jak sądził, oznaczało, że zamierza uzyskać lepsze wykorzystanie wielu rdzeni.
Absolutnie najgorszymi inżynierami oprogramowania są ci, którzy są wystarczająco dobrzy, by być niebezpieczni, ale nie na tyle dobrzy, by rozpoznać, kiedy podejmują złą decyzję.
Jeszcze gorzej, gdy nie sprawdzają po fakcie, że decyzja była w rzeczywistości zła, mierząc skutki swoich zmian za pomocą jakiegoś bezstronnego władcy.