Windows Support

[krasznaa]

This morning I was trying to get the code working on Windows. I guess I'm just masochistic...

After a lot more struggle than I would've expected, I can make at least most things compile. (I believe I found a Visual Compiler bug with the vecmem::binary_page_memory_resource implementation. That just refuses to compile into a DLL with exported symbols. If the compiler doesn't have the export the symbols of the class, it can compile fine. But if I request its symbols to be exported, the compilation dies on trying to instantiate the vecmem::binary_page_memory_resource::m_pages variable.)

But now I ran into one more issue, which brings the whole Windows port into question... The unit test of vecmem::contiguous_memory_resource fails on Windows in "Debug" mode. 😦 It turns out that MSVC does a lot of things during debugging. In order to test correct memory accesses, std::vector-s allocate memory with some padding in "Debug" mode. Which breaks the test that we have for that type...

The good news is that at least in "Release" mode the test succeeds. But at this point I've run into so many issues with that #@$% Windows build that I wanted to open a discussion about it. Whether anybody else but me even cared a little bit about making the project support that platform.

Pinging @stephenswat, @paulgessinger.

[stephenswat]

Personally I see zero good reason to support Windows, as far as I know all serious scientific computing in ATLAS, HEP, and outside of that happens on Linux or on Mac, right? Supporting Windows doesn't seem worth the effort to me.

That said, you're right that the contiguous_memory_resource relies on some implementation-defined behaviour rather than standard-defined behaviour. So it is a little bit iffy. I wonder if we can somehow come up with a better version of those tests...

[krasznaa]

"Properly" supporting it is indeed not really on the table. ROCm is not likely to ever work on Windows. Though CUDA and oneAPI are available for it... (They don't work with the current CMake code of the project though...)

I did run into a couple of interesting warnings from MSVC, fixing which could make our code just a tiny bit safer in the long run. (Mostly about lossy type conversions here and there.)

At the same time MSVC also produces a bunch of warnings that they themselves explain on their webpage, can be ignored. (Inheriting from an "STL type", like what we do with std::pmr::memory_resource in a class which is "exported" by a DLL, produces a warning...)

So it's rather an annoyance <-> reward question of how much we want to use MSVC as a debugging tool. I'm normally a fan of goofing around on Windows, but in this instance I'm starting to have my doubts...

[paulgessinger]

My understanding is exporting symbols in a DLL that expose STL types works with a warning, but is generally unsupported and discouraged. As a consequence, I doubt it's worth the effort to get that to work. On the other hand, we could try if producing a static lib on windows works without too much effort. For the purposes of getting extra warnings from MSVC, that should be sufficient, or not?

[krasznaa]

Is it discouraged? 🤔 How would one ever want to use any abstract interface from STL in Windows then? I guess this just never came up before... (This is the first time for me as well that I'm implementing something inheriting from a non-template std:: type...)

Static libraries could be built on Windows without too much effort of course. I was just wondering if there would be any value in explicit symbol exporting/hiding in the vecmem libraries. I'm honestly not sure... (Explicit symbol control could be very good if we start using some external code inside of vecmem. For instance we can only really use Microsoft's onnxruntime code in ATLAS because they rigorously implemented symbol hiding on Linux. Which figures. 😛 But that's a longer story...) On Windows, if one wants to build a DLL, it is of course a must. However with static libraries it doesn't make a difference anyway.

I'll play a bit more on Windows over Easter, and we can discuss afterwards what we should do...

[paulgessinger]

My understanding is you're supposed to use PIMPL as much as possible to hide STL types, and pragma ignore the warnings where not possible.

Not really an expert for windows stuff, so I might be wrong.