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

Cache memory data in instance #291

Merged
merged 1 commit into from
Oct 15, 2024
Merged

Conversation

zherczeg
Copy link
Collaborator

No description provided.

@zherczeg
Copy link
Collaborator Author

This patch moves the memory caching to instance. Since instance is always in a register, the jit can access is easily.

@zherczeg zherczeg force-pushed the cache_memory_props branch 2 times, most recently from 9477a07 to 8e3ae56 Compare September 27, 2024 10:48
@zherczeg
Copy link
Collaborator Author

After some trying, the least painful location for the cache is between the memories and globals.

@zherczeg
Copy link
Collaborator Author

I have updated the patch. Could you check it? Thank you.

void enque(Memory* memory);
void deque(Memory* memory);

TargetBuffer* next;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is there any specific purpose of this next reference?
It seems that TargetBuffer can be linked to each other like linked-list,
but is it possible that one Memory has multiple TargetBuffers?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes. Each Instance which has a reference to a given Memory has a TargetBuffer connected to that memory. The TargetBuffer is simply a cache, since memory properties rarely changes, and a key resource (memory accesses are very frequent).

Comment on lines 68 to 69
size_t size = m_module->numberOfMemoryTypes();
Memory::TargetBuffer* targetBuffers = reinterpret_cast<Memory::TargetBuffer*>(alignedEnd() + m_module->numberOfMemoryTypes());
Copy link
Collaborator

Choose a reason for hiding this comment

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

m_module->numberOfMemoryTypes() could be replaced by size here

Comment on lines +237 to +239
for (size_t i = 0; i < numberOfMemoryTypes(); i++) {
targetBuffers[i].enque(instance->m_memories[i]);
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

As here, each Memory has one TargetBuffer and initialized all at once when the Instance is created.
And all TargetBuffer is dequed when the Instance is destoyed.
So, I'm not sure why TargetBuffer has next reference in itself.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

When a Memory grows, it needs to update all TargetBuffers for all Instances. It has a chain list of TargetBuffers, and goes through them. Normally the Instance knows its Memories, but Memories don't know which Instance uses them.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I see. I missed the point that several TargetBuffers could be created for one Memory when the Memory is shared in multiple Instances.

Signed-off-by: Zoltan Herczeg [email protected]
Copy link
Collaborator

@clover2123 clover2123 left a comment

Choose a reason for hiding this comment

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

LGTM

@clover2123 clover2123 merged commit 0463316 into Samsung:main Oct 15, 2024
14 checks passed
@zherczeg zherczeg deleted the cache_memory_props branch October 15, 2024 04:37
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.

2 participants