Autor: fv (fake_at_cybax.com)
Data: Fri 13 Feb 2004 - 00:39:15 MET
Tomasz Potega claimed:
> fv <fake_at_cybax.com> wrote:
>> Ale ten, widzę że to nie jest zabawa 'kto ma dłuższego'. Możesz wyjaśnić
>> czemu i jaki wpływ ma długość potoku na wydajność ?
> uprzedze, poki Radek skrobnie dluzsza odpowiedz - poki instrukcje wykonywane
> sa sekwencyjnie, dlugi potok jest bardzo fajna sprawa (taki prescott - 31
> osob doklada czesci do produkowanego produktu).
Czyli mamy taśmę produkcyjną. Jaki zysk ma z niej CPU ? Tzn. chodzą
inspektorzy i przewidują: 'o! to znaczy się zaraz będzie chciał %EAX ?
A to potem pewnie %ESP i ret' ? Głupio pytam bo nie wiem na czym polega
przewidywanie.
> gorzej, gdy okaze sie, ze
> trzeba przykladowo wykonac jakis skok (np. warunkowy, gdy warunek jest pozno
> sprawdzany) lub wystapi inne zaburzenie wykonania - czesciowo obrobione
> wyniki instrukcji mozna splukac w sedesie, robote trzeba zaczac od nowa - co
No nie od dziś wiadomo i pod karą grzywny nakazano coby nie uzależniać
skoków od nieznanych danych itp. Co to ma z potokiem wspólnego ?
Znaczy jak są czasem takie rysuneczki pokazujące dwa równoległe
strumienie instrukcji "zjadane" przez CPU to to są te potoki ?
(/me lame)
> zaczynac prace. jesli potokow jest mniej, a architektura i tak dziala z
> przyzwoitym zegarem (jak k6-2 czy k6-iii), te problemy nie maja az tak
> wielkiego wplywu na wyniki fabryki ;)
Ale ten.. skomplikowana architektura potoków i przewidywania egzekucji
wymaga wysiłku od programistów i kompilatorów. A krótkowzroczne
brute-forsy AMD mogą mieć dziadowy kompilator, tak ? Tzn. dedykowany pod
Prescotta kompilator może zdziałać cuda dzięki tym długim potokom ?
> btw nigdy wiecej o potokach po piciu :)
Jakbyś nie wypił to byś się nie rozgadał :) Gimmie more :>
--
:: http://www.stringi.com/viper/ ::
Universe is not only weirder than we imagine
it's weirder than we can imagine!
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Wed 19 May 2004 - 13:12:57 MET DST