yardstiq/quantum-benchmarks

Qrack build missing export.h

Closed this issue · 5 comments

Problem

I tried to build the Qrack experiment with sudo ./bin/benchmark setup qrack and it failed.
I opened this issue because I couldn't find any export.h in this project or the qrack project https://github.com/vm6502q/qrack .

Error message

[ 98%] Built target benchmarks
[100%] Linking CXX executable unittest
[100%] Built target unittest
Install the project...
-- Install configuration: ""
-- Installing: /usr/local/include/qrack/common/config.h
...
-- Installing: /usr/local/share/pkgconfig/qrack.pc
-- Installing: /usr/local/bin/qrack_cl_precompile
In file included from benchmarks.cc:1:
benchmark/include/benchmark/benchmark.h:190:10: fatal error: benchmark/export.h: No such file or directory
 #include "benchmark/export.h"
          ^~~~~~~~~~~~~~~~~~~~
compilation terminated.

I guess this issue should be easy to fix. I'll tag @WrathfulSpatula since this issue is related to Qrack.

@ChienKaiMa That file is in https://github.com/google/benchmark.git, not the Qrack repository. Cloning fresh, I run into the same issue, but it seems to be a bug in Google's benchmark repository, or a change in its required build settings. (I'm still poking around.)

See my PR: #53

You can fork that immediately, if you'd like, and the Qrack build should work, there. (Other C++ simulators might also be affected by the same change, in google/benchmark.)

(Friendly reminder: make sure libopencl.so and an appropriate OpenCL ICD are available on your system, if you intend to benchmark GPU performance. Also, per the intent of this repository, the benchmark is limited to "ket" or "state vector" simulation, but Qrack's default optimal simulation mode will typically be even faster!)

  1. Thank you very much! I have copied your fix and build Qrack successfully.
  2. I will check my GPU setup later since clinfo currently shows I have 0 platforms, while I could find intel backends.
> cat /etc/OpenCL/vendors/*
/opt/intel/oneapi/compiler/latest/linux/lib/oclfpga/host/linux64/lib/libalteracl.so
/opt/intel/oneapi/compiler/latest/linux/lib/x64/libintelocl.so
/opt/intel/oneapi/compiler/latest/linux/lib/x64/libintelocl_emu.so
  1. Our lab made an binary-decision-diagram based simulator (https://github.com/NTU-ALComLab/SliQSim), which is one of a kind. We are looking for suitable benchmarks to demonstrate its advantage, rather than trivial circuits like GHZ states or Bernstein-Vazirani algorithm. Therefore, I am looking into different approaches of simulation and benchmarking, and I will definitely check out the optimal simulation mode you mentioned :)

Solved problem

Below is another problem I just faced and fixed, but I hope there are better solutions.
The OpenCL version on my device is 2.2.18.04.06. Therefore, when CL_HPP_TARGET_OPENCL_VERSION is default to 300 (OpenCL 3.0) , it triggers the template argument errors, which should be CL_HPP_PARAM_NAME_INFO_2_2_ instead of CL_HPP_PARAM_NAME_INFO_3_0_. A solution I found is to modify the default in my opencl.hpp , but I think it is not the best solution.

Detailed error message

-- Installing: /usr/local/bin/qrack_cl_precompile
In file included from /usr/include/CL/cl2.hpp:17,
                 from /usr/local/include/qrack/common/oclengine.hpp:40,
                 from /usr/local/include/qrack/qmaskfusion.hpp:15,
                 from /usr/local/include/qrack/qfactory.hpp:16,
                 from benchmarks.cc:2:
/usr/include/CL/opencl.hpp:445:112: note: #pragma message: opencl.hpp: CL_HPP_TARGET_OPENCL_VERSION is not defined. It will default to 300 (OpenCL 3.0)
 # pragma message("opencl.hpp: CL_HPP_TARGET_OPENCL_VERSION is not defined. It will default to 300 (OpenCL 3.0)")
                                                                                                                ^
In file included from /usr/include/CL/cl.h:32,
                 from /usr/include/CL/opencl.h:38,
                 from /usr/include/CL/opencl.hpp:538,
                 from /usr/include/CL/cl2.hpp:17,
                 from /usr/local/include/qrack/common/oclengine.hpp:40,
                 from /usr/local/include/qrack/qmaskfusion.hpp:15,
                 from /usr/local/include/qrack/qfactory.hpp:16,
                 from benchmarks.cc:2:
/usr/include/CL/cl_version.h:43:139: note: #pragma message: cl_version: CL_TARGET_OPENCL_VERSION is not a valid value (100, 110, 120, 200, 210, 220). Defaulting to 220 (OpenCL 2.2)
 #pragma message("cl_version: CL_TARGET_OPENCL_VERSION is not a valid value (100, 110, 120, 200, 210, 220). Defaulting to 220 (OpenCL 2.2)")

In file included from /usr/include/CL/cl2.hpp:17,
                 from /usr/local/include/qrack/common/oclengine.hpp:40,
                 from /usr/local/include/qrack/qmaskfusion.hpp:15,
                 from /usr/local/include/qrack/qfactory.hpp:16,
                 from benchmarks.cc:2:
/usr/include/CL/opencl.hpp:1480:1: error: ?L_PLATFORM_NUMERIC_VERSION??was not declared in this scope
 CL_HPP_PARAM_NAME_INFO_3_0_(CL_HPP_DECLARE_PARAM_TRAITS_)
 ^~~~~~~~~~~~~~~~~~~~~~~~~~~

@ChienKaiMa This might work for your other problem:

In any C source file or CMake project that uses OpenCL, you can define the following macros:

#define CL_HPP_MINIMUM_OPENCL_VERSION 110
#define CL_HPP_TARGET_OPENCL_VERSION 200

...or change the 3-digit version numbers as appropriate, where 110 is OpenCL v1.1 and 200 is v2.0. As far as I know, Qrack's minimum compatibility level is v1.1. It uses optional out-of-order queue execution from v2.x, if that's available, but it should automatically fall back to pure v1.1 compatibility otherwise. Since v1.1 features are the minimum requirement for v3.0, besides optional v3.0 features, you should be good with any version of OpenCL from v1.1 forward!

(Also, I'll have to check out your binary decision diagram simulator! After IEEE Quantum Week last October, hearing talks from the Jülich supercomputing center, I was personally inspired to add Qrack::QBdt, as a simulator option to the Qrack library, where "QBDT" stands for "quantum binary decision tree"! That simulator type is still experimental, though, and not part of the default optimal stack.)