Co do cen Quad Core to ceny hurtowe mają spaść z 851 $ w pierwszym kwartale do 530 $ w drugim kwartale, w związku z premierą AMD K8L.
530 $ (+marża, cło i VAT) to tyle ile obecnie kosztuje E6700 (około 2000 zł), taka cena za procesor czterordzeniowy wydaje mi się rozsądna.

Można będzie odpalić w tle dwa albo nawet trzy procesy obliczeniowe i nadal normalnie pracować na kompie ! Fakt że to się przyda głównie grafikom, animatorom i naukowcom, a nie zwykłym graczom czy internautom.

Moim zdaniem warto jeszcze zaczekać te kilka miesięcy, czas pokaże co będzie szybsze i bardziej ekonomiczne (C2Q czy K8L).
Już nie mówiąc o premierze samej Visty PL.
Może także ceny pamięci spadną i niezbędne do Visty 2GB DDR2 800 MHz nie będzie kosztować 1000 zł ?

równie dobrze można by się zapytać przedstawiciela Intela, w osobnym wątku, ile by kosztowało wyprodukowanie C2D w latach siedemdziesiątych...

E tam, Polacy jakoś przeważnie mają tendencję do działania tak, by sobie udowodnić, iż nie warto się wysilać, żeby coś zrobić

A propos 2012 roku, to może faktycznie lepiej pomedytować i się oświecić czy coś, niż tracić czas na komputery i okolice

A słyszałes ze wg wyliczen PAN procesor oparty na bramkach i innych elementach wykonanych z nanorurek bedzie ok 1000000 razy drozszy niz najszybszy obecny procesor i oni licza jeszcze na korzysc

za 10 lat beda jakies cuda na kiju kto wie czy swiat nie skonczy sie w 2012r

Oczywiście nie zgadzam się, że nie napisałem, tego co mi zarzucasz, że nie napisałem, bo przecież napisałem, jest wyżej. Kwestia interpretacji, wynikającej być może z odmienności doświadczeń. Nie piszę już nic więcej, oprócz tego: Myślę niskopoziomowo, tak uważam trzeba myśleć, żeby temat "prześwietlić". Uważam, że wnioski z prześwietlenia są poprawne. A teraz dajemy sobie na luz i czekamy kilka latek. Trzymam kciuki za naszą pamięć, żeby do tematu wrócić. Oraz za pclab.pl, żeby wciąż istniał i odwałał tak jak teraz kawał dobrej roboty

Wiem bardzo dobrze, jak to działa "od kuchni". Dziwne, że uważasz, że troluję, skoro sam nie podajesz konkretów (ja np. podałem konkretny przykład rozbijania przez kompilator typowego kodu, który był pisany bez myślenia o wątkach), teraz twierdzisz, że podaję wyrywki z teorii (a podałem proste praktyczne przykłady, w odróżnieniu od ciebie - uniknąłeś pytania o nie dające się zrównoleglić algorytmy, lub chociaż napotkane przez ciebie problemy nie rozwiązywalne przez kompilator, a rozwiązywalne dla człowieka).
Programowałem wystarczająco dużo, żeby się na ten temat wypowiadać, akurat bez openmp, bo nie miałem takiej potrzeby, ale chętnie przeczytam, jakie problemy miałeś w używaniu wielowątkowości we swoich/znanych programach.
Nie udowodniłeś także, ani nie poparłeś niczym twierdzenia, że bieżące algorytmy są w większości jednowątkowe (tutaj ja podałem proste kontrprzykłady w linkach). Wyniki testu nie świadczą o tym, a wręcz przeciwnie - zobacz interepretację testu specviewperf.
Skoro tyle od ciebie to historycy zweryfikują resztę

A słyszałeś o technologiach odzyskiwania energii termicznej w strukturach grzejącego się krzemu i zamianie jej z powrotem na energię elektryczną? Albo o układach scalonych, których podstawą budowy jest nie krzem, ale nanorurki? Ponoć są świetne, bo się praktycznie nie grzeją. Tak więc jak na dzień dzisiejszy masz rację, ale nie wyklucza to wcale, że za powiedzmy 10 lat będziemy mieć procesory 128 rdzeniowe... chłodzone pasywnie

rozumowanie logiczne, tylko gdzieś wiatraczek odfrunął za niebieskimi migdałami
procesory jednordzeniowe tez się przegrzewają, bo są, według mnie, "niedopracowane". dla mnie dopiero laptopowe wersje są tymi "właściwymi"

