On 11 Paź, 15:34, M <m...@g...com> wrote:
> On 11 Paź, 12:58, ptoki <s...@g...com> wrote:
>
> > Bo architektura x86 jest taka specyficzna ze trzeba caly procek
> > taktowac szybciej i z tego powodu wiecej tranzystorow musi sie
> > bardziej grzac (Opisal to Jan Kowalski ponizej).
>
> Było tak z architekturą NetBurst (Pentium 4), potem weszła Core i
> udało się poprawić wydajność a zmniejszyć grzanie z GHz.  Choć w sumie
> to już było, nazywało się Pentium M tylko trochę wyprzedziło swój czas
> (wtedy na oszczędność energii zwracano uwagę głównie w laptopach, a w
> desktopach i serwerach mniej).  Teraz jeszcze Atom...  AMD też w
> porównaniu z P4 wypadało lepiej.

Mialem na mysli ciutke co innego. Chodzi o to ze jak procek "cos"
liczy to relatywnie duzo jego elementow musi pracowac. Trudno osiagnac
taki stan zeby film sobie lecial a 90% procka spalo. No, powoli do
tego dorastamy ale dalej procek musi za duzo pierdół robic. Na amidze
daaawno temu granie mod-a od strony procka ograniczalo sie do
zaprogramowania dma zeby wgralo mod-a z dysku/flopa, zaprogramowaniu
dma zeby slalo dane do bodajze "pauli" i powiadomieniu tejze o
parametrach jak ma te dane grac. No i na czekaniu az ktos sie odezwie
ze skonczyl.
A w x86 jednak masa ukladow procka musi pracowac. No i jak sie nudzi
to ewentualnie zwolni ale jak cokolwiek robi to sie taktuje szybciej
prawie caly. Taka to architektura...

>
> > Przy taktowaniu 4GHz dlugosc fali jest porownywalna z rozmiarami
> > komponentow na plycie i po prostu procek nie nadaza byc karmiony taka
> > iloscia danych zeby byl sens zwiekszania jego wydajnosci w ten sposob.
>
> Taktowanie 4 GHz jest tylko wewnątrz CPU, pamięci mają już
> kilkakrotnie mniej (np. FSB 1333 MHz to w rzeczywistości zegar 333 MHz
> i dane przesyłane 4 razy w jednym cyklu).
>
Ale to nadal slabo bo dzisiejsze procki potrafia dosyc sprawnie liczyc
(intele zawsze dobrze liczyly) i jednak jak sie zajrzy statystyki
wewnatrz to dosyc duzo (od okolo 5-30%) czasu jest spedzone na
czekaniu na dane czy to z ram czy z portow i to mimo cache, modulow
predykcji i wielu potokow. A programisci nie maja nerwow zeby
optymalizowac kod nawet na jeden typ cpu a co dopiero na kilka
generacji...


> > Dlatego widzimy objaw metody "dziel i rzadz" i procesory sa
> > zwielokratniane i sama pamiec tez tego niedlugo bedzie doswiadczac.
> > Juz teraz GPU ma swoja dedykowana pamiec na ktorej "liczy" i albo
> > pojawia sie lepsze kontrolery pamieci ktore beda nadazac karmic
> > rdzenie danymi albo architektura pojdzie w kierunku dedykowanych
> > obszarow dla grupy rdzeni.
>
> Są już takie platformy (architektura NUMA) - wcześniej AMD, później i
> Intel wprowadził CPU z zintegrowanym kontrolerem pamięci (wcześniej
> była to część chipsetu, co było wąskim gardłem).  Kto wie, może
> następnym krokiem będzie pamięć od razu wbudowana w CPU (by jeszcze
> bardziej skrócić połączenia).
>
No niby juz dawno jest (cache) ale to nadal nie to co powinno byc. Od
dawna czekam az przemysl dojrzeje to tego co miala amiga. Czyli procki
specjalizowane i do tego dosyc samodzielne. Czesciowo zarzadzanie
energia w wielordzeniowcach to realizuje ale to nadal pomysl stosowany
w pojedynczych rejonach.
Ale powoli do tego sie dochodzi (GPU, rdzenie, karty specjalizowane
(MPEG) i takie tam).

> A na nowym sprzęcie Vista i tak bardziej muli niż Win3.11 na starym
> Pentium ;) - słuszna uwaga o rozwoju oprogramowania.  Linux ma tu
> szansę coś tu poprawić (np. już wykorzystuje wielordzeniowość do
> przyspieszenia startu systemu przez uruchamianie wielu procesów
> równolegle, zamiast jak dawniej po kolei).

Z tym zwielokratnianiem startu to nie tyle chodzilo o rdzenie co o
opoznienia. Bo np. inicjalizacja samej sieci wymagala jakiejs
komunikacji po sieci a tutaj czasy mogly skakac ponad sekunde. I tak
kazdy agent zabieral swoje milisekundy to na sieci to na dysku a to na
karcie ktora inicjalizowal i w sznurku wychodzilo dlugo mimo ze mozna
bylo robic rownolegle i bylo by szybciej...
Ale dlugo tego nie optymalizowano bo ile razy sie kompa bootuje? :)