Re: Turion vs Celeron

Autor: Rafał Bartoszak <sprocket_at_sys.BezSpamu.pl>
Data: Thu 02 Feb 2006 - 19:49:07 MET
Message-ID: <1mubrvt2f78pc$.19h5pqb8bzcoh.dlg@40tude.net>
Content-Type: text/plain; charset="iso-8859-2"

Dnia 2006-02-02 13:55:19, encja *mpx* wymodziła przez port 119 co
następuje:

> Celerony mają fatalny system pamięci cache. W ramach kastrowania Intel
> wyciął nie tylko pojemność, ale także liczbę obszarów które moga być
> równocześnie cachowane. Najgorsze są Celerony ze rdzeniem Northwood, bo mają
> tylko 2 dzielną (2 way set associative) pamięć podręczną. To nie wystarcza
> żadnemu oprogramowaniu, bo obszary, które powinny być cachowane są
> przynajmniej 3 - stos, sterta i kod programu.
[...]
Sorry, ale trochę bez sensu gadasz...
To, że cache jest dwudrożny, to nie znaczy, że może buforować dwa
obszary pamięci.
Więcej zaufania do Intela, sądzisz że strzeliliby takiego byka...? ;)

>
> Do testowania czasów dostępu do pamięci Sandra się nie nadaje,

Nie testowałem czasów dostępu, tylko szybkość zapisu/odczytu bloku
pamięci, z zależności od rozmiaru bloku. Sandra robi takie ładne
wykresiki, na których bardzo ładnie widać spadek efrktywności cache ze
wzrostem rozmiaru bloku.
Celeron początkowo miał pasmo 2x większe od Turiona, ale po 128 KB
szybkość poszła gwałtownie na pysk. Turion trzymał się do 1 MB
I tu IMO jest klucz - kompilacja jest procesem, przy którym cache bardzo
pomaga, a ten celeron ma go po prostu za mało.

[...]
> Czasy opóźnień pamięci są ważne w algorytmach które często skaczą po
> wskaźnikach lub referencjach, tzn.operujacych na strukturach typu grafy,
> drzewa itp..

Dołożę do tego liczne skoki w kodzie programu i dostaniemy...kompilację.
Pasuje.

-- 
pozdro...
____________________________________________________
[ |>|>|> sprocket  |   sprocket@sys.BezSpamu.pl    ]
[ Rafał Bartoszak  | maile w HTML'u lądują w koszu ]
Received on Thu Feb 2 19:50:05 2006

To archiwum zostało wygenerowane przez hypermail 2.1.8 : Thu 02 Feb 2006 - 19:51:03 MET