ilosc rdzeni jest ograniczona wiadomo rdzen wytwarza ciepło bo cos tam liczy wiec jak umiescisz duzo rdzeni na małym proceszorze to sie stopi przyszłosc nalezy do platform wielo procesorowych:)

cdarek: Wybacz, że tak późno odpowiadam, ale to chyba bez znaczenia, bo po przeglądnięciu wcześniejszych postów i Twojego ostatniego doszedłem do wniosku, że bezcelowe jest kontynuowanie tej dyskusji. Z całym szacunkiem, ale wiele wskazuje na to, że nie wiesz jak to wszystko działa "od kuchni". Może coś wiesz, ale wygląda to trochę tak, jakby to były jakieś luźne wyrywki z teorii, które nijak do siebie nie pasują poza Twoimi wyobrażeniami. Zastanawiałem się nawet, czy celowo nie "trolujesz" tutaj ostatnimi postami. Tak czy inaczej tyle ode mnie. Sorry. (Możesz tak czy inaczej wrócić do tego co pisałem za parę latek i zweryfikować z tym co będzie...)

P.S. Nikt zainteresowany tematem w zasadzie nic nie traci, bo wszystko co najważniejsze napisałem już w poprzednich postach i nie ma sensu się powtarzać.



A ja obstawiam, że jeśli nic się nie skomplikuje, to będziemy mieć w kolejnych generacjach dokładanie rdzeni (choćby i po jednym...), ale bez wynalazków typu "HT". Natomiast jeśli coś nie wypali, lub technologie nie nadążą, to możemy spodziewać się marketingowego powrotu "potworka HT" na platformie x86...

Ja jestem zadowolony z dwóch rdzeni. Kiedy renderowałem materiał w Vegas 5.0, program robił mi ją ponad dwie godziny. Teraz wyprobowalem Vegas 7, SZOK, cała operacja zamknela sie w 30 min - optymalizacja kodu plus dodatkowy procesor do obliczeń dał niesamowity wzrost wydajności. Prawie 5 razy szybciej. I to na zwykłym latopiku z TURIONEM X2.

wyscig predkosci narazie na kilka lat ugrzazł na barierze termicznej, zacyna sei wyscig w rdzeniach i platformach kilku procesorowych w efekcie za kilka lat nikogo nie bada dziwic platformy z 4 procesorami z 4 rdzeniami/cpu + HT

Nieprawda, właśnie skalowanie na liczbę jąder powinno się odbywać automatycznie - właśnie dlatego, że niedługo nie będzie znana ich liczba. Openmp robi to automatycznie (teraz, więc nie jest to sf)
Z ideą się godzę, ale uważam, że jeśli mamy wykorzystać więcej rdzeni, to programista powinien mieć w tym minimalną rolę, a większość powinien robic kompilator.



Skoro będą to techniki, to może je robić kompilator. Programy nie robią się same tylko dlatego, że przeniesienie rzeczywistych problemów na język komputerowy musi się odbywać narazie przez człowieka. Jeśli algorytm jest już zapisany w komputerowym języku, to jest już pole do popisu dla kompilatora.



Program napisany w C++ ma narzucone pewne ograniczenia, które pochodzą po części z bardzo starego C, przez co kompilator traci część możliwości optymalizacji w zrównoleglaniu - bo to nie było uwzględnione w tym języku. To, że można w nim zrobić wątki, nie oznacza, że jest optymalny. To taka różnica jak np. C++ vs Java - program funkcjonalnie taki sam w większości przypadków można napisać, ale możliwości kompilatora w optymalizacji będą różne, ze względu na konstrukcję języka.
To, że w ogóle można tworzyć wątki w C++ i innych językach, a i tak kończy się to odwołaniem do systemu, nie oznacza, że nie są narzucone sztuczne ograniczenia.



Źle interpretujesz wyniki. Test jasno pokazuje, że nie pisali kodu od nowa, tylko usprawnili oczywiste do zrównoleglenia miejsca ręcznie rozbijając na 2 wątki. To właśnie metoda którą ty proponujesz się tu nie sprawdza - czyli rozbijanie algorytmów ręcznie.



