Tak w kwestii formalnej 'Każdy poziom pamięci podręcznej jest i tak znacznie szybszy od nawet najszybszego RAM-u'. Powinno być DRAM-u zamiast RAM-u, jako że cache to zwykle SRAM ;]
Tak czy siak dobra robota, wreszcie można się przekonać naocznie gdzie i kiedy przydaje się cache.
Mogli by dawać więcej L2/L3 na osobnym kawałku krzemu na tej samej płytce co CPU. SRAM względem DRAM wymaga około 4 razy więcej tranzystorów. Mimo to warto, brak potrzeby odświeżania ma duże plusy. Dodatkowo między CPU i Cache było by do 1cm odległości zatem znacznie lepiej jak do RAM, gdzie jest 10 razy tyle. A wiadomo jak opór elektryczny zależy od odległości
Czy można procesor nauczyć przewidywania (predykcji) rozgałęzień kodu? Wyobraźmy sobie sytuacje, że uruchamiamy swoją ulubioną grę/program, za pierwszym razem procesor gromadzi w jakiś pliku wskazówki co do rozgałęzień kodu, za drugim uruchomieniem gra chodzi już szybciej. Realne?
Czy można procesor nauczyć przewidywania (predykcji) rozgałęzień kodu? Wyobraźmy sobie sytuacje, że uruchamiamy swoją ulubioną grę/program, za pierwszym razem procesor gromadzi w jakiś pliku wskazówki co do rozgałęzień kodu, za drugim uruchomieniem gra chodzi już szybciej. Realne?
Raczej nie. Chyba, że za każdym razem gra robiłaby dokładnie to samo. Problem z przewidywaniem jest w wielu miejscach i nie jest to taka prosta sprawa, jak to może wyglądać. Polecam poczytać chociażby: http://wazniak.mimuw.edu.pl/index.php?titl...w_komputerowych
Pamiętam w podstawówce jakieś 18 lat temu mówili nam o tym jak ważny jest cache. Dlatego biorąc 4 lata temu laptopa brałem ten z procem o największej ilości cache (4MB). To logiczne ze na końcu jest RAM, a potem dysk.
Mam procesor Core 2 Duo E8200 z 6 MB pamięci podręcznej Cache L2. Co mogę powiedzieć, że wcześniej miałem Dual Core E5300 i widać było różnicę w wydajności. Pamięć podręczna jest ważna w dzisiejszych procesorach !
Kto się zgadza, to dawać + i ocenę !
Niestety mam inne wnioski po przeczytaniu CAŁEGO testu O ile w starszych konstrukcjach wzrost wydajności był wyraźnie odczuwalny (10%+) to już w najnowszych procesorach nie ma sensu dopłacać do dodatkowych MB pam. podręcznej - między 6 a 8 różnice wydajności są mniej niż marginalne.
Dodatkowo wygląda na to iż pchanie więcej niż 8MB może powodować zauważalne spadki wydajności w aplikacjach.
Czy można procesor nauczyć przewidywania (predykcji) rozgałęzień kodu? Wyobraźmy sobie sytuacje, że uruchamiamy swoją ulubioną grę/program, za pierwszym razem procesor gromadzi w jakiś pliku wskazówki co do rozgałęzień kodu, za drugim uruchomieniem gra chodzi już szybciej. Realne?
Raczej nie. Chyba, że za każdym razem gra robiłaby dokładnie to samo. Problem z przewidywaniem jest w wielu miejscach i nie jest to taka prosta sprawa, jak to może wyglądać. Polecam poczytać chociażby: http://wazniak.mimuw.edu.pl/index.php?titl...w_komputerowych
Oczywiście nie chodziło mi o cała grę ( by trzeba było ją przechodzić jak po sznurku), ale o części ( pewne partie) kodu.
Niestety mam inne wnioski po przeczytaniu CAŁEGO testu O ile w starszych konstrukcjach wzrost wydajności był wyraźnie odczuwalny (10%+) to już w najnowszych procesorach nie ma sensu dopłacać do dodatkowych MB pam. podręcznej - między 6 a 8 różnice wydajności są mniej niż marginalne.
Musisz pamiętać, że w przypadku Sandy Bridge'a tej pamięci jest relatywnie i tak dużo, więc i zysk jest niewielki. Moim zdaniem Twój wniosek jest zbyt daleko idący.
aY227 @ 2012.12.03 15:46
Dodatkowo wygląda na to iż pchanie więcej niż 8MB może powodować zauważalne spadki wydajności w aplikacjach.
Nie obserwuję tego na podstawie wyników Core i7-3820.
Widać że i5 oraz i7 to genialne procesory - model z mniejszą pamięcią L3 prawie wcale nie ustępuje temu z 8Mb. Widocznie intel ma bardzo dobre mechanizmy 'pobierania z wyprzedzeniem'. Bardzo duży '+' za artykuł
Raczej nie. Chyba, że za każdym razem gra robiłaby dokładnie to samo. Problem z przewidywaniem jest w wielu miejscach i nie jest to taka prosta sprawa, jak to może wyglądać. Polecam poczytać chociażby: http://wazniak.mimuw.edu.pl/index.php?titl...w_komputerowych
Oczywiście nie chodziło mi o cała grę ( by trzeba było ją przechodzić jak po sznurku), ale o części ( pewne partie) kodu.
Na pierwszy rzut oka: więcej zachodu niż korzyści. Naprawdę polecam poczytać, jak działa procesor i wtedy będzie wiadomo, że trudno jest przewidywać między innymi z powodu skoków (funkcji, pętli, if-ów itp).
Jest jeszcze jedno - w GCC kompilacja z '-march=native' uwzględnia rozmiary i typy cache'u przy kompilacji do optymalnego rozłożenia kodu i danych w pamięci. Jest to widoczne na przykład w rozwijaniu pętli (loop unroll) - rozwija się je tylko tyle, żeby się zmieściły w icache. Jak przekroczy się granicę, wydajność drastycznie spada. Z drugiej strony za słabo rozwinięta pętla nie wykorzystuje w pełni potoku. A to tylko jeden aspekt.
W benchmarkach lepiej wypadały procesory, dla których typ i rozmiar cache odpowiadały temu użytemu do kompilacji
Tak czy siak dobra robota, wreszcie można się przekonać naocznie gdzie i kiedy przydaje się cache.
Odnoszę wrażenie, że czym nowsza gra tym gorzej działa bez cache - mam rację?
Raczej nie. Chyba, że za każdym razem gra robiłaby dokładnie to samo. Problem z przewidywaniem jest w wielu miejscach i nie jest to taka prosta sprawa, jak to może wyglądać. Polecam poczytać chociażby: http://wazniak.mimuw.edu.pl/index.php?titl...w_komputerowych
Pioy był blisko, ale Ty trafiłeś
Kto się zgadza, to dawać + i ocenę !
Niestety mam inne wnioski po przeczytaniu CAŁEGO testu
Dodatkowo wygląda na to iż pchanie więcej niż 8MB może powodować zauważalne spadki wydajności w aplikacjach.
Raczej nie. Chyba, że za każdym razem gra robiłaby dokładnie to samo. Problem z przewidywaniem jest w wielu miejscach i nie jest to taka prosta sprawa, jak to może wyglądać. Polecam poczytać chociażby: http://wazniak.mimuw.edu.pl/index.php?titl...w_komputerowych
Niestety mam inne wnioski po przeczytaniu CAŁEGO testu
Musisz pamiętać, że w przypadku Sandy Bridge'a tej pamięci jest relatywnie i tak dużo, więc i zysk jest niewielki. Moim zdaniem Twój wniosek jest zbyt daleko idący.
Dodatkowo wygląda na to iż pchanie więcej niż 8MB może powodować zauważalne spadki wydajności w aplikacjach.
Nie obserwuję tego na podstawie wyników Core i7-3820.
Raczej nie. Chyba, że za każdym razem gra robiłaby dokładnie to samo. Problem z przewidywaniem jest w wielu miejscach i nie jest to taka prosta sprawa, jak to może wyglądać. Polecam poczytać chociażby: http://wazniak.mimuw.edu.pl/index.php?titl...w_komputerowych
Na pierwszy rzut oka: więcej zachodu niż korzyści. Naprawdę polecam poczytać, jak działa procesor i wtedy będzie wiadomo, że trudno jest przewidywać między innymi z powodu skoków (funkcji, pętli, if-ów itp).
W benchmarkach lepiej wypadały procesory, dla których typ i rozmiar cache odpowiadały temu użytemu do kompilacji