Systemy operacyjne

Linux poradzi sobie z wielordzeniowoscią

Tomasz  | Redaktor serwisu benchmark.pl
Autor: Tomasz
21 komentarzy Dyskutuj z nami

Zegary procesorów już dawno przestały przyspieszać. Teraz producenci oferują nam za to coraz większą liczbę rdzeni, która niedługo będzie liczona w dziesiątkach. Czy systemy oparte na platformie Linux są gotowe na nadejście tak złożonych układów?

Pytanie to jest o tyle bardziej istotne, że Linux dominuje na komputerach pełniacych rolę serwerów, tam też kolejne rdzenie dodawane są najszybciej. Zespół z MIT (Massachusetts Institute of Technology) przeprowadził eksperyment, który dał interesującą odpowiedź. 

  Warto przeczytać:
 

Stworzono system, w którym ośmiordzeniowy procesor symulował zachowanie jednostki o 48 rdzeniach. Następnie stopniowo uruchamiane były kolejne rdzenie wirtualne. Po jakimś czasie okazało się, że zwiększanie ich liczby nie powoduje wzrostu wydajności, a wręcz przeciwnie - spowalnia system. Okazuje się, że to zjawisko można w prosty sposób wytłumaczyć. Otóż w systemach wielordzeniowych wiele jednostek na raz operuje na tym samym fragmencie danych. Tak długo, jak te dane są potrzebne, nie należy ich usuwać z pamięci. Odpowiada za to centralny licznik, który jest zwiększany przez aktywne rdzenie i zmniejszany, gdy informacja przestaje być im potrzebna. Gdy osiągnie wartość zero, miejsce w pamięci jest zwalniane.

Okazuje się, że gdy rośnie liczba rdzeni, każdy z nich wykonuje coraz mniejszą część zadania, a coraz więcej czasu zajmuje samo ustawianie tego licznika. Dla większych wartości sam narzut na sychronizację pochłania znaczną część mocy obliczeniowej.

 

 

Programistom udało się po niewielkich modyfikacjach kodu sprawić, że system poradził sobie z tym problemem. Wystarczy, że każdy z rdzeni będzie przechowywał własny licznik dostępu do zasobu, a synchronizacja będzie następować tylko od czasu do czasu. Pozwoliło to znacząco poprawić wydajność procesora i w efektywny sposób wykorzystać wszystkie 48 rdzeni.

"Badania pokazują, jak skaluje się system w chwili obecnej" - komentuje Frans Kaashoek, profesor kierujący grupą wykonująca eksperyment - "Fakt, że główna przeszkodą w skalowaniu okazał się licznik mówi nam, że wiele problemów zostało już rozwiązanych. Oczekiwalismy, że trudności będą znacznie poważniejsze. Wystarczy tylko poprawić sposób liczenia referencji, z czym społeczność linuksowa spokojnie da sobie radę." I dodaje: "Sam fakt, że problem był łatwy do rozwiązania nie oznacza, że łatwo było go odnaleźć. To jednak tylko hipoteza, którą twórcy Linuksa będą musieli sprawdzić na rzeczywistych systemach."
 

 

Z kolei profesor Remzi Arpaci-Dusseau tak komentuje wyniki prac - "Głównym pytaniem, na które będą musieli odpowiedzieć twórcy systemu, jest to, co zrobią z systemami, w których liczba rdzeni zdecydowanie wzrośnie. Konieczne może być całkowite przeprojektowanie systemu wedle nowej architektury. Opracowany raport jest pierwszą próbą rozwiązania problemu w sposób naukowy."

Miłośnicy linuksa moga więc być spokojni, podobnie jak nabywcy procesorów wyposażonych w coraz większą liczbę rdzeni.
 

Źródło: Physorg

Polecamy artykuły:    
Przegląd rynku: obudowy PC
5 x SSD i 1 x HDD - praktyczne testy dysków
100 porad do Windows 7

 

Komentarze

