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? :)

do góry

Am 11.10.2010 15:22, schrieb RoMan Mandziejewicz:
> Hello Waldemar,
>
> Monday, October 11, 2010, 3:10:02 PM, you wrote:
>
> [...]
>
>>> Teoretycznie można by nawet zrobic hybryde asynchroniczną. Kiedys nazywało
>>> się to transputerami. Kazdy procek działa sobie, ale komunikują się bardzo
>>> mocno na poziomie procesorów. Trochę podobnie działa PS3 i nowe potwory 80 i
>>> wiecej procesorowe Intela, ale z kolei obcinajac dosc mocno instrukcje. Nie
>>> sa to zwykle procesory.
>> Transputery to był dobry pomysł, ale miały mnóstwo błędów i były bardzo
>> upierdliwe w programowaniu. Obecnie pomysł wraca do powszechniejszego
>> użytku (komputery wojskowe do obróbki zdjęć radarowych już to mają od
>> lat).
>
> Hmmm... Współczesne karty grafiki zawierają bardzo ciekawe procesory,
> które niekoniecznie muszą liczyć grafikę... Oprogramowania
> wykorzystującego możliwości procesorów kart grafiki powstaje coraz
> więcej.

są nawet drivery do Matlaba. Gdzieś widziałem obrazek PCta wypchanego
kartami graficznymi do oporu ;-). W końcu procesory 256 bitowe nie są w
powszechnym (normalnym) zastosowaniu. A jak jest tych procesorów
kilka(naście) na jednej karcie, to jeszcze lepiej. Tylko potrzebujesz
dobry zasilacz (albo dobre zasilacze).

Waldek

do góry

On 11 Paź, 14:30, "Miron (Asha) Kitkowsk" <a...@w...wp.mxx.wp.pl>
wrote:
> ptoki wrote:
> > On 11 Paź, 09:18, "identifikator: 20040501" <N...@g...pl>
> > wrote:
> >> pytałem na grupie .pecet, ale tam raczej nie wiedzieli... czy Ktoś może
> >> wie czemu to częstotliwości taktowania procesorów do PC już od ładnych
> >> paru lat nie wzrastają?
>
> Jest jeszcze sciezka asynchronicznosci lub hybryd. Sam widzialem opisy
> dialajacych ukladow intela z rdzeniem weglowym. A asynchronicznosc zupelnie
> omija bariere jakichkolwiek herców.
>
Ale asynchronicznosc juz jest. Bo procek czeka na dane ktore najpierw
zaciaga cache a czasem to cache juz te dane ma bo sobie przewidzialo
ze beda potrzebne. I o ile do rejestru i do cache L1 cpu ma dostep w 1
cyklu to z pamieci OIDP jest to minimum 5 operacji (nawet nie cykli)
(OIDP translacja adresu z przestrzeni programu na przestrzen
wirtualna, potem na fizyczna (OIDP daje sie zrobic w 1 cyklu ale nie
zawsze), potem jakies inkrementacje, zabranie z cache lub z pamieci do
cache a potem z cache) Nie jestem na bierzaco ale jeszcze za czasow
pentium 3 bylo to tak pomotane. Teraz pewnie wirtualizacja pododawala
kolejne cykle...

> Teoretycznie można by nawet zrobic hybryde asynchroniczną. Kiedys nazywało
> się to transputerami. Kazdy procek działa sobie, ale komunikują się bardzo
> mocno na poziomie procesorów. Trochę podobnie działa PS3 i nowe potwory 80 i
> wiecej procesorowe Intela, ale z kolei obcinajac dosc mocno instrukcje. Nie
> sa to zwykle procesory.

No, jak amiga kiedys :)
Generalnie jak kiedys badalem jak zbudowac sobie samemu mp3 player to
zniesmaczylo mnie ze wiekszosc projektow opierala sie na karcie sd, uC
i sta013. Ale tak naprawde to jest ta "lepsza" droga. Dedykowane
tranzystory dla standardowych zastosowan. Tak jak karty mpeg, ssl,
mp3, GPU i takie tam.
Niech beda skuteczne, szybkie, energooszczedne.
A tak winrar pakuje standardowy algorytm w cpu a moglo by byc szybciej
w dedykowanym scalaku.

PS. Wiem, wiem. Klient by zglupial jakby sie sprzedawca zapytal jaki
chce modul rar czy zip i ile MB pojemnosci zobie zyczy :)

do góry

W dniu 11.10.2010 17:48, ptoki pisze:
> Niech beda skuteczne, szybkie, energooszczedne.
> A tak winrar pakuje standardowy algorytm w cpu a moglo by byc szybciej
> w dedykowanym scalaku.
>
> PS. Wiem, wiem. Klient by zglupial jakby sie sprzedawca zapytal jaki
> chce modul rar czy zip i ile MB pojemnosci zobie zyczy :)
Po czym okazywałoby się, że lzma jest znacznie lepsze, więc nie będziesz
używał chipu, tylko procesora. Albo okaże się, że jest błąd w
implementacji i przy pewnych parametrach pliki wychodzą uszkodzone - nie
mówiąc o tym, że do "często używanych algorytmów" porobiłoby się wiele
kostek.


Robi się już od pewnego czasu FPGA na kartach PCI-E. Nie widzę problemu
w tym, żeby za jakiś czas nie było możliwości kupienia sobie
karty+zestawu zaimplementowanych algorytmów, które mogą być w niej
skonfigurowane w zależności od potrzeb - ale to tylko dla specyficznych
zastosowań. W "zwykłych" komputerach procesor jest uniwersalny i to jest
jego siła. Karty graficzne też ze specjalizowanych układów stały się
uniwersalnymi procesorami wektorowymi.

--
Pozdrawiam
Michoo

do góry

ptoki wrote:

> On 11 Paź, 14:30, "Miron (Asha) Kitkowsk" <a...@w...wp.mxx.wp.pl>
> wrote:
>> ptoki wrote:
>> > On 11 Paź, 09:18, "identifikator: 20040501" <N...@g...pl>
>> > wrote:
>> >> pytałem na grupie .pecet, ale tam raczej nie wiedzieli... czy Ktoś
>> >> może wie czemu to częstotliwości taktowania procesorów do PC już od
>> >> ładnych paru lat nie wzrastają?
>>
>> Jest jeszcze sciezka asynchronicznosci lub hybryd. Sam widzialem opisy
>> dialajacych ukladow intela z rdzeniem weglowym. A asynchronicznosc
>> zupelnie omija bariere jakichkolwiek herców.
>>
> Ale asynchronicznosc juz jest. Bo procek czeka na dane ktore najpierw
> zaciaga cache a czasem to cache juz te dane ma bo sobie przewidzialo
> ze beda potrzebne.


Nie wiesz co to asynchronicznosc lub wymyslasz na sile.
Wiesz co to jest cykl? To wlasnie propagacja sygnalu lub instrukcji po
procesorze. nie da sie wydac procesorowi instrukcji przed zakonczeniem
poprzedniej (pomijam skrypty czy jak to kazdy producent nazywa).
W asynchronicznych procesorach nie wiesz ile bedzie dzialac instrukcja.
Nawet moze byc tak, ze jeden procesor moze robic je 2,3 na raz.

Tak, ze cache i mikroprogramy to zupelnie inna bajka.

>> Teoretycznie można by nawet zrobic hybryde asynchroniczną. Kiedys
>> nazywało się to transputerami. Kazdy procek działa sobie, ale komunikują
>> się bardzo mocno na poziomie procesorów. Trochę podobnie działa PS3 i
>> nowe potwory 80 i wiecej procesorowe Intela, ale z kolei obcinajac dosc
>> mocno instrukcje. Nie sa to zwykle procesory.
>
> No, jak amiga kiedys :)

Nie bardzo. Nawet mocno nie bardzo. Ale kto inny lepiej to opisał niż mi się
chce.


--
Na wszystko nie można odpowiadać "tak"

do góry

Michoo wrote:

> Robi się już od pewnego czasu FPGA na kartach PCI-E. Nie widzę problemu
> w tym, żeby za jakiś czas nie było możliwości kupienia sobie
> karty+zestawu zaimplementowanych algorytmów, które mogą być w niej
> skonfigurowane w zależności od potrzeb - ale to tylko dla specyficznych
> zastosowań. W "zwykłych" komputerach procesor jest uniwersalny i to jest
> jego siła. Karty graficzne też ze specjalizowanych układów stały się
> uniwersalnymi procesorami wektorowymi.

Wlasciwie cos takiego już jest od lat. IBM robi procesory do baz danych ;)

--
Na wszystko nie można odpowiadać "tak"

do góry

Użytkownik "Miron (Asha) Kitkowsk" <a...@w...wp.mxx.wp.pl> napisał w
wiadomości news:4cb3428f$0$22800$65785112@news.neostrada.pl...
> Michoo wrote:
>
>> Robi się już od pewnego czasu FPGA na kartach PCI-E. Nie widzę problemu
>> w tym, żeby za jakiś czas nie było możliwości kupienia sobie
>> karty+zestawu zaimplementowanych algorytmów, które mogą być w niej
>> skonfigurowane w zależności od potrzeb - ale to tylko dla specyficznych
>> zastosowań. W "zwykłych" komputerach procesor jest uniwersalny i to jest
>> jego siła. Karty graficzne też ze specjalizowanych układów stały się
>> uniwersalnymi procesorami wektorowymi.
>
> Wlasciwie cos takiego już jest od lat. IBM robi procesory do baz danych ;)
>

Na przykład do DB2...

Pozdrowienia. Krzysztof z Tychów.

do góry

In the darkest hour on Mon, 11 Oct 2010 08:36:57 -0700 (PDT),
ptoki <s...@g...com> screamed:
> 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.

Chyba nie wiesz, jak zbudowany jest procesor. Co innego gdy 90% czasu
CPU śpi, a co innego gdy jego 90% nic nie robi.

--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:233B ]
[ 09:11:27 user up 12588 days, 21:06, 1 user, load average: 0.97, 0.28, 0.64 ]

Democracy is too good to share with just anybody. -- Nigel Rees

do góry

On 12 Paź, 09:12, "Artur M. Piwko" <m...@b...pl>
wrote:
> In the darkest hour on Mon, 11 Oct 2010 08:36:57 -0700 (PDT),
> ptoki <s...@g...com> screamed:
>
> > 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.
>
> Chyba nie wiesz, jak zbudowany jest procesor. Co innego gdy 90% czasu
> CPU śpi, a co innego gdy jego 90% nic nie robi.
>
Oczywiscie ze co innego.
A to jak zbudowany i jak dzialaja niektóre procesory z rodziny x86
dosyc dobrze wiem.
Co nadal nie zmienia faktu ze wiekszosc malych rzeczy jakie robi cpu w
PC powoduje ze relatywnie duzo czesci procesora nie moze ani sie uspic
ani zmienic taktowania na mniejsze. O duzych zadaniach juz nie
wspominam.
Sytuacje troche ratuje fakt ze buforowanie danych w peryferiach
pozwala na krótkie okresy pracy i dluzsze okresy usypiania CPU ale
byle flaszyk na stronie czy antywirus ktory sie obudzi i zaczyna
skanowac caly dysk sytuacje mocno pogarsza.

do góry

W dniu 12.10.2010 09:12, Artur M. Piwko pisze:
> In the darkest hour on Mon, 11 Oct 2010 08:36:57 -0700 (PDT),
> ptoki<s...@g...com> screamed:
>> 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.
>
> Chyba nie wiesz, jak zbudowany jest procesor. Co innego gdy 90% czasu
> CPU śpi, a co innego gdy jego 90% nic nie robi.
>
Ale oba przypadki są na raz możliwe:
jeżeli procesor budzi się tylko po to, żeby nakazać kolejny transfer
MDMA z dysku do pamięci a potem z pamięci do pamięci karty to nie
pracuje zbyt dużo. Że wykonywane przez niego operacje są relatywnie
proste to nie pracuje zbyt intensywnie. (Podobno obciążenie procesora
(load avg) na poziomie 3% nie jest niczym dziwnym przy dekodowaniu
obrazu full-hd za pomocą VA-API.)

--
Pozdrawiam
Michoo

do góry