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

Use wide to speedup coverage map with stable toolchains #3131

Closed
wtdcode opened this issue Apr 5, 2025 · 8 comments
Closed

Use wide to speedup coverage map with stable toolchains #3131

wtdcode opened this issue Apr 5, 2025 · 8 comments

Comments

@wtdcode
Copy link
Member

wtdcode commented Apr 5, 2025

I did a benchmark for SIMD implementation of coverage map: https://github.com/wtdcode/libafl_simd_bench

The motivation is that we can use wide to replace std::simd so that we no longer need nightly to gain the speedup. It looks like that wide has almost the same performance as std::simd. I can draft a PR if we agree to introduce wide.

wdyt? @tokatoka @domenukk @rmalmain

@wtdcode
Copy link
Member Author

wtdcode commented Apr 5, 2025

Attached benchmark from aarch64.

@domenukk
Copy link
Member

domenukk commented Apr 5, 2025

If it's not 100% the same perf, we can also just use wide for stable and leave simd for nightly

@tokatoka
Copy link
Member

tokatoka commented Apr 5, 2025

it's good

@domenukk
Copy link
Member

domenukk commented Apr 5, 2025

If it's not 100% the same perf, we can also just use wide for stable and leave simd for nightly

This would also mean we could move to simd in stable if it ever lands, though

@tokatoka
Copy link
Member

tokatoka commented Apr 5, 2025

his repo shows it's almost the same. so no reason to keep portable simd

@domenukk
Copy link
Member

domenukk commented Apr 5, 2025

Well I think it's good to keep it around in order to switch back some day in the future

@domenukk
Copy link
Member

domenukk commented Apr 5, 2025

Ppl are still working actively on the feature, and once it lands it'd be better to get rid of the extra dependency I feel. See
rust-lang/rust#86656

@wtdcode
Copy link
Member Author

wtdcode commented Apr 6, 2025

I will gate different implementations via features so that we still keep that while allowing users to choose.

@tokatoka tokatoka closed this as completed Apr 8, 2025
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