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.

Sign up for GitHub

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

Jump to bottom

EFM decoder performance improvements #801

Merged
merged 3 commits into from
Oct 2, 2022
Merged

EFM decoder performance improvements #801

merged 3 commits into from
Oct 2, 2022

Conversation

atsampson
Copy link
Collaborator

Two changes to F3Frame that together make ld-process-efm about 2.5x faster overall:

  • Convert T-values directly into EFM symbols, rather than going bit-by-bit via an intermediate buffer. This also fixes a bug where it'd very occasionally write the final bit in the wrong place, so you get very slightly better results.
  • Use a little hash table to convert EFM symbols into values, rather than a linear search. The hash function was found using this script.

@atsampson
Use const pointers in F3Frame.
de41d0d
@atsampson
Rewrite the frame-unpacking code in F3Frame::setTValues.
f09021b 
This code converted T-values to a representation of the frame, then
extracted EFM values from it. Both phases looped through every bit of
the frame, which was very slow.

Rewrite it to go directly from T-values to EFM values, with a single
loop that executes once per T-value rather than once per bit. Profiling
shows it now takes 5% of ld-process-efm's runtime rather than 50%.

Comparing the output of the two versions also revealed that the original
code would sometimes write the very last bit in the wrong place, usually
hitting a merging bit but very occasionally corrupting the last EFM
value in the frame (1-3 times an hour). So the new code produces very
slightly better results.
@atsampson
Use a hash table to decode EFM symbols.
13a7df7 
The existing code did a linear search across a 256-entry array. Since
this fits in L1 cache it wasn't as bad as it looked, but doing it with a
hash table instead reduces the number of memory reads by a factor of
100 (at most 2 reads per lookup).

The hash function here was designed by an exhaustive search using a
Python program.
@atsampson atsampson added enhancement ld-decode-tools An issue only affecting the ld-decode-tools labels Oct 2, 2022
@happycube happycube merged commit 11e42e7 into happycube:master Oct 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@happycube happycube happycube approved these changes

@simoninns simoninns Awaiting requested review from simoninns

Assignees
No one assigned
Labels
enhancement ld-decode-tools An issue only affecting the ld-decode-tools
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
2 participants
@atsampson @happycube