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

Improve numpy-scipy runtime performance #30

Open
pthomadakis opened this issue Sep 21, 2023 · 1 comment
Open

Improve numpy-scipy runtime performance #30

pthomadakis opened this issue Sep 21, 2023 · 1 comment
Assignees

Comments

@pthomadakis
Copy link
Collaborator

In some cases there is a significant difference in runtime performance between mlir-cpu-runner and code executed through the numpy-scipy interface.
This issue also appears when compiling and running the COMET llvm dialect IR through the following steps:

  1. mlir-translate --mlir-to-llvmir to generate the llvmir code
  2. opt --O3 -S to optimize the llvmir code of the previous step
  3. clang/gcc -O3 to generate the executable.
  4. Run the executable.
@pthomadakis pthomadakis self-assigned this Sep 21, 2023
pthomadakis added a commit that referenced this issue Sep 29, 2023
…-cpu-runner (#30).

  By passing the target triple returned by ``llvm-config --host-target`` to llvm opt.

  Also fixed a bug where calling the kernel function in a loop would cause wrong code generation.
  Finally, made integration test use multiprocessing
@pthomadakis
Copy link
Collaborator Author

Solved issue by passing --mtriple=<cpu-triple> to opt

@pthomadakis pthomadakis reopened this Oct 12, 2023
pthomadakis added a commit that referenced this issue Oct 12, 2023
…alls to a single one at the slight cost of readability (#30).

We now need only create 1 process to lower scf->llvm, translate, opt, and generate the library, instead of doing it in separate steps.
pthomadakis added a commit that referenced this issue Oct 13, 2023
…-cpu-runner (#30).

  By passing the target triple returned by ``llvm-config --host-target`` to llvm opt.

  Also fixed a bug where calling the kernel function in a loop would cause wrong code generation.
  Finally, made integration test use multiprocessing
pthomadakis added a commit that referenced this issue Oct 13, 2023
…alls to a single one at the slight cost of readability (#30).

We now need only create 1 process to lower scf->llvm, translate, opt, and generate the library, instead of doing it in separate steps.
pthomadakis added a commit that referenced this issue Oct 22, 2023
…-cpu-runner (#30).

  By passing the target triple returned by ``llvm-config --host-target`` to llvm opt.

  Also fixed a bug where calling the kernel function in a loop would cause wrong code generation.
  Finally, made integration test use multiprocessing
pthomadakis added a commit that referenced this issue Oct 22, 2023
…alls to a single one at the slight cost of readability (#30).

We now need only create 1 process to lower scf->llvm, translate, opt, and generate the library, instead of doing it in separate steps.
pthomadakis added a commit that referenced this issue Oct 22, 2023
…-cpu-runner (#30).

  By passing the target triple returned by ``llvm-config --host-target`` to llvm opt.

  Also fixed a bug where calling the kernel function in a loop would cause wrong code generation.
  Finally, made integration test use multiprocessing
pthomadakis added a commit that referenced this issue Oct 22, 2023
…alls to a single one at the slight cost of readability (#30).

We now need only create 1 process to lower scf->llvm, translate, opt, and generate the library, instead of doing it in separate steps.
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

1 participant