21
Zaloguj się, aby skomentować
avatar
Dodaj
Komentowanie dostępne jest tylko dla zarejestrowanych użytkowników serwisu.
  • avatar
    Konto usunięte
    "Czy systemy oparte na platormie" - Platformie : ] literóweczka.
  • avatar
    Irrlicht
    Radzenie sobie z wielowątkowością to jest całkiem ciekawe wyzwanie intelektualne dla programistów nie tylko linuksowych. Kod pisany bez myślenia o wielowątkowości czasem się nawet do przerobienia na wielowątkowy nie nadaje. Tutaj pokazano że zrównoleglenie na kilka wątków to jest nieco inna bajka niż zrównoleglanie na naprawdę wiele wątków.

    IMO przydałoby się mieć języki programowania z wbudowaną paralelnością, w miarę kompatybilne z tym co już jest popularne (C, C++, ...) i szeroko akceptowane w środowisku programistów. Bo używanie bibliotek (pthreads, MPI) czy innych "przybudówek" typu OpenMP to jednak ma sporo wspólnego z dawnymi, urokliwymi czasami, kiedy się pisywało wstawki w assemblerze.
  • avatar
    atheros
    Nie ma co narzekać. Większość aplikacji nie potrzebuje masywnej wielowątkowości. Z założenia motto aplikacji unixowych to rób tylko jedno, ale bardzo dobrze. Tak więc typowo mamy 100 procesów, w większości jednowątkowych, i wąskim gardłem robi się samo jądro, które dzieli zasoby między nimi.

    A co do języków programowania, powstało GO, które może coś ciekawego wniesie (sam chyba dzisiaj go spróbuję).

  • avatar
    cyferluu
    szkoda ze wielordzeniowość/wielowątkowość nie działa jak dyski w raid, albo karty graficzne w sli.

    masz 2 dyski i dzielą się po połowie wiec każdy ma 2 razy mniej do przerobienia :D

    nie był by świat prostszy?

    masz 1 rdzeń to on liczy całość, masz 2 rdzenie każdy liczy tylko połowę, masz 4 wiec każdy zajmuję się ćwiartką w stosunku do jednordzeniowca.

    masz 1L vodki
    wypijesz samemu to leżysz
    wypijesz z kumplem leżycie ale vodka kończy sie 2x szybciej
    wypijesz z 3 znajomymi to idziecie po kolejną butelkę :D

    takie moje bujanie w obłokach
  • avatar
    Konto usunięte
    Nie wiem jak działa zarządanie pamięcią w linuksie, ale co do osbsługi wielu rdzeni, wielowątkowości i wielu procesów, to linuks jakieś 4-5 lat temu, nie pamiętam dokładnie, ma nową szybszą biblioteke do obsługi takich wnalazków. I przynajmniej w tej kwestii wielu problemów być nie powinno.

    Skalowalność też zależy od architektury na jakiej pracuje system.

    A przełączanie zadań, kiedy i jak, to całkiem osobny problem. ;)

    A problem jest tego typu że czasem operuje sie na tych samych danych a czasem nie na tych samych ;) I to co najlepsze dla jednego nie koniecznie musi być dobre dla drugiego.

    Dlatego np w kernelu istnieje kilka opcji które można dostosować, takie jakie nam pasują.
  • avatar
    jeomax.co.uk
    A ja troche poczytalem zrodlo i wydaje mi sie, ze ktos zaczal belkotac. Fakt, ze niby to z biura prasowego MIT-u, niemniej jak na tak powazna uczelnie, przydaloby sie wiecej szczegolow (co to jest ten licznik umiejscowiony w centralnej lokacji - mi to brzmi jak PC w CPU, ale z gory wiadomo, ze tym byc nie moze, bo PC dotyczy rozkazow, nie danych).
    Poza tym, co z linuksami, ktore stoja na dotychczasowych klastrach i superkomputerach, a obsluguja multiCPU wieksze od 48 rdzeni ? Przeciez one funkcjonuja juz od dawna...
  • avatar
    NomadDemon
    ale ja albo nie widze, albo nie ma nic napisane o arch procesora, bitach, ani o niczym...
  • avatar
    anglik666
    TA, przecież na świecie są setki serwerów linuxowych z ponad tysiącami procesorów i co, one są wolniejsze ?
  • avatar
    anglik666
    Tak, ale po co emulować 48 rdzeni za pomocą 8, jeśli za przyzwoite pieniądze można kupić płytę z 4 gniazdami pod Opterony serii 6000 i ma się rzeczywistą liczbę rdzeni równą 48, cały ten news brzmi jak sprzed kilku lat... Prywatni ludzie używają takich kompów do obliczeń rozproszonych i linux dobrze sobie tam radzi... Można zajrzeć choćby tu:
    http://foldingforum.org/viewtopic.php?f=55&t=14757
  • avatar
    NomadDemon
    linux sprzetem bardzo dobrze zarzadza, jedynie sterowniki graficzne troszke kuleja, ale ram,procesor i peryferia dzialaja super
  • avatar
    Konto usunięte
    Czym innym jest obsługiwać czy widzieć z poziomu systemu wiele wątków, a czym innym jest wykorzystać efektywnie ich wydajność. Przy wielu wątkach dochodzi narzut na rozdzielenie zadań, synchronizację, równoległy dostęp do pamięci (lokowanie, oczekiwanie wątku na inny wątek) itp. Pomijam sam problem rozdziału zadania na wątki, bo to nie zawsze jest możliwe i efektywne.

    > Zegary procesorów już dawno przestały przyspieszać.

    Proponuję aby autor:

    - rozróżnił zegar od wydajności, bo to nie zawsze idzie w parze,
    - zapoznał się z procesorami innych producentów niż Intel i AMD. IBM jakoś jest w stanie przyspieszać zegar i osiąga 5.2 GHz i oszałamiającą wydajność pojedynczego wątku. Aplikacja działa wtedy szybciej bez jakiejkolwiek ingerencji w kod.