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
Please clarify the benchmark output for each test #7
Comments
Thanks for your report, You can write another python script to generate markup tables from the CSV output, but the default output of the tests should not change as plot.py rely on that, I'll be happy to merge it if you send PR. |
Thank you. You answered my question. My older phenom has different behaviour from newer cpus. This is my first experience where trying a crate on 2 different cpu's results in different rankings of crate performance. Amd/Intel cpu run-time tests for me usually provide similar crate rankings no matter the multi-core cpu involved. Very bizarre. I tried the very same tests on a Intel Xeon E5-2630 v2 6-core 12-thread cpu running on a fedora silverblue 36. flume flume-async kanal kanal-async uname -a cat /proc/cpuinfo |
Ok, LOL so I performed the same test on a more powerful 10-core 20-thread Intel E5-2630 v4 cpu on a Centos 7 system. kanal fedora silverblue 36 6-core 12thread was 1.163023444 faster than kanal centos 7 10-core 20-thread!!! That's impressive work speaking volumes about kernel performance improvements. kanal is 4.52X faster than flume. flume flume-async kanal kanal-async uname -a cat /proc/cpuinfo |
Thanks for your report and the time that you put into testing Kanal, right now I'm dealing with a race condition and that is likely that it is slowing the Kanal in some cases, I like to see the results.png of both tests, especially I like to see how Golang is performing in your older hardware. if it's possible for you please upload them. |
kanalOnSilverblue36-AMD-FX-8350.zip kanal runs on Fedora Silverblue 37, tkinter won't install just yet for whatever reason.
"sudo rpm-ostree rollback" wasn't cutting it because it doesn't adjust the bios/boot/grub to the desired deployment. I assumed it would do that and it doesn't. The right commands to use are "ostree admin status" and "ostree admin undeploy". Undeploy is the one that deletes the deployments from the system and adjusts the uefi/bios/grub to point to the previous deployment.
On Fedora Silverblue 36, for turtle plots to generate successfully:
As requested, all the graphs and csv's are attached which include the go channel results which you were looking for on this particular CPU. Cheers. |
Hey David, Could you please rerun your benchmarks on phenomx8 hardware with the latest git clone? |
Good morning, here are the latest benchmarks with popos updated and latest rust nightly and latest go on phenom x8.
|
Thanks! It seems Kanal's own mutex still performing better than standard mutex even on your older system. |
Here it is on Fedora Silverblue 36 with the latest kernel as requested on the phenom x8.
I've attached the .csv files for this one. |
Please close it. I just did as you requested which was run the kanal benchmarks with the latest kernel 6.07-200 found in fedora silverblue 36 on phenom x8. I hope it proves useful to you. Thank you again. Cheers. |
Thanks for the time that you put to test Kanal, I really appreciate it. It's useful for sure, I need to know how Kanal is performing in different hardware. |
I isolated just one particular use case I am familiar with and interested in seeing how it compares with flume in particular.
I changed both of these:
https://github.com/fereidani/rust-channel-benchmarks/blob/main/z_run.rs#L20
https://github.com/fereidani/rust-channel-benchmarks/blob/main/z_run.rs#L44
to better describe what the numbers dumped mean:
as believe this is what it truly describes. Is that right or did I misunderstand?
Here are the number on fedora silverblue 37 on an 8-core phenomx8
So when I read the above it seems to indicate it takes more nanoseconds for async message passing. Did I misunderstand?
kanal also seems to process less messages per second? Did I also misunderstand this?
The following indicates to me that flume is faster with the numbers I get:
flume 3146619 messages per second >
kanal 2746278 messages per second >
flume-async 2511041 messages per second >
kanal-async 2229356 messages per second
Again when I look at average one message durations,
flume 158900701 nanoseconds <
kanal 182064603 nanoseconds <
flume async 199120601 nanoseconds <
kanal async 224280043 nanoseconds
Did I misunderstand all this?
From what I just observed,
1)flume is faster than flume async.
2)kanal is faster than kanal async.
3)kanal is faster than flume async
4)kanal async is the slowest.
5)flume is the fastest.
The text was updated successfully, but these errors were encountered: