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

FEXCore/JIT: Encode the JITRIPReconstructionEntries using variable length integer #4302

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

Sonicadvance1
Copy link
Member

When #2722 implemented this initially and #4271 switched over to signed int16_t there was assumptions made that int16_t was a reasonable trade-off in encoding size versus needing to deal with 8-bit values being too small in some cases.

In the common case we are almost always encoding 8-bit values because instructions are typically linear (and less than 15-bytes in size), but 16-bit was chosen because optimizing JIT and multiple instructions that don't cause exceptions can add up to larger than 8-bit.

Instead of hardcoding 16-bit values, implement a variable length integer class where ~96.8% of values are 8-bit encoded, and the remaining 3.19% are encoded using 16-bit. Due to some constraints that #4271 put in place, we can basically guarantee currently that branch targets are within 16-bit. The VL class does support 32-bit and 64-bit as well so if we change behaviour then nothing needs to change.

Some stats when running Sonic Mania with multiblock enabled.

Encoded integers: 3,504,907
Encoded 8-bit:    3,393,095 (96.8%)
Encoded 16-bit:     111,812 (3.19%)
Encoded 32/64-bit:        0

Encoded Size:       3,615,181 bytes (3.44MiB)
Fixed encoded size: 7,007,604 bytes (6.68MiB)

Definitely worth using and saves the headache of large RIP/PC offsets causing problems.

…ngth integer

When FEX-Emu#2722 implemented this initially and FEX-Emu#4271 switched over to signed
int16_t there was assumptions made that int16_t was a reasonable
trade-off in encoding size versus needing to deal with 8-bit values
being too small in some cases.

In the common case we are almost always encoding 8-bit values because
instructions are typically linear (and less than 15-bytes in size), but
16-bit was chosen because optimizing JIT and multiple instructions that
don't cause exceptions can add up to larger than 8-bit.

Instead of hardcoding 16-bit values, implement a variable length integer
class where ~96.8% of values are 8-bit encoded, and the remaining 3.19% are encoded using 16-bit.
Due to some constraints that FEX-Emu#4271 put in place, we can basically
guarantee currently that branch targets are within 16-bit. The VL class
does support 32-bit and 64-bit as well so if we change behaviour then
nothing needs to change.

Some stats when running Sonic Mania with multiblock enabled.
Encoded integers: 3,504,907
Encoded 8-bit:    3,393,095 (96.8%)
Encoded 16-bit:     111,812 (3.19%)
Encoded 32/64-bit:        0

Encoded Size:       3,615,181 bytes (3.44MiB)
Fixed encoded size: 7,007,604 bytes (6.68MiB)

Definitely worth using and saves the headache of large RIP/PC offsets
causing problems.
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.

1 participant