OpenMP to boczna ścieżka ewolucji. Taki neandertalczyk programowania wielowątkowego. Ja bym się od tego trzymał z daleka.

OpenMP jest potworkiem zaimportowanym z FORTRANa do zrównoleglania prostych pętli przy obliczeniach numerycznych. Jeśli jest się lowlevelowym hakerem i potrzebuje się tylko tego, to proszę bardzo. Nie rozszerza się to jednak specjalnie poza bardzo specyficzne przypadki masywnych obliczeń (które teraz już raczej powinno się robić na GPU np za pomocą C++AMP). Współcześnie powinno się raczej definiować oprogramowanie jako zbiór zadań powiązanych siecią zależności, które można rozwiązywać równolegle. Tylko takie podejście daje nadzieję na sensowną skalowalność na przyszłych maszynach. Cytat:

Ostatnio edytowany przez laoo/ng (2012-01-17 10:51:07)

"Trochę" utopijny i jak to z utopiami bywa najpewniej skończy się na manifeście. Ale skoro już fantazjujemy, to ja proponuję http://chapel.cray.com. Ten przynajmniej już jest ;)

Ostatnio edytowany przez laoo/ng (2012-01-17 13:54:37)

Eetam. zrównoleglanie powinno być robione na dwóch poziomach:
a) języka (zrównoleglanie pętli, itp)
b) projektu (podział procesów na wątki, itp)

To wszystko w nowoczesnym C (+biblioteki) już jest. Języki które maja zrównoleglanie natywnie, raczej załatwiaja tylko a), a b) i tak trzeba realizować bibliotekami.

Co do GPU: to jest fajne, ale tu raczej się nie da tak łatwo żeby jeden program działał na CPU+GPU (jeden, tj. w formie jednego kodu źródłowego). Dlatego wydaje mi się że GPU zostanie jak zostanie - do specjalizowanych zastosowań (tj. np. głowny kod w C i dodatkowy w specjalistycznym języku na GPU).

No i nie zapomnijmy o skomplikowaniu całości. Spójrzcie na procesor Cell w PS3: widać po nim że power jest (i nieliczne produkcje to wykorzystują) ale ciężko się do niego dobrać, oj ciężko.

BartoszP na to odpisał:

jellonek: no programowanie na jaga to wogóle wyższa szkoła jazdy, szczególnie z powodu ciekawych błędów w hardłerze :)

Język dynamiczny ma szanse być wydajniejszy, ale tracing jit ma jedną wadę - wydajniejszy będzie dopiero po kilku przejściach kodu, co w niektórych zastosowaniach jest niezadowalające lub wręcz niedopuszczalne. Ja nie upieram się koniecznie przy C, ale ogólnie jestem fanem języków ze składnią zawierającą {} :) (najbardziej lubię C#). Zresztą C też może być ekonomiczny, zależy co chcesz mierzyć. No i w czymś te dolne warstwy trzeba napisać.

Epi: np. C11 http://en.wikipedia.org/wiki/C11_(C_standard_revision)

To nadal jest asembler, tylko dołożyli nowe makra. ;) Popularne kompilatory do tej pory nie doczekały się pełnej implementacji C99, z czego można wnioskować, że implementację ciekawostek z C11 zobaczymy pewnie nieprędko - na razie widać niewielki ruch w GCC, gdzie dodaje się nową składnię do niektórych już obsługiwanych ficzerów. Dojeżdżanie martwego konia i sztuka dla sztuki.

jellonek: żeby pypu miało na czym ruszyć musisz mieć interpretry pythona napisany w czymś bliższym procesora. Można to napisać w asmie, ale chyba przyznasz że w C prościej. Bootstrap jest niestety nieusuwalnym krokiem.

Epi: to sie tak mówi, ale wcale tak nie jest, szczególnie jak się weźmie pod uwagę optymalizacje których dziś potrafią dokonać kompilatory.

D jest ciekawe, ale moim zdaniem trochę za mało rozwojowe.

Epi: ludzie dzielą się na tych którzy rozumieją wskaźniki i na tych którzy mają dziewczyny ;) Niestety ci ostatni nigdy nie będą dobrymi programistami (moim zdaniem).

Adam: wiem ze to zabrzmi dziwnie, ale slyszales kiedys o... kross kompilacji? :)
i jaki tam D, ć ftw! ;)

Nie zgodzę się. Ingerencja w język naprawdę nie jest do tego potrzebna. parallel_for_each + lambda z "nowoczesnego C++" ;) załatwia sprawę.

Tu też. Jeśli nie piszemy systemu czasu rzeczywistego czy innych cudów, to program dzielimy na zadania. Wątki to zbyt niskopoziomowy koncept, żeby zawracać sobie nim głowę.

"Nowoczesne C++" ma wszystko co potrzeba do wygodnego zrównoleglania pętli i podziału programu na zadania na poziomie biblioteki bez ingerencji w język (ot przykładzik).

A zajawkę C++AMP czytał? Kod C++ bez mrugnięcia przekłada się na GPU i runtime sam dba o "gory details". Oj coś nie nadążacie panowie...

Ale za to błędy wychodzą u programisty podczas kompilacji, a nie u użytkownika podczas wykonania ;)

Nie ma jak porównywać hipotetyczne wyniki po wyciskaniu siódmych potów w optymalnej sytuacji z JITera do niechlujnie skompilowanego kodu w C/C++ i to pewnie na debugu ;)
Czytam to już n-ty raz i chyba pythonowców to jakoś super jara.
Ale szkoda że to "potrafi" być nieprawdą, skoro "statyczniaki" mają Profile-guided optimization... ;)

Ostatnio edytowany przez laoo/ng (2012-01-17 19:46:04)