Add the incremental mapping function, which re-utilizes the previous mapping results to acceleterate ccurrent mapping. #24

yyan7223 · 2024-09-10T03:38:02Z

No description provided.

tancheng

Plz also add description for this PR, thanks!

tancheng · 2024-09-10T05:27:44Z

README.md

@@ -102,8 +102,14 @@ Execution
  - [regConstraint](https://github.com/tancheng/CGRA-Mapper/blob/589fd61434966e4d4a44220b59854b1795bc7cde/test/param.json#L18): the number of registers used to temporarily hold the arrived data for later computation. Set as 8 by default.
  - [optLatency](https://github.com/tancheng/CGRA-Mapper/blob/589fd61434966e4d4a44220b59854b1795bc7cde/test/param.json#L19): used to support multi-cycle execution. If this field is not specified, every operation is done in one single-cycle. Note that there is currently no hardware support for this feature, which is supposed to be used for performance exploration only.
  - [optPipelined](https://github.com/tancheng/CGRA-Mapper/blob/589fd61434966e4d4a44220b59854b1795bc7cde/test/param.json#L23): used to enable pipelined execution of the multi-cycle operation (i.e., indicated in [optLatency](https://github.com/tancheng/CGRA-Mapper/blob/589fd61434966e4d4a44220b59854b1795bc7cde/test/param.json#L19)).
+<<<<<<< HEAD


Sorry it's a typo

tancheng · 2024-09-10T05:27:51Z

README.md

  - [additionalFunc](https://github.com/tancheng/CGRA-Mapper/blob/589fd61434966e4d4a44220b59854b1795bc7cde/test/param.json#L24): used to enable specific functionalities on target tiles. Normally, we don't need to set this field as all the tiles already include most functionalities. By default, the `ld`/`st` is only enabled on the left most tiles. So if you wanna enable the memory access on the other tiles, this field needs to be provided. 
+
+=======


Sorry it's a typo

tancheng · 2024-09-10T05:30:13Z

README.md

+
+=======
+  - [additionalFunc](https://github.com/tancheng/CGRA-Mapper/blob/589fd61434966e4d4a44220b59854b1795bc7cde/test/param.json#L24): used to enable specific functionalities on target tiles. Normally, we don't need to set this field as all the tiles already include most functionalities. By default, the `ld`/`st` is only enabled on the left most tiles. So if you wanna enable the memory access on the other tiles, this field needs to be provided.
+  - [incrementalMapping](https://github.com/yyan7223/CGRA-Mapper/blob/10aa217e9e995b6dfa4242e0ce121b79668e9995/test/param.json#L28C1-L28C33) `true` indicates incremental mapping while `false` indicates heuristic/exhaustive mapping. Incremental mapping re-utilizes the previous mapping results to accelerate current mapping.


I am wondering why we need to let the user perform the two-step experiment. Why cannot just set this to true, and it will automatically perform heuristic/exhaustive first, then, based on the generated .json and perform the incremental mapping?

Imagine a situation that we firstly map the KERNEL1 with 200 DFGNodes on 400 CGRANodes, and the heuristic mapper takes 1 hour to finish this.

Then let's say KERNEL2 takes 10 of 400 CGRANodes from KERNEL1, normally we need to re-map KERNEL1 on the rest of 390 CGRANodes from the scratch, which will cost us 1 hour again. This is the time when we need the incremental mapping, we can simply set the incrementalMapping to true, then the mapping can finish within several minutes.

But for small DFG mapping on small CGRAs, the heuristic mapper has already been fast enough and we seem do not need incremental mapping to further accelerate the mapping, so that's why I set incrementalMapping default to false.

(I have not really tested the incremental mapping on large DFG and large CGRA, It will definitely bring significant mapping acceleration, but may require additional tricks to ensure mapping quality. Anyway, I think incremental mapping might be an interesting idea in CGRA just like it in FPGA)

Thanks for the explanation. Does it mean:

We need to manually disable 10 nodes (before the second time mapping for KERNEL1) as those nodes are occupied by KERNEL2?

It is possible that the 10 nodes totally destroy the routing opportunities for the second time KERNEL1's mapping? So we have to re-map? How is this case handled?

IncrementalMapping needs to check whether the increMapInput.json exists in the folder?

If it exists, how to guarantee it is for KERNEL1, instead of some random kernels?

I don't think we need to manually do this. There should be some sort of task scheduler that is responsible for automatically generating resource allocation decisions and corresponding param.json for Kernel1 adn Kernel2, just like the DRIPS controller.

Yes it is possible, but we can add a mechanism in the future like if resource changes over 50% of CGRANodes, incremental mapping is automatically disabled and start to re-map, just like in Vivado.

Yes, IncrementalMapping should check whether increMapInput.json is corresponding to Kernel1, which can be achieved by comparing some fields in .json like KernelID. Or if developers use CGRA-Flow, we can simply add a message box and let them choose the correct .json.

Current merge request is just a initial version of incremental mapping, and I know there are lots of functions are incomplete, but I’m happy to complement all the related functions in the future and hope they actually contributes to the CGRA development rather than just some academic ideas.

But for now, if I want to use this feature, I need manually disable some tiles (before invoking the incremental mapping) to see its effect, right?

Can you please provide the description about the constraint (users need to guarantee that increMapInput.json exists and the incrementalMapping can only work on the same kernel (and users need to manually disable some tiles?).

Please check the updated README.md

tancheng · 2024-09-10T05:30:17Z

README.md


+>>>>>>> b9b4a106e781ac2f8506ceca4a29abded7a088da


Sorry it's a typo

tancheng · 2024-09-10T05:32:36Z

src/Mapper.cpp

@@ -1346,3 +1346,223 @@ map<int, CGRANode*>* Mapper::getReorderPath(map<CGRANode*, int>* t_path) {
  return reorderPath;
 }

+
+// save the mapping results to json file for subsequent incremental mapping


// save the mapping results to json file for subsequent incremental mapping -> // Saves the mapping results to json file for subsequent incremental mapping.

Same to the other comments, thanks!

Has been corrected

tancheng · 2024-09-10T05:44:22Z

src/Mapper.cpp

+                        bypassNums_CGRANode[numBypass].push_back(curCGRANode);
+                }
+
+                for (auto iter : bypassNums_CGRANode){ // map is sorted by key from smallest to largest by default, and tile with fewer bypass nodes has higher priority 


space between ) and {.

Has fixed all similar issues

tancheng · 2024-09-10T05:45:07Z

src/Mapper.cpp

+
+        int initLevel = level;
+        while(true){
+                map<int, vector<CGRANode*>> bypassNums_CGRANode;


Plz comment on what is this map used for.

map<int, vector<CGRANode*>> bypassNums_CGRANode is used for sorting the CGRANodes with the number of bypass operations required to communicate with its predecessors.

Has been corrected

tancheng · 2024-09-10T05:47:59Z

src/Mapper.cpp

+
+// incremental mapping functions
+int Mapper::incrementalMap(CGRA* t_cgra, DFG* t_dfg, int t_II){
+        if(readRefMapRes(t_cgra, t_dfg) == -1) return -1;


It seems the indent of all your functions is not aligned with existing codebase. Plz make them consistent (two spaces iirc).

Has been corrected

tancheng · 2024-09-10T05:50:17Z

src/Mapper.h

@@ -27,6 +27,11 @@ class Mapper {
    list<map<CGRANode*, int>*>* getOrderedPotentialPaths(CGRA*, DFG*, int,
        DFGNode*, list<map<CGRANode*, int>*>*);

+    /***********Added by yyf on 2024/09/10 for incremental mapping**************/


space between * and Added

space between mapping and *

You can replace yyf with your github ID or email. Or leave it as it is.

Has been corrected

tancheng · 2024-09-10T05:50:50Z

src/Mapper.h

@@ -27,6 +27,11 @@ class Mapper {
    list<map<CGRANode*, int>*>* getOrderedPotentialPaths(CGRA*, DFG*, int,
        DFGNode*, list<map<CGRANode*, int>*>*);

+    /***********Added by yyf on 2024/09/10 for incremental mapping**************/
+    map<DFGNode*, CGRANode*> refMapRes;


Plz comment on refMapRes.

refMapRes is short for reference mapping results, which contains the mapping relationship between each DFGNode and CGRANode

reference mapping indicates the original mapping read from the .json, right?

When I say comment on, I mean provide the // Provides comments above the corresponding code. Thanks~!

Then plz add the comments above it.

tancheng · 2024-09-13T03:41:32Z

README.md

+
+=======
+  - [additionalFunc](https://github.com/tancheng/CGRA-Mapper/blob/589fd61434966e4d4a44220b59854b1795bc7cde/test/param.json#L24): used to enable specific functionalities on target tiles. Normally, we don't need to set this field as all the tiles already include most functionalities. By default, the `ld`/`st` is only enabled on the left most tiles. So if you wanna enable the memory access on the other tiles, this field needs to be provided.
+  - [incrementalMapping](https://github.com/yyan7223/CGRA-Mapper/blob/10aa217e9e995b6dfa4242e0ce121b79668e9995/test/param.json#L28C1-L28C33) `true` indicates incremental mapping while `false` indicates heuristic/exhaustive mapping. Incremental mapping re-utilizes the previous mapping results to accelerate current mapping.


Thanks for the explanation. Does it mean:

We need to manually disable 10 nodes (before the second time mapping for KERNEL1) as those nodes are occupied by KERNEL2?

It is possible that the 10 nodes totally destroy the routing opportunities for the second time KERNEL1's mapping? So we have to re-map? How is this case handled?

IncrementalMapping needs to check whether the increMapInput.json exists in the folder?

If it exists, how to guarantee it is for KERNEL1, instead of some random kernels?

tancheng · 2024-09-13T03:44:58Z

src/CGRANode.cpp

@@ -579,3 +579,7 @@ void CGRANode::disableAllFUs() {
  m_supportComplex = false;
  m_supportVectorization = false;
 }
+
+bool CGRANode::isDisabled() {


So now, disabled implicitly indicates two cases:

HW choice to disable it, no data can pass it, no operation can map on it, or even serve as a dead point in the fabric.

Another simultaneous kernel is occupying this CGRA tile/node, which makes it impossible for current kernel to leverage it.

Correct?

Thanks for the confirmation, plz summarize above two cases and put the summary as comment above the m_disabled.

I think about it again, if CGRANode5 is allocated to Kernel1, m_disabled should be set to false in Kernel1's paramCGRA.json but true in other kernels' paramCGRA.json

tancheng · 2024-09-13T03:48:04Z

src/Mapper.cpp

+}
+
+// generates the placement recommendation list for current DFGNode by referencing its placement in the former mapping results
+// Two principles: RPT & MBO


Thanks, super clear!

tancheng · 2024-09-13T03:49:04Z

src/Mapper.cpp

+}
+
+// generates the placement recommendation list for current DFGNode by referencing its placement in the former mapping results
+// Two principles: RPT & MBO


Plz just provide the full name for RPT and MBO for now.

tancheng · 2024-09-13T03:51:37Z

src/Mapper.h

@@ -27,6 +27,11 @@ class Mapper {
    list<map<CGRANode*, int>*>* getOrderedPotentialPaths(CGRA*, DFG*, int,
        DFGNode*, list<map<CGRANode*, int>*>*);

+    /***********Added by yyf on 2024/09/10 for incremental mapping**************/
+    map<DFGNode*, CGRANode*> refMapRes;


reference mapping indicates the original mapping read from the .json, right?

When I say comment on, I mean provide the // Provides comments above the corresponding code. Thanks~!

tancheng · 2024-09-13T05:55:35Z

src/Mapper.cpp

@@ -1346,3 +1346,206 @@ map<int, CGRANode*>* Mapper::getReorderPath(map<CGRANode*, int>* t_path) {
  return reorderPath;
 }

+// Saves the mapping results to json file for subsequent incremental mapping


Period at the end, thanks! Same to the others.

Sorry what do you mean?

mapping -> mapping. Sorry for being picky.

Has fixed all similar issues

tancheng · 2024-09-13T05:58:54Z

src/Mapper.cpp

+  int maxLevel = CGRANodes_sortedByLevel.size() - 1;
+  cout<<t_dfgNode->getOpcodeName()<<t_dfgNode->getID()<<" is mapped to Tile "<<refCGRANode->getID()<<" in the referenced mapping results, refLevel="<<refLevel<<endl;
+
+  int initLevel = level;


If level indicates the number of FanIO, why not just fanIO instead of level?

BTW, can we replace fanIO with inOutDegree? WDYT?

Yeah these two variables are easily confused, I use the following examples to explain the difference:

map<int, vector<CGRANode*>> FanIO_CGRANodes = {
{4, {CGRANode5, CGRANode6, CGRANode9, CGRANode10}},
{3, {CGRANode1, CGRANode2, CGRANode4, CGRANode7, CGRANode8, CGRANode11, CGRANode13, CGRANode14}},
{2, {CGRANode0, CGRANode3, CGRANode12, CGRANode15}}
}
{CGRANode5, CGRANode6, CGRANode9, CGRANode10} all have FanIO=5 and Level=0
{CGRANode1, CGRANode2, CGRANode4, CGRANode7, CGRANode8, CGRANode11, CGRANode13, CGRANode14} all have FanIO=4 and Level=1
{CGRANode0, CGRANode3, CGRANode12, CGRANode15} all have FanIO=3 and Level=2

For an athelete in a championship, FanIO is his score, while Level is his ranking.

I thought I/O degree is for DFG and FanIO for CGRA?

Xiangyu Kong, Yi Huang, Jianfeng Zhu, Xingchen Man, Yang Liu, Chunyang Feng, Pengfei Gou, Minggui Tang, Shaojun Wei, and Leibo Liu. 2023. MapZero: Mapping for Coarse-grained Reconfigurable Architectures with Reinforcement Learning and Monte-Carlo Tree Search. In Proceedings of the 50th Annual International Symposium on Computer Architecture (ISCA '23). Association for Computing Machinery, New York, NY, USA, Article 46, 1–14. https://doi.org/10.1145/3579371.3589081

Sounds good, i am okay with FanIO. Can you rename level to priority? I still think we can just compare FanIO without using level or priority, which is more straightforward to me (i.e., larger FanIO has higher priority), level is just reversing their original ordering. Either way is fine, you can make the call. Just plz let me now.

Larger FanIO not always has higher priority, for example in the referenced mapping results, DFGNode10 is mapped to CGRANode4 that has FanIO=4, which is a middle level of FanIO because we also have CGRANodes whose FanIO=3 and FanIO=5 under 4x4 CGRA.

So when incrementalMap() choose which CGRANodes within the new resource allocation decision have highest priority for DFGNode10 to map on, those CGRANodes with the middle level of FanIO will be selected. And the middle level of FanIO may not always equal to 4, for example in the new resource allocation decision shown in the follow image, the middle level of FanIO is 2 (Others levels are FanIO=1 and FanIO=3).

Comparing the FanIO may mislead incrementalMap() to select the CGRANodes with FanIO=3 if you think larger FanIO has higher priority?

So sorry I still think level may be more appropriate than priroity.

How could there exist FanIO=5 under 4x4 CGRA? I assume you are talking about FanIO=4. It sounds like you are ordering the tiles based on how their FanIO is closed to the FanIO of the tile the DFGNode was originally mapped on. Can you please schedule a 20min one-on-one meeting with me?

Plz add comment "The level is used to ordering the CGRANodes based on the FanIO. Though FanIO of each CGRANode would change for different CGRA architectures, the DFGNode prefers to being mapped onto the CGRANode with same level."

tancheng · 2024-09-13T18:28:52Z

src/Mapper.cpp

@@ -1365,8 +1365,8 @@ void Mapper::generateJSON4IncrementalMap(CGRA* t_cgra, DFG* t_dfg){

  jsonFile<<"     \"Tile2Level\":{"<<endl;      
  // Generates level informations of current mapping results
-  map<int, vector<CGRANode*>> FanIO_CGRANodes;
-  vector<int> FanIOs;
+  vector<int> FanIOs; // FanIO is the number of links of current CGRANode connected to other CGRANode.


Plz just move the comments above the code. You can insert a line between two comments if you want.

Same to the others.

Has fixed all similar issues

tancheng · 2024-09-14T02:35:56Z

src/Mapper.cpp

@@ -1469,7 +1478,8 @@ list<CGRANode*> Mapper::placementGen(CGRA* t_cgra,  DFGNode* t_dfgNode){

  int initLevel = level;
  while (true) {
-    map<int, vector<CGRANode*>> bypassNums_CGRANode; // Sorts the CGRANodes with the number of bypass operations required to communicate with its predecessors.
+    // Sorts the CGRANodes with the number of bypass operations required to communicate with its predecessors.


Comments could be in two lines.

Has fixed all similar issues

tancheng · 2024-09-14T02:36:48Z

src/Mapper.cpp

          }
        }
      }
-      if (dfgNodeMapFailed) break; // Current DFGNode fails mapping, increase II and restart
+      // Current DFGNode fails mapping, increase II and restart.


// Increases II and restart if current DFGNode fails the mapping.

Has been corrected

tancheng · 2024-09-14T02:37:34Z

src/Mapper.cpp

          }
          else {
+            // Switches to next tile in placementRecommList.


// Switches to the next tile.

Has been corrected

tancheng · 2024-09-14T02:38:48Z

src/Mapper.cpp

        }
        else {
          if (schedule(t_cgra, t_dfg, t_II, *dfgNode, path, false)) {
+            // Current DFGNode finishes mapping, move to next DFGNode.


// Current DFGNode is scheduled successfully, moves to the next DFGNode.

Has been corrected

tancheng

Plz address the last two comments so we can merge this PR, thanks for the effort~!

tancheng · 2024-09-16T03:05:11Z

README.md

@@ -103,6 +103,7 @@ Execution
  - [optLatency](https://github.com/tancheng/CGRA-Mapper/blob/589fd61434966e4d4a44220b59854b1795bc7cde/test/param.json#L19): used to support multi-cycle execution. If this field is not specified, every operation is done in one single-cycle. Note that there is currently no hardware support for this feature, which is supposed to be used for performance exploration only.
  - [optPipelined](https://github.com/tancheng/CGRA-Mapper/blob/589fd61434966e4d4a44220b59854b1795bc7cde/test/param.json#L23): used to enable pipelined execution of the multi-cycle operation (i.e., indicated in [optLatency](https://github.com/tancheng/CGRA-Mapper/blob/589fd61434966e4d4a44220b59854b1795bc7cde/test/param.json#L19)).
  - [additionalFunc](https://github.com/tancheng/CGRA-Mapper/blob/589fd61434966e4d4a44220b59854b1795bc7cde/test/param.json#L24): used to enable specific functionalities on target tiles. Normally, we don't need to set this field as all the tiles already include most functionalities. By default, the `ld`/`st` is only enabled on the left most tiles. So if you wanna enable the memory access on the other tiles, this field needs to be provided. 
+  - [incrementalMapping](https://github.com/yyan7223/CGRA-Mapper/blob/10aa217e9e995b6dfa4242e0ce121b79668e9995/test/param.json#L28C1-L28C33) `true` indicates incremental mapping while `false` indicates heuristic/exhaustive mapping. Incremental mapping re-utilizes the previous mapping results of current kernel (e.g., on 4x4 CGRA) to accelerate its mapping on the new resource allocation decisions (e.g., on 5x5 CGRA). To simply check the acceleration effect of incremental mapping, calls heuristic mapping first to generate `increMapInput.json` for current kernel on 4x4 CGRA, then sets incrementalMapping to `true` and performs mapping on 4x4 CGRA again, finally checksthe elapsed time differences. 


mapping on 4x4 CGRA again, finally checksthe elapsed time differences. -> mapping on 5x5 CGRA again, finally checks the elapsed time differences.

tancheng · 2024-09-16T03:08:45Z

src/Mapper.cpp

+  int maxLevel = CGRANodes_sortedByLevel.size() - 1;
+  cout<<t_dfgNode->getOpcodeName()<<t_dfgNode->getID()<<" is mapped to Tile "<<refCGRANode->getID()<<" in the referenced mapping results, refLevel="<<refLevel<<endl;
+
+  int initLevel = level;


Plz add comment "The level is used to ordering the CGRANodes based on the FanIO. Though FanIO of each CGRANode would change for different CGRA architectures, the DFGNode prefers to being mapped onto the CGRANode with same level."

yyan7223 added 6 commits September 10, 2024 03:06

Incremental Mapping

640ed34

Update README.md

10aa217

Update README.md

b9b4a10

set incrementalMap in param.json default to false

f9b5c84

...

328427a

...

00d2658

tancheng reviewed Sep 10, 2024

View reviewed changes

yyan7223 added 3 commits September 12, 2024 10:58

fix typos

c3c284c

Fixes indent type

8365910

Fix indent issue

8ec0b09

tancheng reviewed Sep 13, 2024

View reviewed changes

Add comments to key variables

ea76c04

tancheng reviewed Sep 13, 2024

View reviewed changes

fix comments issues

d00acdd

tancheng reviewed Sep 14, 2024

View reviewed changes

fix comments

d9d99b1

tancheng reviewed Sep 16, 2024

View reviewed changes

has fixed comments issues

c9cc6d3

tancheng merged commit e76bf4e into tancheng:master Sep 16, 2024
1 check passed

		- [additionalFunc](https://github.com/tancheng/CGRA-Mapper/blob/589fd61434966e4d4a44220b59854b1795bc7cde/test/param.json#L24): used to enable specific functionalities on target tiles. Normally, we don't need to set this field as all the tiles already include most functionalities. By default, the `ld`/`st` is only enabled on the left most tiles. So if you wanna enable the memory access on the other tiles, this field needs to be provided.

		=======


		>>>>>>> b9b4a106e781ac2f8506ceca4a29abded7a088da

Add the incremental mapping function, which re-utilizes the previous mapping results to acceleterate ccurrent mapping. #24

Add the incremental mapping function, which re-utilizes the previous mapping results to acceleterate ccurrent mapping. #24

Conversation

yyan7223 commented Sep 10, 2024

tancheng left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

yyan7223 Sep 12, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

yyan7223 Sep 13, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tancheng left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

yyan7223 Sep 12, 2024 •

edited

Loading

yyan7223 Sep 13, 2024 •

edited

Loading