mulţi cache – puţini pricep

Am aflat recent că procesorul meu e foarte slab comparativ cu ce se cumpără azi. Am început să mă informez despre ce se mai poartă și ar intra în soketul plăcii mele de bază. Am găsit cîteva alternative și am început să citesc review-uri despre cîteva procesoare.

Am ajuns la o comparație între 2 Athlonuri, unu cu cache dublu față de celălalt. Persoanele care făcuseră testele nu dădeau vreun sens legat de software analizei pe care o făceau: măsurau și desenau grafice.

Partea care mi-a atras atenția a fost următoarea: cum și care software este influențat de cantitatea mai mare de memorie cache de nivel 2 în procesor.

Ce ne spuneau cifrele în trecere: codul Java nu e influențat prea mult de dublarea cache-ului. Codul .NET și Visual Studio.NET sînt mai sensibile și viteza lor crește vizibil odată cu mărirea memoriei cache.

Ce se poate înțelege de aici?

Punctul de vede Javistic:

• Java e atît de bun încît nu are nevoie de prea mult cache, el merge rapid și cu puțin cache.

Punctul de vedere .NET-istic:

• .NET e scris destul de bine încît să profite de mai mult cache și viteza se scalează corespunzător.

Asta îmi amintește de specialiștii care erau deranjați de faptul că Windows Vista “freacă” harddiscul atunci cînd calculatorul nu face nimic altceva (e “idle”). Cel mai bine ar fi dacă nu l-ar folosi: LED-ul ar sta stins spre confortul lor și programul pe care au șanse de 90% să-l lanseze în următoarele minute (browserul web de exemplu) va fi adus în 10 secunde în memorie de pe harddisc în loc să fie deja acolo. Mai bine economisim puțin LED și așteptăm “după Windows” cînd avem nevoie de ceva. De ce să nu lăsăm calculatorul să-și tragă și el sufletul? Așa și cu memoria cache: putem să o folosim profitînd de faptul că o avem (dacă o avem) sau o putem economisi. Diferența e că în cazul cache-ului nefolosit, nici măcar nu avem un LED liniștitor.

Cazul codului care nu beneficiază de creșterea cantității de cache e mai nefericit decît spuneam. Codul ăsta nu din economie nu folosește eficient memoria cache, nu din generozitatea de a-l lăsa altora. Nici nu poți economisi resursa asta, ea se umple involuntar cu ce “consideră” că e necesar. Ineficiența vine numai din lipsa localizării datelor și a codului. Dacă ele nu sînt localizate și zburzi absurd prin memorie de ici colo, șansele sînt mici să beneficiezi de cache, o să-l “murdărești” tot timpul cu lucruri pe care nu vei mai apuca să le prinzi acolo data viitoare pentru că alte informații “nelocalizate” le vor lua locul.

Aici din nou calitatea codului care face colectarea gunoiului în .NET își spune cuvîntul: colectorul de gunoi face eforturi ca după ce a adunat gunoiul, eliminînd zone localizate la întîmplare în heap, după cum vor fi fost ele alocate cînd a fost nevoie și au devenit inutile între timp, face eforturi ziceam să păstreze “aproape” sau “împreună” datele rămase după ce gunoiul a fost colectat. Mai exact dacă obiecte au fost declarate împreuna (unul după altul sau aproape în timp/spațiu de cod), colectorul de gunoi va încerca să le țină împreună și după ce a adunat gunoiul de printre ele, ca să-l ajute pe programator să poată ține datele localizate așa cum le-a crezut la declarare și să poată gîndi codul eficient luînd în considerare persistența localizării. Fără eforturile astea, după o colectare, localizarea ar fi complet aleatoare și rezultatele ar semăna cu cele din Java.