Procesory wielordzeniowe

W dniu niedziela, 5 października 2014 16:30:21 UTC+2 użytkownik A. L. napisał:

No nieee... Byle burok "skapnąłby się", że korzystam z google.groups . Na wygląd postów w Twojej odczytywarce nie mam żadnego wpływu. Może mi powiesz żem Burok bo z GG korzystam? G Ci do tego, nie chcesz to się nie odzywaj. A tak w temacie.. Masz coś do powiedzenia w temacie, czy ino czekasz na krótką linijkę do krótkiej linijki, w której po krótce opiszę to co jest zawarte w głównym wątku.

Miszczu!! Dzięki za wsparcie. Nie umiałem wysłać, a jednak poszło. W końcu odczytałeś geniuszu.

Doradź mi miszczu jeszcze coś. Pytać się o coś na grupach dyskusyjnych, czy raczej nie? Będą tu jakieś porady, czy ino zjeby?

=============

Dobrze dyskutuje się z Bartkiem, można mieć inne zdanie na "coś tam", wymiana poglądów/argumenty, miło się gada.

================

Z Tobą A.L. się nie da. Wyżej ..asz niż ...e masz.

Tak

Idziesz do KF. Permanantnie. Z burakami nie rozmawiam.

A.L.

W dniu niedziela, 5 października 2014 18:19:18 UTC+2 użytkownik A. L. napisał:

Ależ proszę bardzo, jak Guru z erystyką nie daje sobie rady, to najprościej nie słuchać adwersarza.

A odnośnie epitetów, to radzę trochę przystopować. W najlepszym przypadku możesz być Pan postrzegany na grupie w/g użytego przez Pana określenia.

Tymczasem do zobaczenia w KF.

Dzięki temu że pamięć cache jest szybka i lokalna dla rdzenia, nie zajmuje ani trochę czasu. Mechanizm "klasyczny" jest dość prosty. Procesor chcąc odczytać komórkę pamięci wystawia adres na szynę adresową. Ta nie jest podpięta bezpośrednio do pamięci RAM, a do układu zarządzającego cache. Adres jest dzielony na logiczne kawałki: w dużym uproszczeniu wygląda to tak, że najmłodsze bity określają przesunięcie na stronie, a starsze numer strony. Trochę jak intelowe offset i segment, ale sensowniej zrobione. Numer strony jest porównywany z numerami stron ściągniętymi do cache, i jeśli strona jest załadowana, odpowiednia wartość jest zwracana do procesora, a jeśli nie - układ (podkreślam że to jest układ, program nic o tym nie wie) zarządzania cache ściąga stronę z pamięci wyższego poziomu (czyli kolejny poziom cache, albo pamięć RAM.)

Jeśli strona siedzi w cache to cała procedura nie zajmuje nawet jednego cyklu zegara. Dzieje się tak dlatego, że tablica translacji jest zaimplementowana jako pamięć asocjacyjna - taka sprzętowa baza danych adresowana zawartością. Na wejście podajesz numer strony do której się odwołujesz, na wyjściu otrzymujesz albo informację gdzie ta strona jest w cache, albo że jej nie ma. To w którym wierszu tabeli ta informacja jest zapisana nie ma najmniejszego znaczenia.

W nowych procesorach może to wyglądać na sztuczki magiczne, ale magii tam nie ma. Tablica translacji jest uaktualniana przez układ zarządzania cache który wie dokładnie które strony są załadowane do cache i pod jakimi adresami. Ani kompilator ani procesor nie muszą o tym wiedzieć.

To nie kompilator. Ten mechanizm jest wbudowany w krzem. Najprostszy manager cache reaguje na to co procesor chce odczytać i ściąga w razie potrzeby. Doktoraty są robione na "wróżeniu z fusów" które pomoże ściągnąć stronę do cache zanim faktycznie będzie potrzebna.

[...]

To nie jest bełkot marketingowy, a jeden (kilka?) z doktoratów. Nie wiem jak to działa w szczegółach, ale polega mniej-więcej na tym że jak układ sterujący wykonaniem rozkazów widzi w kolejce instrukcję skoku to będzie się starał przewidzieć która strona pamięci będzie potrzebna i zleca układowi cache żeby ją ściągnął. W ostateczności może zawsze upewniać się że dostępny jest kod dla obydwu wariantów, ale to jest bardzo naiwne i nie-ekonomiczne podejście.

Gratuluję odkrycia jednej z najprostszych optymalizacji możliwych do zaimplementowania na etapie projektowania struktur danych :)

Tablica ma rozmiar A x B. Odwołujemy się do elementu (i, j). Adres elementu w przestrzeni liniowej przy zapisywaniu danych wierszami to k = (j * A) + i

Kompilator może tak ułożyć kod żeby podprogram wykonywany przez dłuższy czas w całości zmieścił się w cache. O tym żeby dane były tak ułożone musisz sam zadbać. Poczytaj sobie o cache locality (możesz zacząć tutaj:

kompilator ani Ty nie musicie się przejmować panowaniem nad stronicowaniem. To jest robota układu zarządzania cache zaszytego w krzemie tuż obok rdzenia procesora.

Jak czytam wywody niektórych elektroników to chętnie bym wysłał ich na kurs podstaw inżynierii programowania. Lekkie poszerzenie horyzontów na pewno nie zaszkodzi :)

pzdr. j.

Cytuje: "Wyżej ..asz niż ...e masz." Ja tez radze przystopowac.

Do zobaczenai

A.L.

W dniu niedziela, 5 października 2014 19:50:19 UTC+2 użytkownik Jacek Radzikowski napisał:

Po pierwsze to wielki sorry za wycięcie kupy dyskusji w której brałeś udział. Jak kto chce, niech sobie te wpisy poczyta. W pewnej części zgadzam się z Tobą, w pewnej nie. Ale to duperele, nie warto tutaj sobie zawracać tym głowy. A co się zaś tyczy fragmentu Twojego wpisu, którego nie wycicachałem, no to cóż..

Jak nie wyciachałem, to wypadałoby wdać się w polemikę, a nie jak niejaki AL "idziesz do KF", bo tak każdy dzieciak potrafi.

No to wdaję się w ową. Co było pierwsze? Jajco, czy kura? Hmmm.. Mamy drobny problem..

Co było pierwsze: program, czy komputer ? I co jest ważniejsze? Program czy komputer?

Tak z historycznego punktu widzenia, to chyba najpierw został skonstruowany ENIAC, następnie maszyny typu IBM360/ODRA1305, systemy operacyjne GEORGE2, aż w końcu pojawił się geniusz A.L. , dzięki któremu wylądowałem w kiblu (KF).

Zawsze mi sie wydawalo ze cache trafia linia na nie cala strona. ;-).

j.w. przewaznie zbiorowo asocjacyjna.

Jednej z lepszych algorytmow przewidywanie skokow zaimplementowany w procesorze Citrix byl taki: skok wykonywany jest zawsze :-). I co ciekawe nie odstepowal tragicznie od uwczesnego mu pentium intela ktore (o ile dobrze pamietam) mialo liczniki trafien predykcji.

Mozna tez jak ARMie miec instrukcje ktore sa zawsze przepychane przez pipeline ale z zaleznosci od flagi wykonywane bardz ignorowane.

Stronicowanie ma niewiele wspolnego z cache i bez wsparcia programowego nie dziala. Zdaje sie ze miales co innego na mysli ;-).

Mozna by odniesc wrazenie ze piszesz ogolnie o sprzecie. Nie jest tak dobrze, chociazby bariery pamieci nas w programie nie omina.

Pozdrawiam

Marek

W dniu niedziela, 5 października 2014 20:29:20 UTC+2 użytkownik A. L. napisał:

Brak konsekwencji. Podobno jestem w KF. Do zobaczenia w KF? Weż wyluzuj.. Albo dyskutuj tutaj, albo sam się zkilfajluj.

W cache ląduje całą linia. A jak to jest z transportem w górę? Mamy problemy z false sharing, ale jest on tylko wydajnościowy, jeśli na raz będę zapisywał jednym wątkiem do tablicy w miejscach parzystych, drugim w nieparzystych, poza wydajnością wszystko będzie w porządku. Czyli nie pcham w górę całej linii. Jak to jest sprzętowo? [a do tego kołacze mi się instrukcja MOVNTQ, która wysyła dane do pamięci 'z pominięciem cache']

pzdr bartekltg

Dnia Sun, 05 Oct 2014 22:38:43 +0200, bartekltg napisał(a):

Jakos musieli zrobic, aby dzialalo. Widac te miliardy tranzystorow sa tam nie bez powodu :-)

J.

Zamiast rozwiązywać takie zadziwiające problemy nie lepiej zrobić porządną i szybką pamięć dobrze zinterfejsowaną z cpu? Cray zdaje się używał półokrągłych płyt żeby prąd miał krótszą drogę, ciekawe po co... współczesny PC jest 10x szybszy od craya a płyty główne półokrągłe nie są... Tylko proszę nie używać argumentu "bo tak taniej" - dlaczego rozwój techniki zawszę musi być popychany tanimi rozwiązaniami?

Architektura wieloprocesorowa ze wspolna pamiecia jest poj... z definicji. Zawsze bedzie jakas wspolna magistrala i zawsze problem pamieci.

Lepiej juz bylo. Ptzypominam architekture zwana "transputer" gdzie kazdy procesor mial swoja pamiec, byl fizycnie neizalezny od innych procesorow, a polaczone byly szybkimi (jak na owe czasy) linkami. Architektuar dzialala znakomicie i byla swego czasu bardzo popularna. Spzredawano komputery zawierajace 128 transputerow w niezbyt wygorowanej cenie. Mialem peceta z "koprocesorem" z 16 transputerow. Do dziz nan plytki. Oprawilem sobie niektore w ramki ku pamieci.

Problemy zrownoleglalo sie znakomicie.

Niestety, niefart polegal na tym ze chipy produkowno w Europie. Firma Thomson, a potem Inmos nei mogla sobie poradzic z pprodukcja i wyjsc poza 50 MHz zegar. I caly pomysl szlag trafil

A.L.

Dnia Sun, 05 Oct 2014 17:58:20 -0500, A.L. napisał(a):

Ta wspolna pamiec to roznie moze byc zorganizowana, i chyba roznie jest zorganizowana - np kazdy procesor z wlasna pamiecia, ale dostepna tez dla innych.

IMO to one tanie nie byly, rzeklbym drogie ...

Uzywales ? Ja nie, ale znajomi w tym bardziej siedzieli i mowili ze przy wiekszej ilosci zaczyna zyc wlasnym zyciem.

A to zrownoleglanie ... to ciagle w zasadzie niezalezne komputery, slabo polaczone, bo te linki przestaly byc szybkie, wiec wcale nie tak latwo na to rownolegly program stworzyc.

Mial wiecej niefartow. W zasadzie cala architektura byla bardzo innowacyjna ... tylko pare lat pozniej ta innowacyjnosc okazala sie kula u nogi. Thomson z produkcja chyba jednak wyszedl do Malezji, ale to juz nie przynioslo klientow. Ktorych chyba w ogole bylo malo.

To sie moglo nadawac jako zawansowany uC do sterowania, ale chyba ambicja ich zgubila i zanim to dojrzeli, to sie rynek skonczyl.

J.

Neispecjalnie. Kupowalem z firmy CSA, plytki z proesorem i pameicia, cos kolo 150 dolcow za sztuke.

Nie mialem problemow

Limki byly szybkie, 10 mbps. Mohe sparwdzic, bo cala dokumentacja techniczna stoi na polce

programwoalo sie doskonale, w natywnym jezyku Occam, C, Moduli i pascalu. Zrownoleglalo sie lepiej niz na procesorze ze wspolan pamiecia.

O ile sobie przypominam to chyba nie.

To moglo zmienic spsoob w jaki uzywa sie komputery

A.L.

Dnia Mon, 06 Oct 2014 00:35:23 +0200, Marek napisał(a):

Te polokragle to zdaje byly w czasach, gdy komputer mial rzedu 2m srednicy.

Bo drogie sie zle sprzedaja :-)

J.

On 2014-10-06 00:35, Marek wrote: [...]

Wątpię. Bo istnieją jednak różne Cray-e. :-) Wydajność niektórych liczy się w petaflopach:

współczesny pecet, i to taki lepsiejszy, na i7, to raptem w okolicach

100 gigaflopów wyciąga, np.

I marnuje te gigaflopy diabli wiedzą na co. Dla mnie, zaczynającego zabawę z komputerami 30 lat temu widok, że byle GoogleDriveSync zajmuje 107MB pamięci jest niewyobrażalną grozą :(

Mam komputer pracujący teoretycznie tysiące razy szybciej niż pierwszy PC, na którym pracowałem 27 lat temu. Programy jednak uruchamiają się wolniej - nawet dysk SSD nie jest w stanie nadgonić absurdalnego rozrostu nawet najbanalniejszych programów - jest ledwie 500 razy szybszy od starego MFM a rozmiary programów wzrosły szybciej :(

Ale to bardziej wina sposobu programowania niż architekty. Za czasów DOSa programiki były znacznie mniejsze, a 486 to przecież ten sam komputer;-)

Widać czas klientów nie jest na tyle cenny, by chciali zapłacić za szybszy program. TO mają skrypty ptthona odpalone w wirtualnej maszynie JAVA ;-)

Goła obróbka danych jest szybsza tyle, ile trzeba. Mulą interfejsy.

pzdr bartekltg