Och, jakże niewiele spośród tych rozlicznych programów, zalegających w pamięci RAM typowo użytkowanych PC, w rzeczywistości pracuje. One sobie leżą i czekają, aż użytkownik wykrzesa z siebie jakieś zainteresowanie dla nich.
A z tym "zapchaniem" jednego jądra przez SO to już w ogóle jakieś nieporozumienie...

Od siebie dodam tylko przypomnienie, że i tak nie mamy na dzień dzisiejszy nic lepszego od Core 2 Duo. Aktualnie platformy AMD 4x4 i 2xC2D alias C2Q nie są ani specjalnie dobre, ani jakoś specjalnie opłacalne - nawet dla szeroko rozumianych profesjonalistów. Przede wszystkim nie ma jednak powszechnego, dobrze zrównoleglonego oprogramowania. Dlatego premiera K8L i prawdziego czterordzeniowca od Intela poprawi sytuację trochę, ale tylko trochę. Reszta w rękach ewolucji.

Alez ja nie jestem przeciwnikiem wielordzeniowosci. Wrecz przeciwnie. Udowadnialem tylko, ze tworzenie oprogramowania, ktore w pelni wykorzysta takie prockie nie jest latwe, jak to niektorzy uparcie udowadniaja... Tu nie wystarczy Delphi i tutoriale z netu... A bez takich aplikacji zyskujemy tylko kilka procent wydajnosci + komfort pracy na zwawym systemie. Placac ciezka kase za kazdy dodatkowy rdzen wymagamy przeciez nieco wiecej, prawda?

Co do gier - nie chodzi o przyzwyczajenia, tylko o sam proces zachodzący w grze - logika gry musi polegać na poprzednich stanach, grafika musi poczekać na logikę itd. Trzeba by rozbić poszczególne elementy składające się na logikę konkretnej gry, stąd trudność, bo do każdego przypadku trzeba będzie podejść oddzielnie.

Co do języków programowania - C i C++ są niewystarczające dla bieżących zadań stojących przed programistą (inne powody niż wątki), stąd powstanie javy i c#/.net (przy czym ten drugi będzie wiodącym językiem, także dla gier pod windows vista). Skoro powstały te dwa języki, bo C/C++ były niewystarczające dawniej, to czemu nie miał by powstać nowy język, który uwzględnia wymagany nowy poziom abstrakcji, którym jest wielowątkowość? Być może "stare" języki uzupełnione o openmp staną się standardem programowania, ale ponieważ teraz cały rozwój idzie w stronę rdzeni, więc logicznym jest oczekiwać postępu także w dziedzinie języków.
Przesyłanie danych paczkami jest dobrym pomysłem, ale jaka jest potrzeba kontrolowania tego ręcznie, strugania własnej synchronizacji, skoro można po prostu oznaczyć części kodu nowymi konstrukcjami wysokiego poziomu, tak jak np. w openmp i pozwolić kompilatorowi martwić się o synchronizację? Można rzeźbić, ale po co? Przecież nie tak trudno sobie wyobrazić wykonanie tej pracy przez kompilator.
Może nawet warto by użyć jeden rdzeń do analizy kodu w trakcie uruchamiania w celu podziału na inne rdzenie ;p?


No właśnie nie płaci się wiele za drugi rdzeń, przynajmniej nie więcej niż dawniej się płaciło za topowe wersje procesorów.
Tutoriale do programowania wątków też się znajdują na sieci, i nie jest to jakaś wyższa szkoła jazdy.

przeciez jasno napisalem w niektorych przypadkach podwojenie l2 moze przyniesc przyrost mocy, w niektorych przypadkach to nie zawsze. nie tlumacz mi roznicy poemiedzy natywnym 4rdzeniowcem a sklejonymi dwu rdzeniowcami...

Sam piszesz, że w przypadku gier często może być tak, iż potrzebne będzie indywidualne podejście do konkretnych problemów. Pytanie więc, czy nawet jeśli już powstaną nowe języki, to czy będą one naprawdę dość elastyczne? I ile czasu potrzeba na ich stworzenie? A co do rzeźnienia w kodzie - w sumie cały proces programowania sprowadza się do rzeźbienia - na tym czy innym etapie. Przyzwyczajenia i wyrobione schematy skracją ten proces - teraz trzeba zmienić i przyzwyczajenia i schematy, ponieważ zmienił się paradygmat (czy raczej: wciąż powoli się zmienia).

