search

Lokathor / wide

A crate to help you go wide. By which I mean use SIMD stuff.
https://docs.rs/wide
zlib License
279 stars 23 forks source link

Improve performance of saturating float to int casts #108

Closed CryZe closed 2 years ago

CryZe commented 2 years ago

I randomly stumbled across a Chrome bug ticket where they reported that their lowering of saturating float to int casts is suboptimal:

https://bugs.chromium.org/p/v8/issues/detail?id=12094

They by now merged a fix. The code I ported was based on Chrome and thus the same performance pitfall applies to wide.

CryZe commented 2 years ago

Spurious link error?!

CryZe commented 2 years ago

I'm thinking this is the incremental compilation bug in 1.52.0. We probably should use 1.52.1.

CryZe commented 2 years ago

Alright, no idea what's wrong then.

CryZe commented 2 years ago

Seems like stable is unaffected by whatever weird bug this is in 1.52 though.

Lokathor commented 2 years ago

does it build with latest nightly/stable? We can just bump the minimum rust version if it's necessary.

CryZe commented 2 years ago

It seems to. Idk if bumping MSRV for a compiler bug makes sense. I'll try 1.53 and co. to see what the next MSRV would need to be.

CryZe commented 2 years ago

Alright, failing now on beta too. I'm out of ideas. Works just fine for me locally.

CryZe commented 2 years ago

Maybe the specific native target-cpu uses some instructions or so that the MSVC linker can't handle?!

CryZe commented 2 years ago

Googling the error makes it sound like the .exe is still running or something?!

CryZe commented 2 years ago

Fun, the problem is unrelated to my changes and seems to happen on the main branch too.

CryZe commented 2 years ago

I'm guessing that we end up with the same .exe hash and thus it wants to overwrite the previously created one, but Windows runners have started running Windows Defender or so in the background which locks the file for scanning.

Lokathor commented 2 years ago

well, put the changes in and the rest is a cargo issue.

CryZe commented 2 years ago

Well more of a Github Actions bug. We may need to use a different target folder for the target-cpu=native, so it doesn't collide.

Lokathor commented 2 years ago

Oh. Can we break it up across more CI tasks so that each goes in separate VM instances and they don't clash?

Lokathor commented 2 years ago

alternative target folder also works too i guess

CryZe commented 2 years ago

Yep, cargo clean fails as well, not being able to remove the executables. So they are definitely being scanned.

CryZe commented 2 years ago

This is ready now btw. Using a separate target folder worked.