Autor: Jan Rychter (jwr_at_icm.edu.pl)
Data: Sat 11 Nov 1995 - 21:30:46 MET
Grzegorz Szyszlo (ZNIK_at_avalon.wbc.lublin.pl) napisal:
:tak. tylko te testerki szybkosci maja bardzo krotki kod, i im pewnie
:starczyloby do szczescia 64KB, tzn. nie wykazaly by zadnego spowolnienia.
:Niestety karpiu przy systemach wielozadaniowych duzy cache sie naprawde
:przydaje jak przez procesor w kolko przewalane sa coraz to nowe procesy.
:chodzby taki niby "wielozadaniowy" findofze. potrafi sprawnie obsluzyc jedynie
:jedno zadanie, ale tasuje tyle danych przewala przez procesor ze cache
:faktycznie sie przydaje. Zeby przetestowac cache trzeba niestety testera
:ktory jest od niego kilkakrotnie wiekszy. wtedy widac roznice.
... oczywiscie przygladales sie jak wykonuja sie programy pod
roznymi systemami, wiesz jak zorganizowany jest cache (np. co to jest
4-way associativity i tag ram), co w nim jest trzymane, kiedy jest
uniewazniany (flush) i tym podobne, skoro mowisz z taka pewnoscia
siebie takie rzeczy ?
Nie obraz sie, ale 'wielozadaniowosc findofze' (czego bym o takowej
nie sadzil) nie ma tu nic do rzeczy.
A co do testera cache i RAM -- nie ma to jak gcc pod Linuxem. Tworzy
ono olbrzymie ilosci 'rozproszonych' struktur danych ze
wskaznikami. A, jak zapewne Ci wiadomo, proba zapisu pod niewazny
wskaznik powoduje SEGFAULT. Stad tutaj wszelkie przeklamania wychodza
natychmiast. (na ogol jedna kompilacja jadra wystarcza).
Oczywiscie mowie tu o testowaniu _niezawodnosci_ cache a nie
fizycznej szybkosci SRAM. Kazdy wie ze jak sie probuje cache'owac duze
obszary pamieci to wazna jest szybkosc RAM a nie SRAM. Za to duzego
znaczenia nabiera logiczna organizacja cache i sposob jego dzialania.
pozdrawiam,
jwr
_______________________________________________________________________
Jan Rychter jwr_at_itc.pw.edu.pl
http://www.itc.pw.edu.pl/~jwr jwr_at_icm.edu.pl
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 12:26:54 MET DST