Chodzi mi o to:
Jest kod -> możemy podzielić na wątki ręcznie -> program (skompilowany) -> może się automatycznie dzielić w oznaczonych sekcjach -> system -> rozdziela wątki na wolne jądra.
Teraz, jeśli masz program który nie został podzielony na etapie tworzenia, ani kompilacji - to nie masz żadnego innego miejsca w którym może zostać wykorzystana wielordzeniowość. Stąd wniosek: algorytm w takim programie nadal może być łatwy do zrównoleglenia, tylko nie zostało to wykonane. Nie możesz twierdzić, że został napisany tak, że trzeba go koniecznie przepisać na wielowątkowy od podstaw. Nie wiesz, czy kompilator sobie z tym nie poradzi - może nawet z 90% przyspieszeniem.




Nie o to mi chodziło, raczej o opis problemu.



Obie te rzeczy wykonuje się niezmiernie rzadko. W szczególności ustalanie co ma być w rejestrach jest już praktycznie nie spotykane. Czy tylko człowiek wie, co umieścić w rejestrach? Jak rozbić pętle?



Konkretny język komputerowy narzuca sposób tłumaczenia na kod maszynowy. Widzę, że nie rozumiesz tego na przykładzie C++, bo jest stosunkowo niskiego poziomu (ale nie jest asemblerem, więc też ma swoje ograniczenia - spore dla zrównoleglania), więc pomyśl na przykładzie javy. Według twojej teorii mogę tam zrobić dowolny program, bo to tylko inny język? Będzie miał takie same możliwości optymalizacji jak C++, asembler? Nie. Tak samo jest z C++ do programowania równoległego, optymalizacje kompilatora są blokowane przez strukturę języka.



W przypadku automatycznego podziału ten problem nie zaistnieje, bo nigdy nie będzie rozdzielania na więcej wątków niż ma procesor rdzeni, a procesor z większym narzutem przy obsłudze swoich rdzeni niż korzyściami nie zostanie wyprodukowany. Jaki był by sens procesora, który się dusi przy ilości wątków o liczbie swoich rdzeni?

Nie wiem o co chodzi, ten cytat nie chce się zacytować
"obliczeniowej. Możemy nauczyć się tak pisać aplikacje, żeby wyciskały moc z procesorów wielordzeniowych bardziej w stylu 3D Max, niż w stylu... WinRAR (który mimo, iż na tle przypadków beznadziejnych dobrze się skaluje na wielu "

WinRAR jest zaskakujący dla mnie - imho ta aplikacja jest przykładem bardzo trudnego do zrównoleglenia algorytmu. To, że przeskalowała się jest dużym sukcesem. Zupełnie mnie nie dziwi, że przyrost nie jest 90% w tym przypadku, bo z pewnością większość algorytmu nie nadaje się w ogóle do zrónoleglenia. Założę się, że inne programy kompresujące mają podobne albo gorsze wyniki.



Wychodzisz z założenia, że wątki są na poziomie algorytmów. Według mnie to niskopoziomowa rzecz, na tyle, że powinien się nią głównie zajmować kompilator.
I tu się różnimy w swoich zdaniach: człowiek nie będzie dużo lepszy od kompilatora. Chcesz pisać każdy algorytm od nowa, a jeśli natkniemy się na barierę sensownej liczby rdzeni i znowu ruszy wyścig prędkości to będzie wszystko trzeba robić od nowa

