GCC on Windows - Bash on Ubuntu on Windows (WSL), CygWin, MinGW
To answer your first question, yes, you can do that compile under WSL.
To answer your other questions, let's look at MinGW. This is what the Wikipedia entry for MinGW says:
MinGW was forked from version 1.3.3 of Cygwin.[5] Although both Cygwin and MinGW can be used to port Unix software to Windows, they have different approaches:[16] Cygwin aims to provide a complete POSIX layer comprising a full implementation of all major Unix system calls and libraries. Compatibility is considered higher priority than performance. On the other hand, MinGW's priorities are simplicity and performance. As such, it does not provide certain POSIX APIs which cannot easily be implemented using the Windows API, such as fork(), mmap() and ioctl().[16] Applications written using a cross-platform library that has itself been ported to MinGW, such as SDL, wxWidgets, Qt, or GTK+, will usually compile as easily in MinGW as they would in Cygwin.
Windows programs written with Cygwin run on top of a copylefted compatibility DLL that must be distributed with the program, along with the program's source code. MinGW does not require a compatibility layer, since MinGW-based programs are compiled with direct calls to Windows APIs.
(https://en.wikipedia.org/wiki/MinGW)
This is what the MinGW web page (http://www.mingw.org) says:
MinGW, a contraction of "Minimalist GNU for Windows", is a minimalist development environment for native Microsoft Windows applications.
MinGW provides a complete Open Source programming tool set which is suitable for the development of native MS-Windows applications, and which do not depend on any 3rd-party C-Runtime DLLs. (It does depend on a number of DLLs provided by Microsoft themselves, as components of the operating system; most notable among these is MSVCRT.DLL, the Microsoft C runtime library. Additionally, threaded applications must ship with a freely distributable thread support DLL, provided as part of MinGW itself).
MinGW compilers provide access to the functionality of the Microsoft C runtime and some language-specific runtimes. MinGW, being Minimalist, does not, and never will, attempt to provide a POSIX runtime environment for POSIX application deployment on MS-Windows. If you want POSIX application deployment on this platform, please consider Cygwin instead.
I am familiar with WSL and Cygwin more than MinGW. From what I know, MinGW is more targeted to producing reasonably portable, high-performance Windows binaries whereas Cygwin is more targeted to Unix users (or those wanting to port applications that were written for Unix/POSIX) who want a Unix-like environment under Windows with all the trimmings. As you indicated, Cygwin programs at least used to be less easily distributable to others who don't have Cygwin installed (due to license considerations, but see the link below). MinGW programs run as native Windows programs using undocumented Windows native libraries. WSL binaries don't run under Windows by themselves; they only run in the WSL environment (or possibly native Linux systems). WSL maps Linux kernel calls to Windows kernel calls, whereas Cygwin implements Unix/Posix library calls. WSL relies on a real Linux distribution to provide it's environment, whereas Cygwin relies on its own environment. (WSL has an advantage in that it will run existing binaries without recompilation.) I don't think any of this is too important to you, because you're not planning on distributing your binaries. You want high performance. According to Wikipedia, MinGW is higher performance than Cygwin, but it's also 32-bit which may be a problem with your applications. There is a 64-bit environment similar to MinGW but it's a different project.
An important consideration is whether you want to write Windows code or Unix/Linux/POSIX code. MinGW is for developing Windows applications using Windows APIs (although you can fold in some limited POSIX support); WSL and Cygwin are for developing Unix/Linux/POSIX applications. This matters for portability purposes. But if you are developing the type of programs I think you are, nearly all straight computations and very little fancy I/O, it may just boil down to personal preference or convenience. If you can come up with a small representative program that takes a significant amount of time and try running it under each environment, you can find out which has the best performance. That is going to depend I think on your own mix of operations.