procesory PC

Reply to
identifikator: 20040501
Loading thread data ...

identifikator: 20040501 snipped-for-privacy@go2.pl napisał(a):

W momencie gdy procesory do PC zbliżyły się do granicy 4GHz okazało się, że procesory pobierają nieakceptowalne ilość energii którą rozpraszają w postaci trudnego do odprowadzenia ciepła. W związku z tym zamiast za wszelką cenę walczyć z wiatrakami aktualnej technologii krzemu producenci procesorów sięgnęli po technologię komputerów wieloprocesorowych - znanych od dawna jednak nie używanych w warunkach domowych z racji zaporowej ceny. Tak narodziły się procesory wielordzeniowe, które dominują dziś na rynku procesorów PC. Oczywiście nie ma róży bez kolców, efektywne wykorzystanie systemów wieloprocesorowych zależy od rodzaju uruchamianego oprogramowania w szczególności od możliwości podzielenia zadania na oddzielne wątki i przekazaniu ich do równoległego wykonywania przez rdzenie procesora. Nie każde oprogramowanie jest przygotowane w ten sposób, dlatego ostatnio pojawiają się rozwiązania hybrydowe - procesory zdolne do "podkręcenia" jednego ze rdzeni w przypadku gdy aplikacja nie korzysta z wielowątkowości.

Reply to
Jan Kowalski

Pan Jan Kowalski napisał:

Nie walczyć, a wręcz przeciwnie -- zaprzyjaźnić się. Bez solidnego wiatraka do takiego procesora nie ma co podchodzić.

Reply to
Jarosław Sokołowski

Pan J.F. napisał:

Gdyby tak teraz ktoś zabrał się za rozwój oprogramowania z takim samym zapałem, jaki wcześnie towarzyszył podkręcaniu gigahertzów. Te same komputery by śmigały jak z procesorem 40GHz i pamięcią

64GB.
Reply to
Jarosław Sokołowski

Moja wersja: 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). Ale jest jeszcze jeden powod: 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. 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.

Reply to
ptoki

Jest jeszcze sciezka asynchronicznosci lub hybryd. Sam widzialem opisy dialajacych ukladow intela z rdzeniem weglowym. A asynchronicznosc zupelnie omija bariere jakichkolwiek herców.

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.

Reply to
Miron (Asha) Kitkowsk

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). Dzisiaj "transputerami" są stosunkowo tanie komputery połączone szybkimi seryjnymi linkami (>10Gbit/s) między sobą, każdy ma swoje kilka GB pamięci i wsio hula. Szukać pod hypercube architecture oraz massive multiprocessor architecture. Wszystkie obecne rekordowe superkomputery są w ten sposób budowane. W mniejszych systemach też już się pojawia, jak np. blade system IBMa.

Transputery miały statyczną architekturę kostki czterowymiarowej (w ogólności dowolnej figury czterowymiarowej). Procesory komunikacyjne (switchboard) umożliwiające dynamiczną zmianę konfiruracji były co prawda przez InMOS planowane, ale nigdy nie ujrzały światła dziennego. Obecne komputery mają w tym zakresie dużo większe możliwości. Na przykład automatyczna diagnostyka umożliwia wyłapanie wadliwego węzła i jego wymianę bez wyłączania kompa. Operator dostaje maila, że węzeł 4711 w piątej szafie, 3 piętro 6 blade od lewej ma feler, bierze zapasowy pod pachę i wymienia.

Kwestia pamięci jest co prawda nadal problemem, ale tu też już rozwiązania były. Na przykład taki staruszek jak Cray 1 miał procesor z taktem 12.5ns, a pamięć chodziła na 100ns. Była ona podzielona na 8 banków, które pracowały z przesuniętym zegarem. Niestety czasem było to dość problematyczne, doświadczyłem to na własnym grzbiecie.

Waldek

Reply to
Waldemar Krzok
[...]

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.

[...]
Reply to
RoMan Mandziejewicz

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.

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).

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).

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).

Reply to
M

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...

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...

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).

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

Reply to
ptoki

Am 11.10.2010 15:22, schrieb RoMan Mandziejewicz:

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

Reply to
Waldemar Krzok

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...

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

Reply to
ptoki

W dniu 11.10.2010 17:48, ptoki pisze:

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.

Reply to
Michoo

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.

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

Reply to
Miron (Asha) Kitkowsk

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

Reply to
Miron (Asha) Kitkowsk
Reply to
invalid unparseable

In the darkest hour on Mon, 11 Oct 2010 08:36:57 -0700 (PDT), ptoki snipped-for-privacy@gmail.com screamed:

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

Reply to
Artur M. Piwko

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.

Reply to
ptoki

W dniu 12.10.2010 09:12, Artur M. Piwko pisze:

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.)

Reply to
Michoo

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.