How can I make 64-bit compiles with Cygwin?

[hgm]

OK, thanks all!

I managed to make a 64-bit compile on a stand-alone MinGW64 install, using this horrible x64... command. I am pretty sure it was a 64-bit compile, as it started to produce warnings for assigning pointers to not-large-enough integers.

However, using "gcc -O2" there seems no speed difference between the 32-bit and 64-bit versions. (One took 6.98 sec to reach depth 15, the other 6.91, which is within the noise.) Best results I got for a 32-bit compile with

gcc -O3 -s -fomit-frame-pointer shokidoki.c -o sdk.exe

In that case the time needed to reach depth 15 dropped to 5.55 sec. Strange enough -O3 in stead of -O2 had no effect on the 64-bit compiles, while using -fomit-frame-pointer increased thetime to 7.52 sec!

This is a bit disappointing, as I had hoped there could be some speed advantage in using the larger register set of the x64 architecture. I guess my coding style is such that the standard set of x386 registers is fully sufficient to produce optimal code, the high-level program already avoiding bottle-necks that extra registers could solve.

But it is good to know that for now I can stick to 32-bit compiles.

Btw, it seems that installing the x64 mingw stuff on Cygwin did as a side effect upgrade my 32-bit gcc there from version 3.4.3 to version 4.5.3. It is this new version that refuses the -mno-cygwin flag.

[diep]

Yes you can make 64-bit binaries with cygwin. Confusing part is that you have to use "x86_64-w64-mingw32-gcc.exe" instead of "gcc". I.e.:

With x86_64-w64-mingw32-gcc.exe there is no need for cygwin anymore as x86_64-w64-mingw32-gcc.exe already compiles directly from DOS command prompt box in windoze.

[rvida]

PS: As pointed out by Michel, it is far easier to compile the Windows binary using Linux than using DOS.

Using _DOS_ it would be hard indeed. AFAIK the only DOS port of gcc was djgpp which did not target Win32/64 platforms.

[Tom Likens]

You need to download & install a 64bit enabled version (obviously). I use this one:

http://sourceforge.net/projects/tdm-gcc ... e/download

It produces 64bit executables right out of the box. You can still build a 32bit binary if you specify -m32 command line parameter.

Have you been able to successfully create a PGO-optimized executable with the Windows version of MingW?

--tom

Actually, I answered my own question. PGO works fine under Windows for MinGW.
It gives a reasonable 4-5% speedup. I still can't really get it to work right under
Linux though when I cross compile for Windows.

[Kirill Kryukov]

With x86_64-w64-mingw32-gcc.exe there is no need for cygwin anymore as x86_64-w64-mingw32-gcc.exe already compiles directly from DOS command prompt box in windoze.

I agree, in a sense that cygwin shell is not needed. At least personally I never use it, when I need to run any cygwin's binary I do so from other shells or scripts.

What I like in cygwin though is the installer (setup.exe) as it allows to semi-automatically keep the whole thing up-to-date. It would be even more useful if they could port everything to 64-bit, and include more recent GCC.

[Don]

In my experience it is far more convenient to make 64bit windows binaries by cross-compiling in Linux rather that doing it in Windows itself.

I make all my windows binaries in Linux using mingw. What H.G. wants is Mingw not cygwin.

But I have also done compiles with Mingw for windows. For some reason it has always been a little tricky getting everything set up -but once you do it works great.

[lucasart]

PS: As pointed out by Michel, it is far easier to compile the Windows binary using Linux than using DOS.

Using _DOS_ it would be hard indeed. AFAIK the only DOS port of gcc was djgpp which did not target Win32/64 platforms.

Sorry, I meant the Windows command line (cmd.exe).

[Don]

You need to download & install a 64bit enabled version (obviously). I use this one:

http://sourceforge.net/projects/tdm-gcc ... e/download

It produces 64bit executables right out of the box. You can still build a 32bit binary if you specify -m32 command line parameter.

Have you been able to successfully create a PGO-optimized executable with the Windows version of MingW?

--tom

Actually, I answered my own question. PGO works fine under Windows for MinGW.
It gives a reasonable 4-5% speedup. I still can't really get it to work right under
Linux though when I cross compile for Windows.

The way I did it was a big surprise but works. Build the linux version first, then profile it. Use the profile created from the linux version to compile the windows version with.

To may amazement this produces much faster windows binaries. I never tried profiling the binary by running it in wine - that might work too. How did you do the profile and PGO?

Don

[Tom Likens]

The way I did it was a big surprise but works. Build the linux version first, then profile it. Use the profile created from the linux version to compile the windows version with.

To may amazement this produces much faster windows binaries. I never tried profiling the binary by running it in wine - that might work too. How did you do the profile and PGO?

Don

Hello Don,

It's amazing how these things vary from program to program. I tried your method first, (i.e. generate a Linux profile version, run it to create the .gcda files, then build a Windows version utilizing the profile data). But, it didn't really work for me. It found most of the files, but it also complained that the source locations for a number of functions had changed. A typical example:

Code: Select all

/proj/mingw-w64/mingw-w64-x86_64/bin/x86_64-w64-mingw32-g++ -DX86_64 -DFAST -m64 -Ofast -fno-rtti -fno-exceptions -fomit-frame-pointer -march=k8 -mtune=generic -static -fprofile-use -fprofile-dir=/proj/djinn/build/profile -Wall -W -Wno-sign-compare -Wno-error=coverage-mismatch -Wno-coverage-mismatch -I../src/engine -I../src/console -I../src/lib -I../src/chant -c ../src/console/runepd.cpp
../src/console/runepd.cpp: In function ‘void __gnu_cxx::new_allocator<_Tp>::construct(__gnu_cxx::new_allocator<_Tp>::pointer, const _Tp&) [with _Tp = epd_t; __gnu_cxx::new_allocator<_Tp>::pointer = epd_t*]’:
../src/console/runepd.cpp:1258:1: warning: source locations for function ‘_ZN9__gnu_cxx13new_allocatorI5epd_tE9constructEPS1_RKS1_.isra.43’ have changed, the profile data may be out of date [enabled by default]

And while it built the binary, it was actually slower than just building it without using PGO. Almost all the functions it complained about were inline functions, so the problem may be that the Window's compile is treating the inline functions differently (I haven't dug into this too deeply yet).

So anyway, what I did for the latest Window 64 compile was to install MinGW64 on my one dual-boot windows machine. I hated doing this as I'm a Unix guy through and through, but, it worked. And even better PGO worked without any problems, so for now this is the interim solution until I can track down *exactly* what's going wrong with my PGO run when I cross-compile in Linux.

regards,
--tom