Niby prawda, ale cały artykuł jest bardziej naukowy niż praktyczny (co nie jest zarzutem, wręcz przeciwnie). Ciekawi mnie, ile straciliśmy na decyzji AMD o obcięciu pamięci podręcznej FXa 4300 (FX-41xx miał pełne 8MB).

Po co uczyć - procesory już to umieją. Przewidywanie skoków ze sprawnością 90% to nic niezwykłego we współczesnych procesorach.

O kurcze...
Świetny art. Faktycznie nie ma sensu niby testować FX4300 vs FX63/83...

To potwierdza moje obserwacje na temat tego, że generalnie większy cache głównie przydaje się do tych najtrudniejszych zadań. Np. w renderingu jest różnica pomiędzy procesorami z większym cachem, ale.... no właśnie nie w prostej siatce nawet high-poly.
Ciekawe, że A10 wydajne tak samo jak FX...

Najważniejszy problem o jakim trąbie od dawna jest to, że właśnie....
....może zamiast większej kaszy dać więcej rdzeni.

W przypadku Vishera widzę, że można by wcisnąć jeszcze dwa moduły zamiast L3. Takie rozwiązanie dałoby AMD odpowiednią wydajność do rywalizacji z intelem na polu serwerowym.

Nieee no. Mojej opadającej szczęki nie mam co szukać na podłodze, bede musiał iść do sąsiada piętro niżej . PC Labowcy ostatnio czytają w myślach czytelników. Czyżbyście zdobyli kryształową kulę renderująca myśli czytelników w DX11 i dzięki temu tak skutecznie je interpretujecie???

To to ja wiem Chodziło mi o to, że takowy test przekaże nam wiedzę czysto teoretyczną, bo w praktyce nie będzie takiego procesora (najpewniej). O to mi chodziło, bo tak to oczywiście można było i przetestować Core i7-2600K z dwoma rdzeniami bez HT na 3 GHz i porównać do Pentiuma G860

Raczej niezbyt realne, bo instrukcje są zaszyte w strukturze fizycznej procesora. Niektóre instrukcje potrafią być wykonywane nawet w czasie jednego taktu. Stworzenie dodatkowego pakietu instrukcji adaptacyjnych mogłoby być interesujące, ale łatwiej optymalizować programy pod procesory niż procesory pod programy

Wystarczy w FX-6300 zablokować jeden moduł, oczywiście biorąc poprawkę na różnicę w zegarach - FX-4300 - 3,8 GHz, FX-6300 - 3,5 GHz.

Tak, ale najpewniej nie będzie 2-modułowca z 8 MB L3, więc takie porównanie byłoby czysto naukowe.

I wydajność cache chcesz zabić odczytem z dysku?

Pomysł jak na razie nierealny, bo procesor nie ma informacji jaki program wykonuje. Dostaje ciąg instrukcji i na ich podstawie działa.
Można by pokusić się o programowalny układ predykcji skoków. W trakcie ładowania aplikacji system ładuje odpowiedni program układu.

Jest jeszcze problem taki, pod dany program jest optymalizacja, a co z całą resztą działającą w tle? Czy taka optymalizacja miałaby działać na jeden rdzeń/moduł, czy na cały procesor? Jeżeli na poszczególne jednostki, to co z przełączaniem zadań między jednostkami?

Generalnie lepiej optymalizować kod pod daną architekturę niż procesor pod dany program. Mniej okazji do dziwnych sytuacji i spadku wydajności.

Zapowiada się bardzo ciekawy artykuł, zabieram się do czytania. Szkoda tylko, że nie daliście jeszcze Piledrivera z 8 MB L3 i zablokowanymi modułami. Patrząc jednak na zadziwiająco małe różnice między Athlonem 750 a FX-4300, cudów by pewnie nie było...

Oj marny ten wniosek, marny.

Wskazana większa uwaga przy czytaniu testu :+)

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

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).

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.


Nie obserwuję tego na podstawie wyników Core i7-3820.

brakło pomiaru zużycia prądu każdej pary (a tym samym wpływu na ten parametr ilości pamięci)

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.

Pioy był blisko, ale Ty trafiłeś