Remove vek dependency.

[TannerRogalsky]

Up front: I won't feel slighted if you decline this PR. I mostly did this for my own use but I figured I'd push upstream just in case.

I initially wanted just to remove the serde dependency from my tree but when I got in here and started looking at the code I figured I could trim my tree even more since the usage of vek in this project is restricted to the rasterizer implementations.

Changelog:

• Replace vek with float arrays
• Remove features associated with vek
• Simplify feature variants (should be more difficult to create a feature combination that doesn't compile)

Was pleasantly surprised to see that there was a performance improvement. Auto-vectorization never ceases to amaze.

teapot/[1, 1]           time:   [3.1923 ms 3.2334 ms 3.2857 ms]
                        change: [-23.022% -21.423% -19.842%] (p = 0.00 < 0.05)
                        Performance has improved.

                        change: [-25.687% -23.491% -21.631%] (p = 0.00 < 0.05)
                        Performance has improved.
  2 (6.25%) high mild
  1 (3.12%) high severe

teapot/[640, 480]       time:   [5.1802 ms 5.1946 ms 5.2099 ms]
                        change: [-22.849% -20.976% -19.161%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 3 outliers among 32 measurements (9.38%)
  1 (3.12%) high mild
  2 (6.25%) high severe

teapot/[1024, 800]      time:   [6.7946 ms 6.9040 ms 7.0218 ms]
                        change: [-28.973% -26.394% -23.945%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 3 outliers among 32 measurements (9.38%)
  3 (9.38%) high mild

Benchmarking teapot/[2048, 1600]: Warming up for 1.0000 s
Warning: Unable to complete 32 samples in 5.0s. You may wish to increase target time to 8.8s, enable flat sampling, or reduce sample count to 10.
teapot/[2048, 1600]     time:   [17.232 ms 17.499 ms 17.765 ms]
                        change: [-24.200% -21.514% -18.662%] (p = 0.00 < 0.05)
                        Performance has improved.

teapot/[4096, 3200]     time:   [55.785 ms 56.339 ms 56.937 ms]
                        change: [-29.571% -28.268% -26.929%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 1 outliers among 32 measurements (3.12%)
  1 (3.12%) high mild

[zesterer]

Happy to accept this change, although most work is being done on the refactor branch where, IIRC, this has already been done.

[TannerRogalsky]

Maybe that branch hasn't been pushed as it's pretty behind on github.

[zesterer]

My bad, I'd forgotten the branch had been merged.

Happy to merge this, although I can't deny the increase in boilerplate does make me a little sad. Was there any particular reason that you were looking to simplify your dependency tree?

[TannerRogalsky]

Particularly the inclusion of serde and it's proc macro has a disproportionate impact on my compile times. I'm also compiling this to a wasm target so am a little more conscientious of additional code payload than I would normally be for a native binary.

[zesterer]

Have you tried simply disabling default features for vek? I imagine that cuts all of that out.

Code-wise, vek is pretty much entirely generic code so it's pay-as-you-go in terms of extra binary size (the compiler will flatten the abstractions down well anyway). That aside, any linker worth its salt will remove unreferenced symbols if told to do so.

[TannerRogalsky]

Yeah

…

On Thu, Dec 19, 2024, 7:16 p.m. Joshua Barretto ***@***.***> wrote: Have you tried simply disabling default features for vek? I imagine that cuts all of that out. — Reply to this email directly, view it on GitHub <#34 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAE74UY6U3WCUGU77NNOUU32GNOVPAVCNFSM6AAAAABTYHECZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJVHE4TONBZGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[zesterer]

In that case, would configuring vek to have default features disabled be satisfactory for you?

[TannerRogalsky]

At this point, I wouldn't go back to using vek in my fork of this project. Barring results from more robust benchmarks, the performance characteristics for both compile time and runtime are steering me away from having vek in my dependency tree at all.

That said, I'm not going to maintain my fork except for myself so I certainly understand your reluctance to reinvent the wheel for these math operations. If serde had been easier to remove from my dependency tree I probably would have not cared about this in the first place.

[zesterer]

That's fair enough. I do want to try to experiment with a few things: I think vek::Lerp::lerp does a range clamp, so that might explain some of the performance difference here. I'm happy to merge this though.