spike: Test using SIMD to parse coordinates

[sbernauer]

Can be extended to parse rgba when we already have it in our vector. I think the swizzle (shuffle) part is costing most of the performance

[fabi321]

I'm feeling your pain, it takes 54ms on my machine, compared to 20ms for my solution, or 18.5ms for the existing solution

[fabi321]

from my testing, it is faster to cast the values into the final type at this point.

[sbernauer]

The thing is the idea with shuffling all the needed stuff (x, y and (later on) rgb) into a well-defined position only works with u8 as far as I could find :(

[fabi321]

I'm just doing a digits>=10 on digits, as everything below b'0' will wrap around, this catches all characters other than digits.

[fabi321]

Also a note on types: I tried to change my solution to u16 (I'm currently using u32), but it was 20% slower. That's why I'm using u32.

[fabi321]

If I follow the docs, and use cargo bench -Zbuild-std --target x86_64-unknown-linux-gnu, the time usage goes down to 21.5ms, from 50ms.

[sbernauer]

Ahh you're right! Have read that and had it back of my mind, but totally missed that. Thx!

[sbernauer]

That kind of motivates me to continue on this and add the rgb parsing as well ^^

[fabi321]

the following test fails:
assert_eq!(simd_parse_coord(b"1 2\n "), (1, 2, 3));
The problem is, that the spaces after the newline are not ignored, and lead to an invalid pattern

[fabi321]

This is the reason why I use trailing_zeros to get the number of digits, as it stops at the first one, and ignores all the other clutter. This obviously only works on one number at a time.

[sbernauer]

Yep, I have noticed the failing tests as well. I already have an idea on how to solve this (with no performance penalty), but I did not continue any further until we solved the performance problem. The -Zbuild-std improved things quite a bit, so I might add the rgb parsing and than re-visit the performance.