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

Make use of ArrayPool<T> to reduce memory allocs for neural net arrays. #48

Open
colgreen opened this issue Mar 28, 2021 · 2 comments
Open
Assignees

Comments

@colgreen
Copy link
Owner

colgreen commented Mar 28, 2021

When we decode a genome to a neural net we tend to allocate a few arrays. It would be good to try and use ArrayPool (probably, actually MemoryPool.Shared ?) where possible to minimise allocation and GC activity.

This work can be guided by the memory and GC tracking info from the performance profiler - we can use the efficacy sampler project to generate the workload for this.

Using arrays from a pool also means we avoid the memory clearing/zeroing overhead that occurs when getting a new array from the heap.

@colgreen colgreen self-assigned this Apr 26, 2021
@colgreen
Copy link
Owner Author

colgreen commented Aug 1, 2021

Some more work towards this item has been done in this commit https://github.com/colgreen/sharpneat-refactor/commit/0f61c84a530abb73664ab152f83cbe58af2d5b40

@colgreen
Copy link
Owner Author

colgreen commented Aug 1, 2021

As a possible next step, we could rent the array used for connection weights in neural nets. This is a new array for acyclic nets, but is taken directly from the genome for cyclic nets. Hence, a wrapper type that is IDisposable can be used, with two versions, one which returns the array on disposal (for acyclic nets), and another that doesn't (for cyclic nets).

Further to that, we could also use ArrayPool for genome arrays instead of the current approach of trying to re-use arrays in offspring genomes where possible. That re-use means an array is not owned by any one genome, and thus we don't know when an array is ready to be returned to an ArrayPool (unless we reference count, which is probably going too far in terms of complexity of the codebase).

@colgreen colgreen transferred this issue from another repository Jan 1, 2023
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

No branches or pull requests

1 participant