Co do wystarczalności języków, to każdy, nawet najprostszy język wystarczy do wszystkiego... z tym, że niekoniecznie będzie do wszystkiego najwygodniejszy. I tu dochodzimy do teorii języków i podwalin samego sposobu programowania. Otóż osobiście widzę tu duże możliwości poprawy i szansę zmiany sposobu programowania na zawsze (i na lepsze). Z tym, że ktoś to musi zrobić, a ja nie mam czasu Oczywiście może powstać cokolwiek, co ułatwi programowanie kodu równoległego dla wielu rdzeni, ale na razie trudo sobie coś takiego wyobrazić... W znaczeniu: Coś równie łatwego w zastosowaniu, co uniwersalnego. Prędzej powstaną frameworki i biblioteki pod konkretne problemy, niż jakieś kompleksowe rozwiązanie. Pożyjemy, zobaczymy. Jedno jest pewne: Czas i środki potrzebne do takiej przemiany są ogromne, więc w najblizszym czasie możemy się tylko zrelaksować. Nie ma co czekać w napięciu na coś, co szybko nie nadejdzie, bo można dostać wrzodów

A to co piszesz o podziale kodu (w zasadzie powinno być: zadań) na wiele rdzeni, to dokładnie tak się programuje CELL. Główny rdzeń oprócz tego, że jest to wariant PowerPC ogólnego zastosowania, ma przede wszystkim bojowe zadanie dzielić zadania pomiędzy rdzenie wektorowe, równoważyć ich obciążenie, oraz łączyć wyniki ich pracy w jedną całość. Sam kod pisany pod jeden wątek to straszna kula u nogi przy próbie podziału na kilka rdzeni, jednak rozplanowanie algorytmu na równoległe zadania rozwiązuje ten problem i pozwala wycisnąć maksimum wydajności. No ale tego trzeba się uczyć praktycznie od nowa. Jest to zupełnie nowy paradygmat, więc trzymanie się starych schmatów i zrównoleglanie na siłę nie sprawdzi się na dłuższą metę - zwłaszcza przy rosnącej stale liczbie rdzeni. Życzę sobie i wszystkim, żeby w nieodległej przyszłosci wszystkie aplikacje skalowały się płynnie do liczby dostępnych rdzeni co najmniej tak, jak renderer Cinema 4D

... sa jeszcze programy inzynierskie do symulacji, takze te 4 rdzenie napewno sie przydadza w takim SmartSpice ;P

Brrrrr. PSpice. Koszmar powraca. Piła, pamiętasz ?

Ad rem.
Moim zdaniem żaden kompilator nie da rady sam optymalnie rozdzielić programu na rdzenie. To znaczy lokalnie może dać radę, ale tak naprawdę frukta kryją się w PRZEMYŚLENIU problemu - a to na razie (dzięki Bogu!) domena programistów jednak. Tylko globalna optymalizacja, której kompilator nie podoła, zapewni największy wzrost wydajności. Trzeba przemyśleć, które zadania można wykonywać równolegle, gdzie są punkty sychronizacji itd. Nie wszystkie zadania da się zrównoleglić.
W grach np. jeden rdzeń może zajmować się obsługą AI. Ale tego sam kompilator nie wymyśli. On może wymyślić jedynie jak tą malutką pętelkę w środku rozłożyć.


Pozdrawiam,
S.

W sumie racja 90% softu w uruchominego na kompie nic nie robi
Może zapchanie jednego jądra to przesada ale z pewnością wybajeżony system potrafi nieźle spowolnić kompa do tego jakiś antyvirus .... ziarnko do ziarnka i zbierze sie miarka. Ja napewno gdybym miał lepszy sprzet to uruchamiał bym naraz więcej programów i moze nawet używał bym jakiegoś topornego systemu niewiadomo czas pokarze.....

