-
Notifications
You must be signed in to change notification settings - Fork 7
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
Comments
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
Solved issue by passing |
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
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:
mlir-translate --mlir-to-llvmir
to generate the llvmir codeopt --O3 -S
to optimize the llvmir code of the previous stepclang/gcc -O3
to generate the executable.The text was updated successfully, but these errors were encountered: