Today endler.dev/2017/yes/ was brought to my attention. Thanks for such a good explanation @matthiasendler!!
My system:
- GNU Yes: 6.60GiB/s
- Rust version (optimized): 5.74GiB/s
- In @nim_lang: 6.24GiB/s (only adding buffering over the naïve version which was ~60MiB/s).
My system:
- GNU Yes: 6.60GiB/s
- Rust version (optimized): 5.74GiB/s
- In @nim_lang: 6.24GiB/s (only adding buffering over the naïve version which was ~60MiB/s).
Jul 28, 2022 · 7:10 AM UTC
3
8
40
@matthiasendler @nim_lang And I forgot mentioning the optimized Rust version is 51 lines of horror...
0
0
4
@kraptor You can use metaprogramming to unroll that stdout.write() at CT.
1
0
0
@juancarlospaco Not sure it will make any difference:
1. there's no data dependency between instructions within the loop.
2. the branch predictor at "while true" is always 100% right.
3. there's an inherent lock in the write() as it maps to a syscall(): we are at the mercy of the kernel anyway.
1. there's no data dependency between instructions within the loop.
2. the branch predictor at "while true" is always 100% right.
3. there's an inherent lock in the write() as it maps to a syscall(): we are at the mercy of the kernel anyway.
0
0
1
@kraptor @nim_lang @matthiasendler I used writeBuffer instead of write and looks faster in my system, not sure if you can test in your system.
1
0
1





