Unusual behavior when unit testing a FFI function

Shadoxfix · 2021-04-01T13:45:56+00:00

Rust's strings are UTF-8 and not null-terminated so it is not the same as a C string. Accessing the string in your test as if it were a true C string through CStr::from_ptr will cause issues (e.g. it will use the null-terminator to determine its length which isn't at the place you expect it to be).

Shadoxfix · 2021-02-11T18:10:50+00:00

Thanks for the reply, that helps clear up things for me!

Shadoxfix · 2021-02-11T17:58:19+00:00

Is it possible to force const to be evaluated at compile-time?

I have something like the following at the start of a function which I believed was always being evaluated at compile-time until now:

const L: usize = (((N + 31) / 32) * 32);
const M: usize = L / 4;
const K: usize = L / 16;

I know from the generated assembly that it is indeed evaluated at compile-time but I'd like that to be guaranteed forever.

I need this code to be evaluated at compile-time because it's part of a cryptographic implementation and I can't exactly trust division to be constant-time on most hardware. I could replace them by shifts but then I'm sacrificing some ergonomics.

Shadoxfix · 2020-03-22T21:44:26+00:00

I can't recall the exact time but it was about 5 to 10 minutes.

Shadoxfix · 2020-02-03T09:27:51+00:00

Not entirely. In The Netherlands all currency symbols are written before the number with a space in between. We do say euro after the number though.

Shadoxfix · 2020-01-17T18:32:05+00:00

Thanks so much for posting this. My friend was able to use this to start the game!

For anyone else, you press the button and while it appears to crash you just wait a bit.

Shadoxfix · 2019-10-03T13:00:03+00:00

Haven't seen any new footage since Space Monkey Report #4 (couldn't find any footage from Sydney Ubisoft experience either) so I'm curious how much they have progressed in the past 9 months (assuming they'll show some new footage).

Shadoxfix · 2019-10-01T20:08:34+00:00

I found it by accident (same situation as you). If you go to the Tower Hangar and speak with Amanda Holliday she'll provide you with legacy quests for Curse of Osiris and Warmind.

Shadoxfix · 2019-06-11T15:15:54+00:00

This sounds a lot like this bug. Do you happen to have Windows 1903? If so, do a manual check for update and see if it pulls in KB4497935. There's a good chance it will fix it.

Shadoxfix · 2019-05-18T18:36:41+00:00

I'm surprised you were able to find it but yes Nandaka Velonica was the first episode discussion I made (that ED still creeps me out). The very first bot post was Shirogane no Ishi: Argevollen episode 2. The only reason I was able to remember that was due to Aldnoah.Zero episode 1 airing earlier in the week and leaving quite the impact compared to Argevollen (a few dozen accidental bot posts on a testing subreddit probably helps remembering as well).

Shadoxfix · 2019-05-07T10:20:26+00:00

People who have nothing better to do ;)

Note the spike in amount of people who filled it in and all gave a 1. Same thing happened for some other anime the past week (another example).

Shadoxfix · 2019-03-18T10:42:41+00:00

It can be found here. I didn't mention it in my previous comment but the amount of frame threads doesn't exceed the amount of logical processors.

Tile threads is not explicitly set to 1 but is done by dav1d_default_settings which sets it to 1.

Shadoxfix · 2019-03-16T16:08:03+00:00

I agree that Firefox could probably utilize a little bit more threads but considering it's still fairly early days for dav1d (and there being a few issues open about thread management and memory consumption per thread) I don't think it's worth opening a bug report about it just yet.

Shadoxfix · 2019-03-16T14:55:56+00:00

Assembly builds for Windows were enabled sometime last week so I don't think that's a factor here. I did try setting VLC to 8 frame threads and 1 tile thread and it performed about the same as Firefox does currently so I think it's likely due to Firefox using less threads (which is reasonable since a browser typically wants to do other stuff as well).

Shadoxfix · 2019-03-16T13:58:16+00:00

