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

feat(backend): Use fixed-point WeightKg for weights. Closes #363 #365

Open
wants to merge 3 commits into
base: development
Choose a base branch
from

Conversation

sstangl
Copy link
Contributor

@sstangl sstangl commented May 27, 2024

This patch ports the OpenPowerlifting weight representation to Go.

The new WeightKg type represents numbers like `123.45` by storing them
in a fixed-point integer representation, like `12345`. The advantage of
this representation is that integer comparisons and arithmetic are
significantly faster than the corresponding floating-point operations,
because integers do not require loads into XMM registers.

This patch ports the OpenPowerlifting weight representation to Go.

The new WeightKg type represents numbers like `123.45` by storing them
in a fixed-point integer representation, like `12345`. The advantage of
this representation is that integer comparisons and arithmetic are
significantly faster than the corresponding floating-point operations,
because integers do not require loads into XMM registers.
@sstangl sstangl requested a review from euanwm as a code owner May 27, 2024 20:33
@sstangl
Copy link
Contributor Author

sstangl commented May 27, 2024

This is the first non-trivial Go code I've written, so please be skeptical if something looks unidiomatic. It would be nice to have a benchmark for this in the test suite -- if there's a preferred entrypoint for loading the DB and performing searches, please let me know.

I benchmarked this by manually disabling the server's cache and investigating /leaderboard. Performance seems largely unchanged, maybe slightly faster, but the majority of overhead appears to be elsewhere. Response times are extremely variable in both development and this branch, between 7ms and 60ms, although I haven't investigated enough to blame GC yet.

@euanwm
Copy link
Owner

euanwm commented May 27, 2024

I'm going to leave this open while I crack on with the lower-hanging fruit this week as jet-lag will be seeping into my grey matter very shortly.

Check out the benchmarking suite in Go (testing.B), I've used it a bunch on other projects and it's super handy at measuring these sort of improvements.

I'll create an issue for myself to tidy some stuff up to allow for easier benchmarking without having to do it manually.

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

Successfully merging this pull request may close these issues.

2 participants