Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Współpraca u-Procesora z Pamiecia

cyber48 27 Cze 2008 22:07 1116 5
  • #1 27 Cze 2008 22:07
    cyber48
    Poziom 10  

    Witam !

    Krótkie pytanie z podstaw techniki mikroprocesorowej:

    Jak to jest ze procesor z zegarem np. 1GHz potrafi wspolpracowac z pamięcią która ma czas dostepu o wiele dłuższy niż cykl zegarowy procesora (tutaj ok. 1 ns).. i na odwrot - jak to sie dzieje ze "wolny" procesor np. 8080 potrafi wspolpracowac z "szybką" pamięcią ?

    Jaki warunek musi spełniac procesor a jaki pamięc by ich wspolpraca byla możliwa ? Czy ktos mógłby dokładniej to wyjasnic.. ?

    0 5
  • #2 27 Cze 2008 22:25
    don diego
    Poziom 32  

    Jeśli pamięć nie nadąża, to czeka się odpowiednią ilość cykli zegarowych. Tak jest na przykład w mikrokontrolerach z rdzeniem ARM. Przy dużych częstotliwościach rdzenia ustawia się cykle oczekiwania.

    0
  • #3 28 Cze 2008 00:49
    nsvinc
    Poziom 35  

    Jedno tylko mnie lekko dziwi wlasnie przy takiej technice...

    Skoro rdzen CZEKA na odczytanie danej instrukcji i ich parametrów, to co robi w tym czasie? Bo mnie sie zdaje ze nic nie robi...

    Nawet biorąc pod uwagę prefetch i pipelining, tak czy siak rdzen traci moc gdy musi na cokolwiek czekać - dziwne to jest, przeciez wspomniane metody (caching zreszta tez) nie niweluje w wielu przypadkach definitywnej kichy z predkoscia wykonywania istrukcji...

    Ja akurat nie czaje tego, PO CO rdzen buja sie na gigaherc, skoro pamiec mu wysyła cos co trzeci takt (w najlepszym przypadku) ?....:]

    0
  • #4 28 Cze 2008 01:02
    MirekCz
    Poziom 35  

    Pamięć ma określoną czas na odpowiedź (powiedzmy 10ns).
    Jeżeli procesor jest szybszy, to musi poczekać odpowiednią liczbę cykli zegarowych tak, żeby pamięć zdążyła zwrócić odpowiednie dane.
    To jest powód dla którego nowoczesne procesory mają pamięć cache L1, L2 czy nawet L3. Dostęp do takiej pamięci jest bardzo szybki (jeden-kilka cykli do L1, kilkadziesiąt do L2, sto z groszem do L3), natomiast dostęp do pamięci operacyjnej (głównej) jest dużo wolniejszy - kilkaset cykli.
    Gdyby procesor przy każdym zapisie/odczycie danych miał czekać kilkaset cykli to prędkość jego działania byłaby żałosna.

    W drugą stronę jest zupełnie inaczej. Jeżeli pamięć jest szybsza od procesora to nie ma problemu, bo procesor wysyła prośbę o przygotowanie danych do pamięci i zanim ma szanse je pobrać to te dane już są gotowe i czekają na odbiór. W praktyce jest to nie spotykane, bo procesory generalnie są dużo szybsze od pamięci.

    nsvinc:
    Jest wiele sytuacji, w których procesor się nie buja:
    a) wykonywanie operacji bez odczytywania/z rzadkim odczytywaniem danych z pamięci
    b) niektóre instrukcje zabierają więcej niż jeden cykl zegarowy
    c) prefetch pozwala ściągnąć dane do cache i w ten sposób procesor ma je praktycznie natychmiast w rejestrze
    d) nowoczesne procesory mają po kilka równolegle działających jednostek wykonawczych w jednym rdzeniu i tak jednostka I może robić dodawanie, w tym czasie jednostka II robi mnożenie na liczbach zmiennoprzecinkowych, a jednostka III ładuje jakieś dane z cache L1 do rejestru.
    Na tym polega optymalizacja kodu. Program musi być tak napisany, żeby procesor mógł równocześnie używać kilku jednostek wykonawczych a za razem żeby dane zacząć pobierać na tyle wcześnie, żeby były na czas w rejestrach. Do tego jeszcze dochodzi kwestia organizacji danych (np. z pamieci do L1 wczytywana jest każdorazowo paczka kilkudziesięciu bajtów, więc odczytywanie z pamięci bajtów następujących po sobie jest bardzo szybkie, bo po pierwszym bajcie kolejne x jest w cache, natomiast dowolne skakanie po pamięci jest b.wolne, bo za każdym razem ściągasz dane z najbardziej odległego ramu.

    Inny przykład może być taki, że kiedyś bardzo opłacało się robić tzw. lookup tables - czyli tablice z np. przeliczoną wartością sinusa, żeby nie używać wolnych operacji obliczania sinusa na procesorze.
    Teraz jest to mniej opłacalne lub wręcz nie opłacalne, bo:
    -na procesorze bardzo szybko można obliczyć sinusa, a dodatkowo równolegle mogą być robione inne obliczenia
    -wczytywanie z pamięci jest wolne, względnie wolniejsze niż kiedyś
    -posiadanie dużej tablicy lookuptable w pamięci powoduje, że tablica się ładuje do cache L1/L2 i wypiera stamtąd inne dane. Gdy procesor chce ponownie władować inne dane to okazuje się, że już ich nie ma w cacheu i musi ponownie sięgać do wolnej pamięci zewnętrznej

    0
  • #5 28 Cze 2008 13:19
    Ch.M.
    Poziom 27  

    Idąc w drugą stronę: relatywnie wolny procesor ARM może posiadać sprzętowy sterownik pamięci zewnętrznej i obsługiwać ją tak, jakby ona była wewnątrz jego struktury. Warunkiem jest tutaj posiadanie wbudowanego sterownika, bo na softwarowym zajmie Ci taka sama operacja odczytu/zapisu jakieś 3x więcej czasu plus ewentualne operacje wynikające z przerwania poprzedniego zadania.
    Co do prędkiego obliczania sinusa na procesorze ARM, to nie zgodzę się z tym, wczytanie jest o wiele szybsze i to nawet dla niskich rozdzielczości. Dzieje się tak dlatego, że brakuje w nim koprocesorów matematycznych. Dedykowany uC w kalkulatorze potrafi na o wiele wolniejszym zegarze dokonać tych samych obliczeń w podobnym czasie. Czyli tak jak poprzednio: wbudowany kontroler zajmuje się swoją działką, a CPU dostarcza mu tylko rozkazów i danych.

    Wracając do pytania: warunkiem tym jest sprzętowa implementacja danych rodzai pamięci.
    Pozdrawiam

    0
  • #6 28 Cze 2008 14:43
    nsvinc
    Poziom 35  

    >Ch.M.

    Nie do konca się zgadzam. Moze obecne procesory nie mają super koprocesorów rodem 8087 (ktory zreszta pracował z zegarem 4.77MHz), lecz mają wybitnie rozbudowane jednostki ALU...

    Np. nowe pice32 maja w soie moduł nazwany 'koprocesorem', ktory potrafi matematycznie mnożyć, dzielić i inne cuda...

    Nowe ARMy Cirrusa (jądro ARMv7) posiadają paredziesiąt sprzętowych operacji na liczbach tak samo całkowitych jak i floatach...

    Na takiej jednostce obliczeniowej policzenie sinusa nie będzie zajmować kosmicznej ilości cykli - metody numeryczne polegaja glownie na operacjach podstawowych(+,-,*,/)

    Jednak procki bez takich cudów będą się długo męczyć z prostym dzieleniem wiele taktów - wtedy warto sięgnąć po LUT.

    0