Obawiam się, że „robię coś złego” tutaj, jeśli tak, usuń mnie i przepraszam. W szczególności nie widzę, jak tworzę zgrabne małe adnotacje, które stworzyli niektórzy ludzie. Mam jednak wiele obaw / spostrzeżeń dotyczących tego wątku.
1) Skomentowany element w pseudokodzie w jednej z popularnych odpowiedzi
result = query( "select smurfs from some_mushroom" );
// twiddle fingers
go_do_something_with_result( result );
jest zasadniczo fałszywy. Jeśli wątek oblicza, to nie kręci kciukami, wykonuje niezbędną pracę. Z drugiej strony, jeśli po prostu czeka na zakończenie IO, to nie jest wykorzystuje czasu procesora, cały punkt infrastruktury kontroli wątków w jądrze polega na tym, że CPU znajdzie coś pożytecznego do zrobienia. Jedynym sposobem na „poruszenie kciukami”, jak sugerowano tutaj, byłoby utworzenie pętli odpytywania, a nikt, kto zakodował prawdziwy serwer sieciowy, nie jest na to wystarczająco przygotowany.
2) „Wątki są trudne”, ma sens tylko w kontekście udostępniania danych. Jeśli masz zasadniczo niezależne wątki, tak jak ma to miejsce w przypadku obsługi niezależnych żądań internetowych, to wątkowanie jest banalnie proste, po prostu kodujesz liniowy przepływ obsługi jednego zadania i siedzisz całkiem wiedząc, że obsłuży on wiele żądań i każdego będzie skutecznie niezależny. Osobiście zaryzykowałbym to, że dla większości programistów nauka mechanizmu zamykania / oddzwaniania jest bardziej złożona niż zwykłe kodowanie wersji wątku od góry do dołu. (Ale tak, jeśli musisz komunikować się między wątkami, życie staje się naprawdę trudne naprawdę szybko, ale nie jestem przekonany, że mechanizm zamykania / oddzwaniania naprawdę to zmienia, po prostu ogranicza twoje opcje, ponieważ takie podejście jest wciąż możliwe do osiągnięcia dzięki wątkom W każdym razie, że ”
3) Jak dotąd nikt nie przedstawił żadnych prawdziwych dowodów na to, dlaczego jeden konkretny typ zmiany kontekstu byłby mniej lub bardziej czasochłonny niż jakikolwiek inny typ. Moje doświadczenie w tworzeniu wielozadaniowych jąder (na małą skalę dla wbudowanych kontrolerów, nic tak wymyślnego jak „prawdziwy” system operacyjny) sugeruje, że tak nie byłoby.
4) Wszystkie ilustracje, które do tej pory widziałem, które pokazują, jak szybszy jest Węzeł niż inne serwery WWW, są strasznie wadliwe, jednak są one wadliwe w sposób, który pośrednio ilustruje jedną korzyść, którą zdecydowanie zaakceptowałbym dla Węzła (i to nie jest wcale nieistotne). Węzeł nie wygląda tak, jakby wymagał (a nawet nie zezwala) na dostrojenie. Jeśli masz model gwintowany, musisz utworzyć wystarczającą liczbę wątków, aby obsłużyć oczekiwane obciążenie. Zrób to źle, a skończysz na niskiej wydajności. Jeśli jest za mało wątków, procesor jest bezczynny, ale nie jest w stanie zaakceptować większej liczby żądań, utworzyć zbyt wiele wątków, a ty zmarnujesz pamięć jądra, aw przypadku środowiska Java również zmarnujesz pamięć główną sterty . W przypadku Javy marnowanie sterty jest pierwszym, najlepszym sposobem na zwiększenie wydajności systemu, ponieważ wydajne zbieranie śmieci (obecnie może się to zmienić w przypadku G1, ale wydaje się, że jury wciąż nie jest w tym punkcie co najmniej na początku 2013 r.) zależy od dużej ilości zapasów. Więc jest problem, dostrój go za mało wątków, masz bezczynne procesory i słabą przepustowość, dostrój go za dużo, i zapada się na inne sposoby.
5) Jest inny sposób, w jaki akceptuję logikę twierdzenia, że podejście Węzła „jest z założenia szybsze” i to jest to. Większość modeli wątków wykorzystuje model przełącznika kontekstu podzielony na przedziały czasowe, nałożony na bardziej odpowiedni (alert oceny wartości :) i bardziej wydajny (a nie ocena wartości) modelu zapobiegawczego. Dzieje się tak z dwóch powodów: po pierwsze, większość programistów wydaje się nie rozumieć pierwszeństwa z wyprzedzeniem, a po drugie, jeśli nauczysz się wątkowania w środowisku Windows, tworzenie czasów jest takie, czy ci się to podoba, czy nie (oczywiście, to wzmacnia pierwszy punkt ; przede wszystkim w pierwszych wersjach Javy zastosowano priorytetowe zapobieganie implementacjom Solaris i systemowi timeslicing w Windows. Ponieważ większość programistów nie rozumiała i narzekała, że „wątkowanie nie działa w Solaris” wszędzie zmienili model na przedziały czasu). W każdym razie najważniejsze jest to, że tworzenie czasów powoduje dodatkowe (i potencjalnie niepotrzebne) przełączniki kontekstu. Każdy przełącznik kontekstu zajmuje czas procesora i ten czas jest skutecznie usuwany z pracy, którą można wykonać na rzeczywistym zadaniu. Jednak ilość czasu zainwestowanego w zmianę kontekstu z powodu tworzenia przedziału czasu nie powinna przekraczać bardzo małego odsetka całkowitego czasu, chyba że dzieje się coś dziwacznego i nie widzę powodu, dla którego mogę oczekiwać, że tak będzie w przypadku prosty serwer WWW). Tak, tak, przełączniki nadmiaru kontekstu biorące udział w tworzeniu fragmentów są nieefektywne (i nie zdarzają się one w i czas ten jest skutecznie usuwany z pracy, którą można wykonać na prawdziwej pracy pod ręką. Jednak ilość czasu zainwestowanego w zmianę kontekstu z powodu tworzenia przedziału czasu nie powinna przekraczać bardzo małego odsetka całkowitego czasu, chyba że dzieje się coś dziwacznego i nie widzę powodu, dla którego mogę oczekiwać, że tak będzie w przypadku prosty serwer WWW). Tak, tak, przełączniki nadmiaru kontekstu biorące udział w tworzeniu fragmentów są nieefektywne (i nie zdarzają się one w i czas ten jest skutecznie usuwany z pracy, którą można wykonać na prawdziwej pracy pod ręką. Jednak ilość czasu zainwestowanego w zmianę kontekstu z powodu tworzenia przedziału czasu nie powinna przekraczać bardzo małego odsetka całkowitego czasu, chyba że dzieje się coś dziwacznego i nie widzę powodu, dla którego mogę oczekiwać, że tak będzie w przypadku prosty serwer WWW). Tak, tak, przełączniki nadmiaru kontekstu biorące udział w tworzeniu fragmentów są nieefektywne (i nie zdarzają się one wwątki jądra z reguły, btw), ale różnica będzie wynosić kilka procent przepustowości, a nie rodzaj liczby całkowitej, która jest sugerowana w oświadczeniach dotyczących wydajności, które są często sugerowane dla Węzła.
W każdym razie przepraszam, że to wszystko jest długie i chaotyczne, ale naprawdę czuję, że do tej pory dyskusja niczego nie udowodniła i chętnie usłyszę od kogoś w którejkolwiek z tych sytuacji:
a) prawdziwe wyjaśnienie, dlaczego Node powinien być lepszy (poza dwoma scenariuszami, które przedstawiłem powyżej, z których pierwszy (słabe dostrojenie) uważam za prawdziwe wyjaśnienie wszystkich testów, które do tej pory widziałem. [[edytuj ], im więcej o tym myślę, tym bardziej zastanawiam się, czy pamięć używana przez ogromną liczbę stosów może być tutaj znacząca. Domyślne rozmiary stosów dla współczesnych wątków bywają dość duże, ale pamięć przydzielana przez system zdarzeń oparty na zamknięciu byłby tylko tym, czego potrzeba)
b) prawdziwy test porównawczy, który faktycznie daje uczciwą szansę wybranemu serwerowi wątkowemu. Przynajmniej w ten sposób musiałbym przestać wierzyć, że twierdzenia są zasadniczo fałszywe;> ([edytuj] jest to prawdopodobnie silniejsze niż zamierzałem, ale wydaje mi się, że wyjaśnienia dotyczące korzyści w zakresie wydajności są w najlepszym razie niepełne, a przedstawione testy porównawcze są nieuzasadnione).
Na zdrowie, Toby
select()jest szybsze niż zamiana kontekstu wątku.