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

Performance Evaluation: A request to Include in JIT comparison #3

Open
jserv opened this issue Aug 26, 2023 · 2 comments
Open

Performance Evaluation: A request to Include in JIT comparison #3

jserv opened this issue Aug 26, 2023 · 2 comments

Comments

@jserv
Copy link

jserv commented Aug 26, 2023

I would like to make a request for the inclusion of a test item based on copyjit for evaluation within the existing jit-comparison project. Currently, the project offers a basic comparison among gccjit, GNU Lightning, libjit, and MIR. To ensure comprehensive coverage of JIT compilers, it would be beneficial to add a test that focuses on copyjit's performance.

copyjit is a notable contender in the JIT landscape, and including it in the evaluation would provide valuable insights into its performance characteristics. This addition would contribute to a more thorough analysis of JIT compilers and enable developers and researchers to make informed decisions about their usage.

@Kimplul
Copy link
Owner

Kimplul commented Aug 26, 2023

Good suggestion, I added copyjit along with lightening and two bytecode implementations for reference.

A simple loop probably isn't the best test case, as it seems that most JITs are able to produce near-optimal code (at least when handwritten) for it. I don't really think there's a single test that would cover all aspects of JITs, but a number of smaller tests could be useful. Something like matrix operations and fibonacci sequences come to mind, though implementing them is firmly in the TODO pile for now.

@Kimplul
Copy link
Owner

Kimplul commented Sep 7, 2023

I added a recursive fibonacci sequence as a test case to jit-comparison.

Not all libraries have an implementation yet but the ones that do show a larger disparity between each library compared to the loop case, which in this case is probably a good thing.

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

No branches or pull requests

2 participants