Mam wrażenie, że nie możesz pogodzić się z ideą nauki programowania na nowo w ramach pojawienia się nowego paradygmatu. Widzę, że chodzi Ci wyłącznie o język wspomagający kompilator w dzieleniu małych elementarnych działań na wątki. Coś takiego może powstać, ale jak już napisałem - podobna idea ma krótkie nóżki i jeśli jednoukładowe procesory będą mieć w przyszłości 4, 8, 16, 32, itd. jąder (czy może 4, 9, 16, 25, trzymając się idei kwadratowego kształtu procesora ), to podobny język może nie zdążyć powstać, nim stanie się bezużyteczny. Wszystko już napisałem wcześniej: Albo ten język będzie niewyobrażalną dla nas rewolucją, bezdyskusyjnym przykładem "masterpiece", albo nie będzie go wcale, ponieważ kto będzie się uczyć nowego języka dającego do 10% przyspieszenia na jądro, skoro będą istnieć klasyczne techniki zrównoleglania, których wystarczy się tylko nauczyć, i które gwarantować będą nawet blisko 100% wzrostu wydajności na jądro? OK - skąd podejrzenie, że tylko jakieś 10% może dać taki specjalizowany język i kompilator? Ano stąd, że trochę tak "na oko" nawet specjalizowany człowiek nie będzie w stanie dużo więcej wycisnąć z kodu opisującego typowe algorytmy, czy w ogóle z kodu, jaki dostanie do opracowania. Jest jeszcze szansa, że ten kod będzie wyjątkowo sprzyjał takiej operacji, wtedy zysk będzie większy. A będzie i kod, który w ogóle się nie da tak podzielić. OK, możesz mówić, że to nadal kod w C++. Ale co z tego? Gdzieś wcześniej wspomniałem, że każdy język programowania jest przetłumaczalny na każdy inny. Niech by sobie nasz specjalista tłumaczył to co dostanie na dowolnie wybrany sposób, niech nawet dzięki temu osiągnie zysk 11% zamiast 10%, tylko że to nic nie zmienia. Co do autoamtycznego rozbijania na wątki w aktualnie testowanych programach - jest szansa, że niektóre patche do gier wprowadzające obsługę procesorów wielordzeniwych zostały tak potraktowane. Albo ręcznie ktoś wymyslił na gotowym kodzie kilka nieefektywnych wątków, tak "żeby były", albo użył kompilatora, który coś tam jest w stanie wymyśleć w tym kierunku (bo nikt mi nie wmówi, że w ciągu miesiąca napisali cały kod gry od nowa pod wielordzeniowce). Efekty są jakie są - czyli żadne, albo prawie żadne, łącznie ze wzrostem wydajności na dwóch rdzeniach i spadkiem na czterech. Najlepszy żywy dowód, że nie tędy droga.




A co ma tu do rzeczy fakt, że wątki na procesory rozdziela system? Wątki należą do systemu i tylko on może je rozdzielać. Dobrze, gdy program może wskazać konkretny rdzeń, na którym chce uruchomić wskazany wątek (w większości przypadków może). Póki co jednak system nie dzieli jednego wątku na kilka (tak też można zrozumieć, to co napisałeś...), ani nie ogranicza możliwości programów co do korzystania z wielowątkowości. A to, że jakiś program jest napisany wyłącznie na dwa wątki, żeby przyspieszyć na dokładnie dwurdzeniowym procesorze, co daje brak wzrostu wydajności w przypadku czterech rdzeni - to już tylko i wyłącznie wewnętrzny problem tego programu (i jego autorów).




Ależ właśnie dokładnie to oznacza. Jeśli w praktyce tak działają, to właśnie takie są. To, że akurat jakiś algorytm da się w teorii przyspieszyć poprzez łatwe rozbicie go na wiele wątków jest akurat bez znaczenia, jeśli nie został tak napisany.




Moglibyśmy przejść na pisanie i porównywanie kodów źródłowych, ale to chyba bez sensu - nie mam za specjalnie na takie zabawy czasu, nie wiem jak Ty Odpowiadam na pytanie, dlaczego to człowiek powinien rozbijać kod na wątki, a nie maszyna: Ponieważ tylko człowiek wie, jak to zrobić. A przynajmniej tylko człowiek wie, jak to zrobić w taki sposób, żeby wieloprocesorowość miała w ogóle sens. To nie do końca prawda, że nie mam kontroli nad optymalizacją z poziomu kodu źródłowego (np. C ma stosowne dyrektywy dla kompilatora, którymi programista może podpowiadać kompilatorowi jakie ma intencje wobec danego kawałka kodu - można np. kazać starać się trzymać dane w rejestrach, albo kazać rozwijać pętle). Nie jest prawdą, że kod nie jest bezpośrednio przekładany na język maszynowy - jeszcze zależy, jak rozumiesz to, co napisałeś - ale generalnie dokładnie to co napiszesz w języku wysokiego poziomu, dokładnie to będziesz miał w kodzie. Fakt, że może zostać to bardzo różnie wyrzeźbione i z bardzo różnymi trickami, ale to będzie dokładnie to.

