Czy wszyscy programiści powinni mieć wielordzeniowe procesory?

Oryginalny post: Should All Developers Have Manycore CPUs?

Autor: Jeff Atwood

Dwurdzeniowe procesory są już dzisiaj standardem, i to z dobrego powodu -- istnieją pokaźne, dające się udowodnić wzrosty wydajności, wynikające z posiadania drugiego procesora, czekającego na zadania, których pierwszy procesor nie może obsłużyć, w momencie, gdy jest zapracowany. Jeśli tak, to dwurdzeniowe procesory chronią Cię przed źle napisanym oprogramowaniem; jeśli zepsuta aplikacja zużywa całą moc procesora, to wszystko co może dostać, to 50% jego mocy. Nadal dostępny jest drugi procesor, który zagwarantuje, że system operacyjny pozwoli Ci ubić CrashyApp 5.80 SP1 Enterprise Edition w rozsądny sposób. To kumpelski układ w krzemowej formie.

Mój poprzedni wpis o modernizowaniu procesora w Twoim komputerze był bardziej kontrowersyjny niż zamierzałem. Oto co napisałem:

Moim zdaniem, czterordzeniowe procesory są nadal marnotrawieniem prądu chyba, że umieścisz je w serwerze. Cztery rdzenie w komputerze są dobre do przechwalania się i do matematycznej wyższości (tak, 4 > 2), ale te cztery rdzenie nie dostarczają mierzalnego wzrostu wydajności w aplikacjach używanych przez większość ludzi. Włączając w to narzędzia do programowania.

Niefortunnie to ująłem, ponieważ powyższe stwierdzenie przyciemniło resztę wpisu. Moim zamierzeniem było zachęcenie ludzi do podejmowania uzasadnionych decyzji podczas wyboru procesora. Doprawdy, wybierz taki procesor jaki chcesz; ważną częścią tego wpisu było pozbycie się obaw przed rozbudową swojego komputera. Na tyle na ile powyższy paragraf rozproszył uwagę czytelników od tego celu -- przepraszam.

Niemniej jednak, mam silne uczucia w tym temacie. Za często widuję użytkowników uwiedzionych przez kampanię reklamową Intela, ślepo zakładając, że jeśli dwa rdzenie procesora są lepsze od jednego rdzenia, to, no.. cztery, osiem, albo szesnaście musi być szalenie szybkie! I opróżniają swoje portfele. Obawiam się, iż wielu użytkowników pada ofiarą marketingowych łasic, płacąc dodatkowo za wydajność, która nigdy się nie urzeczywistni. To tak jak za starych, niedobrych czasów Pentium 4 z tym, że zamiast absurdalnej ilości megaherców, mamy absurdalną liczbę rdzeni procesora.

Chciałbym, aby ludzie zrozumieli, że istnieje tylko garść aplikacji, która potrafi wykorzystać moc więcej niż dwóch rdzeni, i mają one tendencje skupiania się wokół pewnych wyspecjalizowanych dziedzin. Jak dla mnie, chodzi tylko o dane z benchmarków, a one nie wykazują żadnych nieodpartych powodów, aby przejść na cztery rdzienie, o ile regularnie nie zajmujesz się jednym z poniższych:

  • "ripowanie" bądź kodowanie video
  • profesjonalne renderowanie scen 3D
  • uruchamianie naukowych symulacji

Jeśli często robisz jedno z powyższych, niewątpliwie cztery rdzenie (albo osiem) są dobrym wyborem. Ale jest to jedynie moja rekomendacja, bazująca na danych z benchmarków, a nie żelazny fakt. To Twoje pieniądze. Wydaj je jak chcesz. Jedyne co proponuję, to abyś wydał je rozsądnie.

Ach, ale zostaje jeszcze argument wielozadaniowości. Wybłagałem komentatorów, którzy byli pewni korzyści płynących z czterech rdzeni, aby wskazali mi benchamarki wielozadaniowości, które wskazywałyby głęboką różnicę w wydajności pomiędzy dwu a więcej-niż-dwurdzeniowymi procesorami. To ciekawe. Sieć jest zalana zylionem stron z recenzjami sprzętu, ale ciężko jest znaleźć benchmark wielozadaniowości na którejkolwiek z nich. Myślę, że to dlatego, iż liczba zadań wykonywanych równocześnie potrzebna, aby poważnie obciążyć więcej niż dwa rdzenie, leży na granicy absurdu. Jak to wskazał Anand:

