Provide Visual Studio 2010 support (for python 3.4)

[hughperkins]

Hi,

I have a couple of neural net projects for OpenCL, ie https://github.com/hughperkins/DeepCL and https://github.com/hughperkins/clnn They're currently using clblas. I'm tentatively interested in investigating using clblast instead, since eg psyhtest recommends it here. I notice you require c++11 I currently support C++0x and Visual Studio 2010 as standard across my projects, for a few reasons:

• many people still use old version of gcc, like 4.4 or so
• many people are using Python 3.4 (which is Visual Studio 2010), or Python 2.7 (which is Visual Studio 2008, but 2008 is basically approximately compatible with 2010, in either direction; both are approximately c++0x standard, in my experience, with a couple of smallish discrepancies).

I know that C++11 gives you a few conveniences as a developer, which it's hard to resist :-) To what extent might you consider dropping your compiler requirements from c++11 down to c++0x / Visual Studio 2010?

Hugh

[hughperkins]

You know what? I changed line 62 of CMakeLists.txt from c++11 to c++0x, and the library built just fine, no errors :-)

(Mind you, I seem to be lacking tuners, and tests for some reason, with samples set to 'OFF'. Not sure why?)

[hughperkins]

(Hmmm, the tests have clBLAS as a dependency? :-P)

[CNugteren]

Good to hear! Be aware that CLBlast is still very much under development, so some features might be missing or performance might be sub-optimal. Perhaps it is better to wait 2 or 3 more months? In the meantime it is a good idea to see what is still missing, so I can focus on those issues.

The library is C++11, and it's going to stay that way. However, I am trying to use only those features supported earlier on by compilers. For example GCC 4.7 and MSVC 2015 are not fully C++11 compatible, but they do properly compile the code.

I don't think C++0x is something you can theoretically provide support for, because it is just an earlier development name for C++11. What could be done is trying older compilers and see what is already supported and what can be easily be fixed (e.g. by changing the compiler flag). So, I propose the following:

• You let me know which MSVC versions already work out-of-the-box (I don't have those installed), and we can update the README.
• I'll add testing on older GCC and Clang versions to my TODO list, trying to see what can be done there.

[hughperkins]

So... there are a couple of issues here perhaps. Should you be using the most modern compiler, so that you get the best optimizations and fastest speed? Probably :-) Should you be using the latest possible features?

So, C++11 is a strict superset of the features in C++0x, as far as I know. If you compile with -std=c++0x, you are guaranteed that you can also compile with -std=c++11, as far as I know, but the opposite is not hte case. From the point of view of being a developer, there are some really nice features in C++11 that are very hard to resist the temptation to use. A few that I used, and had to rip out when I downgraded to C++0x are:

Raw strings, which I ripped out relunctantly hughperkins/DeepCL@e57e8d6367a

Object variable initializers, which I removed for example in hughperkins/DeepCL@1745c4c2822 and hughperkins/DeepCL@af83f52c30be0b0

chrono is actually in c++0x, but not supported in msvc10. Bye bye chrono hughperkins/DeepCL@40ab3013f1

I remember there is some nice functoinality about list initializers too, in c++11, not in c++0x, but I cant find an example.

Finally I downgraded from c++11 to c++0x in hughperkins/DeepCL@49e991e42370ec , which made it easier to not use msvc10-incompatible stuff.

Of course, your target audience might be different from mine, but the way I looked at it, finally, was, sure c++11 makes the experience as a library maintainer slightly easier, but if it restricts the potential target audience of library users, is it worth the ~a few hours total that it took to remove the c++11-incompatible features?

Philosophy aside :-) Looking at your concrete proposals:

You let me know which MSVC versions already work out-of-the-box (I don't have those installed), and we can update the README.

Ok, I dont either :-) But I might spin up an ec2 instance, and have a try. (I'm a ubuntu 15.10 64-bit guy myself :-D )

I'll add testing on older GCC and Clang versions to my TODO list, trying to see what can be done there.

Cool, sounds good :-)

[hughperkins]

msvc10 build output: https://gist.github.com/anonymous/cb36b86bbdd188c040a7f95e8410dbe6

[hughperkins]

(Note that it occurs to me that one other possibility would be that the library itself is built with c++11, msvc2013, etc, and then the client programs are built with some other compiler. This is a bit tricky to do, and you'd almost certainly need to provide a pure C interface, and probably avoid sending strings over it, or be careful about that. I actually did this finally for DeepCL, so that the python-bit is built using eg msvc2008, and the c++ bit is built using msvc2010, and there is a c-interface between the two.

Gory details on the risks and methodology of mixing msvc runtimes here: http://siomsystems.com/mixing-visual-studio-versions/
)

[CNugteren]

About your last remark: there is already a pure C interface to CLBlast and there are no usages of the STL (such as the strings you mentioned) in the interfaces, so that could be a possibility perhaps? Once release 1.0 is there I will also supply pre-compiled binaries.

Somewhere earlier on you said:

You know what? I changed line 62 of CMakeLists.txt from c++11 to c++0x, and the library built just fine, no errors :-)

Which compiler was this? I tried just now with GCC 4.6, but it is missing too many C++11 features to get it compiled, so GCC 4.7 seems to be the lower limit.

I still have to look into your pull-request, but ideally I prefer it the other way: an additional header for compatibility with MSVC 2010, rather than changing the CLBlast library itself. However, this might not be possible in all cases, so I'll have to look into that.

[hughperkins]

I still have to look into your pull-request, but ideally I prefer it the other way: an additional header for compatibility with MSVC 2010

Ok. How would that work?

there is already a pure C interface to CLBlast and there are no usages of the STL (such as the strings you mentioned) in the interfaces, so that could be a possibility perhaps?

