Hey, no worries. I also couldn’t get MM to run on my dual processor box when running Win, so I switched to Ubuntu right away. It is also possible that your Threadripper is pushing the limits on the H/W side, so subtle compatibility issues with your motherboard or RAM could be at play. BSODs are kernel related and that is where the code meets the H/W.
I also think that we are conflating two separate problems. The first is how well the code is optimized for a given platform (as we can see, running Linux MM gives ~10% faster plots than running it on Win). The second problem manifests itself when the box has more than one processor, and for whatever reason MM code just breaks down on Win. If I remember right, people reported running BB fine on Win boxes with multiple processors, so this problem is most likely MM related. Most likely, this problem is exactly with those cross-platform libs that MM is using, not really with MM code written by Max (some thread wrappers giving long timeouts).
Although, saying that, we could try to “partition” MM code into two components. The first would be the code crunching part, and this most likely runs with the same speed on all platforms. The second is thread handling part, and potentially this is where all those differences are coming from. Not sure whether this is the case, but that would be my bet. Trying to optimize the second part for Win may not be a trivial task, though.
What I am trying to say is that we should not generalize based on just one program, especially as we know that MM development is purely under Linux, where Stotik is just trying to wrap it up in a Win binary without doing much if any code changes. Sure, Max is using general purpose cross platform libs to make it run virtually everywhere, but that is not the same as hand optimizing the code for a given platform. Some or maybe most of those libraries are providing the lowest common denominator optimization and are usually tilted in the way the original developer was more proficient.
Actually, the driver issue you brought up is a good example. Usually, under Linux, there is a “native” driver (e.g., for Ethernet or USB chips), and as long as the H/W is not really butchered badly, all works fine. On the other hand, on Win side, most of the drivers are derived from a Win sample code that is just a sample code. What it means that most of the low-cost parts run rather deficient drivers. IMO, this is where Linux really has less issues. Although, if there is no good match for a given H/W, most likely such H/W is just not usable under Linux (where virtually every H/W has some sort of Win drivers).