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

Print some machinst metrics #8107

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

Conversation

lpereira
Copy link
Contributor

This is just a first pass at trying to gather some insights that might lead to memory savings later. For instance, by compiling SpiderMonkey with this patch, we get these metrics out:

Key(machinst.buffer.data): 0.0: 4 0.5: 412.0315874877959 0.9: 1636.1480687972453 1.0: 110084
Key(machinst.buffer.relocs): 0.0: 0 0.5: 1.9999056357269998 0.9: 9.999149133010329 1.0: 600
Key(machinst.buffer.traps): 0.0: 0 0.5: 11.999920242205052 0.9: 57.00277828432678 1.0: 3833
Key(machinst.buffer.call_sites): 0.0: 0 0.5: 1.9999056357269998 0.9: 9.999149133010329 1.0: 600

Which suggest that the fields in MachBuffer struct could be reduced:

  • Half of the functions are under 412 bytes; most are under 1.6kB.
  • Half of the functions have 2 relocs; most have at most 10.
  • Half of the functions have 12 traps; most have at most 57. The default allocation of 16 is probably OK for this field.
  • Half of the functions have 2 call sites; most have at most 10.

Of course, there's only one MachBuffer per thread compiling code, so the savings here are marginal, but this approach could be used in other parts of the code to find more useful things.

The output formatting at this point is pretty crude as this is merely a proof-of-concept, but something better can be made later if necessary.

This is just a first pass at trying to gather some insights that might
lead to memory savings later.  For instance, by compiling SpiderMonkey
with this patch, we get these metrics out:

Key(machinst.buffer.data): 0.0: 4 0.5: 412.0315874877959 0.9: 1636.1480687972453 1.0: 110084
Key(machinst.buffer.relocs): 0.0: 0 0.5: 1.9999056357269998 0.9: 9.999149133010329 1.0: 600
Key(machinst.buffer.traps): 0.0: 0 0.5: 11.999920242205052 0.9: 57.00277828432678 1.0: 3833
Key(machinst.buffer.call_sites): 0.0: 0 0.5: 1.9999056357269998 0.9: 9.999149133010329 1.0: 600

Which suggest that the fields in MachBuffer struct could be reduced:

 - Half of the functions are under 412 bytes; most are under 1.6kB.
 - Half of the functions have 2 relocs; most have at most 10.
 - Half of the functions have 12 traps; most have at most 57.  The
   default allocation of 16 is probably OK for this field.
 - Half of the functions have 2 call sites; most have at most 10.

Of course, there's only one MachBuffer per thread compiling code, so
the savings here are marginal, but this approach could be used in other
parts of the code to find more useful things.

The output formatting at this point is pretty crude as this is merely a
proof-of-concept, but something better can be made later if necessary.
@github-actions github-actions bot added cranelift Issues related to the Cranelift code generator cranelift:area:machinst Issues related to instruction selection and the new MachInst backend. labels Mar 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cranelift:area:machinst Issues related to instruction selection and the new MachInst backend. cranelift Issues related to the Cranelift code generator
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant