Autor: GLide (glide_at_terramail.pl)
Data: Sun 31 Mar 2002 - 19:22:00 MET DST
On Fri, 29 Mar 2002 09:09:05 -0600, "Pszemol" <Pszemol_at_PolBox.com>
wrote:
>Jeśli procek będzie miał szynę danych taktowaną 100MHz
>to nie zdarzy się sytuacja że będzie czekał na pamięci
>gdy one również będą taktowane zegarem 100MHz...
I co z tego? Czy myslisz, ze dostep procesora do pamieci nastepuje tak
po prostu? Wybranie konkretnego adresu w pamieci i przeslanie go do
procka chwile trawa (przeciez wystepuja opoznienia czasy wybrania
adresu itp.)
http://as5-4-5.mt.g.bonet.se/hacks/bandwidth.html
Oczywiste jest ze przyrost wydajnosci systemu nie bedzie
proporcjonalny do przyrostu taktowania pamieci, ale jezeli mozesz to
ustawic w Biosie, pamieci moga pracowac z szybszym zegarem, nie
nastepuje pogorszenie stabilnosci systemu (bo nie powinno) to dlaczego
nie korzystasz z tego udogodnienia (chociazby mialo to podniesc
wydajnosc o marnych kilka %)
>I nie sądzę aby cokolwiek poprawiło sytuację przyspieszenie
>pamięci do 133 czy nawet do 150 MHz... W układzie wolny CPU
>i szybka pamięć to procek staje się najsłabszym ogniwem łańcucha.
Przy dzisiejszych predkosciach osiaganych przez procesory
(oscylujacych wokool 1HGz i wiecej) wyglada to juz znacznie inaczej.
GLide
PS. Wlasnie sobie sprawdzilem zwykle kodowanie DivX procek D800_at_1000
1. fsb/mem 100/100 czas: 2min 1sek
2. fsb/mem 100/133 czas: 2min 10sek
Blur w Photoshopie na sporym obrazku A4 300dpi
1. 1min 44sek
2. 1min 47sek
Podczas oepracji wykluczylem wplyw korzystania ze swapa i szybkosci
oczytu/zapisu na dysku przy kodowaniu.
Postaram sie jeszcze zapuscic jakis render pod LightWavem.
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Wed 19 May 2004 - 00:34:18 MET DST