A teraz na bardzo abstrakcyjnym przykładzie pokażę Ci, jak bardzo się mylisz twierdząc, że kompilator jest właściwym miejscem rozwiązania problemu rozbijania kodu na wątki, oraz dlaczego istnieje "programowanie współbieżne", a nie "kompilacja współbieżna". Załóżmy więc teoretycznie, że mamy spory, ale skończonej długości algorytm, który da się bez problemu podzielić na wiele równoległych części (aż do takich wielkości nawet kilkudziesięciu instrukcji asemblera włącznie), oraz że mamy maszynę potrafiącą wykonywać nieskończenie wiele wątków jednocześnie (ale marzenia, BTW ). Dzielimy więc algorytm na dwa wątki - uzyskujemy wzrost prędkości działania bliski 100%. Dzielimy na cztery - znowu podwajamy wydajność obliczeniową, wykorzystując równomiernie więcej mocy maszyny. Co się stanie, gdy będziemy tak dzielić kod? Otóż dojdziemy do tych malutkich, najmniejszy możliwych fragmentów. I wtedy okaże się, że algorytm wcale nie pracuje z prędkoscią wynikającą z pomnożenia wydajności jednego rdzenia razy liczbę rdzeni. Stanie się tak dlatego, że zwiększał będzie się narzut związany z przełączaniem się między wątkami, z przekazywaniem małych procji danych, z synchronizowaniem krótko wykonujacych się wątków, itd. Efekt będzie taki, jak z ustawieniem zbyt którkiego "time slice", czyli plasterka czasu, po jakim procesor jednordzeniowy przełącza się na kolejne zadanie - więcej będzie się on wtedy przełączał niż pracował - a ten przykład nie oddaje jeszcze pełni problemu, bo nie musi on przy tym czekać na żadną synchronizację. Można to wszystko podsumować tak, że nigdy żaden kompilator (no, chyba że jakiś AI ) nie będzie w stanie efektywnie podzielić na wątki dużych zadań, a dzieląc małe doprowadzi do opisanej sytuacji - będzie potop małych zadanek, zdolnych wykonywać się dobrze na dwóch, a może i nawet (ale już mniej efektywnie) na czterech rdzeniach, ale na pewno nie na większej ich liczbie. A że będzie to robione "na siłę" gwarantuje, że wydajność nie przekroczy pewnie 10%. Tak to wygląda od strony kuchni.

Tymczasem ucząc się nowego sposobu programowania jesteśmy w stanie nauczyć się świadomie od zera projektować zadania tak, żeby zagospodarować całą moc procesorów wielordzeniowych. Możemy używać wspominanych przeze mnie kilkakrotnie "modułów wykonawczych", możemy użyć współbieżnego algorytmu sortującego tam, gdzie sortowanie zajmuje 90% czasu procesora, albo użyć zwykłego algorytmu jednowątkowego na jednym rdzeniu (np. z innymi niepodzielnymi lub szybko wykonujacymi się zadaniami), gdzie posortowanie to kwestia ułamka dostępnej mocy obliczeniowej. Możemy nauczyć się tak pisać aplikacje, żeby wyciskały moc z procesorów wielordzeniowych bardziej w stylu 3D Max, niż w stylu... WinRAR (który mimo, iż na tle przypadków beznadziejnych dobrze się skaluje na wielu rdzeniach, to celowo podaję tu za przykład). Podsumowując: Programy piszą programiści, programy to zbiory algorytmów, kompilatory rzeźbią kod, ale na pewno nie wyrzeźbią nam nowych algorytmów, których potrzebujemy dla wykrzesania maksimum mocy z wielu rdzeni. Napisanie nowych, współbieżnych algorytmów należy do programistów, a nie do wyczarowania przez kompilatory. Gdyby tak nie było, to programy dawno już by się same pisały

I tu nie zrozumiałeś tego, co jest w podanych przeze mnie linkach. Wyniki testów nie są miarodajne dla możliwości kompilatorów, bo nie ma podstaw, żeby sądzić, że testowane programy były skompilowane automatycznie rozbijającym na wątki kompilatorem (czyli nie wiesz czy on by w tym przypadku zadziałał czy nie i z jaką sprawnością).
Narazie jedynym rozdzielaczem wątków jest system, czyli program wcześniej jednowątkowy, lub z "zakodowanymi" dwoma wątkami nie ma prawa przyspieszyć - tylko tyle wynika z testów. Nie oznacza to, że algorytmy w nim zawarte są jednowątkowe i trzeba obmyślać je od nowa.

Nie wiem czemu uważasz, że konieczne jest rozbijanie na wątki przez człowieka, a nie maszynę. Tak czy inaczej twój kod nie jest bezpośrednio przekładany na język maszynowy, więc nie masz pełnej kontroli nad optymalizacją. Nie rozdzielasz ręcznie np. zmiennych do konkretnych rejestrów i jakoś cię to nie boli.
Uważam, że kompilator jest odpowiednim miejscem do pokonania tego problemu, a co najwyżej język powinien oferować minimalne możliwości ręcznego "rozbijania".