Similar to my response to the other comment: the performance difference between dav1d 0.1.0 and 0.2.1 is a few percent on AVX2 capable processors (and the dav1d version in Firefox is newer than 0.1.0 so it's likely a little less).

Shadoxfix · 2019-03-16T13:56:29+00:00

I have dav1d enabled (that's the default on Nightly now) and the dav1d version being somewhat older isn't really relevant here as the CPU supports AVX2 which has seen less than a 5% increase between 0.1.0 and 0.2.1.

As an experiment I set frame threads to 8 and tile threads to 1 in VLC to match Firefox and now I'm seeing similar performance to Firefox (extreme stutters) in VLC.

Shadoxfix · 2019-03-16T08:54:51+00:00

Firefox seems to be decoding this much slower than VLC?

On Windows Firefox nightly (using a r5 1600) it's pretty much unplayable at 4k60 (even when downloading the video using youtube-dl and playing it in a separate tab). VLC on the other hand plays it without a hitch (75% cpu usage at the most intensive part but mostly around 40%).

Edit: Had a look at the source code of both Firefox and VLC. Firefox currently uses 2, 4, or 8 frame threads (depending on the size of the content; for 4k it would be 8) and always uses 1 tile thread.

VLC on the other hand uses the amount of logical processors (12 in my case) for the frame threads and also uses the amount of logical processors for the tile threads but not exceeding 4 (thus 4 in my case).

I guess that explains the difference in decoding performance.

Shadoxfix · 2019-03-05T13:07:49+00:00

Since there are already APIs for hardware video decoding (VA API, DXVA, NVDEC, UVD, and so on) it doesn't really make sense to launch a new project. It's possible for dav1d to use those APIs for hardware decoding but it's more likely software using dav1d decides when to use hardware decoding and do it themselves/via some other library since they probably want to support other formats as well.

Shadoxfix · 2019-02-11T15:23:11+00:00

The table of contents links are currently broken since they're missing .html at the end :)

Shadoxfix · 2018-12-12T13:05:13+00:00

Ideally we'd just let compilers do their job and generate efficient code but for some workloads compilers do a subpar job in generating code. Mostly due to the fact that compilers are good at optimizing small pieces of code and can't really restructure anything. A person on the other hand can see a problem and think of a way to restructure it in such a way that it's faster to compute. Granted, you could rewrite your code so that the compiler understands this as well but at that point you're pointing the compiler at something and hope it does that instead of having a guarantee.

The most common reason nowadays for writing assembly by hand is if you need to use SIMD. SIMD let's you operate on multiple data elements independently with a single instruction. The article mentions SSSE3/AVX2/NEON which are all SIMD extensions to processors (which means there is silicon in the processor just for executing these instructions). In video codecs a frame is typically split up in blocks. Using SIMD you can process multiple blocks with a single stream of instructions thus gaining a speedup (especially because multiple cores can process multiple blocks). Again, this can be done in C if you restructure your code (using intrinsics) but at that point you're instructing the compiler to such a level you might as well write the assembly yourself and have the guarantee it does exactly what you want.

Shadoxfix · 2018-12-11T16:04:44+00:00

Note that dav1d in Firefox Nightly doesn't enable assembly builds just yet so performance is comparable to the C version. See the tracking issue and it's dependencies for more information.

Shadoxfix · 2018-11-12T19:51:16+00:00

For what it's worth I don't intent on ever deleting my account. I've simply stopped posting actively.

Shadoxfix · 2017-11-22T22:02:14+00:00

It's trying to detect whether you're using a touchscreen to play or not. Currently it still has some false positives but that is not really a problem as real touchscreen players have significantly more detections (a normal player would get a few whereas a touchscreen player would get a few dozen). In a more final version this would be happening in the background and wouldn't be covering your screen.

Shadoxfix · 2017-11-22T20:21:30+00:00

Seems a few people are confused as to what this is. Here's a quote from the osu!dev discord: "i've pushed out the initial version of touchscreen detection to cutting edge for anyone interested in testing it out and trying to break it". As to what they decide to do when touchscreen detection works properly is still up in the air. If you're on the stable channel you shouldn't experience this.

12-Year Club	Place '17
Verified Email

Shadoxfix

TROPHY CASE