Najprostszy język nie wystarczy np. nie powstają żadne większe aplikacje w asemblerze. Fizycznie nie starczyło by programistów na świecie, żeby napisać w tym duży program. Tak samo z rdzeniami - jak będzie ich kilkadziesiąt, to wszystko jedno czy uzyskasz 10% na rdzeniu dzięki kompilatorowi w minutę, czy 90% przyspieszenia po rzeźbieniu latami.
Zauważ, że są ludzie którzy wierzą w "reverse hyperthreading", czyli wykonanie sprzętowe tego, o czym mówię do około 2010-2015 roku. Łatwiej będzie wykonać to programowo - bo program jest na wyższym poziomie abstrakcji, jest łatwiejszy do analizy.
Dzisiejsze języki są nieprzystosowane, ze względu na ograniczenia, jakim podlega napisany w nich kod, które zostały narzucone zanim pomyślano o zrównoleglaniu. Dlatego w C++ potrzeba specjalnego frameworku, ręcznego oznaczania na różne sposoby sekcji kodu. To mogło by być zrobione lepiej w jakimś nowym języku, który nie narzuca kompatybilności z starociami typu C.
Zajrzyj np. do tego artykułu:
http://www.devx.com/amd/Article/29117
http://developer.amd.com/article_print.jsp?id=11
Jak widać, nie jest to wielkie halo zrobić coś takiego.

Ze sie wtrace... ale gdzie najwazniejsze zastosowanie takich procesorow? Czemu nie ma postawionego Linuxa z jakimis kilkoma serwerami terminalowymi? Z realnych aplikacji wieloprocesorowych mamy 3DMaxa i Winrara i pozniej wnioski ze "4 rdzenie sie nie przydaja". Gdyby tak bylo to by nie powstawaly takie konstrukcje jak specjalizowane 48 rdzeniowce Azul'a. No ja przepraszam.

Skoro już zabrnęliśmy w dyskusję o programowaniu na platformy wielordzeniowe, to pozwolę sobie przypomnieć Mitosis...
http://pclab.pl/art21258.html

RS wracam do naszej dyskusji o i860.
Faktyczne jestem naocznym świadkiem historii.

Można powiedzieć że wszystko już było, patrząc na
wielką rewelacje AMD polegającą na integracji procesora graficznego wewnątrz CPU.

Jest to temat na bardzo ciekawy artykuł z historii dziejów komputeryzacji.

A co do problemów z wielordzeniowością a tym samym wieoprocesorowością.

Dawno dawno temu ktoś wymyślił Transputer i taki magiczny język Occam.
(Sewgo czasu Transputery można było podłaczyć do Atari ST.)
Co ciekawe, dodawało się kostki i moc obliczeniowa "sama" rosła.
Wynika z tego że stworzenie dobrego rozwiązania wieloprocesorowego
nie jest nie możliwe. To kwestia czasu ewentualnie sięgnięcia w przeszłość.
Wcześniej wydawało się że moc obliczeniowa jest nieograniczona - > MHz
mogą wszystko. Dziesięciolecie lub 2 temu był ten sam problem co dzisiaj.
Nie sposób było istotnie przyspieszyć procesory przez MHz, stąd wieloprocesorowość. Technologia poszła do przodu przybyło MHz, procesory supersckalarne. Jeżeli starczy czasu zobaczymy pewnie dobrą wieloprocesorowość.
Jeżeli inżynieria materiałowa będzie szybsza, znowu dzisiejsze transputery trafią do szuflady.


Transputery mogą być nawet pierwowzorem dla HyperTransport
Coś takiego już tam było.

To zabawne, młodsi koledzy spierają się czy to będzie możliwe.
To już było możliwe dawno temu.
Problemem może być tylko wpasowanie tego w x86.
Czy ta stara chabeta jeszcze coś będzie wstanie pociągnąć.
Tyle jej naładowali na grzbiet, że nikomu nie chce się zmieniać wierzchowca.

Dodam jeszcze, że w Poznaniu dostępna jest instalacja Transputerowa.
Parastation - 12 węzłów T805
Tandemnode - 64 węzły T800

Jako żywo przypomina to dzisiejsze serwery z Opteronami
Pamięć ram przyłączona do procesorów.
4 połączenia do innych procesorów.

