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

Autor: Paweł Cern <imie_at_nazwisko.pl>
Data: Wed 06 Sep 2006 - 18:03:20 MET DST
Message-ID: <4288f$44fef146$3eb3255a$8893@news.chello.pl>

>>
>> Oczywiście że nie, szyna jest 128-bitowa ale niekoniecznie całe 128 bitów
>> bierze udział w transakcji. Determinuje to maska.
>
> Wydaje mi sie ze nie przeczytales jednego z moich poprzednich postow!
> Linie maski nie sa we wspolczesnych procesorach x86 podpiete. Intel kiedys
> w niektorych wersjach chipsetow serwerowych je podpinal ale to juz dawno
> nieaktualne. Wiec cale 128 bitow bierze udzial w transakcji.
>

To jakim cudem karty PCI ze starszych komputerów dalej działają? Przecież
odwołanie do rejestru urządzenia peryferyjnego (nawet odczyt) zmienia stan
urządzenia. Zatem odwołanie do rejestrów sąsiednich podczas gdy chcemy
czytać/pisać jeden, byłoby niepożądane i powodowałoby nieprawidłową pracę
urządzenia.

>>
>> To dlaczego ludzie płaczą że DDR-y 533 na niskich timingach są czasami
>> szybsze niż 800-ki? I to nie zawsze, zależy od testu.
>
> Nie rozumiem co masz na mysli?
>

To że niektóre pamięci DDR533 mają czas dostępu (nie mylić z okresem
transferu wiązkowego!) krótszy niż DDR800. I tak np. CAS latency = 5 przy
800MHz oznacza opóźnienie rzędu 6,25ms a CAS latency = 3 przy 533MHz oznacza
około 5,63 ms. Do tego dochodzi jeszcze RAS to CAS delay itp. Okaże się, że
przy transferze wiązkowym 8 słów DDR800 wykona to szybciej, ale przy 2
słowach DDR533 będzie szybszy.

>>...W 16-bitowych x86 miałeś AX i mogłeś ładować na raty, AH i AL.
>
> A w 8-bitowych i to niekoniecznie x86 byly rejestry 8-bitowe i mialoby to
> cos udowodnic? Ja pisze o wspolczesnych procesorach 32/64 bitowych.
>

Miało, niekoniecznie cały rejestr musi brać udział w operacji.

>
> Co nie zmienia faktu ze ze kontroler i tak zawsze odczyta pelna linie
> cache'u w AMD (64 bajty) lub sektor cache'u w Intelu (128 bajtow) o czym
> pisalem wczesniej.

Niezawsze, inny uczestnik dyskusji już to uzasadnił. Instrukcje sterujące
cache także służą do optymalizacji programu.
Received on Wed Sep 6 18:05:08 2006

To archiwum zostało wygenerowane przez hypermail 2.1.8 : Wed 06 Sep 2006 - 18:51:06 MET DST