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

Slow performance on Linux? #336

Open
alshdavid opened this issue May 11, 2024 · 4 comments
Open

Slow performance on Linux? #336

alshdavid opened this issue May 11, 2024 · 4 comments

Comments

@alshdavid
Copy link

alshdavid commented May 11, 2024

Hi, I have written a wrapper util on top of ipc_channel that handles the handshake, swapping channels between the host/child and adds a request/response API.

The performance on my M1 MBP was great, but I was surprised to find that the performance on Linux was significantly slower!

So I wrote a benchmark to test it out. The benchmark sends n requests, blocking on their responses (100k requests means 200k messages over the channel).

I'm not sure if it's my configuration, perhaps something else is interfering, however here are my results

Hardware

  • Windows: AMD 5950x - Windows 10
  • Linux: AMD 5950x - Fedora 39
  • MacOS: M1 Macbook Pro

Results

Platform message count duration
macos 10k 0.487s
windows 10k 0.356s
linux 10k 2.301s
macos 100k 1.550s
windows 100k 3.497s
linux 100k 13.608s
macos 1m 14.404s
windows 1m 34.769s
linux 1m 150.514s

Time taken for n round trip messages - Lower is better

chart

I am have tried with/without the memfd option enabled and I have tried making this async (using tokio channels/threads) with the same outcome.

This is my wrapper (benchmarks are under examples)
https://github.com/alshdavid/ipc-channel-adapter

To run the benchmark run just bench {number_of_requests} e.g. just bench 100000

I'm investigating if another dependency is interfering, will update with my findings - but at the surface, any idea why this might be?

@alshdavid
Copy link
Author

alshdavid commented May 11, 2024

When running the benchmark using tokio and sending all the requests at once and waiting for them to return concurrently it's a lot better.

Tested with just bench-async

Platform message count duration
macos 100k 1.176s
windows 100k 0.368s
linux 100k 4.026s

@alshdavid
Copy link
Author

I was able to replicate this on Ubuntu. Wonder where the performance loss is occuring

@mrobinson
Copy link
Member

mrobinson commented Oct 2, 2024

Hello, we've been testing this benchmark on our own systems. When plugged we see benchmark results in line with the ones you have posted for non-Linux platforms, @alshdavid. That said, we've noticed that power saving mode or throttling due to being unplugged has a massive effect on the results. For instance, when I switch my machine to "Power Saver" in Gnome the results I get are:

Ryzen 7 7840U / Ubuntu

Power Save Count Duration
Off 100k 3.072s
Off 1m 34.654s
On 100k 7.392s
On 1m 71.326s

Macbook M3 Max

Energy Mode Count Duration
High 100k 2.389s
High 1m 22.772s
Low 100k 2.720s
Low 1m 26.808s

Perhaps what's happening here is that the Linux implementation is very sensitive to power saving mode.

@mukilan
Copy link
Member

mukilan commented Oct 2, 2024

I can confirm the same (i.e worse performance on power saving and numbers on par with OP's Windows and MacOS for performance mode) on NixOS 24.05, 24 × 12th Gen Intel® Core™ i7-12800HX, 64GB RAM

message count power saving perfomance mode
100K 21.441s 3.821s
1M 67.033s 24.460s

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

3 participants