Skoro chcesz się poprzeć doświadczeniem, to powiedz coś konkretnego, bo nie bardzo mam się jak do tego odnieść.

Po piersze, straszne pieprzenie bez zrozumienia pieprzonego tematu

Po drugie, jeśli to ma w ogóle sens, zachęcam panów Tylin i sool do zapoznania się z poniższym wątkiem:

http://forum.pclab.pl/index.php?showtopic=...33;entry3071368

Po trzecie zapewniam, że problem architektury wielordzeniowej dla aplikacji mainstream jest ponadsystemowy i Linux mu jak najbardziej podlega



Przeczytaj mój poprzedni, kompleksowo napisany post




W moim przypadku takie przypuszczenie wynika z doświadczenia, reszta może posiłkować się wynikami testów aplikacji na C2Q Rozbijanie algorytmów to na pewno krok we właściwą stronę, przy czym dla najlepszych efektów musi mieć to miejsce "u korzeni" problemu, a nie "w liściach"



Jednak w praktyce takie rozwiązanie najprawdopodobniej byłoby albo niesamowicie zamotane, albo wymagałoby osobnej kompilacji dla danej liczby rdzeni.




...i tak samo nie podlega w zasadzie dyskusji, że szkoda prądu za te kilka % przyspieszenia, które da się w ten sposób uzyskać. W dodatku porównanie możliwości kompilatórów w materii "rzeźbienia" kodu, do możliwości podziału kodu na wątki jest według mnie niespecjalnie oczywiste. To jednak dwie różne bajki. Nie programuje się nigdy algorytmu jako całości, nawet nie bardzo wiadomo jak możnaby to zrobić. Programuje się natomiast elementarne kroki algorytmów, co zostawia już naprawdę małe pole do popisu dla kompilatorów w kwestii wielowątkowości. W czasach dwurdzeniowców lepszy mały zysk z takiej optymalizacji, niż żaden. Ale gdy liczba rdzeni się zwiększy sam zobaczysz, jak krótkie nóżki mają takie "workaround-y". Ani to skalowalne, ani wydajne.

Nie chodzi mi o napisanie kompilatora "C" w asemblerze, a jedynie o zastosowanie struktur i makr, które podniosą czytelność kodu na poziomie źródeł programów asemblerowych. Zresztą to nie jest bardzo konieczne. Wiele lat hobbystycznie programowałem w asemblerach różnych procesorów (z 5 rodzajów tego było), do tego przez jakiś czas bawiłem się (także czysto hobbystycznie ) w crackowanie - z własnego doświadczenia mogę zapewnić więc, że po pewnym czasie człowiek ma tak, jak bodajże Cipher w Matrix - przestaje widzieć kod, a zaczyna blondynki, rude... Czy jakoś tak, hehe Nie odwołując się do innych mechanizmów można poczynić pewne założenia, dzięki którym podprogramy i moduły nie będą sobie bruździć (jeśli w C++ mamy wolność, to aż brak słów żeby opisać, co mamy w asm...), do tego wprawa w pisaniu i czytaniu niweluje troszkę brak ułatwień składni znanych z C - i da się. Ale bardziej złożone problemy oczywiście lepiej pisać pod jakąś bardziej złożoną abstrakcją, np. C# (autor książki "Thinking in Java" w najnowszym wydaniu we wstępie napisał, że C# jest dużo lepszy niż Java ) Pytanie: Czy ten hipotetyczny język zrównoleglający o którym piszesz miałby działać tak, że ułatwiałby dzielenie większych zadań, czy po prostu ułatwiałby dzielenie drobnych rzeczy, typu np. pojedyncze pętle?




