Skip to content
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

Simple and flat ArrayTable #18

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

kbieganski
Copy link
Contributor

@kbieganski kbieganski commented Mar 27, 2024

This patch simplifies the implementation of ArrayTable.
Instead of being an array of pointers to pointers, it is now flattened into an array of pointers.
Also, it now uses std::vector, leading to less manual memory management and overall less manual bookkeeping.
I expect this to bring a slight speedup, but I haven't measured it properly yet.

Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
@CLAassistant
Copy link

CLAassistant commented Mar 27, 2024

CLA assistant check
All committers have signed the CLA.

@kbieganski kbieganski changed the title Simple and flat ArrayTable and ObjectTable Simple and flat ArrayTable Mar 28, 2024
@kbieganski
Copy link
Contributor Author

kbieganski commented Mar 28, 2024

I dropped the change to ObjectTable, as it wasn't actually helpful, and was likely to cause some issues with moving objects.

@rovinski
Copy link

Do you have any benchmark measurements to show improvement? I think it is unlikely to be approved unless there are.

@kbieganski
Copy link
Contributor Author

The goal of this PR was to simplify the code, but I observed about 1% speedup on BlackParrot and 2% on Ibex.

@@ -657,7 +657,7 @@ Graph::makePrevPaths(Vertex *vertex,
}

PathVertexRep *
Graph::prevPaths(Vertex *vertex) const
Graph::prevPaths(Vertex *vertex)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

The loss of one indirection means we can't use const here, but if we're getting non-const pointers to vertices, then I would argue the graph is not actually const.

void deleteBlocks();

size_t size_;
// Block index of free block (blocks_[size - 1]).
BlockIdx free_block_idx_;
// Index of next free object in free_block_idx_.
ObjectIdx free_idx_;
// Don't use std::vector so growing blocks_ can be thread safe.
Copy link
Collaborator

Choose a reason for hiding this comment

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

I guess you missed the comment that you deleted that explains why std::vector cannot be used here. If you look at the commit history you will see that it used to use std::vector. When the the vector grows it fails with multiple threads.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I didn't miss it. vector::swap is basically no different from the previous approach. See https://godbolt.org/z/8sqqTPMMf

However, I suppose implementations other than libstdc++ might exhibit different behavior on lower optimization levels. So I pushed a manual swap implementation just to be sure.

Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
@kbieganski
Copy link
Contributor Author

@jjcherry56 Do you have any further feedback?

Copy link
Owner

@parallaxsw parallaxsw left a comment

Choose a reason for hiding this comment

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

I don't really see a compelling reason to make these changes. It is only marginally "simpler". The last change to replace swapping the vectors is a giant step backwards.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants