W dniu niedziela, 5 października 2014 11:01:21 UTC+2 użytkownik Jacek Radzikowski
napisał:
> s...@g...com wrote:
>
>
>
> > W dniu niedziela, 5 października 2014 01:47:28 UTC+2 użytkownik Jacek
>
> > Radzikowski napisał:
>
> >
>
> >> Jak już wspomniał Andrzej, w takim przypadku strona pamięci z danymi
>
> >>
>
> >> zostanie przepisana do pamięci cache i problem jednoczesnego dostępu do
>
> >>
>
> >> zewnętrznej kostki przestanie istnieć.
>
> >>
>
> >
>
> > Dlaczego?! Cóż tam za magia jest zaszyta w tym cache'u, że pozwala na
>
> > jednoczesny dostęp do dwóch albo i więcej(ilość rdzeni/wątków) adresów
>
> > jednocześnie?
>
>
>
> L1 jest najczęściej do wyłącznego użytku rdzenia. A jeśli nie - to działa
>
> mechanizm identyczny do opisanego. Z tą drobną różnicą że pamięć cache jest
>
> o wiele szybsza i przestoje są krótsze.
>

OK, czas dostępu do cache jest argumentem przekonywującym. Zapomnijmy na chwilę o
wielowątkowości/wielordzeniowości. A co w przypadku jeżeli mamy program, którego kod
znacznie objętościowo przekracza pojemność cache'a? A z reguły tak jest. No i teraz w
wyniku działania programu przy spełnieniu jakiś tam warunków mamy dłuuuugie skoki do
innej części kodu? Nie mam zamiaru się tutaj wymądrzać i deprecjonować sensu
pakowania cache'a do procka, ale czy zawsze ten mechanizm jest porządany? No bo w
przypadku dłuuugich skoków o ile dobrze rozumiem pamięć cache powinna być
przeładowana na nowy obszar kodu. No a to przeładowanie, to jakby na to nie patrzeć
zaś komunikacja z pamięcią zewnętrzną, a co za tym idzie zaś trzeba na to trochę
czasu... Bilans zysków i strat wydaje mi się może być przy spełnieniu pewnych
warunków wręcz niekorzystny. Tak se gdybam...