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.

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?

Nie istnieje. Stad pytania o oplacalnosc zakupu szybszego X2 lub wolniejszego X4.

--
Pozdr
G

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

Użytkownik "Boguś" <telemorele@wp.pl> napisał w wiadomości news:4d5fc260$0$2495$65785112news.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

ViRuS napisał:

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ś

W dniu 11-02-19 19:45, Boguś pisze:

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

Dnia Sat, 19 Feb 2011 19:45:26 +0100, Boguś napisał(a):

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

epsilon$ while read LINE; do echo \>"$LINE"; done < "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.

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

--
/\-\/\-\/\-\/\-\/\-\/\-\/\ \  Kruk@epsilon.eu.org   / / http://epsilon.eu.org/ \ \/-/\/-/\/-/\/-/\/-/\/-/\/

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?

--
[ 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) ]

Użytkownik "Przemysław Ryk" <przemyslaw.ryk@gmail.com> napisał w wiadomości news:dv2krdnx68u6$.dlgmaverick.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).

Dnia Mon, 21 Feb 2011 22:14:04 +0100, Ghost napisał(a):

(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) ]

Przemysław Ryk <przemyslaw.ryk@gmail.com> napisał(a):

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.

Dnia Tue, 22 Feb 2011 21:17:04 +0100, Przesmiewca napisał(a):

Przemysław Ryk <przemyslaw.ryk@gmail.com> napisał(a):

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.

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") ]

Użytkownik "Przesmiewca" <przesmiewca@vpp.com.pl> napisał w wiadomości news:0968m6dqsk847ln7nt0u432nc8bs668qdv4ax.com...

Przemysław Ryk <przemyslaw.ryk@gmail.com> napisał(a):

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.

  Oooo... Najbardziej mi się podoba, że na Q6600 mogę skutecznie zapuścić W2k, XP, Ubuntu pod kontrola Visty 64.

--
marfi

Dnia Tue, 22 Feb 2011 22:48:03 +0100, marfi napisał(a):

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

W dniu 2011-02-22 21:00, Przemysław Ryk pisze:

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

Dnia Wed, 23 Feb 2011 08:43:40 +0100, robot napisał(a):

W dniu 2011-02-22 21:00, Przemysław Ryk pisze:

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.

W których filtrach. Konkretnie poproszę.

--
[ Przemysław "Maverick" Ryk                   ICQ: 17634926    GG: 2808132 ]
[ Love. The slowest form of suicide.                  (znalezione w necie) ]

W dniu 2011-02-23 09:51, Przemysław Ryk pisze:

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

Dnia Fri, 04 Mar 2011 10:41:30 +0100, robot napisał(a):

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

Dnia Sun, 20 Feb 2011 02:37:48 +0100, Przemysław Ryk napisał(a):

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

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?

--
|""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
| Radosław Sokół  |  http://www.grush.one.pl/              |
|                 |  Politechnika Śląska                   |
\........................................................../

Dnia Tue, 22 Feb 2011 18:17:14 +0100, Radosław Sokół napisał(a):

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") ]

W dniu 22.02.2011 21:00, Przemysław Ryk pisze:

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.

--
|""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
| Radosław Sokół  |  http://www.grush.one.pl/              |
|                 |  Politechnika Śląska                   |
\........................................................../

Dnia Sat, 12 Mar 2011 14:53:57 +0100, Radosław Sokół napisał(a):

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

W dniu 12.03.2011 19:05, Przemysław Ryk pisze:

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.

--
|""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
| Radosław Sokół  |  http://www.grush.one.pl/              |
|                 |  Politechnika Śląska                   |
\........................................................../

Użytkownik "Boguś" <telemorele@wp.pl> napisał w wiadomości news:4d600fbf$0$2445$65785112news.neostrada.pl...

ViRuS napisał:

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

Co takiego i czym liczysz?

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.

--
|""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
| Radosław Sokół  |  http://www.grush.one.pl/              |
|                 |  Politechnika Śląska                   |
\........................................................../

Użytkownik "Radosław Sokół" <rsokol@magsoft.com.pl> napisał w wiadomości news:2011021918550000grush.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

W dniu 19.02.2011 20:51, marfi pisze:

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ół  |  http://www.grush.one.pl/              |
|                 |  Politechnika Śląska                   |
\........................................................../

Użytkownik "Radosław Sokół" <rsokol@magsoft.com.pl> napisał w wiadomości news:2011022013165400grush.one.pl...

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.

W dniu 20.02.2011 15:31, MC pisze:

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ół  |  http://www.grush.one.pl/              |
|                 |  Politechnika Śląska                   |
\........................................................../

Radosław Sokół napisał:

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ś

Dnia Sun, 20 Feb 2011 14:16:56 +0100, Radosław Sokół napisał(a):

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

W dniu 22.02.2011 20:50, Przemysław Ryk pisze:

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

--
|""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
| Radosław Sokół  |  http://www.grush.one.pl/              |
|                 |  Politechnika Śląska                   |
\........................................................../

Radosław Sokół <rsokol@magsoft.com.pl> wrote:

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

W dniu 23.02.2011 08:51, wit pisze:

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.

--
|""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
| Radosław Sokół  |  http://www.grush.one.pl/              |
|                 |  Politechnika Śląska                   |
\........................................................../

Radosław Sokół <rsokol@magsoft.com.pl> wrote:

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

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.

--
|""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
| Radosław Sokół  |  http://www.grush.one.pl/              |
|                 |  Politechnika Śląska                   |
\........................................................../

Dnia 05.03.2011 Radosław Sokół <rsokol@magsoft.com.pl> napisał/a:

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.

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.

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ół  |  http://www.grush.one.pl/              |
|                 |  Politechnika Śląska                   |
\........................................................../

On Sat, 12 Mar 2011, Radosław Sokół wrote:

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

Użytkownik "Radosław Sokół" <rsokol@magsoft.com.pl> napisał w wiadomości news:2011031212482300grush.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.

W dniu 12.03.2011 20:22, MC pisze:

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ół  |  http://www.grush.one.pl/              |
|                 |  Politechnika Śląska                   |
\........................................................../

Użytkownik "Radosław Sokół" <rsokol@magsoft.com.pl> napisał w wiadomości news:2011031219410100grush.one.pl...

W dniu 12.03.2011 20:22, MC pisze:

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.

On Sat, 12 Mar 2011, MC wrote:

Użytkownik "Radosław Sokół" <rsokol@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

W dniu 12.03.2011 21:42, MC pisze:

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

Radosław Sokół <rsokol@magsoft.com.pl> wrote:

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

Użytkownik "Radosław Sokół" <rsokol@magsoft.com.pl> napisał w wiadomości news:2011021918550000grush.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? Gdyby ogłosić konkurs na największy hamulec w rozwoju informatyki oddałbym swój głos na wielordzeniowość.

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?

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

--
|""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
| Radosław Sokół  |  http://www.grush.one.pl/              |
|                 |  Politechnika Śląska                   |
\........................................................../

Użytkownik "Radosław Sokół" <rsokol@magsoft.com.pl> napisał w wiadomości news:2011022013212900grush.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ć.

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.

Użytkownik "MC" <m5c@go2.pl> napisał w wiadomości news:ijr8f3$sk0$1node2.news.atman.pl...

Użytkownik "Radosław Sokół" <rsokol@magsoft.com.pl> napisał w wiadomości news:2011022013212900grush.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?

Użytkownik "Ghost" <ghost@everywhere.pl> napisał w wiadomości news:ijrb6e$afl$1mx1.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?

Użytkownik "MC" <m5c@go2.pl> napisał w wiadomości news:ijrou2$fdi$1node2.news.atman.pl...

Użytkownik "Ghost" <ghost@everywhere.pl> napisał w wiadomości news:ijrb6e$afl$1mx1.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.

W dniu 20.02.2011 15:28, MC pisze:

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

--
|""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
| Radosław Sokół  |  http://www.grush.one.pl/              |
|                 |  Politechnika Śląska                   |
\........................................................../

epsilon$ while read LINE; do echo \>"$LINE"; done < "Radosław Sokół"

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.

--
\-- -- -- -- -- -- -- -- -- -- -- -- / |  Kruk@epsilon.eu.org   | | http://epsilon.eu.org/ | /-- -- -- -- -- -- -- -- -- -- -- -- \

W dniu 20.02.2011 16:13, Mariusz Kruk pisze:

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ół  |  http://www.grush.one.pl/              |
|                 |  Politechnika Śląska                   |
\........................................................../

epsilon$ while read LINE; do echo \>"$LINE"; done < "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,

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

Użytkownik "MC" <m5c@go2.pl> napisał w wiadomości news:ijqutk$hs8$1node2.news.atman.pl...

Użytkownik "Radosław Sokół" <rsokol@magsoft.com.pl> napisał w wiadomości news:2011021918550000grush.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.

"ViRuS" <bleble@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 :]

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.

Dnia Sat, 19 Feb 2011 21:11:42 +0100, Przesmiewca napisał(a):

"ViRuS" <bleble@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 :]

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.

Jak napisał obok Qbab: są problemy, których nie da się zrównoleglić.
Ale wiele się da, i te powinny być zrównoleglane.

--
GLaF

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.

Użytkownik "ViRuS" <bleble@blebleble.pl> napisał w wiadomości news:ijqsh1$28q$1inews.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ąć.

Użytkownik "MC" <m5c@go2.pl> napisał w wiadomości news:ijqv8d$i5d$1node2.news.atman.pl...

Użytkownik "ViRuS" <bleble@blebleble.pl> napisał w wiadomości news:ijqsh1$28q$1inews.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ąć.

No to bierz sie za pisanie.

W dniu 2011-02-20 12:51, MC pisze:

Użytkownik "ViRuS" <bleble@blebleble.pl> napisał w wiadomości
news:ijqsh1$28q$1inews.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.

Dnia 2011-02-19, o godz. 16:38:29
"ViRuS" <bleble@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

Dnia Sat, 19 Feb 2011 11:02:50 +0100, ViRuS napisał(a):

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?

W dniu 10.03.2011 22:34, Piotrek pisze:

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ół  |  http://www.grush.one.pl/              |
|                 |  Politechnika Śląska                   |
\........................................................../

Użytkownik "Radosław Sokół" <rsokol@magsoft.com.pl> napisał w wiadomości news:2011031212493000grush.one.pl...

W dniu 10.03.2011 22:34, Piotrek pisze:

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.