Oczywiście absolutnie się nie zgadzam, że kompilatory i przyszłe języki programowania zniosą konieczność podziału zadań na wątki W dodatku sam powyżej piszesz, dlaczego tak będzie Załóżmy, że program będzie chciał się skalować, a nie będzie znać liczby rdzeni, których będzie powiedzmy od 1 do... 128 ... To co mu da kompilator? Kod jest już wygenerowany. Jakoś słabo to widzę, że kompilator pomoże w automatycznym skalowaniu do liczby rdzeni. Więcej nawet! Optymalizacja kompilatorów przy liczbie rdzeni prawdopodobnie większej niż 4 będzie już dawać praktycznie zerowe przyspieszenie. Proste problemy, które kompilatory dzielą na wątki mają ograniczoną "rozbieralność" - i po prostu się nie bardzo da, nawet przy ręcznym, indywidualnym podejściu. Pewnie dlatego przy programowaniu maszyn wieloprocesorowych od wielu, wielu lat dzieli się wyłącznie zadania. Optymalizacja na poziomie języka i kompilatora, którą reklamujesz, pewnie od strony uzyskanych przyspieszeń byłaby nie warta rachunku z elektrowni BTW: Kompilator nigdy nie będzie mądrzejszy od programisty w kwestii podziału kodu na wątki (no OK, to zleży jeszcze od programisty ), natomiast w obecnych czasach różnych i szybko zmieniających się architektur wstawki asemblerowe dla typowego kodu są faktycznie bez sensu, ale już w przypadku używania rozszerzeń typu np. SSE3 mają ogromny sens




Oczywiscie, że tak uważam. Więcej da podniesienie szyny FSB o parę MHz i... wyłączenie HT w BIOS HT ma bowiem tę ciekawą właściwość, że w niektórych przypadkach aplikacje chodzą kilka % szybciej, a w innych kilka %... wolniej (też za darmo ). Osobiście porównywałem leciwego Bartona 2500+@2450MHz i niedawno nabytego przez znajomego (mimo mych próśb i gróźb) Pentium 4 640@3200MHz. Barton wymłócił go od kilkunstu % do bodajże 50% w niektórych testach, miał przewagę także w testach wielowątkowych w PCMark. Oto w pigułce cała prawda o HT Intela...




Większość zadań da się podzielić na wątki, może nie tak zaraz łatwo, ale na pewno skutecznie. Wszystko to, co się słabo dzieli, albo co nie opłaca się dzielić wrzuca się po prostu w jeden wątek na jeden rdzeń, podczas gdy reszta rdzeni ciężko mieli podzielone zadania.



No i tutaj jest z sedno, co do którego mnie nie przekonuje na razie żaden argument: Do automatyzowania podziału kodu na wątki. To może taki przykład: Mamy 16 rdzeni. Mamy kod, który jakiś magiczny kompilator podzialił nam tak, że pasuje idalnie do rozbijania na 16 wątków na raz, w dodatku równomiernie obciążonych (tak to nawet w T-Mobile nam nie zrobią... no ale załóżmy tak). I teraz pytanie: Ile czasu stracilismy na przełączanie się i synchronizowanie nieustanne między rdzeniami? Rdzenie co kilka/kilkadziesiąt/kilkaset linijek kodu czekają na siebie, przełączają się nieustannie pomiędzy mikrozadaniami, powstają narzuty związane z samym przełączaniem i z oczekiwaniem na synchronizację. Ogromne narzuty, tym większe, im więcej jest rdzeni. To się po prostu nie opłaca. Podtrzymuję pogląd, że kompilatory mogą być "łatką na szybko" problemu braku współbieżnego kodu i umiejętności pisania takiego, ale na pewno nie są przyszłością docelową, a tym bardziej nie są częścią ostatecznego rozwiązania.




Takie "łatanie na szybko" to oczywiście żadna magia. Jednak nigdzie pod podanymi linkami nie jest powiedziane, że tak ma wyglądać przyszłość programowania dla nowego paradygmatu. Jest napisane coś wręcz odwrotnego, już wczoraj miałem to zacytować:

Task-Level Parallelism. If you're writing a new application, you have the opportunity to design the application in order to parallelize at the task layer. That's the best way to go; you can see that in applications like Outlook or Eudora, which are architected in a way that logically separates different tasks into different threads, and which use semaphores and other mechanisms to enable communication between those threads.

I'll be honest: Writing an application to exploit task-level parallelism can be difficult at first; it's like making the transition from structured to object-oriented programming. Think carefully about the best ways to split the code. Some obvious places are areas that have distinctly different needs. For example, a UI layer is I/O bound, but handwriting recognition is CPU-bound. In an application that uses network databases, one thread can communicate and sync with the network and fill a local cache, while another thread works out of that cache.

For another example, a game application might use task-level parallelism to separate out the game physics, the audio, the graphics, the strategy, and the different artificial intelligence characters in the game. If the game runs over a LAN, the related housekeeping and communication over the network could be two separate tasks.

The beauty of task-level parallelism is that it's independent of the underlying technology—it works well on both compiled and managed applications, and doesn't require special compilers. The downside is that it's difficult to retrofit a new design to existing applications, unless they're already written in a manner that happens to be sufficiently modular.

