Re: Celeron 466 a 533 [długie, nudne, zły (?) tok myślenia :^) ]

Autor: Radoslaw Sokol (rsokol_at_magsoft.com.pl)
Data: Wed 04 Sep 2002 - 10:44:10 MET DST


Hi,

Witold Władysław Wojciech Wilk wrote:
>
> [...]
> ale żem się rozpisał. mam nadzieję, że tego za bardzo nie pokićkałem :^)

Na razie udowodniłeś, że wyższa przepustowość magistrali oznacza
większą wydajność :) Tego zaś nikt nie kwestionuje :)

Wracając zaś do zwiększania transferu pamięci wraz ze wzrostem
mnożnika. Pomyśl o takim programiku mierzącym:

test: MOV EBX, 0
       MOV ESI, (adres poczatkowy)
loop1: MOV ECX, 1024
       REP LODSD
       INC EBX
       CALL minelasekunda
       TEST EAX, EAX
       JNZ loop1
       MOV EAX, EBX
       RET

To superprymitywny i niezbyt dokładny program, ale powinien
być dobrym przykładem. Zakładam tutaj, że gdzieś wcześniej
znajduje się wyłączenie cache L2, a całość działa w trybie
32-bitowym bez kontroli żadnego systemu operacyjnego.

Jedynie jedna instrukcja (pracująca w pętli) zajmuje się odczytem
32 bitów danych z pamięci. Pozostałe jednak kiedyś muszą się
wykonać :) Nawet zakładając właściwą predykcję końcowego skoku
oraz pełną potokowość wykonania programu (1 cykl na 1 instrukcję;
założę, że podprogram minelasekunda wykonuje się np. 15 cykli)
będzie widać różnicę między procesorem 2x66 a 4x66 -- po 1024
odczytach pamięci nastąpi w końcu 20 cykli pracy bez kontaktu
z pamięcią (a więc 10 cykli magistrali przy mnożniku 2x), po czym
znów 1024 cykle odczytu (512 cykli magistrali, bo cache L1
zapełnia się od razu 64 bitami danych -- pomijam tu też
czas potrzebny na początku na skonfigurowanie strony pamięci
SDRAM). W efekcie na 1024 odczyty potrzeba 1034 cykli -- już
od razu się traci 1% przepustowości przy tak prostym programie.
Procesor z mnożnikiem 4x straci tylko pięć cykli magistrali
zamiast dziesięciu.

Przy wyższych mnożnikach różnica się praktycznie zatraci, ale
przy bardziej skomplikowanych programach może dalej się ujawniać,
ograniczając transfer pamięci.

Oczywiście sprawę mocno poprawia fakt istnienia pamięci cache
L1 pracującej z pełną prędkością procesora i napełnianej pełnymi
liniami. Jednak przy losowym odczycie (ten program nie powinien
tak naprawdę czytać sekwencyjnie tylko skakać po pamięci, np.
za każdym razem o 64 KB) cache przestanie zupełnie funkcjonować
dla danych (pozostając aktywnym dla kodu -- wyłączenie cache dla
kodu spowodowałoby tragedię wydajnościową).

Maksymalny teoretyczny transfer pamięci jest więc zależny tylko
od FSB i ma znaczenie przy zapełnianiu linii cache. Maksymalny
praktyczny transfer pamięci zależy głównie od algorytmu programu.

-- 
|""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
| Radosław Sokół  |  mailto:rsokol_at_magsoft.com.pl          |
|                 |  http://www.magsoft.com.pl/~rsokol/    |
\................... ftp://sokol.gliwicki.necik.pl/ ......./


To archiwum zostało wygenerowane przez hypermail 2.1.7 : Wed 19 May 2004 - 01:27:26 MET DST