Skip to content

Record encoding concurrency - #2536

Merged
nazar-pc merged 5 commits into
mainfrom
piece-encoding-concurrency
Feb 19, 2024
Merged

nazar-pc merged 5 commits into
mainfrom
piece-encoding-concurrency

Conversation

@nazar-pc

Copy link
Copy Markdown
Member

This leverages scalability introduced in #2526 and allows to improve CPU usage and plotting speed as the result.

The idea here is that there are both parallel and sequential parts of the table generation, so by generating a few tables at a time we can overlap sequential parts with parallel parts and improve CPU utilization. While generating tables for all records requires a lot of RAM, generating tables for only a few records at a time is not too bad.

--record-encoding-concurrency option was added to override default behavior (one record for each 2 cores, but not more than 8 in parallel, which according to my testing with P-cores, E-cores and P+E cores seems to result in peak performance). To get old behavior and lower RAM usage --record-encoding-concurrency 1 can be used.

Code contributor checklist:

@EmilFattakhov EmilFattakhov left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

People are gonna love this, will get it added to the docs!

@nazar-pc
nazar-pc added this pull request to the merge queue Feb 19, 2024
Merged via the queue into main with commit 1b08bde Feb 19, 2024
@nazar-pc
nazar-pc deleted the piece-encoding-concurrency branch February 19, 2024 03:06
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