...a moim zdaniem pójdzie to jeszcze dalej, nie w stronę prostego rozbicia logiki, ale w stronę "modułów wykonawczych", o których pisałem wcześniej. Wszystko zależy od liczby rdzeni - taka filozofia, jak przedstawiona w powyższym cytacie, nie ma zastosowania w sytyuacjach, gdy mamy np. 32 rdzenie, a tym bardziej, gdy mamy 128 Wszystko jest zmianą kwestii myślenia i nabycia nowych umiejętności. W grach mając 32 rdzenie można np. liczyć nie tylko klatkę aktualną animacji, ale także ileś tam klatek do przodu (chodzi o scenę, fizykę, AI, itp.) Można liczyć te obszary, gdzie żaden gracz "nie lata", ani się "nie strzela", więc nic nie wpłynie np. na kaczkę pływającą po jeziorze, czy padający deszcz. Oczywiście, gdy jednak któryś gracz "skręci" w taki obszar dane policzone mogą zostać odrzucone z czegoś w rodzaju "future scene cache", a w ich miejsce zostaną policzone nowe, uwzględniające ingerencję. Przykład ten ma pokazać, że możliwości myślenia na poziomie "advanced task parallelism" jest jak widać dużo i są ogromne, a ich wykorzystanie zależeć będzie nie od próby ratowania się kompilatorami, ale od nauczenia się programowania na nowo. W przeciwnym wypadku AMD i Intel będą mieć paskudne problemy z wciskaniem w rynek mainstream PC bezużytecznych tam procesorów z np. 64 rdzeniami




Pewnie, są całe rzesze programistów, którzy to potrafią: Część się już zdążyła nauczyć, a cały ogrom od dawna już to potrafi - tyle tylko, że przeważnie nie piszą oni dla rynku PC Założenia obecnie pisanych programów po "straszaku" Intela, czyli C2Q, już pewnie wielordzeniowość uwzględniają. Jednak takie programy zobaczymy najwcześniej za rok, za dwa. A ile czasu potrzeba, żeby założenia uwzględniały płynne skalowanie do liczby rdzeni? A ile czasu potrzeba, żeby 90% aplikacji, którym nie zaszkodzi przyspieszenie, zaczęto pisać w ten sposób? Podtrzymuję swoją prognozę: 5 d 7 lat.

I o jakich programach piszesz, że się dobrze w artykule skalowały? Aż zerknąłem tam znowu, żeby się upewnić, czy przypadkiem nie byłem zbyt śpiacy, gdy go czytałem - ale nie, wszystko się zgadza Dobrze skalują się DWIE z przetestowanych aplikacji: 3D Max i Fine Reader 8 OCR. Prawdopodobnie obie zostały stworzone mniej więcej "na serio pod wiele rdzeni", a nie przy pomocy kompilatorów czy frameworków tuszujących problem warsztatu Można jeszcze wspomnieć o WinRAR 3.62, który jak widać skaluje się, ale bez rewelacji - to pewnie "zasługa" OpenMP A poza tym widać jeszcze tylko jakieś pierwsze nieporadne próby i nic więcej. Zobaczymy co będzie za jakiś czas

Nie wymagam rekompilacji dla każdej maszyny, zobacz linki które podałem wcześniej.
Nie chodzi o to, że kompilator może optymalizować na wątki - to nie podlega dyskusji. Tak samo jak nie podlega dyskusji, że jest w stanie optymalizować kod na inne sposoby. Chodzi o to, że nie jest tego teraz w stanie robić tak dobrze, jak by mógł, gdyby nie słabość dzisiejszych języków programowania. Ich konstrukcja osłabia możliwości kompilatora w rozbijaniu na wątki.

Skąd przypuszczenie, że większość algorytmów jest jednowątkowa w swojej konstrukcji? Pisząc algorytmy na procesor z jednym rdzeniem, nikt się specjalnie nie zastanawia nad zrównoleglaniem algorytmu, ale też nie ma powodu, żeby tak nie było (jeszcze raz odsyłam do linków). Jeśli problem rozwiązany algorytmem jest z natury do rozbicia na równoległe części, to i algorytm to odzwierciedla, nieważne czy pisany dla jednordzeniowca czy nie.

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

wista to system dla ludzi szukjacych nowych mozliwosci zmniejszenia mozliwosci blaszaka