As in, I notice that the MingW builds (the fastest option available to Windows users when it comes to Cycles rendering), has been dead for a month and this leaves me wondering.
Is this ever going to be fixed at all (because something that is dead for good may as well be completely removed as an option since there will not be any new builds)? I’ve read on the mailing list of Shadowrom looking into fixing the issues and even getting it working on his end (that and reading about a patch that could fix the OpenMP issue even), but all I want to know is whether or not the support for the platform will simply be pulled as a result (though it would be a bum deal for the Windows users to always be stuck with the slower builds).
Last I tried a VS2012 build, it was still about 10 percent slower than the latest MingW builds when it came to Cycles rendering (though it was faster than older MingW builds). This is confirmed with HolyEnigma’s last build from the 19th of June.
One of the only reasons I use MingW right now is the faster rendering speed for Cycles (and I’m kind of a sucker when it comes to things like that).
If I’m correct VS Express (free version) doesn’t have optimization options so you need to get the full version of VS. Programs compiled in VS also require some dll’s that can be missing in some Windows setups, which is really funny actually. GCC doesn’t require them. Then we can also argue about VS extensions which can lead to less portable source code. GCC is more standard. The newest version of GCC also catches errors that go unnoticed in VS (Express).
When I’m programming in C++ I’m using VS, because it has great IDE, but I’m always doing the release compiling in GCC to get standards right and also use optimization.
the mingw builds have been known to be faster with Cycles CPU rendering only…
i compile it with CUDA too now that i know how to, but GPU render may either be the same
or a little faster with VS builds.
At least for the 2012 Edition, I could find not such limitation, it also supports OpenMP.
Programs compiled in VS also require some dll’s that can be missing in some Windows setups, which is really funny actually. GCC doesn’t require them.
This is annoying indeed, however you can bundle these DLLs with Blender (not sure if it’s actually done). GCC builds also require their own bunch of DLLs that need to be bundled.
Then we can also argue about VS extensions which can lead to less portable source code.
I don’t see how this is relevant to Blender.
GCC is more standard. The newest version of GCC also catches errors that go unnoticed in VS (Express).
Most developers probably use a Linux environment already, so any such errors would not go unnoticed for Blender. This is strictly about providing builds to the end user.
The major drawback of using MingW is of course the fact that the builds are unstable. I don’t think the figure of 10% better performance is relevant enough to keep up such a build environment. That figure may also change if the code is more optimized, so that the compiler doesn’t have to do it.
As far as I read from Psy-Fi (who maintains mingw) the issue is on mingws end. In any case, whether or not it’s Blenders fault doesn’t even matter: 10% performance increase isn’t worth less stability + more effort.
I’m not sure about the unstable part, I can easily build scenes for hours without having a single crash. The only thing that’s even remotely unstable is the Cycles rendered viewport and even then I can avoid most of the hassle because of the preview window.
The thing is, in a rather large majority of cases, the fixing of stability issues in vanilla trunk builds will increase stability for MingW as well.
