Add solution of first task - impelemented loop_mesh_builder

Author: xstupi00

PMC-xlogin00.txt

@@ -0,0 +1,84 @@
+Architektury Výpočetních Systémů (AVS 2019)
+Projekt č. 2 (PMC)
+Login: xstupi00
+
+Úloha 1: Paralelizace původního řešení
+===============================================================================
+
+1) Kterou ze smyček (viz zadání) je vhodnější paralelizovat a co způsobuje 
+   neefektivitu paralelizaci té druhé?
+
+1a)
+Vhodnejšie je parelelizovať smyčku vo funkcii `LoopMeshBuilder::marchCubes` v
+porovnaní s druhou smyčkou vo funkcii `LoopMeshBuilder::evaluateFieldAt`.
+
+1b)
+Neefektivita druhej smyčky je spôsobená výrazne väčším overheadom ako je samotný
+prínos paralelizácie danej smyčky. Táto smyčka sa nachádza vo funkcii
+`LoopMeshBuilder::evaluateFieldAt, ktorá je volaná 8x pre každý beh funkcie
+`BaseMeshBuilder::buildCube`, pre každý vrchol kocky raz. Pre každú kocku, tak
+dochádza k vytvoreniu a následnému zrušeniu daného počtu vlákien (napr. 16) až 8x,
+čo práve spôsobuje veľký overhead a tým zhoršenie celkovej výkonnosti programu.
+
+-------------------------------------------------------------------------------
+
+2) Jaké plánování (rozdělení práce mezi vlákna) jste zvolili a proč? 
+   Jaký vliv má velikost "chunk" při dynamickém plánování (8, 16, 32, 64)?
+
+
+2a)
+Zvolil som dynamický typ plánovania s hodnotou chunk-size=16 (schedule(dynamic, 16)).
+Tento typ plánovania dosahoval pri testovaní rôznych variant o niečo lepšie výsledky
+ako statické plánovanie a v porovnaní s typom `guided` dosahoval takmer rovnaké
+výsledky. Výpočet pre každú kocku trvá približne rovnaký čas, takže môžme povedať, že
+práca je vhodne distribuovaná medzi jednotlivé vlákna už v základe. Malý rozdiel medzi
+statickým a dynamickým plánovaním môže byť spôsobený tým, že v prípadoch, kedy nie sú
+všetky vrcholy kocky pod alebo nad povrchom (povrch pretína kocku) prebieha oproti
+zvyšným iteráciam aj interpolácia vybraných polygónov, čo spôsobí o niečo dlhšie
+trvanie výpočtu v danej iterácií. Takýchto iterácií, v ktorých dochádza k
+interpolácií polygónov, je však z celkového počtu minimum (cca < 8% u bun_zipper_res a
+< 5% u dragon_vrip_res) a preto dynamické plánovanie nespôsobuje väčši rozdiel v tomto
+procese paralelizácie.
+
+
+2b)
+Pri voľbe dynamického plánovania s rôznou hodnotou parametru `chunk-size` som
+nezaznamenal žiadne výrazné zmeny vo výkonnosti programu.
+
+-------------------------------------------------------------------------------
+
+3) Jakým způsobem zajišťujete ukládání trojúhelníků z několika vláken současně?
+
+Použitím pragmy `omp critical` vo funkcii `LoopMeshBuilder::emitTriangle` pred
+uložením daného trojuholníka `BaseMeshBuilder::Triangle_t` do vektora už
+uložených trojuholníkov `LoopMeshBuilder::mTriangles`. Táto pragma identifikuje
+sekcie kódu, ktoré musia byť vykonávané len jedným vláknom v danom čase a
+zabezpečuje tak, že zápis do vektora bude realizovať vždy len jedno vlákno.
+V prípade, že niektoré z vlákien práve realizuje zápis do vektora a súčasne
+iné vlákno má taktiež požiadavku na zápis, bude musieť toto vlákno čakať na
+začiatku kritickej sekcie dokiaľ prvé vlákno nedokončí operáciu zápisu a tým
+vypadne z kritickej sekcie, čím umožní vstup inému vláknu, ktoré čaká na vstupe.
+
+
+Úloha 2: Paralelní průchod stromem
+===============================================================================
+
+1) Stručně popište použití OpenMP tasků ve vašem řešení.
+
+2) Jakým způsobem jste realizovali sesbírání celkového počtu trojúhelníků?
+
+3) Jaký vliv má na vaše řešení tzv. "cut-off"? Je vhodné vytvářet nový 
+   task pro každou krychli na nejnižší úrovni?
+
+4) Jakým způsobem zajišťujete ukládání trojúhelníků z několika vláken současně?
+
+Úloha 2: Grafy škálování obou řešení
+===============================================================================
+
+1) Stručně zhodnoťte efektivitu vytvořených řešení (na základě grafů škálování).
+
+2) V jakém případě (v závislosti na počtu bodů ve vstupním souboru a velikosti 
+   mřížky) bude vaše řešení 1. úlohy neefektivní? (pokud takový případ existuje)
+
+3) Je (nebo není) stromový algoritmus efektivnější z pohledu slabého škálování 
+   vzhledem ke vstupu?

PMC-xstupi00.txt

@@ -2,4 +2,4 @@ qsub -A DD-19-32 -q qexp -l select=1:ncpus=16,walltime=1:00:00 -I
 ml intel CMake Python/3.6.1
 cmake . -DCMAKE_BUILD_TYPE=Release
 make -j
-./PMC ../data/bun_zipper_res4.pts bun_zipper_res4.obj --builder=loop
+./PMC ../data/bun_zipper_res1.pts bun_zipper_res1.obj --builder=loop

commands.txt

@@ -17,3 +17,11 @@ GRID
   -> dĺžka hrany diskretizačnej mriežky a s ňou rozlíšenie diskretizácie a celkový počet "MarchingCubes" (N = g^3)
   -> BaseMeshBuilder.mGridSize;
 
+----------------------------------------------------------------------------------------------
+| static     | 13732 | 13768 | 13743 | 13742 | 13759 | 13758 | 13741 | 13775 | 13743 | 13753 |
+| dynamic 8  | 13698 | 13707 | 13708 | 13721 | 13725 | 13703 | 13718 | 13711 | 13704 | 13701 |
+| dynamic 16 | 13709 | 13730 | 13712 | 13712 | 13722 | 13722 | 13722 | 13731 | 13714 | 13710 |
+| dynamic 32 | 13707 | 13716 | 13734 | 13716 | 13741 | 13725 | 13723 | 13739 | 13721 | 13719 |
+| dynamic 64 | 13746 | 13726 | 13727 | 13743 | 13744 | 13734 | 13744 | 13738 | 13745 | 13736 |
+| guided     | 13710 | 13742 | 13728 | 13704 | 13711 | 13710 | 13697 | 13710 | 13713 | 13705 |
+----------------------------------------------------------------------------------------------

notes.txt

@@ -19,15 +19,15 @@ LoopMeshBuilder::LoopMeshBuilder(unsigned gridEdgeSize)
 
 }
 
-unsigned LoopMeshBuilder::marchCubes(const ParametricScalarField &field)
-{
+unsigned LoopMeshBuilder::marchCubes(const ParametricScalarField &field) {
     // 1. Compute total number of cubes in the grid
     // N = g^3 = mGridSize^3
     size_t totalCubesCount = mGridSize * mGridSize * mGridSize;
 
     unsigned totalTriangles = 0;
 
     // 2. Loop over each coordinate in the 3D grid.
+#pragma omp parallel for default(shared) reduction(+:totalTriangles) schedule(dynamic, 32)
     for (size_t i = 0; i < totalCubesCount; ++i) {
         // 3. Compute 3D position in the grid.
         Vec3_t<float> cubeOffset(i % mGridSize,
@@ -43,8 +43,7 @@ unsigned LoopMeshBuilder::marchCubes(const ParametricScalarField &field)
     return totalTriangles;
 }
 
-float LoopMeshBuilder::evaluateFieldAt(const Vec3_t<float> &pos, const ParametricScalarField &field)
-{
+float LoopMeshBuilder::evaluateFieldAt(const Vec3_t<float> &pos, const ParametricScalarField &field) {
     // NOTE: This method is called from "buildCube(...)"!
 
     // 1. Store pointer to and number of 3D points in the field
@@ -56,11 +55,11 @@ float LoopMeshBuilder::evaluateFieldAt(const Vec3_t<float> &pos, const Parametri
 
     // 2. Find minimum square distance from points "pos" to any point in the
     //    field.
-    for(unsigned i = 0; i < count; ++i)
-    {
-        float distanceSquared  = (pos.x - pPoints[i].x) * (pos.x - pPoints[i].x);
-        distanceSquared       += (pos.y - pPoints[i].y) * (pos.y - pPoints[i].y);
-        distanceSquared       += (pos.z - pPoints[i].z) * (pos.z - pPoints[i].z);
+//#pragma omp parallel for default(shared) reduction(min:value) schedule(static)
+    for (unsigned i = 0; i < count; ++i) {
+        float distanceSquared = (pos.x - pPoints[i].x) * (pos.x - pPoints[i].x);
+        distanceSquared += (pos.y - pPoints[i].y) * (pos.y - pPoints[i].y);
+        distanceSquared += (pos.z - pPoints[i].z) * (pos.z - pPoints[i].z);
 
         // Comparing squares instead of real distance to avoid unnecessary
         // "sqrt"s in the loop.
@@ -77,5 +76,6 @@ void LoopMeshBuilder::emitTriangle(const BaseMeshBuilder::Triangle_t &triangle)
     // Store generated triangle into vector (array) of generated triangles.
     // The pointer to data in this array is return by "getTrianglesArray(...)" call
     // after "marchCubes(...)" call ends.
+#pragma omp critical(emitTriangle)
     mTriangles.push_back(triangle);
 }