Compile error on OSX mojave

[twobombs]

As the title reads. No joy compiling qrack on OSX. Used is the cmake 3.13.3 , make 4.2.1.1 from brew.

Error occurs @ make all install

[bennbollay]

Thanks for the report! Looks like a pretty easy fix, should be able to get to it today.

[WrathfulSpatula]

Thank you! See #128 . If you run into issues after that, we'll keep fixing them sequentially.

[WrathfulSpatula]

Merged that PR. If this works, please let us know. We'll go back in and keep fixing it, if necessary.

[twobombs]

Yup, that fixed it

Ran into some CL header issues later into the build, will look into it myself first by double checking CL driver headers, clinfo and such. Will create a separate ticket when I think it's code.

This ticket can be closed now IMHO.

[WrathfulSpatula]

Thank you, please let us know. It's been a while since I built on Mac, but I remember that the "cl.hpp" C++ header was not available in the default OpenCL installation included in the OS. At the time, I could either temporarily turn off the locks on system files and directories, to add the header with the other system OpenCL includes, or else it was also possible to add the OpenCL include directory locally in the Qrack project folders, where the compiler would still pick it up.

There's a note in the README that basically explains the same thing. The "cl.hpp" header should be available here: https://www.khronos.org/registry/OpenCL/

Closing this issue, but please open another one, (or reopen this one as appropriate,) if you run into other troubles.

[twobombs]

I think I've got a another one here.

This error occured after I fixed the OpenCL headers issue ( by downgrading the CL.HPP file from 2.0 spec to v1.2 ) because most Macs have an Intel Iris/Radeon onboard, which according to Apple's own info is OpenCL 1.2 ( https://support.apple.com/en-us/HT202823 )

[bennbollay]

https://stackoverflow.com/questions/18515183/c-overloaded-virtual-function-warning-by-clang

I would recommend, assuming the errors are indeed spurious, the private option before the disabling of the warning.

[WrathfulSpatula]

This particular answer is the one I favor, which I have used elsewhere:

https://stackoverflow.com/questions/18515183/c-overloaded-virtual-function-warning-by-clang#answer-30192779

I will be able to implement this tonight. Also, I can tell by the name of the "Cohere" method, which has become "Compose," that you're not on the latest code from master. I would suggest using the current state of the code over the last release tag, particularly if you're doing any cross-device OpenCL, and the "Schmidt demposition" of these "Compose"/"Cohere" variants have been fixed. We're close to releasing a v3.1. I know this won't fix your overload problem, though.

Again, I should be able to get to this by tonight. That Stack Overflow thread does give multiple solutions that should hopefully work, though.

[WrathfulSpatula]

See #129 . I'm blind, because I'm not at my development machine, but if the CI fails, I'll get it on the second try, when I come back from picking up lunch.

[twobombs]

passes, yet stops with the same error in a different file ( presumably a similar fix would needed )

[WrathfulSpatula]

It's the same file. This looks like a version difference. If you change "using QEngine::Compose;" to "using QEngine::Cohere;" in your version, it should fix it, here.

Again, the work that went on master in the past week or two, which included this name change, also fixes critical bugs related to the general accuracy of the Schmidt decomposition and cross-device capabilities of "Compose"/"Cohere." However, if you choose to use the slightly older version, (aware of these changes,) just change my "Compose" to "Cohere." The differences might affect mathematical accuracy, though obviously the name change in itself does not.

It's my fault, that you have to come back to us for every separate compiler warning, by the way. Like I said, I'll update my Mac and make sure a build completes on it, tonight. I just can't do so, until I get home and update.

[twobombs]

No problem, I've been building a separate Docker version. That one works as advertised, the osx version was just for some extra test

[WrathfulSpatula]

I'm glad you have some version running, at least.

I hate to admit this publicly, but my dual boot corrupted the Mojave install, last night. I'm basically doing a factory reset on the machine, right now. (If anyone would be concerned, there is 0 essential data on the machine that is not backed up in the cloud. It's purely a machine to have a Mac development environment, so I just don't want to irrecoverably lose the Mac OS.) So, I'm a little delayed on building this, but I see the light at the end of the system recovery tunnel. When the machine is recovered and upgraded, I'll test the build on the latest OS.

In the Qrack 3.0 release and previous, the "Decohere"/"Decompose" Schmidt decomposition basically wipes phase relations from split engines. It went unnoticed for so long, because in the vast majority of the cases we use it for, even in QUnit, we only call that method on a permutation basis eigenstate, which happens to give a correct decomposition. The head of master should correctly Schmidt decompose in general, though. Also, there were problems with "Compose"/"Cohere" and these related methods when used to cross different OpenCL device contexts, which should be fixed, now. We could tag a v3.1, but I'm updating documentation and adding a method to the API for ProjectQ support. So, in our experience, the bugs were only apparent in semi-exotic use cases, but the head of master fixes a few important bugs and is stable.

Experimental multiprocessor support is currently broken, but this is why I've been working on a SimulaQron, to ProjectQ, to Qrack stack to replace our direct support for multiprocessor with a quantum computer network concept. By the time I'm done, it should be possible to achieve multiprocessor (between nodes and on the same node) as a virtual quantum computer network through SimulaQron.

Just so you know what Qrack can do, right now, and what's planned for the near-term. I'll be snowed-in, this weekend, working on the network simulator stack and a Mojave build.

[twobombs]

Stay warm and full of bandwidth :)

The Docker version I build was made on top of a critter I called CUDA-CLuster ( Basically a NV CUDA container with Web VNC & OpenCL support ) that allows stacking of workloads.

So far I've seen that a typical Qrack workload is heavy on compute, it's less on the VRAM. With NVidia-Docker one could run those GPU workloads on top of a single GPU so that workloads can be stacked and therefore resource utilisation can be maximised/optimised.

https://cloud.docker.com/u/twobombs/repository/docker/twobombs/qrack

Some work needs to be done on manuals for controlling those workloads and some on NoSQL DBs for storing, indexing results and such. Nothing fancy; as I read somewhere 27 qubits alone could generate 10k Tera-TB of digital data. ( factor n! ) lol :)

[WrathfulSpatula]

Thank you very much! I'll check it out. I think I was heading down the same line, with the SimulaQron work. Our experiments with multiprocessor operation have, at best, just about matched single OpenCL device mode, but never beat it. With SimulaQron, you could expose a few ports on your containers, and then they can communicate as a virtual quantum network, with simulated quantum network connections.

As for memory usage, the QEngine types generally use 2 floats per each permutation of bits, same as everyone else using float accuracy, but Qrack does have a couple of advantages:

• QUnit is able to break up the representation of a set of qubits into smaller separate representations of subsystems of qubits, when QUnit can determine (or is told, with a hint from "TrySeparate()") that subsystems are definitely not entangled. Each bit separated saves roughly a factor of 2 on memory. (This is due to an optimization developed in a paper from a group at IBM.)
• QEngineOCL, which also underpins QUnit when constructed as such, can keep its state vector entirely in device memory, if it fits, typically saving up to a GB or two from being allocated on general heap. This optimization is completely lost when the state vector allocation is made too big for the device RAM, though.

By the way, #129 has been updated, because I recovered my Mac OS and upgraded to Mojave. That might work for you, now.

[twobombs]

The memory behaviour was very well described and illustrated in your paper on the performance of the Qrack engines, so once the Docker version was build I could see that behaviour in real time on a node - that was a very nice thing to see.

I've changed the git clone URL to the original version so the Docker version will always pull the most recent version when it's build. Should take an hour or so to finish.

[WrathfulSpatula]

Thank you. Let us know if we can close the issue; we're getting off on tangents, a bit. I have a Mojave development environment, now, so I should be able to test anything else that comes up, hopefully.

[twobombs]

Issue can be closed, compile & install works on OSX

tnx!