Nic nowego pod słońcem, a były to lata 80 czasy Amigi Atari ST a nawet Commodore 64.

Pomyliły mi się guziki, prosze to usunąć.

No racja, jeśli napisze się nawet długi program w asemblerze, to nie będzie on duży A co do tego, że by nie starczyło programistów, to bym sie nie zakładał. W asm można stosować makrobloki oraz struktury (na poziomie praktycznie każdego kompilatora), więc z powodzeniem można zrobić wszystkie potrzebne konstrukcje a'la C (który to sam w sobie jest bardzo prosty, a mimo to jaki potężny...). Tylko po co kombinować? Mój przykład miał służyć jedynie pokazaniu, że to nie brak narzędzi jest główną przeszkodą w rozwoju aplikacji równoległych.

Nie mogę się zgodzić, że dla 90% przyspieszenia z każdym rdzeniem trzeba rzeźbić jeden kod latami. Owszem - uczyć się latami takiego programowania, to tak, ale potem to już z górki I jeśli mamy podwajać liczbę tranzystorów, zużycie energii, wydzielane ciepło, żeby pisać jednowątkowo i liczyć na 10% przyspieszenia dzięki kompilatorom, to jest to jakieś ciężkie nieporozumienie.

Co do "reverse hyperthreading", szczególnie na poziomie programowym, to można to między bajki włożyć. Takie jest moje zdanie. No chyba, że nadal gramy o maksimum 10% przyrostu wydajności na rdzeń. Poza tym popatrz na rynek superkomputerów - buduje się takie od lat, ale jakoś nikt nie wpadł na przyspieszanie jednego wątku będąc w posiadaniu architektury wieloprocesorowej (OK, przynajmniej ja nic takiego nie słyszałem, ale to wcale nie znaczy, że nie mam racji Na pewno nic takiego się powszechnie nie stosuje.) "Reverse-hyperthreading" pewnie będzie tym samym co "Hyper-Threading" Intela pod NetBurst - czyli praktycznie niczym.

