diff --git a/docs/bench.md b/docs/bench.md index da58aa8b..ecbcedad 100644 --- a/docs/bench.md +++ b/docs/bench.md @@ -9,38 +9,24 @@ Test Environment: - **Storage**: SK Hynix HFS001TEJ9X115N (NVMe SSD, 1TB, PCIe 4.0 x4) - **Compiler**: clang version 18.1.3 - **OS**: Linux Mint 22 Cinnamon -- **Kernel**: 6.8.0-90-generic +- **Kernel**: 7.0.0-14-generic Baselines: - **libaio**: The asynchronous file IO framework on Linux before io_uring. - **[liburing](https://github.com/axboe/liburing)**: io_uring itself. Since it is not wrapped with coroutines, it is slightly less convenient to use. - **[Asio](https://github.com/chriskohlhoff/asio)**: A popular IO framework in C++. -- **[Monoio](https://github.com/bytedance/monoio)**: A Rust coroutine framework based on io_uring (has more stars than liburing on GitHub). +- **[Monoio](https://github.com/bytedance/monoio)**: A Rust coroutine framework based on io_uring. - **[Compio](https://github.com/compio-rs/compio)**: Another Rust coroutine framework based on io_uring. -## Sequential File Read - -We tested the performance of Condy in 64KB sequential reads on an 8GB file, collected throughput data, and compared it with baseline implementations using libaio and liburing. - -As shown in the figure, as the queue depth (number of concurrent tasks) increases, the read throughput gradually rises. When Direct IO is not enabled, Condy’s throughput is less than 3500MB/s. After registering files and buffers (marked as Fixed in the figure), Condy’s performance improves to some extent. With Direct IO enabled, Condy’s throughput increases significantly. At a queue depth of 4, Condy Direct IO is only slightly better than libaio. However, as the queue depth increases, Condy’s advantage becomes more pronounced, and at a queue depth of 32, throughput saturates (~6700MB/s). Further enabling IO Polling brings some throughput improvement at low queue depths, but as the queue depth increases, throughput is actually lower than with Direct IO alone. Monoio and Compio have lower throughput than libaio at all queue depths, and thus are also much lower than Condy. They did not fully utilize the performance potential of io_uring. Monoio performs slightly better than Compio. - -In addition, Condy’s performance is roughly the same as the baseline program implemented with liburing under the same configuration. - -
-
@@ -68,7 +54,7 @@ We compared the performance of Condy, Asio, Monoio, and Compio Channels by varyi
-As shown in the figure, as the number of coroutines increases, the total time for these frameworks increases linearly. In terms of execution time, Condy achieves a **5x** performance improvement over Asio and Compio. Condy's performance is slightly inferior to Monoio. However, the average creation time per coroutine for Condy only increases by 19ns (compared to 55ns for Monoio).
+As shown in the figure, as the number of coroutines increases, the total time for these frameworks increases linearly. In terms of execution time, Condy achieves a **6.6x** performance improvement over Asio (4M tasks: 236ms vs 1566ms) and a **7.5x** improvement over Compio (236ms vs 1774ms). Condy's performance is on par with Monoio (236ms vs 242ms). The average creation time per coroutine for Condy is 56ns (compared to 58ns for Monoio and 373ns for Asio).
## Coroutine Switch
@@ -88,4 +74,4 @@ We compared the efficiency of Condy, Asio, and Monoio in coroutine context switc
-As shown in the figure, as the number of switches increases, the total time for these frameworks increases linearly. In terms of execution time, Condy achieves a **15x** performance improvement over Asio. It also achieves performance results close to Monoio, with the maximum difference per switch not exceeding 0.8ns (about 3ns per switch).
+As shown in the figure, as the number of switches increases, the total time for these frameworks increases linearly. In terms of execution time, Condy achieves a **16x** performance improvement over Asio (8M switches: 28ms vs 449ms). It also achieves performance results close to Monoio (28ms vs 27ms), with the difference per switch not exceeding 0.2ns (about 3.3ns per switch).
\ No newline at end of file
diff --git a/docs/imgs/channel_number_of_messages.png b/docs/imgs/channel_number_of_messages.png
index 63707219..dd4184c2 100644
Binary files a/docs/imgs/channel_number_of_messages.png and b/docs/imgs/channel_number_of_messages.png differ
diff --git a/docs/imgs/channel_task_pairs.png b/docs/imgs/channel_task_pairs.png
index ec89a5f8..306d2f2d 100644
Binary files a/docs/imgs/channel_task_pairs.png and b/docs/imgs/channel_task_pairs.png differ
diff --git a/docs/imgs/file_random_read_queue_depth.png b/docs/imgs/file_random_read_queue_depth.png
index a5c0fee2..cbd414ae 100644
Binary files a/docs/imgs/file_random_read_queue_depth.png and b/docs/imgs/file_random_read_queue_depth.png differ
diff --git a/docs/imgs/post_switch_times.png b/docs/imgs/post_switch_times.png
index 7df8f285..4d8d444f 100644
Binary files a/docs/imgs/post_switch_times.png and b/docs/imgs/post_switch_times.png differ
diff --git a/docs/imgs/spawn_number_of_tasks.png b/docs/imgs/spawn_number_of_tasks.png
index d871e1b5..8c2fbf54 100644
Binary files a/docs/imgs/spawn_number_of_tasks.png and b/docs/imgs/spawn_number_of_tasks.png differ