Programistów czeka sporo pracy
Anwar Gholoum, jeden z inżynierów zatrudnionych w intelowskim Laboratorium Technologii Mikroprocesorowych, opublikował na oficjalnym blogu Intela wpis, w którym zwraca programistom uwagę na poważne zmiany, jakie zajdą w najbliższych latach.
Gholoum wspomina o rozmowach, jakie toczy z innymi inżynierami. Z jednej strony od lat mówi się o tym, że osoby rozwijające oprogramowanie starają się jak najmniejszym kosztem przystosować je do pracy na dwu- czy czterordzeniowych procesorach. Z drugiej zaś, inżynierowie już dyskutują o procesorach przyszłości, zawierających dziesiątki, setki, a nawet tysiące rdzeni. W przypadku takich procesorów taktyka "oszczędnego" programowania się nie sprawdzi.
Obecnie programiści w dość prosty sposób przystosowują np. gry napisane dla procesorów jednordzeniowych, do współpracy z czterordzeniowymi układami. Wystarczy, że "rozbiją" pojedynczy wątek na kilka oddzielnych: jeden odpowiedzialny za przetwarzanie muzyki, drugi za grafikę, trzeci za sztuczną inteligencję. Taka taktyka zapewnia spore oszczędności, gdyż "rozbite" wątki korzystają z pierwotnego kodu pojedynczego wątku, więc ich przygotowanie nie wymaga dużo pracy. Zmiany takie powodują pewne zwiększenie wydajności, gdyż każdy z wątków może być przetwarzany przez osobny rdzeń. Jeśli zatem rozdzielimy oryginalny wątek na 4, to będą one korzystały z 4 i tylko z 4 rdzeni.
Gholoum uważa, że programiści powinni przygotować się do całkowitej zmiany podejścia. Tak naprawdę procesory przyszłości będą wymagały przepisania niemal całego kodu tak, by każdy z wątków mógł skorzystać z dowolnej dostępnej liczby rdzeni. Dopiero wtedy w pełni wykorzystamy wydajność wielordzeniowych procesorów.
Już w tej chwili istnieją techniki, które działają właśnie w ten sposób. Bardzo dobrze skaluje się ray tracing, czyli śledzenia światła w wirtualnych scenach. Wykorzystywane w tym przypadku algorytmy są tak skonstruowane, że dołożenie kolejnych rdzeni powoduje zwiększenie prędkości przetwarzania, gdyż potrafią one skorzystać z dodatkowych mocy obliczeniowych.
Większość aplikacji jest jednak napisanych tak, że ich skalowanie będzie wymagało olbrzymiego nakładu pracy. Tym bardziej, że zarówno współczesne narzędzia developerskie i testowe oraz języki programowania są mocno zorientowane na przetwarzanie jednowątkowe.
Gholoum zauważa, że programiści specjalizujący się w rynku HPC (high-performance computing) od lat wiedzą o problemach związanych z przetwarzaniem wielowątkowym. Osoby programujące na rynek konsumencki jak dotąd nie przejmowały się kłopotami, z jakimi musieli zmagać się ich koledzy oprogramowaujący potężne klastry. W najbliższych latach może się to zmienić.
Komentarze (34)
este perfil es muy tonto, 2 lipca 2008, 14:26
pod koniec tekstu gość zmienia nazwisko z Gholoum na Goloum
ciembor, 2 lipca 2008, 16:14
A po co się bawić w dzielenie wątków starych programów na różne rdzenie? Przecież za jakiś czas każdy program napisany w dzisiejszych czasach będzie śmigał bez problemu na jednym rdzeniu. Co nie zmienia faktu, że trzeba jak najszybciej zmienić podejście do programowania aby tworząc nowe, bardziej wymagające aplikacje, potrafiły one wykorzystać w pełni możliwości sprzętu.
waldi888231200, 2 lipca 2008, 17:43
A może lepiej żeby każdy program z osobna obsługiwał inny rdzeń. (rzadko jedna tylko aplikacja jest otwarta) 8)
Gość macintosh, 2 lipca 2008, 17:46
"Chętnie zobaczę kilkusetstronicowy PDF Twojego autorstwa ze szczegółowymi wyliczeniami i analizami laboratoryjnymi."
waldi888231200, 2 lipca 2008, 18:22
Mniej kontaktów z m.......m uchroni twoje PM przed przekodowaniem (w agenta Smitha) ;D
ozeo, 2 lipca 2008, 18:23
"A może lepiej żeby każdy program z osobna obsługiwał inny rdzeń. (rzadko jedna tylko aplikacja jest otwarta)"
Nie lepiej bo za jakiś czas rdzeni będzie setki a może i tysiące w jednym procesorze a programów kilka - kilkadziesiąt. Problem w tym ,że zazwyczaj korzystamy z jednego głównego programu np. gry ,który potrzebuje większości mocy obliczeniowej i trzeba go tak zaprojektować aby te wszystkie rdzenie efektywnie wykorzystać a to już wiąże się z zupełnie innymi sposobami programowania niż obecnie stosowane.
Inną sprawą jest to że pojedyncze rdzenie za bardzo nie przyspieszą w następnych latach bo zbliżamy się do kresu wykorzystania materiałów (światło w krzemie szybciej nie poleci) i taktowanie rdzeni dużo większe nie będzie stąd kierunek rozwoju procesorów wielordzeniowych.Zasobożerność aplikacji ciągle rośnie i raczej będzie rosnąć ,więc taktyka 1 rdzeń jedna aplikacja dość szybko się załamie.
waldi888231200, 2 lipca 2008, 18:28
To może procesor sam powinien dzielić swoje zadania pomiędzy poszczególne rdzenie (przydzielać dynamicznie ilość rdzeni do odpowiednich najcięższych zadań) 8)
Gość macintosh, 2 lipca 2008, 19:05
Moim celem przekodowanie jest.
Gdyby środowisko nie było wielozadaniowe niepotrzebowalibyśmy wielordzeniowców.
OS powinien rozdzielać zadania.
Używając wielordzeniowca unikasz konieczności poświęcania czasu procesora na "podział".
Nie "najcięższych zadań" tylko "o najwyższym priorytecie".
mistyfikator(!!)
ozeo, 2 lipca 2008, 23:26
OS już rozdziela zadania i robi tak jak robi dużo lepiej nie będzie. Nie można obsługi wielu rdzeni zwalić na procesor o ile proste instrukcje już są rozdzielane w procesorach wielopotokowych o tyle skomplikowane programy nie dadzą się tak łatwo podzielić jeśli ich się odpowiednio nie zaprojektuje. Oczywiście procesor będzie przydzielał na niskopoziomowym etapie poszczególne zadania do wolnych rdzeni ale to aplikacja wie ile czego potrzebuje a nie procesor. Jak napiszesz aplikację jednowątkowo co będzie wykonywać operacje np. tylko w jednej ustalonej kolejności a będzie wykonywać skomplikowane obliczenia to ani procesor ani OS nie przydzieli jej na kilka rdzeni bo nie będzie jak. To programista w fazie projektowania będzie musiał myśleć jak to zaprojektować aby się dało to wykonać na wielu rdzeniach jednocześnie wykorzystując ich moc. A to jest niestety bardzo skomplikowane.
waldi888231200, 2 lipca 2008, 23:52
Dzięki , ubogacające to było..
Gość macintosh, 3 lipca 2008, 00:11
ozeo: Dzięki, że napisałeś.
To skomplikowane coś nie jest(zgaduje sobie), na pewno opisał to już jakiś matematyk.
W zasadzie programowanie staje się
nudne, męczące i zupełnie, ni w cholere ja pierdziele, nie można mieć satysfakcji
z bloków programów na oddzielne wątki tylko dlatego, że kompilator nie ma preimplementowanego poszukiwania optymalnego rozkładu wątków- program instalacyjny mógłby być zrobiony tak, że dobiera ilość wątków dla kompa na którym mamy wielordzeniowca.. i głupiutkie by to nie było.
wilk, 3 lipca 2008, 15:50
Jak to nie ma? Są kompilatory do obsługi wieloprocesorowości i tworzenia zrównoleglonego kodu. Modele matematyczne i naukowe opracowania także są. Ale wciąż programista musi (choć kompilatory także same mogą podejmować się tego, lecz nie zawsze jest to optymalne) oznaczyć potencjalne miejsca zrównoleglane - są to zasadniczo czasochłonne pętle, które mogą być wykonywane blokami na osobnych rdzeniach/wątkach, bez utraty spójności i zbędnych synchronizacji.
doker, 14 lipca 2008, 23:44
Weźmy 2 * 2 + 2
Dla procesora to kod postaci mniej więcej takiej:
SET REGISTER_A 2
MULTIPLY A 2
ADD A 2
RETURN A
Jak widzisz, nie możesz podzielić pracy miedzy 2 rdzenie, gdyż nie zwrócisz wyniku póki nie dodasz, a nie dodasz póki nie pomnożysz itd.
Chodzi o to aby pisać programy w taki sposób aby jak najdłuższe sekwencje komend były niezależne.
Inny przyklad, biznesowy.
Masz w w bazie dane, a masz je wyslac przez siec. Masz do dyspozycji procedure ktora pobiera dlugi ciag binarnych danych z bazy oraz procedure ktora wysyla dane do przegladarki.
Wielu programistow pobierze dane z bazy i wysle je do przegladarki.
Trudniej jest zrobić tak aby jednocześnie, w czasie pobierania danych z bazy, wrzucać je do bufora, z którego w tym samym czasie, brać ściągnięte już dane i wysyłać do przeglądarki, kasując z bufora. Trzeba pilnować sytuacji gdy miejsce na buffor zostanie cale zapełnione oraz gdy nie ma na razie informacji w buforze. Poza tym trzeba pokona lek przed programowaniem wielowątkowym.
andrew102, 20 lipca 2008, 20:03
uważam, że przykład dokera z 2*2+2 doskonale oddaje problem wielowątkowości, ale wydaje mi się, że należy pisać tak programy, aby jak najkrótsze sekwencje były niezależne, ponieważ wtedy można efektywniej wykorzystać rdzenie (jeden wątek czeka krócej na zakończenie innego), trudno też mówić o niezależności wątków, przeważnie posiadają dostęp do wspólnych danych, dysków, więc długie wątki mogą blokować dane, przez co w związku z integralnością również inne wątki.
Ciekawi mnie na ile ten problem dotyczy wirtualnych maszyn np. java, czy też .NET, co prawda java pozwala pisać programy korzystając z wielowątkowości, ale nie jestem pewien na ile jest to "tłumaczone" na wątki przez maszynę wirtualną.
Jeszcze dodam, że moim zdaniem żaden software czy też hardware nie zrzuci z programisty konieczności zmienienia podejścia do pisania kodu.
leszczo, 22 lipca 2008, 05:23
ta chcial bym zobaczyc plyte glowna z slotem na tysiac rdzeniowy procesor biorac pod uwage iz postep minaturyzacji nie bedzie szedl w nieskonczonosc.
andrew102, 22 lipca 2008, 13:35
postęp miniaturyzacji pewnie i nie będzie szedł w nieskończoność, ale skoro można wyprodukować procesor z setkami milionów tranzystorów, to czemu nie z setkami rdzeni, poza tym pewnie się czepiam ale chyba od czasów inteli trójek (nie wszystkich) nie produkują już procesorów na sloty tylko na gniazda, więc ciężko może być zobaczyć nawet 2 rdzenie na slocie.
leszczo, 22 lipca 2008, 23:25
przyznaje zasugerowalem sie nazwa z angielskiego "socket".
tylko zauwaz ze zblizamy sie do granicy (miniaturyzacji ) gdzie bedzie obowiazywala mechanika kwantowa a nie klasyczna wiec nici z dalszej minaturyzacji wiec obecne rdzenie duzo nie straca na wielkosci wiec tysiac rdzeniowy procesor bedzie pewnie dosc spory.
andrew102, 23 lipca 2008, 01:16
Sądzę, że już teraz bez wzięcia pod uwagę mechaniki kwantowej nie udałoby się tworzenie najnowszych procesorów (mikroskopowy opis zjawisk transportu - przewodnictwo prądu w metalach i półprzewodnikach).
Poza tym kto mówi, że tysiące rdzeni nie będzie właśnie dzięki tranzystorom złożonych z pojedynczych, elektronów.
Sebaci, 23 lipca 2008, 03:41
Na razie mamy 45nm, a zejście do ok. 22nm to zajmie jeszcze dobrych parę lat. Na pewno czekają nas jeszcze procesory 8- i 16-rdzeniowe. A potem to zobaczymy Intel i AMD na razie nie ujawniają planów na dalsze lata. Choć wiem, że Intel majstruje coś z optyką. Także komputery kwantowe to raczej odległa perspektywa, a nawet jak tradycyjne procesory krzemowe wyjdą z użytku, to wejdą optyczne (istnieją jeszcze inne pomysły, takie jak np procesory magnetyczne czy tzw. balistyczne).
A tak w ogóle, nie wszystko sprowadza się tylko do wymiaru technologicznego i ilości rdzeni. Przemyślana architektura jest kluczem do sukcesu (jak w przypadku Core2Duo)... Ważne jest jak zorganizowana jest architektura, jak procesor jest zbudowany. Wcale nie trzeba iść w ilość rdzeni...
A jeśli mowa o procesorach o kilkuset rdzeniach, to czemu miałyby być niemożliwe do skonstruowania? Intel bodajże stworzył 80-rdzeniowy procesor. Bo kto powiedział, że te wszystkie rdzenie mają być tak wielkie jak jeden rdzeń Conroe? Wiele i małe...
I co warto zaznaczyć - w takim wielordzeniowym procesorze przecież każdy z rdzeni nie musi mieć przecież po 2MB cache'u... wspólne L3 o odpowiednio dużej wielkości + osobiste L2 dla każdego rdzenia, o niewielkiej pojemności wystarczy A pewne elementy występują wspólnie dla całego procesora.
Współczesne karty graficzne mają po kilkaset procesorów strumieniowych - shaderów (ich ilość będzie rosła w szybkim tempie wraz z kolejnymi seriami kart). I co, nie można? Można. Mimo że GPU produkowane są w 55 - 65nm.
leszczo, 23 lipca 2008, 17:08
dobrze tylko ze czym schlodzisz te tysiac rdzeni ? powietrze raczej odpada a woda to bys musial miec chyba basen do dyspozycji i nie wiem jaka pompe.
Sebaci, 23 lipca 2008, 19:35
Powietrzem, jak najbardziej! Oczywiście zakładając, że cały chip byłby odpowiednio mały i miał niewygórowane TDP
Karty graficzne chłodzone jakoś są... a shadery w tych szybkich pracują już z zawrotną prędkością ponad 1.5Ghz
andrew102, 25 lipca 2008, 13:48
mi się wydaje, że to przede wszystkim, od ilości tranzystorów, a nie ilości rdzeni zależy moc pobierana przez procesor, no i od częstotliwości, bo nie pamiętam już dokładnie, ale tranzystory w procesorze pobierają energię zdaje się tylko w chwili przełączania stanów, więc czym wyższe taktowanie tym większy pobór. Przy procesorach wielordzeniowych operacje graficzne bardzo prosto można wykonywać na równolegle, więc taktowanie pojedynczego rdzenia może być małe, a biorąc pod uwagę efektywność pracy, jest prawie taka, jakby zsumować częstotliwości wszystkich rdzeni.Co prawda jest w tedy więcej tranzystorów, które potrzebują energii, ale i tak sądzę, że taki układ łatwiej chłodzić, niż jakby pojedynczy rdzeń był taktowany z taką częstotliwością, aby wykonywał pracę układu wielordzeniowego (nie mówiąc o tym, że to jest w sumie nie możliwe).
w46, 25 lipca 2008, 15:54
Nie wszystko trzeba przepisywać na "x-rdzeniowce", wiele aplikacji
spokojnie może działać wydajnie na 1 rdzeniu.
Co innego aplikacje które przetwarzają znaczne ilości danych te mogą wymagać przepisania w celu wyraźnego zwiększenia wydajności.
Dodatkowo obecne trendy w tworzeniu oprogramowania faworyzują aplikacje wysokopoziomowe działające na wirtualnych maszynach (Java, .NET, ...) i w takim przypadku
sama wirtualna maszyna może przejmować rozdział na wiele rdzeni. Swoją drogą kompilatory kodu maszynowego też to mogą wykonywać. Oczywiście są pewne ograniczenia w automatycznym dopasowaniu do wielordzeniowych procesorach (o których przedmówcy wspominają).
Myślę jednak że nie będzie to poważny przełom dla programistów.
andrew102, 27 lipca 2008, 01:43
w aplikacjach biurowych (pomijając hurtownie danych, bazy danych) myślę, że optymalizacja, pod względem wielowątkowości jest nie potrzebna, a mniej lub bardziej stosuje się wielowątkowość, pozwalając na interakcję użytkownika z programem, w trakcie, gdy wykonywane jest w tle inne polecenie, np. transmisja z bazą danych. Co innego we aplikacjach gdzie mamy do czynienia z np. obrazem, możemy przetwarzać w jednym momencie tyle pikseli, ile tylko mamy rdzeni (przy pewnych założeniach). Co pozwala na np. dodawanie efektów w czasie rzeczywistym do materiału video. Myślę, że również obliczenia naukowe, symulacje mogą być nie jednokrotnie prowadzone po części równolegle. Tak więc, myślę, że programistów, którzy muszą pisać przede wszystkim wydajny kod czekają duże zmiany w podejściu do programowania, nie będzie się już liczyć ilość pętli, ale również ich wzajemna niezależność. Co innego programiści aplikacji biurowych w .net, java, etc,