Kiedy próbowaliśmy wymyślać nowe benchmarki dla wielozadaniowości, aby poważnie obciążyć platformy Kentsfield oraz Quad FX [czterordzeniowe], ciągle natykaliśmy się na interesujące, ale nierealne scenariusze, które świetnie sprawdzały się przy obciążaniu testowanych urządzeń, ale kiepsko w dawaniu dobrego powodu, dla którego warto byłoby używać czterech rdzeni.

Co możesz znaleźć natomiast to ten oto benchmarkowy refren powtarzany w kółko:

Tak jak większość dzisiejszych aplikacji, WorldBench, łącznie ze swoimi komponentami, nie zyskuje wiele od więcej niż dwóch rdzeni procesora.

Po tym wszytkim myślę, że popełniłem błąd w moim oryginalnym stwierdzeniu. Programiści nie są typowymi użytkownikami. W rzeczy samej, można rozsądnie założyć, że programiści są z definicji specyficznymi użytkownikami i stąd, powinni poszukiwać wielordzeniowych procesorów, tak jak Kevin powiedział w komentarzach:

Jak wyobrażasz sobie, że programiści piszą aplikacje (to jest to kim jesteśmy i co robimy, prawda?), które potrafią wykorzystać 4, 8, itd... procesorów, jeśli wykorzystujemy platformy z jednym bądź dwoma rdzeniami? Pokażę to na przykładzie wielu monitorów. Programiści potrzebują ich nie tylko po to, by zwiększyć swoją produktywność, ale dlatego, że nie zrozumieją jak kiepsko ich aplikacja działa na wielu monitorach, dopóki jej nie użyją w ten sposób. To samo pozostaje prawdą przy wielordzeniowych procesorach.

Mam na to dwie odpowidzi. Jedna za nich prawdopodobnie się Wam nie spodoba.

Zacznijmy od pierwszej. Absolutnie zgadzam się z tym, iż istotnym jest, żeby programiści rozważyli programowanie pod wiele rdzeni, i posiadanie takiej platformy jest dla nich warunkiem zasadniczym. Najpierw napisałem o tym, dawno w 2004 roku, w "Wątki, współbieżność i najbardziej potężny psychokinetyczny ładunek wybuchowy we Wszechświecie". W istocie, dwójka ludzi, których cytowałem w tym starym wpisie -- prawdziwi liderzy w dziedzinie programowania współbieżnego -- przysłali wczoraj bezpośrednie odpowiedzi do tego wpisu, i obaj zasługują na odpowiedź.

Rick Brewster, od naprawdę niesamowitego projektu Paint.NET, odpowiedział:

He? Pewnym jest, że Paint.NET wykazuje spore osiągnięcia dla czterordzeniowych procesorów, w przeciwieństwie do dwurdzeniowych. Jest nawet benchmark. Powiedziałbym, że zalicza się to do "aplikacji, których używa większość ludzi".

On ma absolutną rację. Czterordzeniowy Q6700 @ 2.66 GHz bije mojego dwurdzeniowego E8500 @ 4.0 GHz na tym benchmarku z wynikiem 26 sekund do 31. Ale z całym szacunkiem do Ricka -- i poważnie, jak najbardziej, uwielbiam Paint.NET, a jego wielowątkowy kod jest niesamowity -- czuję, że ten benchmark testuje wyspecjalizowane (i poddające się zrównoleglaniu) filtry aniżeli główną funkcjonalność. Istnieje długa historia benchmarków Photoshopa w podobnym stylu; to przypadek renderowania 3D bez jednego wymiaru. Jeśli spędzasz znaczną część dnia używająć Photoshopa, powinieneś wybrać platformę, która radzi sobie z nim najlepiej.

Ale jesteśmy programistami, nie projektantami. Spędzamy większość czasu rozmawiając z kompilatorami, interpreterami oraz edytorami różnego rodzaju. Herb Sutter poświęcił cały wpis na swoim blogu, wyjaśniając, że w rzeczy samej, narzędzia do programowania wykorzystują czterordzeniowe procesory:

Musisz używać nie tych narzędzi co trzeba. :-) Na przykład, oto trzy, które znam:

  1. Flaga /MP w Visual C++ 2008, informuje kompilator, aby kompilował pliki w tym samym projekcie równolegle.
  2. Od Visual Studio 2005 obsługujemy równoległe kompilowanie projektów w trybie Batch Build.
  3. Excel 2007 robi równoległą rekalkulację. Zakładając, że arkusz kalkulacyjny jest duży i zawiera nie tylko sekwencyjne zależności między komórkami, skaluje się zazwyczaj liniowo do przynajmniej ośmiu rdzeni.

