Michael S (already5chosen.delete@this.yahoo.com) on November 25, 2020 12:26 am wrote:
> Chester (lamchester.delete@this.gmail.com) on November 24, 2020 11:49 pm wrote:
> > Howard Chu (hyc.delete@this.symas.com) on November 24, 2020 9:41 am wrote:
> > > Michael S (already5chosen.delete@this.yahoo.com) on November 24, 2020 2:22 am wrote:
> > > > Chester (lamchester.delete@this.gmail.com) on November 24, 2020 1:34 am wrote:
> > > > > I'm not sure what hardware Gabriele Svelto used. But if it's a relatively modern
> > > > > 8-core, compatibility layers like cygwin didn't seem to destroy performance.
> > > > >
> > > > > I also briefly tried WSL, but the build breaks there.
> > > >
> > > > From description it sounds like MSYS (most likely MSYS2, rather than original 32-bit
> > > > variant) rather than cygwin. MSYS2 is not slow, but it's less compatible to POSIX.
> > >
> > > Mozilla build system uses MSYS (MSYS2). Cygwin is at least 2-3x slower.
> > > I was the one ported it to MSYS, 15 years ago.
> > >
> > > http://highlandsun.com/hyc/#mozilla
> > >
> >
> > Ok, correction to previous post: compatibility layers like MSYS don't seem to destroy performance :)
>
> Because it's not particularly compatible.
> In MSYS, POSIX compatibility is on the level of system utilities. MSYS's limited compatibility on the level of
> C library calls is more or less the same as MSVC, after all their C library (but not C++ library) is based on
> MS-supplied DLL (from VS2013, I think). And there is no compatibility at all on the level of system calls.
>

That's fine - MSYS is still doing the job of getting FF to build on Windows without breaking. Limiting the scope of compatibility is a valid way to achieve good performance when more compatibility isn't needed to begin with.

Again I don't know what hardware was used in the original Debian/Mac OS test, but I'm still surprised a build on top of a compatibility layer in Windows (even a limited one) was faster than the Debian result with core counts matched.