Skip to content

[vpr][place] refactoring variables in net_cost_handler #2644

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

robluo
Copy link

@robluo robluo commented Jul 13, 2024

net_cost, proposed_net_cost, and bb_updated_before grouped in a struct. bb_updated_before renamed to bb_update_status.

performance data is compared in:
[https://docs.google.com/spreadsheets/d/1VVvTxhVbGLO6Hq9d2ZmZqi7IWLRDFhMkFIhwDXQtYcw/edit?usp=sharing]

Geomean of vtr flow runtime on titan quick qor increased by 3%. Routed wire length remains unchanged.

inet_cost, proposed_net_cost, and bb_updated_before grouped in a struct.
bb_updated_before renamed to bb_update_status.
@github-actions github-actions bot added VPR VPR FPGA Placement & Routing Tool lang-cpp C/C++ code labels Jul 13, 2024
@robluo robluo requested review from vaughnbetz and amin1377 July 13, 2024 19:30
Copy link
Contributor

@vaughnbetz vaughnbetz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some changes requested for commenting and naming.
3% slowdown in place time: there are similar slowdowns in pack and route time, so this just looks like a machine load bounce. So overall the CPU time looks very similar.

@@ -55,14 +55,10 @@ static vtr::NdMatrix<float, 2> chanx_place_cost_fac({0, 0}); // [0...device_ctx.
static vtr::NdMatrix<float, 2> chany_place_cost_fac({0, 0}); // [0...device_ctx.grid.height()-2]

/**
* @brief Cost of a net, and a temporary cost of a net used during move assessment.
* @brief For the first two element in the struct: Cost of a net, and a temporary cost of a net used during move assessment.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should use the member names (net_cost etc.) instead of the order in the struct, in case a member is added or deleted or reordered in the future. It also makes the comment more self-contained.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also comment that there is one entry per cluster level net [0...cluster_ctx.clb_nlist.nets().size()-1] for each of these vectors. (Mention this early in the comment).


/** *
* @brief Flag array to indicate whether the specific bounding box has been updated
* For the last one element in the struct: Flag array to indicate whether the specific bounding box has been updated
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change to "bb_update_status: flag array ..."

@@ -74,7 +70,12 @@ static vtr::vector<ClusterNetId, double> net_cost, proposed_net_cost;
* bounding box is got from scratch, so the bounding box would definitely be
* right, DO NOT update again.
*/
static vtr::vector<ClusterNetId, NetUpdateState> bb_updated_before; // [0...cluster_ctx.clb_nlist.nets().size()-1]
struct NetInfo {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest a somewhat more descriptive name, e.g. PLNetCost.

vtr::vector<ClusterNetId, double> net_cost;
vtr::vector<ClusterNetId, double> proposed_net_cost;
vtr::vector<ClusterNetId, NetUpdateState> bb_update_status; // [0...cluster_ctx.clb_nlist.nets().size()-1]
} NetInfo;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this making a variable NetInfo as well as a struct called NetInfo?

vtr::vector<ClusterNetId, double> proposed_net_cost;
vtr::vector<ClusterNetId, NetUpdateState> bb_update_status; // [0...cluster_ctx.clb_nlist.nets().size()-1]
} NetInfo;
static struct NetInfo net_info;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can just write
static NetInfo net_info;
(or better yet, a renamed
static PLNetCost pl_net_cost;
)

@robluo
Copy link
Author

robluo commented Jul 13, 2024

All comments addressed and pushed again.

Copy link
Contributor

@vaughnbetz vaughnbetz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Some conflicts need to be resolved, and then CI should launch (not sure why only four tests launched so far but hopefully they all launch after the conflicts are updated).

@@ -55,14 +55,12 @@ static vtr::NdMatrix<float, 2> chanx_place_cost_fac({0, 0}); // [0...device_ctx.
static vtr::NdMatrix<float, 2> chany_place_cost_fac({0, 0}); // [0...device_ctx.grid.height()-2]

/**
* @brief Cost of a net, and a temporary cost of a net used during move assessment.
* @brief For each of the vector in this struct, there is one entry per cluster level net:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

vector -> vectors

@AlexandreSinger
Copy link
Contributor

Looks good. Some conflicts need to be resolved, and then CI should launch (not sure why only four tests launched so far but hopefully they all launch after the conflicts are updated).

@vaughnbetz I think the reason the CI did not launch is because this PR is being merged into the placement_move_primitive branch, not master. If you want the CI to run, it would have to be manually dispatched from the action tab; however, @robluo was this target branch a mistake? Based on the commit history, this branch is in fact based off placement_move_primitive not master.

@vaughnbetz
Copy link
Contributor

Ah, that makes sense. Yes, this should be merged into master.

@robluo
Copy link
Author

robluo commented Jul 14, 2024

This work is based on placement_move_primitive, should that be merged first?

@amin1377
Copy link
Contributor

I think Robert is right. We first need to merge the placement refactoring PR before this one. Vaughn has reviewed that PR, and I have addressed his comments. The only remaining task is for me to run the QoR tests one more time. I have discussed this with @AlexandreSinger, and it will be done this week (before Wednesday).

@robluo I have a question regarding the QoR test. Is the baseline the VTR master branch or the placement refactoring PR? Thanks!

@robluo
Copy link
Author

robluo commented Jul 14, 2024

@amin1377 The base line is placement_move_primitive in my QoR test.

Base automatically changed from placement_move_primitive to master July 19, 2024 18:03
@robluo robluo closed this Jul 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lang-cpp C/C++ code VPR VPR FPGA Placement & Routing Tool
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants