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

Finding weird/wrong targets #2564

Open
3 of 4 tasks
boschmitt opened this issue Jan 30, 2025 · 0 comments
Open
3 of 4 tasks

Finding weird/wrong targets #2564

boschmitt opened this issue Jan 30, 2025 · 0 comments

Comments

@boschmitt
Copy link
Collaborator

Required prerequisites

  • Consult the security policy. If reporting a security vulnerability, do not report the bug using this form. Use the process described in the policy to report the issue.
  • Make sure you've read the documentation. Your issue may be addressed there.
  • Search the issue tracker to verify that this hasn't already been reported. +1 or comment there if it has.
  • If possible, make a PR with a failing test to give us a starting point to work on!

Describe the bug

A combination of assumptions in our build system and our code allows CUDA-Q to find nonsensical targets:

[LinkedLibraryHolder.cpp:185] Found Target nvidia-fp64 with config file nvidia-fp64.yml
[LinkedLibraryHolder.cpp:129] CUDA-Q Library Path is /workspace/dev/cuda-quantum/build/lib.
[LinkedLibraryHolder.cpp:140] Skip cusvsim-fp64 simulator for target nvidia-fp64 since it is not available
[LinkedLibraryHolder.cpp:129] CUDA-Q Library Path is /workspace/dev/cuda-quantum/build/lib.
[LinkedLibraryHolder.cpp:140] Skip custatevec-fp64 simulator for target nvidia-fp64 since it is not available
[LinkedLibraryHolder.cpp:195] Found Target: nvidia-fp64 -> (sim=qpp, platform=default)

The above is showing the nvidia-fp64 target being backed by the qpp simulator!

The assumptions:

  • The build systems assumes that a user will always build all the targets his system is capable of supporting and will install the target configuration files independently on whether the targets were actually built. For example:
    • It assumes that nvqir-qpp and nvqir-stim are always built, since the user is quite likely to have a CPU (:
    • It assumes that gpu-backed targets, nvidia-*, are built, if a user has GPUs, CUDA and cuQuantum installed
  • Our code seems to assume that the correct default simulator for all targets is qpp---even if the target is a different simulator and the runtime just happens to fail finding the shared library for it.

Implications:

Not all users build CUDA-Q in the same way. Developers might not want to build the whole world just to test (or benchmark!) specific parts of the system. In this cases, setting a target cudaq.set_target('nvidia') will silently load qpp.

Steps to reproduce the bug

  • In a freshly configured build directory, build the python modules: ninja CUDAQuantumPythonModules
  • You will also need to build the default platform ninja cudaq-default-platform and the qpp backend(?) ninja nvqir-qpp
  • CUDAQ_LOG_LEVEL=info PYTHONPATH=$(pwd)/python python3 -c "import cudaq"

This will output logs showing all targets being "successfully" found and using the qpp simulator.

Expected behavior

  • We should only install targets configuration files is the respective library is built
  • The runtime should not assume all targets default to using the qpp simulator

Is this a regression? If it is, put the last known working version (or commit) here.

Not a regression

Environment

Suggestions

No response

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