>
> Eeee, obecne kontrolery pamieci sa tak skonstruowane ze pojedynczego bajtu
> nie przeczytasz z pamieci tylko duzo wiecej.
Przeczytać to może tak, ale nie zapisać. Po to jest tzw. "maska" (linie DM).
Przecież jeśli chcesz zmienić jeden bajt to musiałbyś robić
read-modify-write, a tak robisz tylko write.
> Nie tylko benchmarki czytaja pisza losowo pojedyncze bloki (czyli
> nie-bajty ;-), optymalizowalismy duzo softu wlasnie na losowe read/write i
> zwlaszcza algorytmy sortujace moga miec tych losowosci bardzo duzo.
A jak dużo tych danych sortujesz? Nie tylko sortowaniem aplikacja się
zajmuje.
>
> Wydaje mi sie ze nie ma czegos takiego jak "normalne" oprogramowanie i z
> tym cache'em to chyba przesadziles. Ja oceniam ze ok. 50% softu, ktory
> dostajemy do optymalizacji ostro jezdzi po pamieci i cache jest za maly
> zeby zmiescic odpowiednie dane.
Zgadza się, ale najczęściej soft w krótkich odcinkach czasu operuje dość
intensywnie na małych ilościach danych, cache ma tu duże znaczenie.
Wyjątkowe sytuacje to np. soft bazodanowy gdzie sortowanie indeksów zajmuje
dość dużo czasu.
> Dodatkowo nawet jezeli dane mieszcza sie w cache'u to mozna okropnie
> pogmatwac sprawe i spowolnic wszystko nawet ponad 10x jezeli w
> nieodpowiedni sposob operuje sie na tych danych, ZWLASZCZA przy losowym
> R/W
>
To już jest zmartwienie Intela/AMD (algorytmy predykcji itp).
Received on Thu Aug 31 13:10:11 2006
To archiwum zostało wygenerowane przez hypermail 2.1.8 : Thu 31 Aug 2006 - 13:51:33 MET DST