parallel extension .Net 4.0

bawiliscie sie moze w net 4 beta rownolegloscia ?
probowalem tworzenia watkow i dzialaja wysmienicie. natomiast dziwna jest dla mnie kwestia zrownoleglania petli

for (int d = 0; d < 100; d++)
 {

 }

 Parallel.For(1, 100, delegate(int d)
                            {

                            });

testowalem dwie petle. pierwsza - standardowa - wykorzystanie procesora z dwoma rdzeniami ok 50%.
Druga, urzekajaca - wykorzystanie procka - 100% a wiec oba rdzenie.
tyle ze wykonuje sie z 4 razy dluzej ..
testowalem to na bardzo duzych petlach.

jedna z mozliwosci - zbyt male zadanie. sumowalem sobie cos tam w petelkach, jakies proste zmienne. moze one same w sobie wykonuja sie tak szybko, ze narzut zwiazany ze zrownolegleniem petli jest nieoplacalny. Testowal ktos na duzych zadaniach ?
wynika z tego ze trzeba bardzo uwazac stosujac powyzsze.
przy jakims zadaniu w czterech zagniezdzonych petlach bez rownoleglosi - okolo 2 minut, przy zrownoleglonych - po 15 minut wylaczylem to, bo nie wiem czy to by sie kiedys wykonalo ..

PlinQ nie testowalem osobiscie, ale podobno daje bardzo dobre rezultaty ;)

Kiedyś testowałem, jakiś prosty raytracer miałem napisany i odpalałem albo normalnie w forze, albo w parallelu. Przyrost jest faktycznie widoczny, w takim raytracingu wszystko może iść równolegle, nie ma z tym najmniejszego problemu, przyspieszenie było ewidentnie widoczne. Podobnie odpalenie równoległych exampli udostępnionych przez MS (też raytracery jakieś), puszczone na trzech rdzeniach, zajmowały wszystkie trzy rdzenie i przyspieszenie było gdzieś w granicach 2,5x czyli bardzo fajne moim zdaniem.
Przy jakichś prostych sumowaniach narzut tworzenia tasków, rzucania między rdzeniami i tak dalej na pewno będzie większy niż sam czas obliczania.

szulazek napisał(a)

przy jakims zadaniu w czterech zagniezdzonych petlach bez rownoleglosi - okolo 2 minut, przy zrownoleglonych - po 15 minut wylaczylem to, bo nie wiem czy to by sie kiedys wykonalo ..

przeanalizuj z czego zewnetrzengo korzytasz w tych po4nych petlach. ilosc zagniezdzen sugeruje, ze masz sporo obiektow 'zrodlowych' i w momencie gdy wszystko opakowales delegatem i parallel'em, kompilator pewnie wygenerowal lock'i, tak aby watki robocze nie przecinaly sie przy dostepach do tych obiektow. sprawdz i sprobuj to wyeliminowac. nie pobieraj kolekcji na bieżąco bezposrednio, tylko odbierz raz i sobie przechowaj lokalnie, zminimalizuj w ogole jakiekolwiek odniesienia do czegokolwiek wewnatrz tych petli. pamietaj o przykazaniu jednej kropki, tutaj moze okazac sie zlote :)

@quetzalcoatl - Mógłbyś podać jakieś źródło gdzie można poczytać o tych generowanych lockach?

Niestety nie, nie pamietam ani linkow, ani nawet dokladnie o co moze chodzic. Napisalem tak jak napisalem - w formie pewnie/moze/sprawdz, poniewaz to jest jedyna opcja jaka przychodzi mi na mysl, ktora moglaby tlumaczyc wzrost z 2 do 15 minut - pominalem fakt, ze autor sam mogl sobie czyms w stope strzelic.

Jakkolwiek dotąd nie zauważyłem/nie spodziewałem się żeby kompilator "śmiał" wstrzelić gdzieś locka, ale ostatnio czytałem, że jednak dorzuca locki np. przy implementacjach eventow - i jest to jeden z breaking changes miedzy 2..3.5 a 4. Na to akurat mam linka:
http://blogs.msdn.com/cburrows/archive/2010/03/18/events-get-a-little-overhaul-in-c-4-part-iii-breaking-changes.aspx tzn. było to opisane wylewnie w czesci I lub II

quetzalcoatl zrobilem pusty przebieg petli. ja mysle ze to narzut na komunikacje.
bo podzielilem najbardziej wewnetrzna petle. zrobie jakis tescik jak bede mial chwile z jakimis innymi operacjami, jak cos wywnioskuje to sie podziele :)

no, to moje w/w sugestie co do mozliwych lockow w eventach czy gdziekolwiek indziej sa kompletnie nietrafione.

przy pustych petlach to dosc oczywiste ze idzie duzo wolniej.. ostatecznie jak miales puste petle for x=0;x<1000,.... nawet takie pozagniezdzane, kompilator mogl je wywalic calkiem jako kod bez efektu albo przynajmniej ostro rozwinac lub w dowolny inny sposob zoptymalizowac same petle.. po opakowaniu w delegata i owinieciu tego w 4x pararell.for juz tego zrobic nie mogl