Temat: OPEN MP vs inne takie
Bardzo ciekawa dyskusja, ale przeniesiona z tematu o PLusie 4.1, azaliż albowiem...
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
BigPEmu 1.12 Richard Whitehouse wydał BigPEmu 1.12
FujiNET firmware v1.3.0 Nowa wersja oprogramowania do interfejsu sieciowego FujiNET. Tym razem z obsługą TCP!
hatari 2.5.0 Od dwóch dni dostępna jest najnowsza (2.5.0) wersja Hatari.
Grawitacja 2024 Czas na kolejną edycję 8 bitowego GameJamu.
Tenebra na Atari ST/STE Wersja gry na duże atari.
Zaloguj się lub zarejestruj by napisać odpowiedź
Bardzo ciekawa dyskusja, ale przeniesiona z tematu o PLusie 4.1, azaliż albowiem...
http://www.phoronix.com/scan.php?page=n … px=MTA0Mzc
OpenMP to boczna ścieżka ewolucji. Taki neandertalczyk programowania wielowątkowego. Ja bym się od tego trzymał z daleka.
laoo: możesz nieco rozwinąć myśl?
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:
To continue enjoying the free lunch of shipping an application that runs well on today’s hardware and will just naturally run faster or better on tomorrow’s hardware, you need to write an app with lots of juicy latent parallelism expressed in a form that can be spread across a machine with a variable number of cores of different kinds – local and distributed cores, and big/small/specialized cores.
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)
to juz wole erlanga z jego skladnia, o ktorej niektorzy pisza ze jest "naturalniejsza niz wszelkie skladnie obiektowe" - chyba dla matematykow...
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ł:
No to stary ale skuteczny...i do tego transputery...hmmm... to kiedyś było cudo.... i wcięcia jak w modnym Pytonie:
http://pl.wikipedia.org/wiki/Occam
Adam: wole dzielic na procesy niz na watki - bo "macham pythonem" :) co do zrownoleglania na poziomie petli - byc moze w najblizszym czasie pojawi sie pod pypy :>
co do c - malo ekonomiczny jezyk, trudniejsze w opracowaniu unit testy, dluzszy cykl pisanie/kompilowanie/debugowanie niz w jezykach dynamicznych, ktore dzieki tracing jit potrafia byc wydajniejsze niz statycznie optymalizowany kod gcc/msvc ;)
podstawa pozostanie i tak precyzowanie zadan ktore maja leciec do koproca (jakiegokolwiek typu by nie byl, ilocorowy by nie byl...).
patrzysz na cell w ps3 - popatrz na jaguara, gdzie ludzie nie wykorzystywali gpu, tylko dalej klepali pod 68k, bo to po prostu umieli... (w jaguarze tez za latwo programu na gpu sie nie pisze ze wzgledu na koniecznosc jego szatkowania na segmenty).
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ć.
"Nowoczesnym C"?
Epi: np. C11 http://en.wikipedia.org/wiki/C11_(C_standard_revision)
Adam: faktycznie dla procesow szybko sie konczoncych C bedzie szybsze, jednak przy programach "dlugo dzialajacych", cokolwiek serwujacych - sam wiesz ;)
btw. co prawda pypy w tej chwili faktycznie transluje sie do c, ale nie oznacza to ze tak musi byc zawsze... tak wiec "te dolne warstwy" wcale w c nie musza byc (np. taki rebol czy redcode, nie pamietam - jest self hosted, podobnie jak haskele, podobnie jak cala inna masa jezykow ... z c wlacznie ;) ). ta "dolna warstwa" to i tak kod maszynowy...
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.
No to w takim razie D: http://www.d-programming-language.org/
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.
Nie mówię o relacji kodu źródłowego do wynikowego, tylko o wszechobecnej arytmetyce wskaźników, rzutowaniu wszystkiego na wszystko i konsekwencjach chwili nieuwagi podczas tych radosnych zabaw.
D nie ma być rozwojowe, tylko praktyczne. Wprawdzie natywnych bibliotek do rzeczy trudnych jest jeszcze jak na lekarstwo, ale proste rzeczy robi się prosto. Jeśli chodzi o wątki i współbieżność, programista już może wybrać, zależnie od preferencji i zadania, std.parallelism albo std.concurrency.
Ponadto oftopikujemy, proponuję banan dla wszystkich. :)
Ostatnio edytowany przez epi (2012-01-17 15:43:18)
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: Nie zmieniaj tematu - nerdowe dowcipy nie wniosą nic do dyskusji o językach (i smakach, bo w końcu ważną funkcją języka jest odczuwanie smaku ;)). Mówię to jako ten, co rozumie wskaźniki i ma dziewczynę. :)
Ludzie po prostu się od siebie różnią i każdy na tym poletku ma swoją mniejszą lub większą grządkę i uprawia sobie na niej (ze skutecznością zależną od inteligencji, umiejętności, wiedzy, pracowitości i zbiegów okoliczności) trochę tego, co mu smakuje, i trochę tego, co może sprzedać. A smaki programistów i kupujących również są najrozmaitsze.
Ostatnio edytowany przez epi (2012-01-17 16:27:37)
Adam: wiem ze to zabrzmi dziwnie, ale slyszales kiedys o... kross kompilacji? :)
i jaki tam D, ć ftw! ;)
Epi: odfiltruj dowcip zostanie to co istotne
jellonek: a co to wnosi do tematu?
Eetam. zrównoleglanie powinno być robione na dwóch poziomach:
a) języka (zrównoleglanie pętli, itp)
Nie zgodzę się. Ingerencja w język naprawdę nie jest do tego potrzebna. parallel_for_each + lambda z "nowoczesnego C++" ;) załatwia sprawę.
b) projektu (podział procesów na wątki, itp)
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ę.
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.
"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).
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).
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...
co do c - malo ekonomiczny jezyk, trudniejsze w opracowaniu unit testy, dluzszy cykl pisanie/kompilowanie/debugowanie niz w jezykach dynamicznych
Ale za to błędy wychodzą u programisty podczas kompilacji, a nie u użytkownika podczas wykonania ;)
ktore dzieki tracing jit potrafia byc wydajniejsze niz statycznie optymalizowany kod gcc/msvc ;)
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)
Moze mi ktos po krotce strescic o co sie klocicie? Bo serio nie wiem.
O rację :) a to już było http://www.atari.org.pl/forum/viewtopic … 09#p139909
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.092 sekund, wykonano 9 zapytań ]