Herb jest ekspertem w dziedzinie programowania równoległego oraz ogólnym guru C++, i oczywiście ma rację we wszystkich trzech punktach. Zupełnie zapomniałem o kompilacji C++, albo raczej, uczciwie powiedziawszy, nie chciałem pamiętać. Czego oczekujecie od gościa wywodzącego się do BASIC'a? Czas kompilacji to olbrzymi cios dla produktywności programistów C++ pracujących na dużych projektach. Czas kompilacji używając gcc oraz time make -j<# of cores + 1> jest dziadkiem wszystkich wielordzeniowych benchmarków programistów. Oto reprezentatywne wyniki kompilowania źródła LAME 3.97:

1 Xeon E5150 (2.66 GHz Dual-Core) 12.06 s
1 Xeon E5320 (1.86 GHz Quad-Core) 11.08 s
2x Xeon E5150 8.26 s
2x Xeon E5320 8.45 s

Może liczby te wydają się małe, ale procenty są niesamowicie ujmujące, szczególnie jeśli zsumujesz sobie ile razy kompilujesz dziennie. Jeśli jesteś programistą C++, potrzebujesz czterordzeniowego procesora od wczoraj. Wymagaj tego.

Ale co z nami, programistami kodu zarządzanego, z naszym brakiem wskaźników i jawnej alokacji pamięci? Herb wspomniał o równoległym kompilowaniu projektów w Visual Studio 2008; jest w menu Tools, Options, Project and Solutions, Build and Run.

Jak obiecano, domyślnie dostosowywuje się do ilości rdzeni jakie posiadam w swoim komputerze -- dwóch. Ściągnałem największy projekt .NET'owy jaki mogłem sobie wyobrazić -- SharpDevelop. Cała solucja jest zadowalająco duża; zawiera 60 projektów. Przekompilowałem to kilka razy w Visual Studio 2008, ale menedżer zadań nie wskazywał dużego obciążenia moich marnych dwóch rdzeni:

Zauważyłem parę szczytów powyżej 50%, ale to jest strasznie średni wynik w porównaniu do make -j4. Nie widzę tu nic, co by wskazywało na polepszenie czasu kompilacji kodu zarządzanego przy przejściu na więcej niż dwa rdzenie. Ciekaw jestem, czy kompilatory Java (albo inne kompilatory języków .NET-opodobnych) radzą sobie lepiej.

Wracając do pytania Kevina: tak, jeśli jesteś programistą, piszącym aplikacje desktopowe, które choć w najmniejszym stopniu mają coś, co da się zrównoleglać, powinieneś mieć taką liczbę rdzeni porcesora w swoim komputerze, jaką potrzebujesz aby testować i debugować swój kod. Proponuję rozpocząć od skalowania do dwóch rdzeni jako, że to wygląda na najbardziej wyzywającą część zadania. Jeśli chcesz więcej, to powodzenia, ponieważ wszytko, co czytałem w temacie pisania skalowalnych, współbieżnych aplikacji, daje z siebie co może, by wytłumaczyć z potwornymi szczegółami, jak piekielnie trudno pisze się kod tego rodzaju.

A oto druga część odpowiedzi, którą obiecałem Wam wcześniej. Ta, której możecie nie polubić. Większość programistów nie pisze aplikacji desktopowych. Piszą aplikacje webowe. Wielu z nich może pisać w językach skryptowych, które nie są kompilowane, lecz interpretowane -- takie jak Ruby, Python czy PHP. Do licha, one nawet nie są wielowątkowe. Pomimo tego, taki kod jakoś osiąga niesamowity poziom współbieżności, skaluje sie do wielkich obciążeń, i dźwiga niektóre z największych serwisów w Internecie. A wszystko to, bez odrobiny myślenia o współbieżności, wątkach, czy wielobieżności. To rodzaj magii, jeśli się o tym pomyśli.

Biorąc pod uwagę to, że siłą rzeczy, podczas tworzenia aplikacji komputery programistów muszą odwzorowywać środowisko serwerowe, powinny one mieć tyle rdzeni, ile jest to możliwe.

1 komentarze:

Anonimowy pisze...

Nawet sympatyczna notka :)

Prześlij komentarz

Related Posts with Thumbnails