Po co komu 4 rdzenie?



Kupiliście ostatnio nowy komputer? Może akurat jest to komputer stacjonarny? I może przypadkiem poddaliście się reklamom najszybszych i kupiliście komputer wyposażony we wspaniały, kilkurdzeniowy CPU? Tak? To jest mi bardzo przykro to powiedzieć, ale przepłaciliście...

Na papierze wszystko wygląda cudnie - więcej procesorów oznacza, że w tym samym czasie mogę wykonać więcej operacji. Teoretycznie więc, jeśli mamy cztery zamiast dwóch procesorów, to przy tym samym taktowaniu mogę wykonać wszystko dwa razy szybciej. Wypakowujemy więc nasz nowy komputer z pudła, odpalamy, instalujemy naszą ulubioną grę, odpalamy nasze ulubione strony i jesteśmy zadowoleni, że wszystko działa nieporównywalnie szybciej niż na naszym starym wysłużonym komputerze. Potem przez chwilę żyjemy w przeświadczeniu, że nasza decyzja była słuszna... aż do momentu w którym okazuje się, że na komputerze kolegi nasza ulubiona gra działa wcale nie wolniej, niż u nas, a przecież on ma tylko dwa rdzenie!

Spieszę wyjaśnić kto jest temu winny i niestety muszę dopiec moim kolegom po fachu, czyli programistom. Problem polega na tym, że niestety o ile technologia SMP (Symmetric Multiprocessing) jako koncepcja pamięta jeszcze sukcesy aktorskie Franka Sinatry, o tyle jej wejście do komputerów osobistych jest stosunkowo nowym pomysłem. To zdanie oczywiście nie wygląda na specjalny przytyk, ale zaczynamy inaczej je czytać wiedząc, że już zupełnie oklepany w sieci AJAX, uwielbiany przez co niektórych język programowania C#, nie wspominając już o DirectX 11, czy forsowanym przez NVidię GC to zdecydowanie młodsze niż SMP technologie. Dlaczego więc programiści, tak szybko uczący się nowych środowisk, języków programowania i wszelkiego rodzaju nowych idei nie potrafią wesprzeć technologii istniejącej od lat 60tych? Otóż dlatego, że SMP wymaga zupełnie innego sposobu myślenia.

Do tej pory każdy pisany program pracował mniej lub bardziej w modelu synchronicznym - wykonujemy coś, patrzymy co się stało od jakiegoś czasu i znów coś wykonujemy. Owszem, dużo obecnie pisanych programów ma architekturę wielowątkową - problem jednak leży nieco głębiej. Wątki nie rozwiązują problemu, gdyż każdy wątek wykonuje konkretną operację - nawet jeśli skorzystamy z polecenia, upraszczając, fork(), w bardzo sprytny sposób zbudujemy sobie wątek pracujący na zupełnie oddzielnym procesie, to nadal wykorzystamy go po to, żeby zrobił "coś". "Ale, ale! Kolego!", powiecie "przecież mogę zrobić cztery razy fork() i mieć cztery wątki, każdy na własnym procesorze!". Owszem, ale nie macie w ten sposób pewności, który z nich się zakończy, a który z nich będzie czekał na inne. W takim razie powiecie, że zrobicie sobie szesnaście forków i będziecie już spokojni - i owszem, wówczas prawdopodobieństwo, że któryś rdzeń będzie mniej obciążony będzie mniejsze, ale ile instrukcji procesora pójdzie na przełączanie pomiędzy procesami?

Oczywiście jest rozwiązanie - my programiści, musimy przestać myśleć jedynie wątkami, obiektami i zdarzeniami - to piękne koncepcje, ale niewystarczające. Trzeba zacząć myśleć potokami - forkować zanim zaczęliśmy wykonywać jakiekolwiek operacje, a potem wrócić do starego dobrego synchronicznego myślenia, na każdym z potoków kolejkować kolejne operacje, od czasu do czasu sprawdzając, gdzie można coś jeszcze dorzucić...

A Ty użytkowniku? Do czasu, aż my się ze sobą pokłócimy, potem się pogodzimy, potem przemyślimy całą sprawę i wypiszemy 10 milionów wpisów na blogach, a może w końcu zaczniemy coś porządnie programować - lepiej przeznacz różnicę z super wypasionego 16sto rdzeniowego procesora do zwykłego dwurdzeniowca na jakieś przyjemne wakacje na południu Francji. Będziesz z tego miał cudowną opaleniznę i wewnętrzny luz, a twój komputer będzie działał równie szybko jak tego twojego  bladego kolegi, który mnie nie posłuchał.



Proszę czekać...
Nie możesz komentować. Budleigh Salterton umieścił Cię na czarnej liście lub Twoje konto nie jest aktywne.