Re: Latency vs. predkosc - co ma wieksze znaczenie dla Core 2 Duo E6600

Autor: uC <uC_at_bla.bla>
Data: Thu 31 Aug 2006 - 22:16:18 MET DST
Message-ID: <ed7g28$tfu$1@news.dialog.net.pl>
Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=response

"Paweł Cern" <imie@nazwisko.pl> wrote in message
news:5c8c0$44f72b35$3eb3255a$16084@news.chello.pl...
> >
>> Kontroler w procach AMD nie ma linii DM, i takowe linie w chipach pamieci
>> podpina sie do DQS...
>
> Że co proszę? :))))) Powiedz to komukolwiek kto pamięciami DDR się zajmuje
> to cię śmiechem zabije. Jeśli sterownik nie używa DM to można je podpiąć
> TYLKO I WYŁĄCZNIE do masy. Ale rozwiązanie to będzie dość mało optymalne -
> zmiana pojedyńczego bajtu pamięci będzie wymagać odczytu i zapisu.

Tak jest wlasnie zbudowany kontroler pamieci w procesorach AMD64 (odsylam do
dokumentacji).
Oczywiscie ze do masy, przepraszam za niescislosc - to pozostalosc z czasow
kiedy projektowalem hardware i druk do niego i dla mnie masa to tez
zasilanie ;-)

>> A skad wiesz ze "najczesciej"?
>
> Przede wszystkim trzeba wiedzieć że procesor operuje nie tylko na danych
> ale i na kodzie (przypominam że "kod" to takie dane dla procesora, żeby
> wiedział co robić :). Rzadko spotyka się kod który składa się wyłącznie ze
> skoków. NAJCZĘŚCIEJ zawiera pętle które składają się z rozkazów
> umieszczonych sekwencyjnie na małych obszarach pamięci. Dlatego kod
> cache-uje się najłatwiej. Podejrzewam że statystycznie conajmniej 50%
> odwołań do przestrzeni pamięci dotyczy kodu, dlatego zakładam że
> "najczęściej".

Akurat wspolczesne procesory (komputerowe) nie maja problemow z cachowaniem
kodu, bo ten zajmuje relatywnie malo miejsca i istnieja odpowiednie
mechanizmy zajmujace sie "zarzadzaniem" kodem. To nie kod jest problemem,
ale dane w odwolaniach do pamieci i to jest fakt!

>> NIe, to jest w bardzo duzym stopniu zmartwienie programisty, a poniewaz
>> wiekszosc programistow nie wie jak dziala hardware mamy tak wielu
>> klientow
>
> Mam wrażenie że programista czasami może nie mieć pojęcia na jakim
> sprzęcie (procesorze) klient uruchomi oprogramowanie. Przecież obecne
> procesory zgodne z X86 czy też AMD64 różnią się.

...i to bardzo i dlatego jest tak duzo zlego softu (czytaj wolnego,
wykorzystujacego kilka procent mozliwosci komputera). Dobre oprogramowanie,
ktore szczegolnie intensywnie liczy (czyli wbrew pozorom duzo codziennych
programow) zazwyczaj robi (powinno) detekcje procesora i podstawia
odpowiednia biblioteke zawierajaca kod zoptymalizaowany pod dany
procesor/platforme (czasami nawet pod stepping procesora). Oczywiscie chodzi
o kod najbardziej krytyczny a nie o caly program.

Pzdr.,

-- 
uC
www.ultracode.eu
Received on Thu Aug 31 22:25:07 2006

To archiwum zostało wygenerowane przez hypermail 2.1.8 : Thu 31 Aug 2006 - 22:51:33 MET DST