Kezdőoldal » Számítástechnika » Programozás » (C++) Hogy lehet az, hogy a...

(C++) Hogy lehet az, hogy a párhuzamosított program sokkal lassabb, mint a szekvenciálisan futó?

Figyelt kérdés

Kaptam egy egyetemi feladatot, miszerint a MergeSort algoritmust kell párhuzamosítva leimplementálni. Röviden, tömören, a MergeSort minden futáskor kettészeli a kapott intervallumot, és a két részre rekurzívan meghívja magát, a baloldali részt aszinkron új szálon, aztán a jobboldalit a jelenlegi szálon, szekvenciálisan, ezután ha mindkét ág lefutott összefésüli az eredményt. Finomításként még azt is meg kellett határozni, hogy mekkora intervallum méret alatt célszerűbb egyszerű buborékrendezést alkalmazni, a szálakra bontogatás helyett. Oké. Megcsináltam, és jópár tesztet lefuttattam, hogy megkapjam, milyen gyorsan fut le adott értékek mellett.


Példának okáért, egy 10 000 adatból álló állományt átlagosan másfél másodperc alatt rendezett le, ha 0 határszámot adtam meg a buborékrendezésre (azaz egyáltalán nem használtam buborékrendezést), meg az optimális értéket valahol 200 környékén lőttem be, ahol 0,033 mp volt az átlagos futási idő.


Az érdekes rész ott következett, hogy kíváncsiságból átírtam egyszerű szekvenciális futásra, többszálú működést kivéve. Azonos körülmények mellett 0,018 másodperc volt az átlagos futási idő 0-s határszám mellett, és 0,013 másodperc optimális (ezesetben 10) határszám mellett. Ez azt jelenti, hogy a buborékrendezés nélküli esetben a szekvenciális változat százszor(!) olyan gyors volt, mint az aszinkron, és az optimális esetben is harmadannyi idő alatt lefutott, 10 ezer adatra.


Mégis hogy lehet az, hogy a több szálra bontás, ami elméletben épp a futás gyorsítását hívatott elősegíteni ilyen drasztikus mértékben lassabb futást eredményezett?


2016. nov. 27. 03:52
 1/3 anonim ***** válasza:
Jól értem, hogy rekurzivan minden lépésben új szálat hozol létre, vagy csak az első lépéskor? (Tehát 2 szál lesz csak). Ha minden lépésben új szálat hozol létre, az baromi nagy overhead + több szálad is lesz valszinűleg mint ahány magod van a gépben, szóval ott a párhuzamositás nem hogy használ, de _nagyon_ lassit.
2016. nov. 27. 10:03
Hasznos számodra ez a válasz?
 2/3 anonim ***** válasza:
Ilyen nagy lassulásnál én un. false sharingre gyanakodnék, vagyis a threadek folyamatosan frissítésre kényszerítik egymás chachéjét, mert bár külön változókat használnak, azok túl közel vannak egymáshoz a memóriában, ezért ugyanazon a cache lineon lesznek (ugyebár a cachébe manaspág már 64bites szokakaszokat rántunk be, ha túl közel vannak a változók akkor mindkét thread catche linejában ott lesznek, és ezért ha akármi írás történik benne, frissíteni fogja az összes másolatot a vezérlés ha kell ha nem. Értelemszerűen jó sok idő és erőforrás pazarlás folyton frissítgetni). [link]
2016. nov. 27. 11:50
Hasznos számodra ez a válasz?
 3/3 anonim ***** válasza:

Egyszeruen tul sok szalad van.

Elvesz a parhuzamositas elonye az "adminisztracion".

Ez onnan is latszik, hogy ha 200 alatt nem csinalsz uj szalat, akkor nem lassul le az otvenedere a dolog.

Meg olyat is csinalhatsz, hogy lemered hany szalat csinalsz es mennyi idobe kerul.

2016. nov. 27. 14:24
Hasznos számodra ez a válasz?

Kapcsolódó kérdések:





Minden jog fenntartva © 2024, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu

A weboldalon megjelenő anyagok nem minősülnek szerkesztői tartalomnak, előzetes ellenőrzésen nem esnek át, az üzemeltető véleményét nem tükrözik.
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!