Co do ułomności C++, to przypominam, że może i nie ułatwia on programowania równoległego, ale też nie utrudnia. W C i C++ od lat pisze się kod dla maszyn wieloprocesorowych. Nie znaczy to oczywiście, że nie da się wymysleć nic lepszego - wspominałem już o tym. Oznacza to raczej, że nie tu tkwi główny hamulec pełnego wykorzystania wieloprocesorowości. A to, że faktycznie trzeba w C++ odwoływać się do systemu, żeby używać wątków niczego nie zmienia (a'propos linków) - wszak C# i Java też nie mają przenośnego między sobą kodu C++ daje olbrzymią wolność, trzeba tylko umieć ją wykorzystać. Poza tym kod wykonywalny, nie ważne czy jego źródło było napisane w C# czy C++ i tak celem obsługi wielowątkowości będzie gdzieś na samym dole odwoływać się do systemu. W pierwszym linku jest mowa dokładnie o tym, o czym cały czas mówię: Pisanie od zera z podziałem zadań jest czymś, od czego programiści nie uciekną. Chwilowe zabawy z kompilatorami to efekt niemocy (braku nowego kodu i umiejętności jego pisania), ewentualne zabawy z frameworkami dają lepsze efekty, ale oczywiście lepiej stworzyć od zera potrzebne algorytmy w wersji równoległej - i to się w końcu stanie, programy będą czerpać maksimum mocy z wielu rdzeni i płynnie się skalować do ich liczby, ale musimy na to jeszcze długo poczekać.




Bo niewiele osób w domu ma coś takiego. Mowa o popularnych zastosowaniach typu desktop i workstation, a nie o przeróżnej maści serwerach. Owszem, na takich procesorach buduje się tanie serwery, z tym, że główny rynek serwerów już dawno oferuje wieloprocesorowość i wielordzeniowość dla specjalistycznych zastosowań (kwestia rożnicy w kosztach). Nas interesuje jak popularny i tani sprzęt klasy mainstream PC sprawdza się w zastosowaniach typu "personal computing" i na ile rynek oprogramowania pisanego dla takich PC jest gotów na wielordzeniowość.




A da się sprawdzić, o ile rosła? Patrzę na problem czysto algorytmicznie i jakoś nie wierzę w cuda. Jeśli rosła o 10%, co jest ostatnio często lansowanym na tym wątku przyspieszeniem to takie wynalazki sprowadzają się do klasycznego "dużo dymu, mało ognia".

Jak napiszemy "C" w asemblerze, to nie będziemy już pisać w asemblerze, tylko w "C". Języki wyższego poziomu mają to do siebie, że uogólniając, likwidują pewne rzadko używane "pułapki" języków niższego poziomu. Poprawny język wspierający wielowątkowość powinien właśnie "zachęcać" do pisania równoległego kodu, nie ma powodu żeby umożliwiał to, co już jest w innych językach.


To był skrajny przykład, odpowiedni kompilator mógłby dać lepsze efekty. Nie chodziło mi też o to, żeby pisać jednowątkowo, tylko o to, że ręczne rozpisywanie zadań na wątki nie ma takiej wielkiej przyszłości jak uważasz.
Po pierwsze niedługo nie będzie znana liczba rdzeni, na których pracuje program - więc zadanie będzie musiało być rozdzielone automatycznie tak czy inaczej - czemu więc nie przez kompilator?
Po drugie kompilator będzie mądrzejszy od programisty w kwestii rozdzielania wątków, tak jak dziś jest mądrzejszy w kwestii optymalizacji kodu (stosowanie wstawek asemblerowych w 99% przypadków nie ma sensu).


Hyperthreading dał średnie przyspieszenie o kilka % za darmo. Skoro uważasz że to nic...
Programowanie na superkomputery to inna sprawa, nie było powodu żeby przyspieszać tam "jeden wątek" skoro w większości używa się ich do przetwarzania dużej ilości danych w ten sam sposób (czyli łatwo się dzielących na wątki).


C++ nie utrudnia samego programowania wielowątkowego, ale jego konstrukcja utrudnia ulepszenie go do automatycznego rozdzielania kodu na wątki (nawet jeśli powstanie kompilator robiący to dla c++, to będzie słabszy niz dla języka opracowanego pod kątem procesorów wielordzeniowych).
Podałem linki, które jasno pokazują, że nie jest to czarna magia i można znaleźć nawet tutoriale na sieci dla niezaawansowanych, które pozwalają w prosty sposób skorzystać z dodatkowych rdzeni, bez konieczności pisania od zera algorytmów.
Problemem są właśnie obecne języki i kompilatory, które nie mają odpowiedniego wsparcia dla szukania błędów w takich programach (np. synchronizacji), ani dla ich pisania (języki są przestarzałej konstrukcji, kompilator ma trudność z automatycznym rozdzieleniem na wątki z tego powodu).
Z samego artykułu jasno wyszło, że wszystko co zostało napisane niedawno już się skaluje, czyli programiści już to potrafią. Część programów z tego nie skorzystała, bo nie było to w założeniach (specview) albo były to gry - tam większy nacisk jest obecnie na kartę graficzną, która jest wąskim gardłem.

co do przyrostu wydajnosci to w sumie jest to bezcelowe w programach symulujacych np naprezenia bo tam chodzi o dokładnosc a nie o czas

A ja standardowo proszę o testy po Linuxem
Vista wio!!! Ubuntu + BERYL ładniejsze i działa bez 2GB ram
więc po co robić testy na systemie który ma wydajność XIX lokomotywy ?

wista to system dla ludzi szukjacych nowych mozliwosci zmniejszenia mozliwosci blaszaka

Wymagasz w ten sposób rekompilacji całego programu na każdej maszynie. Czy będziesz może proponował dawanie exe-ków do 1,2,4,8... procesorów?


Optymalizacji kodu na niskim poziomie i lokalnie. Kompilator nie zoptymalizuje ci słabego algorytmu. Dokładnie tak samo jest w kwestii rozdzielania na wątki.
Jeśli algorytm jest jednowątkowy w swojej konstrukcji to kompilator nic nie pomoże (ew. jedynie zrównolegli jakieś kawałeczki w środku).