Hmmmm, possibly. It's not ideal, because it means I would need to somehow build clblast separately somehow. If you have downloadable binaries for win32, win64, mac os x, then that would cover a lot of use cases.

[CNugteren]

I've started a visual_studio branch, which I will try to make compile on Visual Studio 2012 (to start with). After that we can see if we can go further back in time.

I renamed the issue to reflect better what we're trying to achieve here.

[hughperkins]

I'd prefer you dont rename the thread to 2013 or 2012, these wont help me :-) however, providing 2012 as an intermediate step is of course useful :-)

[CNugteren]

OK, I guess... By the way, I still don't see the relation between C++ and Python. Surely there isn't a tight coupling on Windows between Visual Studio and which Python version you have installed? Note that CLBlast doesn't need any Python at all.

[hughperkins]

Well... you're right actually... if you have downloadable binary distributions for Windows, with a C API, then I can probably get that to work ok, without needing any you-will-hate downgrading of your code away from c++ 11 :-D

[hughperkins]

(eg two zip files, one for win32, one for win64, with the appropriate dll and import lib in each. ideally with the appropriate msvcp.dll in each too, though I can probably live without, if I must :-) )

[hughperkins]

(and... you'd have to be really sure that there is no memory allocated by the caller, and freed by the library, or visa versa. If thats the case, I think it's ok to mix runtimes).

[blueberry]

FWIW, JOCLBlast and Neanderthal use CLBlas from Java and Clojure via the provided C API. If you are calling the lib from python, isn't that the same situation? Compile the library with the provided build script, or get the binary from someone, and that's all. I do not see why the FFI would demand a specific compiler, since the library build is separate from the client build. Or am I missing some Windows/VS shenangians?

[CNugteren]

I've created a visual_studio branch and started to fix things in Visual Studio 2012. Some are easy to fix, but some are much much more involved. Just browsing through the list of unsupported features made be decide to postpone this for now (or for ever?). It is just too much: users should upgrade instead to Visual Studio 2015.

From now on all releases of CLBlas will include binaries for Windows. I plan to release 0.7.0 in a week or so, perhaps you can check afterwards if this works.

[hughperkins]

From now on all releases of CLBlas will include binaries for Windows

cool, sounds good :-)

[CNugteren]

I've just made the 0.7.0 preview release, which now for the first time contains binaries for both Linux and Windows (64-bit only). I don't have much experience with this, so perhaps you can take a look and see if this is transferable to other systems. Perhaps I am missing some files or maybe I'll have to set some specific linker flags in Visual Studio?

[hughperkins]

Ok. Dont suppose... possible to provide a unit tests executable with it? Note that needs 32-bit build too, eg the free vms that MS provides for ie testing are all 32-bit https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/linux/

[CNugteren]

I'm happy to publish a 32-bit build as well if you can make one for me. But is that still in use these days?

[hughperkins]

Unfortunately, I barely have time to maintain build bots for my own libraries, not relaly enough time to maintain build bots for third-party libraries :-D Note that, unlike linux32, you can build windows32 on a windows64 platform. You just flip a switch when you run cmake, choose generator eg 'visual studio 2015', instead of 'visual studio 2015 win64'.

Just in case its useful, you can see my own windows build scripts here:

• win32 https://github.com/hughperkins/DeepCL/blob/jenkins-jobs/jenkins/win32-cpp.bat
• win64 https://github.com/hughperkins/DeepCL/blob/jenkins-jobs/jenkins/win64-cpp.bat

Almost the same. 'win64' in this line https://github.com/hughperkins/DeepCL/blob/jenkins-jobs/jenkins/win64-cpp.bat#L11 , and uses the win64 redistributables instead of the win32 ones https://github.com/hughperkins/DeepCL/blob/jenkins-jobs/jenkins/win64-cpp.bat#L23 Yes, these scripts could probably be refactorized a bit :-D

(Edit: hmmmm, those scripts are almost exactly a year old today :-D )

[CNugteren]

OK, that makes sense. I've now also build 32-bit binaries for Windows. They are part of the release now, again very experimental because they are untested.

I also wrestled with Visual Studio to try to get the correctness and performance tests as part of the (32/64-bit) releases, but I didn't manage to get them to link. At some point if I have some time left I'll try again (perhaps the 1.0.0 release?).

[hughperkins]

I've now also build 32-bit binaries for Windows. They are part of the release now, again very experimental because they are untested.

Cool :-)

I also wrestled with Visual Studio to try to get the correctness and performance tests as part of the (32/64-bit) releases, but I didn't manage to get them to link. At some point if I have some time left I'll try again (perhaps the 1.0.0 release?).

Ok, no worries. Seems like it's gradually moving forward :-)

[CNugteren]

I'll close this issue for now, as Visual Studio 2010/2012/2013 support is not on the agenda (for now). I will build binaries with each release. If anything is wrong with them, you can open a separate issue.

[hughperkins]

Ok, no worries :-)

[CNugteren]

A while back I (unsuccesfully) tried to support Visual Studio 2012:

I've created a visual_studio branch and started to fix things in Visual Studio 2012. Some are easy to fix, but some are much much more involved. Just browsing through the list of unsupported features made be decide to postpone this for now (or for ever?). It is just too much: users should upgrade instead to Visual Studio 2015.

However, support for Visual Studio 2013 is a lot easier to do actually. I am working on a msvc2013 branch which is almost finished and will be merged soon.

So, for future reference: VS 2013 is now also supported.

[hughperkins]

Ok. To be honest, I finally admitted defeat, after:

• python 3.5 is now msvc2015 on Windows (python 3.4 was msvc2010), and
• msvc 2010 community was no longer available

... and upgraded directly to msvc2015, in line with Python 3.5

[hughperkins]

(and also switched everything to c++11 )