Programy jednowątkowe a wiele rdzeni procesora
ViRuS
Czy aktualnie istnieje już jakaś technologia pozwalająca na korzystanie z
kilku rdzeni procesora dla programów jednowątkowych? Pracuję na takim
programie obliczeniowym, niestety korzysta on tylko z jednego rdzenia i na
zmiany się tu nie zanosi. Tymczasem postęp w dziedzinie sprzętu dotyczy
tylko dokładania kolejnych rdzeni, co mnie słabo cieszy... Czy jest jakiś
sposób na to?
Pozdr,L.
G Nowak
Nie istnieje. Stad pytania o oplacalnosc zakupu szybszego X2 lub
wolniejszego X4.
--
Pozdr
G
Boguś
> Czy aktualnie istnieje już jakaś technologia pozwalająca na korzystanie
> z kilku rdzeni procesora dla programów jednowątkowych? Pracuję na takim
> programie obliczeniowym, niestety korzysta on tylko z jednego rdzenia i
> na zmiany się tu nie zanosi.
Jaka to miałaby być technologia?. Sprzęt- niemożliwe, program a skąd ma on wiedzieć co ty liczysz i jak to
zrównoleglić.
Tylko konkretny program musi być tak napisany, by mógł prowadzić obliczenia równolegle. I mała uwaga,
większość programów obliczeniewych nie można zrównolegić, wyjątki to macierze, tablice ( pod warunkiem że
każdą wartość tablicy obliczasz niezależnie) itp.
Zawsze jednak możesz uruchomić drugą aplikacje tego samego programu by liczyć inny zestaw danych. Ma to
jednak sens tylko wtedy gdy obliczenie jakiegoś zestawy są długie.
Możesz również prowadzić jakieś inne obliczenia z innym programem, obrabiać filmy, przeglądać internet itp. I
to wszystko będzie biegło równolegle. No cóż, wymaga to podzielności uwagi i przyzwyczajenia się do tego typu
pracy
--
Boguś
ViRuS
Użytkownik "Boguś" <telem...@wp.pl> napisał w wiadomości
news:4d5fc260$0$2495$6578...@news.neostrada.pl...
> Użytkownik ViRuS napisał:
>
>> Czy aktualnie istnieje już jakaś technologia pozwalająca na korzystanie
>> z kilku rdzeni procesora dla programów jednowątkowych? Pracuję na takim
>> programie obliczeniowym, niestety korzysta on tylko z jednego rdzenia i
>> na zmiany się tu nie zanosi.
>
> Jaka to miałaby być technologia?. Sprzęt- niemożliwe, program a skąd ma
> on wiedzieć co ty liczysz i jak to zrównoleglić.
Jaka? Nie wiem jaka, nie znam się, ale skoro można zapisywać dane równolegle
na dwóch dyskach... :)
> Tylko konkretny program musi być tak napisany, by mógł prowadzić
> obliczenia równolegle. I mała uwaga, większość programów obliczeniewych
> nie można zrównolegić, wyjątki to macierze, tablice ( pod warunkiem że
> każdą wartość tablicy obliczasz niezależnie) itp.
> Zawsze jednak możesz uruchomić drugą aplikacje tego samego programu by
> liczyć inny zestaw danych. Ma to jednak sens tylko wtedy gdy obliczenie
> jakiegoś zestawy są długie.
> Możesz również prowadzić jakieś inne obliczenia z innym programem,
> obrabiać filmy, przeglądać internet itp. I to wszystko będzie biegło
> równolegle. No cóż, wymaga to podzielności uwagi i przyzwyczajenia się do
> tego typu pracy
>
Czyli lipa. Skoro tak, to można się domyślać, że za 10 lat procesory będą
miały po 30 rdzeni i praktyczną wydajność niewiele większą od dzisiejszych
:]
Pozdr,Leszek
Boguś
>>> Czy aktualnie istnieje już jakaś technologia pozwalająca na korzystanie
>>> z kilku rdzeni procesora dla programów jednowątkowych?
>> Możesz również prowadzić jakieś inne obliczenia z innym programem,
>> obrabiać filmy, przeglądać internet itp.
>
> Czyli lipa. Skoro tak, to można się domyślać, że za 10 lat procesory
> będą miały po 30 rdzeni i praktyczną wydajność niewiele większą od
> dzisiejszych :]
Za 10 lat to będzie conajmniej 128 procesorów ;) i fantastyczna wydajność.
Ja mam dostęp do komputera z 4 rdzeniami(a razem 8 wątków) i jakość nie ma problemu z wykorzystaniem jego mocy
(średnie obciążenie 78% czyli średnio 6 wątków jest obciążonych 100%).
Jeżeli nie umiesz wykorzystać mocy procesora wielordzeniowego to widocznie nie zasługujesz na taki ;)
--
Boguś
Radosław Sokół
> Czyli lipa. Skoro tak, to można się domyślać, że za 10 lat procesory będą miały po 30 rdzeni i praktyczną wydajność niewiele większą od dzisiejszych :]
Dlaczego zakładasz, że wszyscy będą używali tak badziewnych
programów, jakiego Ty musisz obecnie używać? ;)
Oprogramowanie *już* dostosowuje się do przetwarzania równo-
ległego. Kiedyś nikt tego nie robił, bo maszyny równoległe
były rzadkością niedostępną nawet dla programistów czasem.
Obecnie każdy może sobie kupić "ośmiordzeniowca" i wtedy
zależy mu, by pisany przez niego program wszystko, co się
da, robił w tle, a najlepiej jeszcze ze zrównolegleniem
przetwarzania.
--
|""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
| Radosław Sokół | http://www.grush.one.pl/ |
| | Politechnika Śląska |
\........................................................../
marfi
news:20110219...@grush.one.pl...
>W dniu 19.02.2011 16:38, ViRuS pisze:
>> Czyli lipa. Skoro tak, to można się domyślać, że za 10 lat procesory będą
>> miały po 30 rdzeni i praktyczną wydajność niewiele większą od
>> dzisiejszych :]
>
> Dlaczego zakładasz, że wszyscy będą używali tak badziewnych
> programów, jakiego Ty musisz obecnie używać? ;)
>
> Oprogramowanie *już* dostosowuje się do przetwarzania równo-
> ległego. Kiedyś nikt tego nie robił, bo maszyny równoległe
> były rzadkością niedostępną nawet dla programistów czasem.
> Obecnie każdy może sobie kupić "ośmiordzeniowca" i wtedy
> zależy mu, by pisany przez niego program wszystko, co się
> da, robił w tle, a najlepiej jeszcze ze zrównolegleniem
> przetwarzania.
>
Pamiętasz to (lipiec 2008)?
"Więcej niż 2 rdzenie są dzisiaj potrzebne tylko osobom ko-
rzystającym ze zrównoleglonego oprogramowania. A tak prawdę
mówiąc, to te 2 rdzenie też nie powinny być większości ludzi
przydatne:"
--
marfi
Przesmiewca
>
>Czyli lipa. Skoro tak, to można się domyślać, że za 10 lat procesory będą
>miały po 30 rdzeni i praktyczną wydajność niewiele większą od dzisiejszych
>:]
Nie, bo na rynku pewnie juz bedzie tylko oprogramowanie potrafiace wykorzystac
wszystkie rdzenie. Wtedy procesor szybciej skonczy prace i szybciej przejdzie w
tryb bezczynnosci, oszczedzajac czas i pieniadze.
Qbab
> Jeżeli nie umiesz wykorzystać mocy procesora wielordzeniowego to
> widocznie nie zasługujesz na taki ;)
>
są problemy których nie da się zrównoleglić :P
Qbab
GLaF
Jak napisał obok Qbab: są problemy, których nie da się zrównoleglić.
Ale wiele się da, i te powinny być zrównoleglane.
--
GLaF
Przemysław Ryk
> Za 10 lat to będzie conajmniej 128 procesorów ;) i fantastyczna wydajność.
> Ja mam dostęp do komputera z 4 rdzeniami(a razem 8 wątków) i jakość nie ma problemu z wykorzystaniem jego mocy
> (średnie obciążenie 78% czyli średnio 6 wątków jest obciążonych 100%).
> Jeżeli nie umiesz wykorzystać mocy procesora wielordzeniowego to widocznie nie zasługujesz na taki ;)
Pracuję w DTP. Mając Adobe CS3, testując swego czasu CS5. Powiedz mi o
wspaniały, jak mogę wykorzystać moc choćby dwurdzeniowego Core 2 Duo?
--
[ Przemysław "Maverick" Ryk ICQ: 17634926 GG: 2808132 ]
[ Taka dziewczyna, jak już zacznie coś w kierunku faceta uskuteczniać, to ]
[ on daje się prowadzić jak cielę na rzeź... ]
[ ...I przeważnie to jest rzeź... (Musk) ]
ViRuS
> Jak napisał obok Qbab: są problemy, których nie da się zrównoleglić.
> Ale wiele się da, i te powinny być zrównoleglane.
>
W informatyce lepiej nie mówić, że coś jest absolutnie niemożliwe bo za parę
lat można wyjść na oszołoma ;) Trudno sobie wyobrazić, że pętla miałaby być
wykonywana przez dwa procesory. Tym niemniej na każdy krok pętli procesor
wykonuje jakąś czynność. Ja głowy nie dam, że tej czynności nie da się
rozdzielić... :) Szkoda póki co, bo to by rozwiązało problem
wielordzeniowości dla dowolnej ilości procesorów.
Pozdr,L.
MC
news:20110219...@grush.one.pl...
>> Czyli lipa. Skoro tak, to można się domyślać, że za 10 lat procesory będą
>> miały po 30 rdzeni i praktyczną wydajność niewiele większą od
>> dzisiejszych :]
>
> Dlaczego zakładasz, że wszyscy będą używali tak badziewnych
> programów, jakiego Ty musisz obecnie używać? ;)
>
> Oprogramowanie *już* dostosowuje się do przetwarzania równo-
> ległego.
Słowo "już" należy wziąć w mooooocny cudzysłów. Ile to już lat minęło odkąd
technologia, z powodu chciwości producentów CPU, zatrzymała się w okolicach
3, 4 GHz? Gdyby ogłosić konkurs na największy hamulec w rozwoju informatyki
oddałbym swój głos na wielordzeniowość.
MC
news:ijqsh1$28q$1...@inews.gazeta.pl...
To się bardzo łatwo mówi. Niestety liczba aplikacji wielowątkowych (jest
jeszcze problem ile ma być tych wątków) jakoś nie chce specjalnie urosnąć.
Radosław Sokół
> Pamiętasz to (lipiec 2008)?
>
> "Więcej niż 2 rdzenie są dzisiaj potrzebne tylko osobom ko-
> rzystającym ze zrównoleglonego oprogramowania. A tak prawdę
> mówiąc, to te 2 rdzenie też nie powinny być większości ludzi
> przydatne:"
0) Domyślam się, że to cytat ze mnie, bo sam tego nie pamię-
tam, Google nie znalazł, a na domowym komputerze w archi-
wum wysłanych tego nie mam (ale może postowałem z pracy).
1) To było prawie trzy lata temu. W IT żaden osąd nie obowią-
zuje przez tak długi czas. Co było słuszne wtedy, nie musi
być słuszne dziś.
2) Pierwsze z tych dwóch zdań podtrzymuję. Typowemu użytkow-
nikowi *wystarczają* dwa rdzenie i dzisiaj już nawet widać
powoli zyski wynikające z ich obecności (wtedy były troszkę
na wyrost, teraz mają już sens).
3) Drugie zdanie straciło swoją ważność właśnie dzięki rozwo-
jowi oprogramowania. Coraz więcej rzeczy jest realizowanych
w tle (ładowanie usług, indeksowanie danych, przesyłanie
plików, renderowanie stron WWW) i zaczyna być widać zysk
wynikający ze zrównoleglania pracy.
4) A za 10 lat, mam nadzieję, będę mógł unieważnić nawet i to
pierwsze zdanie i powiedzieć, że typowy użytkownik odnosi
korzyść nawet z szesnastu rdzeni :)
Radosław Sokół
> Słowo "już" należy wziąć w mooooocny cudzysłów. Ile to już lat minęło odkąd technologia, z powodu chciwości producentów CPU, zatrzymała się w okolicach 3, 4 GHz? Gdyby ogłosić konkurs na największy
> hamulec w rozwoju informatyki oddałbym swój głos na wielordzeniowość.
Przepraszam, a masz jakiś *dowód* na to, że wstrzymanie zwięk-
szania częstotliwości taktowania na 3-4 GHz wynika z "chciwo-
ści" producentów, a nie z braku sensowności lub ograniczeń
technicznych?
Wszyscy wiemy, czym się skończyło powstanie architektury CPU
zbudowanej z myślą o wysokich częstotliwościach taktowania
(NetBurst).
Ja jestem *zadowolony* z braku wzrostu częstotliwości takto-
wania. Po pierwsze, producenci CPU w poszukiwaniu zysku mu-
sieli zwrócić się w kierunku poprawiania wskaźników IPC,
nie tylko poprzez wielordzeniowość, ale też superskalarność
i optymalizację. Z kolei producenci oprogramowania już zaczy-
nają tracić dech i odwracają się nieco od technik pozwalają-
cych tworzyć programy "szybko" zamiast "szybkie".
Może za 10 lat mało kto będzie się zajmował C# lub Javą, bo
powstające w nich programy nie będą konkurencyjne wydajno-
ściowo z najlepszymi produktami pisanymi w C++, Vali, Go czy
czymkolwiek nowym, co w tym czasie jeszcze powstanie? :)
MC
>W dniu 20.02.2011 12:45, MC pisze:
>> Słowo "już" należy wziąć w mooooocny cudzysłów. Ile to już lat minęło
>> odkąd technologia, z powodu chciwości producentów CPU, zatrzymała się w
>> okolicach 3, 4 GHz? Gdyby ogłosić konkurs na największy
>> hamulec w rozwoju informatyki oddałbym swój głos na wielordzeniowość.
>
> Przepraszam, a masz jakiś *dowód* na to, że wstrzymanie zwięk-
> szania częstotliwości taktowania na 3-4 GHz wynika z "chciwo-
> ści" producentów, a nie z braku sensowności lub ograniczeń
> technicznych?
Argument o braku sensowaności obala istnienie tego wątku. Ograniczenia
techniczne oczywiście są, ale dotyczą one aktualnie używanych materiałów.
Wykorzystanie innych pozwoliłoby przekroczyć tę barierę. Dowodów na to jest
mnóstwo, chociażby tranzystor 100 GHz (chodzi w RT) na grafenie zrobiony w
IBM. Ale to wymagałoby doprowadzenia technologii do stanu gotowego do
zastosowania w produkcji masowej oraz przezbrojenia fabryk. Eden jest tuż za
tą górą, tylko trzeba ją przekroczyć.
> Wszyscy wiemy, czym się skończyło powstanie architektury CPU
> zbudowanej z myślą o wysokich częstotliwościach taktowania
> (NetBurst).
Ale to nie jest problem architektury, tylko tranzystorów zdolnych do pracy w
wyższych częstotliwościach.
> Ja jestem *zadowolony* z braku wzrostu częstotliwości takto-
> wania. Po pierwsze, producenci CPU w poszukiwaniu zysku mu-
> sieli zwrócić się w kierunku poprawiania wskaźników IPC,
> nie tylko poprzez wielordzeniowość, ale też superskalarność
> i optymalizację. Z kolei producenci oprogramowania już zaczy-
> nają tracić dech i odwracają się nieco od technik pozwalają-
> cych tworzyć programy "szybko" zamiast "szybkie".
Nie widzę żadnego powodu do radości w tym, że pewne cele zamiast łatwiej
będzie trudniej osiągnąć.
> Może za 10 lat mało kto będzie się zajmował C# lub Javą, bo
> powstające w nich programy nie będą konkurencyjne wydajno-
> ściowo z najlepszymi produktami pisanymi w C++, Vali, Go czy
> czymkolwiek nowym, co w tym czasie jeszcze powstanie? :)
Język programowania jest w istocie rzeczy pochodną konstrukcji procesora.
Masz stos i z tego wynikają sposoby przekazywania danych czy wywoływania
funkcji. Z tego samego powodu rekurencja pozostaje tylko intelektualną
zabawką. Reszta to są drugorzędne szczegóły.
MC
>
> 4) A za 10 lat, mam nadzieję, będę mógł unieważnić nawet i to
> pierwsze zdanie i powiedzieć, że typowy użytkownik odnosi
> korzyść nawet z szesnastu rdzeni :)
Możesz to powiedzieć już dzisiaj. Tyle, ze dotyczy to karty graficznej,
której procesor jest typowym wielordzeniowcem i ma tych rdzeni wielokrotnie
więcej niż 16.
Ghost
Co takiego i czym liczysz?
Ghost
Użytkownik "MC" <m...@go2.pl> napisał w wiadomości
news:ijqutk$hs8$1...@node2.news.atman.pl...
> Użytkownik "Radosław Sokół" <rso...@magsoft.com.pl> napisał w wiadomości
> news:20110219...@grush.one.pl...
>>W dniu 19.02.2011 16:38, ViRuS pisze:
>>> Czyli lipa. Skoro tak, to można się domyślać, że za 10 lat procesory
>>> będą miały po 30 rdzeni i praktyczną wydajność niewiele większą od
>>> dzisiejszych :]
>>
>> Dlaczego zakładasz, że wszyscy będą używali tak badziewnych
>> programów, jakiego Ty musisz obecnie używać? ;)
>>
>> Oprogramowanie *już* dostosowuje się do przetwarzania równo-
>> ległego.
>
> Słowo "już" należy wziąć w mooooocny cudzysłów. Ile to już lat minęło
> odkąd technologia, z powodu chciwości producentów CPU, zatrzymała się w
> okolicach 3, 4 GHz?
Dobre.
Mariusz Kruk
>> Za 10 lat to będzie conajmniej 128 procesorów ;) i fantastyczna wydajność.
>> Ja mam dostęp do komputera z 4 rdzeniami(a razem 8 wątków) i jakość nie ma problemu z wykorzystaniem jego mocy
>> (średnie obciążenie 78% czyli średnio 6 wątków jest obciążonych 100%).
>> Jeżeli nie umiesz wykorzystać mocy procesora wielordzeniowego to widocznie nie zasługujesz na taki ;)
>Pracuję w DTP. Mając Adobe CS3, testując swego czasu CS5.
Dziwne te imiesłowy. Może nie aż w stopniu "idąc do szkoły świeciło
słońce", ale jakieś takie od czapki.
>Powiedz mi o
>wspaniały, jak mogę wykorzystać moc choćby dwurdzeniowego Core 2 Duo?
Normalnie - pracować na jednym monitorze, a na drugi puścić sobie
film. Wtedy drugi rdzeń też będzie mieć zajęcie ;-)
--
/\-\/\-\/\-\/\-\/\-\/\-\/\
\ Kr...@epsilon.eu.org /
/ http://epsilon.eu.org/ \
\/-/\/-/\/-/\/-/\/-/\/-/\/
Ghost
> Użytkownik "Radosław Sokół" <rso...@magsoft.com.pl> napisał w wiadomości
> news:20110220...@grush.one.pl...
>>W dniu 20.02.2011 12:45, MC pisze:
>>> Słowo "już" należy wziąć w mooooocny cudzysłów. Ile to już lat minęło
>>> odkąd technologia, z powodu chciwości producentów CPU, zatrzymała się w
>>> okolicach 3, 4 GHz? Gdyby ogłosić konkurs na największy
>>> hamulec w rozwoju informatyki oddałbym swój głos na wielordzeniowość.
>>
>> Przepraszam, a masz jakiś *dowód* na to, że wstrzymanie zwięk-
>> szania częstotliwości taktowania na 3-4 GHz wynika z "chciwo-
>> ści" producentów, a nie z braku sensowności lub ograniczeń
>> technicznych?
>
> Argument o braku sensowaności obala istnienie tego wątku. Ograniczenia
> techniczne oczywiście są, ale dotyczą one aktualnie używanych materiałów.
> Wykorzystanie innych pozwoliłoby przekroczyć tę barierę. Dowodów na to
> jest mnóstwo, chociażby tranzystor 100 GHz (chodzi w RT) na grafenie
> zrobiony w IBM. Ale to wymagałoby doprowadzenia technologii do stanu
> gotowego do zastosowania w produkcji masowej oraz przezbrojenia fabryk.
> Eden jest tuż za tą górą, tylko trzeba ją przekroczyć.
I gdyby bylo zapotrzebowanie juz dawno chciwosc zapedzilaby producentow do
tej technologii (o ile jest realna). Niestety hobbysci nie sa w stanie
sfinansowac takich kosztow.
>> Wszyscy wiemy, czym się skończyło powstanie architektury CPU
>> zbudowanej z myślą o wysokich częstotliwościach taktowania
>> (NetBurst).
>
> Ale to nie jest problem architektury, tylko tranzystorów zdolnych do pracy
> w wyższych częstotliwościach.
100Ghz powiadasz - jaka odleglosc przebiegnie sygnal w jednym takcie,
uwzgledniajac, ze to nie proznia i sa niezerowe pojemnosci itp? Ile pradu
zuzywa taki tranzystor?
>> Może za 10 lat mało kto będzie się zajmował C# lub Javą, bo
>> powstające w nich programy nie będą konkurencyjne wydajno-
>> ściowo z najlepszymi produktami pisanymi w C++, Vali, Go czy
>> czymkolwiek nowym, co w tym czasie jeszcze powstanie? :)
>
> Język programowania jest w istocie rzeczy pochodną konstrukcji procesora.
> Masz stos i z tego wynikają sposoby przekazywania danych czy wywoływania
> funkcji. Z tego samego powodu rekurencja pozostaje tylko intelektualną
> zabawką. Reszta to są drugorzędne szczegóły.
Rzeco?
Mariusz Kruk
>Ja jestem *zadowolony* z braku wzrostu częstotliwości takto-
>wania. Po pierwsze, producenci CPU w poszukiwaniu zysku mu-
>sieli zwrócić się w kierunku poprawiania wskaźników IPC,
>nie tylko poprzez wielordzeniowość, ale też superskalarność
>i optymalizację. Z kolei producenci oprogramowania już zaczy-
>nają tracić dech i odwracają się nieco od technik pozwalają-
>cych tworzyć programy "szybko" zamiast "szybkie".
Etam. Po prostu narzędzia są bardziej dopracowane. I są lepsi
programiści na rynku.
Jak ktoś się uprze, i tak użyje algorytm O(n!) zamiast O(nlogn) i żadna
technika tu nie pomoże.
>Może za 10 lat mało kto będzie się zajmował C# lub Javą, bo
>powstające w nich programy nie będą konkurencyjne wydajno-
>ściowo z najlepszymi produktami pisanymi w C++, Vali, Go czy
>czymkolwiek nowym, co w tym czasie jeszcze powstanie? :)
Zakładasz, że wydajność jest celem samym w sobie. Tymczasem istotna jest
biznesowa opłacalność projektu. Owszem, wydajność jest jej częścią, ale
tylko częścią. Istotną częścią jest również właśnie możliwość szybkiego
stworzenia oprogramowania, czy "utrzymywalność" kodu. Czy jest to
bardziej, czy mniej istotny czynnik, będzie oczywiście zależało od
konkretnego projektu.
--
\------------------------/
| Kr...@epsilon.eu.org |
| http://epsilon.eu.org/ |
/------------------------\
MC
news:ijrb6e$afl$1...@mx1.internetia.pl...
>>
>> Argument o braku sensowaności obala istnienie tego wątku. Ograniczenia
>> techniczne oczywiście są, ale dotyczą one aktualnie używanych materiałów.
>> Wykorzystanie innych pozwoliłoby przekroczyć tę barierę. Dowodów na to
>> jest mnóstwo, chociażby tranzystor 100 GHz (chodzi w RT) na grafenie
>> zrobiony w IBM. Ale to wymagałoby doprowadzenia technologii do stanu
>> gotowego do zastosowania w produkcji masowej oraz przezbrojenia fabryk.
>> Eden jest tuż za tą górą, tylko trzeba ją przekroczyć.
>
> I gdyby bylo zapotrzebowanie juz dawno chciwosc zapedzilaby producentow do
> tej technologii (o ile jest realna). Niestety hobbysci nie sa w stanie
> sfinansowac takich kosztow.
A po co mają zmieniać technologie i inwestować duże sumy skoro dzisiejsze
erzatze się sprzedają? Tylko brak sprzedaży może zmusić Intele i im
podobnych do zmiany. Ale skoro jest tylu zachwyconych dostawianiem kolejnego
rdzenia, który trudno wykorzystać, no to mamy to, co mamy. Chylę czoła przed
umiejętnością aż tak masowego ogłupienia.
>
> 100Ghz powiadasz - jaka odleglosc przebiegnie sygnal w jednym takcie,
> uwzgledniajac, ze to nie proznia i sa niezerowe pojemnosci itp? Ile pradu
> zuzywa taki tranzystor?
Pierwsze to sobie policz a o drugie zapytaj w IBM. Trochę informacji
znajdziesz tutaj:
http://www.eetimes.com/electronics-news/4087495/IBM-demos-100-GHz-graphene-transistor
>
>>> Może za 10 lat mało kto będzie się zajmował C# lub Javą, bo
>>> powstające w nich programy nie będą konkurencyjne wydajno-
>>> ściowo z najlepszymi produktami pisanymi w C++, Vali, Go czy
>>> czymkolwiek nowym, co w tym czasie jeszcze powstanie? :)
>>
>> Język programowania jest w istocie rzeczy pochodną konstrukcji procesora.
>> Masz stos i z tego wynikają sposoby przekazywania danych czy wywoływania
>> funkcji. Z tego samego powodu rekurencja pozostaje tylko intelektualną
>> zabawką. Reszta to są drugorzędne szczegóły.
>
> Rzeco?
Czego nie rozumiesz?
Norbert
>> Jeżeli nie umiesz wykorzystać mocy procesora wielordzeniowego to widocznie nie zasługujesz na taki ;)
>
> Pracuję w DTP. Mając Adobe CS3, testując swego czasu CS5. Powiedz mi o
> wspaniały, jak mogę wykorzystać moc choćby dwurdzeniowego Core 2 Duo?
No jak to? Odpal sobie 2 x PS i rysuj w obu naraz ;-)
--
pozdrawiam
Norbert
Ghost
> Użytkownik "Ghost" <gh...@everywhere.pl> napisał w wiadomości
> news:ijrb6e$afl$1...@mx1.internetia.pl...
>>>
>>> Argument o braku sensowaności obala istnienie tego wątku. Ograniczenia
>>> techniczne oczywiście są, ale dotyczą one aktualnie używanych
>>> materiałów. Wykorzystanie innych pozwoliłoby przekroczyć tę barierę.
>>> Dowodów na to jest mnóstwo, chociażby tranzystor 100 GHz (chodzi w RT)
>>> na grafenie zrobiony w IBM. Ale to wymagałoby doprowadzenia technologii
>>> do stanu gotowego do zastosowania w produkcji masowej oraz przezbrojenia
>>> fabryk. Eden jest tuż za tą górą, tylko trzeba ją przekroczyć.
>>
>> I gdyby bylo zapotrzebowanie juz dawno chciwosc zapedzilaby producentow
>> do tej technologii (o ile jest realna). Niestety hobbysci nie sa w stanie
>> sfinansowac takich kosztow.
>
> A po co mają zmieniać technologie i inwestować duże sumy skoro dzisiejsze
> erzatze się sprzedają?
Dla pieniedzy?
> Tylko brak sprzedaży może zmusić Intele i im podobnych do zmiany.
Dosc naiwnie postrzegasz rzeczywistosc biznesowa.
>> 100Ghz powiadasz - jaka odleglosc przebiegnie sygnal w jednym takcie,
>> uwzgledniajac, ze to nie proznia i sa niezerowe pojemnosci itp? Ile pradu
>> zuzywa taki tranzystor?
>
> Pierwsze to sobie policz a o drugie zapytaj w IBM.
Znaczy tak se pierdolisz, bez znajomosci stanu rzeczy.
>>>> Może za 10 lat mało kto będzie się zajmował C# lub Javą, bo
>>>> powstające w nich programy nie będą konkurencyjne wydajno-
>>>> ściowo z najlepszymi produktami pisanymi w C++, Vali, Go czy
>>>> czymkolwiek nowym, co w tym czasie jeszcze powstanie? :)
>>>
>>> Język programowania jest w istocie rzeczy pochodną konstrukcji
>>> procesora. Masz stos i z tego wynikają sposoby przekazywania danych czy
>>> wywoływania funkcji. Z tego samego powodu rekurencja pozostaje tylko
>>> intelektualną zabawką. Reszta to są drugorzędne szczegóły.
>>
>> Rzeco?
>
> Czego nie rozumiesz?
Twojego belkotu.
Maciek Babcia
"ViRuS" <ble...@blebleble.pl> napisał(a):
> Czyli lipa. Skoro tak, to można się domyślać, że za 10 lat procesory
> będą miały po 30 rdzeni i praktyczną wydajność niewiele większą od
> dzisiejszych :]
Wydajność wzrośnie. Tylko że oprogramowanie musi być napisane tak by
wykorzystywać więcej niż 1 rdzeń. Wtedy puszcza się to na klastrze
gdzie masz do dyspozycji np. kilkadziesiąt procesorów i kilkaset
rdzeni. Po prostu zamiast wysilać jeden rdzeń taniej jest rozłożyć
robotę na wiele.
Zdrówko
Przemysław Ryk
>>Pracuję w DTP. Mając Adobe CS3, testując swego czasu CS5.
>
> Dziwne te imiesłowy. Może nie aż w stopniu "idąc do szkoły świeciło
> słońce", ale jakieś takie od czapki.
>
>>Powiedz mi o
>>wspaniały, jak mogę wykorzystać moc choćby dwurdzeniowego Core 2 Duo?
>
> Normalnie - pracować na jednym monitorze, a na drugi puścić sobie
> film. Wtedy drugi rdzeń też będzie mieć zajęcie ;-)
A coś bardziej merytorycznie?
--
[ Przemysław "Maverick" Ryk ICQ: 17634926 GG: 2808132 ]
[ Bóg stworzył człowieka ponieważ rozczarował się małpą. Z dalszych ]
[ eksperymentów zrezygnował. (Mark Twain) ]
Ghost
Użytkownik "Przemysław Ryk" <przemys...@gmail.com> napisał w wiadomości
news:dv2krdnx68u6$.dlg@maverick.przemekryk.no-ip.info...
> Dnia Sun, 20 Feb 2011 16:03:47 +0100, Mariusz Kruk napisał(a):
>
>>>Pracuję w DTP. Mając Adobe CS3, testując swego czasu CS5.
>>
>> Dziwne te imiesłowy. Może nie aż w stopniu "idąc do szkoły świeciło
>> słońce", ale jakieś takie od czapki.
>>
>>>Powiedz mi o
>>>wspaniały, jak mogę wykorzystać moc choćby dwurdzeniowego Core 2 Duo?
>>
>> Normalnie - pracować na jednym monitorze, a na drugi puścić sobie
>> film. Wtedy drugi rdzeń też będzie mieć zajęcie ;-)
>
> A coś bardziej merytorycznie?
Wyatrczy, ze masz lokalnie zainstalowana aplikacje webowa, bez problemu
zatrudni trzy procesory (zwlaszcza jesli intensywnie uzywa ajaxa).
Ghost
No to bierz sie za pisanie.
Radosław Sokół
> Pracuję w DTP. Mając Adobe CS3, testując swego czasu CS5. Powiedz mi o
> wspaniały, jak mogę wykorzystać moc choćby dwurdzeniowego Core 2 Duo?
A co konkretnie w tym "CS5"? Chcesz powiedzieć, że taki
Photoshop (nie używam, nie znam) nie obsługuje przetwarzania
równoległego choćby w filtrach?
Radosław Sokół
>> 4) A za 10 lat, mam nadzieję, będę mógł unieważnić nawet i to
>> pierwsze zdanie i powiedzieć, że typowy użytkownik odnosi
>> korzyść nawet z szesnastu rdzeni :)
>
> Możesz to powiedzieć już dzisiaj. Tyle, ze dotyczy to karty graficznej, której procesor jest typowym wielordzeniowcem i ma tych rdzeni wielokrotnie więcej niż 16.
Nie mogę. Z równoległych, programowalnych GPU zysk odnoszą
tylko gracze i niektórzy obliczeniowcy. Użytkownikowi domo-
wemu czy biurowemu nic te dziesiątki czy setki ścieżek obli-
czeniowych nie dają.
Byłem zresztą ostatnio na szkoleniu z wykorzystania CUDA i
jestem niezbyt optymistycznie nastawiony do tej techniki.
GPU nadają się do zrównoleglania bardzo wąskiej grupy zagad-
nień obliczeniowych. Owszem, świetnie sobie poradzą na przy-
kład z przetwarzaniem obrazu czy obróbką wielkich macierzy,
ale brakuje im elastyczności niezbędnej do przyspieszania
typowego oprogramowania biurowo-obliczeniowego.
Radosław Sokół
> Zakładasz, że wydajność jest celem samym w sobie. Tymczasem istotna jest
> biznesowa opłacalność projektu. Owszem, wydajność jest jej częścią, ale
Zakładam, że w normalnym, konkurencyjnym środowisku wyższym
popytem będzie się cieszył produkt lepszy, a więc bardziej
niezawodny i szybszy (a najlepiej jeszcze tańszy). Gdy nie
ma czym konkurować, konkurencja schodzi do poziomu wydajno-
ści.
Niestety, trudno nazwać obecny rynek oprogramowania konkuren-
cyjnym.
Radosław Sokół
>> Przepraszam, a masz jakiś *dowód* na to, że wstrzymanie zwięk-
>> szania częstotliwości taktowania na 3-4 GHz wynika z "chciwo-
>> ści" producentów, a nie z braku sensowności lub ograniczeń
>> technicznych?
>
> Argument o braku sensowaności obala istnienie tego wątku. Ograniczenia techniczne oczywiście są, ale dotyczą one aktualnie używanych materiałów. Wykorzystanie innych pozwoliłoby przekroczyć tę
"Sensowności" w znaczeniu, że podniesienie częstotliwości
taktowania zwiększy faktycznie wydajność. O to mi chodzi.
Bo można zrobić mikroprocesor taktowany 6 GHz, który nie
będzie wcale szybszy od takiego, co ma 3 GHz, prawda?
> Ale to nie jest problem architektury, tylko tranzystorów zdolnych do pracy w wyższych częstotliwościach.
Litości! Akurat ograniczenie nie jest w tranzystorach, ale
w... połączeniach między nimi! Dlatego właśnie NetBurst miał
tak dużo etapów potoków: żeby każdy etap mógł być taktowany
wysokim zegarem, suma długości ścieżek w strukturze etapu
musiała być jak najniższa!
Już dzisiaj produkuje się tranzystory na krzemie czy arsenku
galu, które pracują ze znacznie wyższymi częstotliwościami,
niż te 5-6 GHz. Krzem spokojnie osiąga 40 GHz, GaAs podcho-
dzi chyba blisko do tych 100 GHz. Tylko nie ma jak ich za-
stosować w realnym mikroprocesorze, bo musiałby on mieć ze
40-50 malutkich etapów potoku i w efekcie nijak by wypadał
wydajnościowo (pomijam kwestie upakowania i zużycia mocy).
> Nie widzę żadnego powodu do radości w tym, że pewne cele zamiast łatwiej będzie trudniej osiągnąć.
Jest różnica między łatwym osiąganiem celu a pójściem na
łatwiznę. Programiści obecnie chodzą na łatwiznę, a nie
łatwo programują.
Boguś
>>
>> Możesz to powiedzieć już dzisiaj. Tyle, ze dotyczy to karty
>> graficznej, której procesor jest typowym wielordzeniowcem i ma tych
>> rdzeni wielokrotnie więcej niż 16.
>
> Nie mogę. Z równoległych, programowalnych GPU zysk odnoszą
> tylko gracze i niektórzy obliczeniowcy.
Kilkanaście (lub nawet więcej) milionów graczy kupując najnowszy sprzęt napędza koniunkturę i korzystają na
tym znacznie mniej liczni obliczeniowcy ;)
>
> Byłem zresztą ostatnio na szkoleniu z wykorzystania CUDA i
> jestem niezbyt optymistycznie nastawiony do tej techniki.
Jestem po testach praktycznych (niestety jeszcze nie u mnie) i mogę potwierdzić marny efekt w większości
obliczeń. I nie ma co się dziwić. Znając programy obliczeniowe wiemy, że pełno tam "if" oraz obliczeń
sekwencyjnych a to nie można zrównoleglić.
--
Boguś
Przemysław Ryk
> 0) Domyślam się, że to cytat ze mnie, bo sam tego nie pamię-
> tam, Google nie znalazł, a na domowym komputerze w archi-
(ciach...)
> pierwsze zdanie i powiedzieć, że typowy użytkownik odnosi
> korzyść nawet z szesnastu rdzeni :)
Tak z ciekawości jeszcze dorzucę - czy nie jest przy okazji tak, że dość
mocnym hamulcem jest ciągłe trzymanie się architektury x86?
--
[ Przemysław "Maverick" Ryk ICQ: 17634926 GG: 2808132 ]
[ Romantyk człowiek, któremu miłość zdarza się częściej, niż seks. ]
[ (JoeMonster.org) ]
Przemysław Ryk
> W dniu 20.02.2011 02:37, Przemysław Ryk pisze:
>> Pracuję w DTP. Mając Adobe CS3, testując swego czasu CS5. Powiedz mi o
>> wspaniały, jak mogę wykorzystać moc choćby dwurdzeniowego Core 2 Duo?
>
> A co konkretnie w tym "CS5"? Chcesz powiedzieć, że taki
> Photoshop (nie używam, nie znam) nie obsługuje przetwarzania
> równoległego choćby w filtrach?
AFAIK sporadycznie i to też tylko w niektórych. Co zresztą ładnie obrazują
wyniki uzyskane choćby w tym teście:
http://www.hardwareheaven.com/photoshop.php
Tutaj masz moje wyniki:
http://www.hardwareheaven.com/photoshop_results.php?page=view&id=587:
- Core 2 Duo E8400 @ 3,9 GHz - 191,7 sekundy
Tak na szybko dla porównania:
- Q9550 z taktowaniem 3,77 GHz - 191,2 sekundy
- Core i7-920 z taktowaniem 3,6 GHz - 190,0 sekundy
- Core i7-860 z taktowaniem 4,013 GHz - 189,7 sekundy
- Core 2 Duo E8500 z taktowaniem 4,28 GHz - 189,5 sekundy
Już wiesz, gdzie przy DTP sobie mogę te cztery czy więcej rdzeni wsadzić? :)
--
[ Przemysław "Maverick" Ryk ICQ: 17634926 GG: 2808132 ]
[ Fortuna to niestała dziwka. ]
[ (Konował, Glen Cook "Czarna Kompania") ]
Przemysław Ryk
(ciach...)
>>> Normalnie - pracować na jednym monitorze, a na drugi puścić sobie
>>> film. Wtedy drugi rdzeń też będzie mieć zajęcie ;-)
>>
>> A coś bardziej merytorycznie?
>
> Wyatrczy, ze masz lokalnie zainstalowana aplikacje webowa, bez problemu
> zatrudni trzy procesory (zwlaszcza jesli intensywnie uzywa ajaxa).
Tylko widzisz - mnie ta aplikacja webowa akurat na plaster, bo zajmuję się
zawodowo DTP. Ani Photoshop, ani InDesign, ani Illustrator, ani Acrobat, ani
Distiller wielowątkowo pracować nie chcą - ani w CS3 (którego używam), ani w
CS5 (którego ostro testowałem).
--
[ Przemysław "Maverick" Ryk ICQ: 17634926 GG: 2808132 ]
[ Gdzie w grę wchodzi miłość lub nienawiść, tam gra kobieta miernie. ]
[ (Friedrich Nietzsche) ]
Przesmiewca
>Tylko widzisz - mnie ta aplikacja webowa akurat na plaster, bo zajmuję się
>zawodowo DTP. Ani Photoshop, ani InDesign, ani Illustrator, ani Acrobat, ani
>Distiller wielowątkowo pracować nie chcą - ani w CS3 (którego używam), ani w
>CS5 (którego ostro testowałem).
Jednemu sie przyda, drugiemu nie. Ja np. wirtualizuje w jednym czasie ma
domowym pececie wiele systemow i juz zaczynam sie zastanawiac,
jak tu podmienic 4 rdzeniowca na cos innego.
Przemysław Ryk
Dlatego opisuję jednocześnie, do jakich zastosowań komp mi służy.
Niejednokrotnie już miałem ubaw z osób, które w ciemno 4-ro rdzeniowego CPU
polecały, bo przecież na pewno będzie lepszy...
--
[ Przemysław "Maverick" Ryk ICQ: 17634926 GG: 2808132 ]
[ Ashby: How'd it turn out? Moody: Hard to say. You would know better ]
[ than I. You lived the motherfucker. Ashby: Yeah, but living it right ]
[ means you don't remember much of it at all. ]
[ ("Californication 2x12 La Petite Mort") ]
Radosław Sokół
> Tak z ciekawości jeszcze dorzucę - czy nie jest przy okazji tak, że dość
> mocnym hamulcem jest ciągłe trzymanie się architektury x86?
Dłuższa odpowiedź:
http://www.grush.one.pl/article.php?id=iapx
Krótsza:
Historia dowodzi, że "lepsze" architektury wcale na dłuższą
metę nie były aż tak znacząco wydajniejsze ani oszczędniejsze.
Tak kiedyś chwalony RISC w epoce taniej elektroniki sprawdza
się głównie w prostych zastosowaniach, gdzie kosztem wydaj-
ności da się osiągnąć malutki pobór energii. W zastosowaniach
biurowo-serwerowych w zasadzie różnica jest niewielka już,
choćby dlatego, że obecne procesory x86 to w zasadzie układy
RISC z dekoderem rozkazów na wejściu :)
marfi
news:0968m6dqsk847ln7n...@4ax.com...
Oooo... Najbardziej mi się podoba, że na Q6600 mogę skutecznie zapuścić
W2k, XP, Ubuntu pod kontrola Visty 64.
--
marfi
Przemysław Ryk
>> Jednemu sie przyda, drugiemu nie. Ja np. wirtualizuje w jednym czasie ma
>> domowym pececie wiele systemow i juz zaczynam sie zastanawiac,
>> jak tu podmienic 4 rdzeniowca na cos innego.
>
> Oooo... Najbardziej mi się podoba, że na Q6600 mogę skutecznie zapuścić
> W2k, XP, Ubuntu pod kontrola Visty 64.
Jednocześnie to mi się nie zdarzało, ale bywały sytuacje, że testowałem coś
pod VMware Server - na Core 2 Duo E8400 pogonionym do 3,9 GHz spokojnie
można było się pobawić z odpalonym na wirtualnej maszynie Windows 7
(przydział 1 rdzenia i 3 GB ram). :)
--
[ Przemysław "Maverick" Ryk ICQ: 17634926 GG: 2808132 ]
[ Prawda, nawet gdy dotyczy rzeczy drobnej, przekracza niepewne poglądy ]
[ na zagadnienia naprawdę wzniosłe. (Leonardo da Vinci) ]
robot
> Tylko widzisz - mnie ta aplikacja webowa akurat na plaster, bo zajmuję się
> zawodowo DTP. Ani Photoshop, ani InDesign, ani Illustrator, ani Acrobat, ani
> Distiller wielowątkowo pracować nie chcą - ani w CS3 (którego używam), ani w
> CS5 (którego ostro testowałem).
>
Photoshop wykorzystuje 4 rdzenie ale tylko w filtrach, co w sumie
jest bez znaczenia.
--
pozdrawiam
wit
> Historia dowodzi, że "lepsze" architektury wcale na dłuższą
> metę nie były aż tak znacząco wydajniejsze ani oszczędniejsze.
> Tak kiedyś chwalony RISC w epoce taniej elektroniki sprawdza
> się głównie w prostych zastosowaniach, gdzie kosztem wydaj-
> ności da się osiągnąć malutki pobór energii. W zastosowaniach
> biurowo-serwerowych w zasadzie różnica jest niewielka już,
> choćby dlatego, że obecne procesory x86 to w zasadzie układy
> RISC z dekoderem rozkazów na wejściu :)
Trochę dziwna ta odpowiedź bo sugeruje, że RISC to taka pieśń przeszłości, i
jednocześnie, że wygrał i CISC jako takich już nie ma ;)
wit
Osadnik
> Użytkownik "ViRuS" <ble...@blebleble.pl> napisał w wiadomości
> news:ijqsh1$28q$1...@inews.gazeta.pl...
>>
>>
>>> Jak napisał obok Qbab: są problemy, których nie da się zrównoleglić.
>>> Ale wiele się da, i te powinny być zrównoleglane.
>>>
>>
>> W informatyce lepiej nie mówić, że coś jest absolutnie niemożliwe bo
>> za parę lat można wyjść na oszołoma ;) Trudno sobie wyobrazić, że
>> pętla miałaby być wykonywana przez dwa procesory. Tym niemniej na
>> każdy krok pętli procesor wykonuje jakąś czynność. Ja głowy nie dam,
>> że tej czynności nie da się rozdzielić... :) Szkoda póki co, bo to by
>> rozwiązało problem wielordzeniowości dla dowolnej ilości procesorów.
>
> To się bardzo łatwo mówi. Niestety liczba aplikacji wielowątkowych (jest
> jeszcze problem ile ma być tych wątków) jakoś nie chce specjalnie urosnąć.
I jest sporo aplikacji unikalnych które nigdy nie będą wielowątkowe.
Przemysław Ryk
W których filtrach. Konkretnie poproszę.
--
[ Przemysław "Maverick" Ryk ICQ: 17634926 GG: 2808132 ]
[ Love. The slowest form of suicide. (znalezione w necie) ]
Mariusz Kruk
>> biznesowa opłacalność projektu. Owszem, wydajność jest jej częścią, ale
>Zakładam, że w normalnym, konkurencyjnym środowisku wyższym
>popytem będzie się cieszył produkt lepszy,
Tylko ta "lepszość" dalece nie zawsze jest dobrze zdefiniowana. I nie
zawsze znaczy to samo dla różnych osób. Na praktycznie dowolnym
(pomijając niektóre bardzo ustandaryzowane) rynku.
>Niestety, trudno nazwać obecny rynek oprogramowania konkuren-
>cyjnym.
A to inna bajka niestety.
--
Kruk@ -\ |
}-> epsilon.eu.org |
http:// -/ |
|
Radosław Sokół
> Trochę dziwna ta odpowiedź bo sugeruje, że RISC to taka pieśń przeszłości, i
> jednocześnie, że wygrał i CISC jako takich już nie ma ;)
*Czysty* RISC to pieśń przeszłości. Nie masz już w zasadzie
na rynku PowerPC, Alphy, MIPSa (mówię o poważnym udziale, a
nie dostępności w ogóle!) i kilku innych architektur. Jedy-
nie SPARC chyba się jakoś jeszcze trzyma. No i oczywiście
ARM -- tylko że głównie na rynku urządzeń mobilnych, a i
tam podgryza go uproszczony x86 w postaci Atoma choćby
(a AMD też szykuje swoje rozwiązanie).
Analogicznie mało już jest "czystych" CISCów o klasycznej
architekturze, bo faktycznie skaluje się ona niezbyt dobrze.
Obecne x86 to z zewnątrz CISC, w środku RISC. Prawie RISC
(bo jest np. mało dostępnych bezpośrednio rejestrów).
I ma to jak największy sens, bo kod CISC jest bardziej
zwarty, a rdzenie RISC są szybsze.
wit
> Obecne x86 to z zewnątrz CISC, w środku RISC. Prawie RISC
> (bo jest np. mało dostępnych bezpośrednio rejestrów).
> I ma to jak największy sens, bo kod CISC jest bardziej
> zwarty, a rdzenie RISC są szybsze.
Czyli po prostu RISC. "Zewnętrzny" CISC jest tylko dla zachowania
kompatybilności.
wit
robot
>> Photoshop wykorzystuje 4 rdzenie ale tylko w filtrach, co w sumie
>> jest bez znaczenia.
>
> W których filtrach. Konkretnie poproszę.
>
Na przykład radial blur, innych nie sprawdzałem ale w razie potrzeby mogę
jeszcze posprawdzać.
--
pozdrawiam
Przemysław Ryk
>>> Photoshop wykorzystuje 4 rdzenie ale tylko w filtrach, co w sumie
>>> jest bez znaczenia.
>>
>> W których filtrach. Konkretnie poproszę.
>>
> Na przykład radial blur, innych nie sprawdzałem ale w razie potrzeby mogę
> jeszcze posprawdzać.
Byłbym wdzięczny.
--
[ Przemysław "Maverick" Ryk ICQ: 17634926 GG: 2808132 ]
[ Kiedy kobieta nie ma racji pierwsza rzecz, którą należy zrobić, to ]
[ natychmiast ją przeprosić. (Oscar Wilde) ]
Radosław Sokół
> Czyli po prostu RISC. "Zewnętrzny" CISC jest tylko dla zachowania
> kompatybilności.
Można się długo kłócić. W zasadzie jednak o zaklasyfikowaniu
procesora jako RISC lub CISC decyduje zbiór rozkazów (bo od
ukierunkowania rozkazów na rozbudowane lub uproszczone tryby
adresowania wziął się podział RISC-CISC), a nie budowa wewnę-
trzna. Można mówić, że taki i7 jest mikroprocesorem CISC o
budowie wewnętrznej przypominającej RISC, ale według mnie
zdecydowanie nie, że jest procesorem RISC.
Sergiusz Rozanski
> W dniu 23.02.2011 21:58, wit pisze:
>> Czyli po prostu RISC. "Zewnętrzny" CISC jest tylko dla zachowania
>> kompatybilności.
>
> Można się długo kłócić. W zasadzie jednak o zaklasyfikowaniu
> procesora jako RISC lub CISC decyduje zbiór rozkazów (bo od
> ukierunkowania rozkazów na rozbudowane lub uproszczone tryby
> adresowania wziął się podział RISC-CISC), a nie budowa wewnę-
> trzna. Można mówić, że taki i7 jest mikroprocesorem CISC o
> budowie wewnętrznej przypominającej RISC, ale według mnie
> zdecydowanie nie, że jest procesorem RISC.
Tzn bardzo dobrym przybliżeniem było to że w przypadku RISC
_każdy_ rozkaz zajmuje 1 cykl cpu - są to proste operacje, a
ich redukcja ilościowa też przyspiesza wykonywanie.
wit
> Można się długo kłócić. W zasadzie jednak o zaklasyfikowaniu
> procesora jako RISC lub CISC decyduje zbiór rozkazów (bo od
> ukierunkowania rozkazów na rozbudowane lub uproszczone tryby
> adresowania wziął się podział RISC-CISC), a nie budowa wewnę-
> trzna.
No można się kłócić, ale ja już nie mam zacięcia ;). Myślę, że ciężko
dzisiaj mówić o podziale RISC-CISC, RISC miał być procesorem o prostej
konstrukcji wykonującym szybko proste rozkazy, jak się to ma do
rozbudowanych algorytmów przewidywania skoków, register-renaming, data
prefetchingu, out of order exec., speculative exec. i tp.? Moim zdaniem
słabo, w takim dzisiejszym x86 więcej chyba jest logiki "kombinującej jak
mniej liczyć" niż "liczącej".
Wycofuję się ;)
wit
Piotrek
> Witam,
> Czy aktualnie istnieje już jakaś technologia pozwalająca na korzystanie z
> kilku rdzeni procesora dla programów jednowątkowych? Pracuję na takim
> programie obliczeniowym, niestety korzysta on tylko z jednego rdzenia i na
> zmiany się tu nie zanosi. Tymczasem postęp w dziedzinie sprzętu dotyczy
> tylko dokładania kolejnych rdzeni, co mnie słabo cieszy... Czy jest jakiś
> sposób na to?
>
> Pozdr,L.
Może niekoniecznie technologia ale był chyba taki program Multicore
Optimizer w którym dało się ustawiać programy tak by korzystały z kilku
rdzeni. Może to by pomogło?
Radosław Sokół
> Tzn bardzo dobrym przybliżeniem było to że w przypadku RISC
> _każdy_ rozkaz zajmuje 1 cykl cpu - są to proste operacje, a
> ich redukcja ilościowa też przyspiesza wykonywanie.
Widzę tutaj parę nieścisłości.
Przede wszystkim RISC *nigdy* nie miał redukować liczby
rozkazów. Ba, często RISCe mają bardzo dużo rozkazów, czasem
bardzo skomplikowanych nawet.
Najważniejsza zmiana polega na likwidacji trybów adresowania.
Rozkazy operują tylko na rejestrach wewnętrznych. Jedynie wy-
dzielone operacje LOAD i STORE są realizowane z wykorzysta-
niem pamięci zewnętrznej (i ew. jakichś trybów adresowania)
i w związku z tym mogą zająć więcej niż jeden cykl pracy pro-
cesora.
Zresztą mikrokontrolery AVR8, zaliczane przecież do RISCów,
wiele rozkazów realizują w 2-3 cyklach zegarowych. Choćby
instrukcje porównania i skoków, o ile pamiętam.
Radosław Sokół
> Może niekoniecznie technologia ale był chyba taki program Multicore
> Optimizer w którym dało się ustawiać programy tak by korzystały z kilku
> rdzeni. Może to by pomogło?
Nie ma możliwości, by jakieś zewnętrzne narzędzie zmieniało
sposób działania programu niedostosowanego do pracy wielo-
wątkowej.
Owszem, można zoptymalizować przyporządkowanie procesów jed-
nowątkowych do poszczególnych rdzeni, ale nie trzeba do tego
specjalnych programów i daje to bardzo niewiele.
Radosław Sokół
> AFAIK sporadycznie i to też tylko w niektórych. Co zresztą [...]
Szczerze mówiąc, spodziewałem się po Photoshopie nieco wię-
cej. Tym bardziej, że tyle się ostatnio mówiło o tym, że za-
czyna wykorzystywać nawet GPU. A tu się nagle okazuje, że
nawet wielordzeniowych CPU nie wykorzystali do końca dobrze.
Niepotrzebnie narzekałem na GIMPa, że nie przetwarza obrazu
równolegle w większości filtrów ;)
Okazuje się, że Apple ze swoim Core Image może być do przodu,
bo generowany dynamicznie kod filtrów może wykorzystywać wie-
lowątkowość i przetwarzanie równoległe na GPU. Ciekawe jak
wygląda wydajność np. Aperture w zależności od liczby rdze-
ni i typu karty graficznej.
Gotfryd Smolik news
> W dniu 06.03.2011 11:11, Sergiusz Rozanski pisze:
>> Tzn bardzo dobrym przybliżeniem było to że w przypadku RISC
>> _każdy_ rozkaz zajmuje 1 cykl cpu - są to proste operacje, a
>> ich redukcja ilościowa też przyspiesza wykonywanie.
>
> Widzę tutaj parę nieścisłości.
>
> Przede wszystkim RISC *nigdy* nie miał redukować liczby
> rozkazów. Ba, często RISCe mają bardzo dużo rozkazów, czasem
> bardzo skomplikowanych nawet.
Radku, a Ty kiedyś obejrzałeś co oznacza rozwinięcie
akronimu RISC? ;)
Bo to, że marketingowcy nazywają "riscami" różne różności,
które do RISCa mogą się mieć jak pięść do nosa, to jest
CAŁKIEM odrębna rzecz.
Nie chce mi się sprawdzać ile to instrukcji (bez PALcode)
miała np. Alpha, ale tak, to był RISC (do tego endian
neutral). To, że później "dopchnięto" istrukcje podobne
w charakterze do SSE itd to inna sprawa (widać RISC
co do idei wcale nie jest taki dobry jak go malują ;>)
> Najważniejsza zmiana polega na likwidacji trybów adresowania.
Ale to jest RAMC, nie RISC ;)
(a poważniej - dopiero drugie założenie na liście założeń RISCa)
> Zresztą mikrokontrolery AVR8, zaliczane przecież do RISCów,
> wiele rozkazów realizują w 2-3 cyklach zegarowych.
A to inna sprawa, bo wtykanie tezy o obowiązkowej
1-cyklowości do RISCa to nieporozumienie (np. procesor
który ma *skutecznie* obsługiwać architekturę systemową
wielowątkową powinien mieć jakiś mechanizm synchronizacji
typu "gwarancja że nie z cache", a to wymusza wiele taktów).
pzdr, Gotfryd
Przemysław Ryk
>> AFAIK sporadycznie i to też tylko w niektórych. Co zresztą [...]
>
> Szczerze mówiąc, spodziewałem się po Photoshopie nieco wię-
> cej. Tym bardziej, że tyle się ostatnio mówiło o tym, że za-
> czyna wykorzystywać nawet GPU. A tu się nagle okazuje, że
> nawet wielordzeniowych CPU nie wykorzystali do końca dobrze.
Na GPU akcelerowane jest AFAIR tylko powiększanie widoku i obracanie obrazu.
Nie wiem, czy którykolwiek z filtrów wykorzystuje GPU do obliczeń. No ale
skoro Adobe z takim zadęciem się chwaliło, że od InDesigna CS5 eksport do
PDFa można wykonać w tle, to co się dziwić. :D
> Niepotrzebnie narzekałem na GIMPa, że nie przetwarza obrazu
> równolegle w większości filtrów ;)
:)
> Okazuje się, że Apple ze swoim Core Image może być do przodu,
> bo generowany dynamicznie kod filtrów może wykorzystywać wie-
> lowątkowość i przetwarzanie równoległe na GPU. Ciekawe jak
> wygląda wydajność np. Aperture w zależności od liczby rdze-
> ni i typu karty graficznej.
Nie moja bajka akurat, bo z japkami mi jakoś nie po drodze. :D
--
[ Przemysław "Maverick" Ryk ICQ: 17634926 GG: 2808132 ]
[ Kobieta jest jak cień, gdy ją gonisz - ucieka; gdy Ty podążasz ]
[ w przeciwnym kierunku - ona podąża za Tobą. ]
MC
news:20110312...@grush.one.pl...
>
> Przede wszystkim RISC *nigdy* nie miał redukować liczby
> rozkazów. Ba, często RISCe mają bardzo dużo rozkazów, czasem
> bardzo skomplikowanych nawet.
Ale miałyby ich jeszcze wiecej gdyby nie...
> Najważniejsza zmiana polega na likwidacji trybów adresowania.
> Rozkazy operują tylko na rejestrach wewnętrznych. Jedynie wy-
> dzielone operacje LOAD i STORE są realizowane z wykorzysta-
I właśnie na likwidacji rozmaitych trybów adresowania polega ta redukcja
która tkwi w nazwie.
MC
news:20110312...@grush.one.pl...
>> Może niekoniecznie technologia ale był chyba taki program Multicore
>> Optimizer w którym dało się ustawiać programy tak by korzystały z kilku
>> rdzeni. Może to by pomogło?
>
> Nie ma możliwości, by jakieś zewnętrzne narzędzie zmieniało
> sposób działania programu niedostosowanego do pracy wielo-
> wątkowej.
>
> Owszem, można zoptymalizować przyporządkowanie procesów jed-
> nowątkowych do poszczególnych rdzeni, ale nie trzeba do tego
> specjalnych programów i daje to bardzo niewiele.
Widzę, że w końcu wychodzi na moje.
Radosław Sokół
> I właśnie na likwidacji rozmaitych trybów adresowania polega ta redukcja która tkwi w nazwie.
Owszem, tylko że większość uznaje, że redukcja dotknęła
mnemoników ("zlikwidowano skomplikowane rozkazy, są tylko
najprostsze") a nie konkretnych kodów rozkazów (których
faktycznie jest o niebo mniej właśnie z racji braku koniecz-
ności kodowania w rozkazie informacji o operandzie).
Radosław Sokół
> Na GPU akcelerowane jest AFAIR tylko powiększanie widoku i obracanie obrazu.
Tak, to wiem.
> Nie wiem, czy którykolwiek z filtrów wykorzystuje GPU do obliczeń. No ale
O ile mi wiadomo -- nie.
MC
news:20110312...@grush.one.pl...
>> I właśnie na likwidacji rozmaitych trybów adresowania polega ta redukcja
>> która tkwi w nazwie.
>
> Owszem, tylko że większość uznaje, że redukcja dotknęła
> mnemoników ("zlikwidowano skomplikowane rozkazy, są tylko
> najprostsze") a nie konkretnych kodów rozkazów (których
> faktycznie jest o niebo mniej właśnie z racji braku koniecz-
> ności kodowania w rozkazie informacji o operandzie).
Dla mnie to rozróżnienie jest mocno akademickie. Przecież i tak np. operacji
arytmetycznych nie wykonuje się w RAM-ie nawet jeśli istnieje taki rozkaz.
Musi nastąpić pobranie, a po wykonaniu operacji - odesłanie.
Gotfryd Smolik news
> Użytkownik "Radosław Sokół" <rso...@magsoft.com.pl> napisał
[...]
>> Owszem, tylko że większość uznaje, że redukcja dotknęła
>> mnemoników ("zlikwidowano skomplikowane rozkazy, są tylko
>> najprostsze")
[...]
Ja jestem w tej większości :>
>> a nie konkretnych kodów rozkazów (których
>> faktycznie jest o niebo mniej właśnie z racji braku koniecz-
>> ności kodowania w rozkazie informacji o operandzie).
To jest kolejny element. *Kolejny*, nie pierwszy. Patrz niżej.
> Dla mnie to rozróżnienie jest mocno akademickie. Przecież i tak np. operacji
> arytmetycznych nie wykonuje się w RAM-ie nawet jeśli istnieje taki rozkaz.
> Musi nastąpić pobranie, a po wykonaniu operacji - odesłanie.
Zgoda. Ale konstrukcyjnie różnica jest - w przypadku złożonych
metod adresowania odwołania musi "rozgryźć" elektronika procesora,
dekodując złożony rozkaz (a raczej jego pola bitowe), w przypadku
prymitywów - jest to zadanie dla kompilatora (z dołożeniem
w praktyce kawałkowi odpowiedzialnemu za optymalizację) plus
(jeśli w assemblerze) programisty.
Niemniej to jest "część druga".
Wracając do "sprawy CISC".
"typowy CISC", dajmy na to taki VAX, miał w architekturze takie
podstawowe :P rozkazy jak dzielenie wielomianów tudzież liczenie
CRC czy też "skok tablicowy" (niemal wprost implementację Fortranowego
"obliczane GOTO").
W tym świetle uznawanie x86 za CISC jest takie bardziej... marketingowe
właśnie, w nim jest więcej złozoności wynikłej z kompatybilności
wstecznej niż CISCa ;)
Fakt, że instrukcje mogły (w przykładowym VAXie) wskazywać
operandy na 3. poziomie wskaźników (z możliwością dodawania przesunięcia
jednocześnie na 2 poziomach, i to zarówno z rejestru jak i bezpośrednio!)
jest już IMO "dodatkowy", i tu się nieco rozmijam z Radkiem :)
(wersja o "złożoności adresowania" prowadzi do równie dużej różnicy
między "prawdziwym CISCem" typu VAXa a "uproszczonym CISCiem" w postaci
x86, trochę komplikacji zapewnia tylko fakt istnienia segmentacji w x86).
pzdr, Gotfryd
Radosław Sokół
> Dla mnie to rozr�nienie jest mocno akademickie. Przecie� i tak np. operacji arytmetycznych nie wykonuje si� w RAM-ie nawet je�li istnieje taki rozkaz. Musi nast�pi� pobranie, a po wykonaniu operacji
> - odes�anie.
I w�a�nie to pobranie i odes�anie powoduje, �e dekodowanie
rozkaz�w jest znacznie wolniejsze. Ponadto utrudnia si�
okre�lanie zale�no�ci rozkaz�w, a wi�c i zmniejsza mo�li-
wo�� skutecznej zmiany kolejno�ci realizacji operacji.
Mikroprocesory RISC s� w stanie zmienia� kolejno�� odczyt�w
i zapis�w do pami�ci nawet. W rodzinie Intela jest to zaka-
zane -- wszystkie odczyty i zapisy musz� by� w kolejno�ci
zapisanej w programie (co upraszcza oprogramowanie, ale
zmniejsza wydajno��).
--
|""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
| Rados�aw Sok� | http://www.grush.one.pl/ |
| | Politechnika �l�ska |
\........................................................../