Feb 152017
 

GCC on CygWin logoStill using my aging XP x64, I recently tried to compile a newer version of the GNU compiler collection (GCC) on my equally aging installation of [CygWin], v1.7.35(0.287/5/3). Reason is that I can no longer update CygWin itself, because the project did away with NT5.x compatibility, so now you need Windows Vista or 7 for the latest version. Given that CygWin uses a rolling release model, you can’t get any “in between” versions later on. Also, despite my best efforts to make use of the great work of Peter Castros’ [CygWin Timemachine], I still haven’t managed to get a later version of CygWin that still supports XP. The later versions all have some kind of massive problem with the bash/sh permanently crashing and coredumping. No idea what the reason is.

And even if it would work, I’d still be stuck with GCC 5.3.0 or 5.4.0 or something. It’s not that I absolutely need a fresh C/C++ compiler right now, but it’s good to be prepared, especially when it comes to the adoption of modern C++ standards. Since I’m doing my own Windows builds of libav and ffmpeg (also: For a new x265-based benchmark project similar to my old [x264 benchmark]), I wanted to be able to use a current version.

On Linux and BSD UNIX, compiling and using a new version of GCC is surprisingly simple! On CygWin however, it bombed for me trying to build the JNI (Java Native Interface), and after disabling it, it stumbled over some mysteriously missing files while I was following [this guide].

Luckily, a commenter named Joaquin provided a [solution] for this: CygWin seems to be missing some prerequisites that need to be downloaded. A script for doing that is included in the ./contrib/ folder of the unpacked GCC source tree, ./contrib/download_prerequisites! Let’s have a look inside:

  1. # Download some prerequisites needed by gcc.
  2. # Run this from the top level of the gcc source tree and the gcc
  3. # build will do the right thing.

Sounds useful… and:

  1. # Necessary to build GCC.
  2. MPFR=mpfr-2.4.2
  3. GMP=gmp-4.3.2
  4. MPC=mpc-0.8.1

Aha! So we’re missing “mpfr”, “gmp” and “mpc”. [mpfr] is a floating-point math library, [gmp] is another arithmetic library, and [mpc]… well, a math library as well. I have no idea why my CygWin would be missing those, or maybe it just doesn’t have the required versions? Uhm, and the following:

  1. # Necessary to build GCC with the Graphite loop optimizations.
  2. if [ "$GRAPHITE_LOOP_OPT" = "yes" ] ; then
  3.   ISL=isl-0.15

[ISL] is optional, but I guess it’s useful? I’m not actually sure what it really does though. Whatever it is, just call that helper script before the configuration stage, and everything should be fine. While sitting inside the root of the unpacked source tree, for GCC version 6.3.0 in my case (make SURE to choose a --program-suffix, or installation might effectively annihilate your platform compiler!), do something like this on your CygWin terminal:

./contrib/download_prerequisites
./configure --program-suffix=-6.3.0 --enable-languages=c,c++ --disable-shared 
make -j12
make install

I’m limiting myself to C/C++ here. I don’t need Fortran (I think) and the JNI component of the Java stuff breaks on CygWin anyway, so we’ll leave Java out. Also, we’ll have no link-time optimization (lto), but the important stuff will be there. The C++ shared library is disabled and I built the thing with -j12 to spawn 12 threads (or is it processes?) for speeding up the build, since I have 12 logical CPUs.

And that’s it!

To test things, I recompiled ffmpeg-3.2.4 with the new GCC 6.3.0 + yasm 1.3.0, and everything turned out just fine after rolling out the resulting ffmpeg.exe including some necessary CygWin libraries (cygwin1.dll and cygiconv-2.dll):

.\ffmpeg.exe -version | find /V "configuration"
ffmpeg version 3.2.4 Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 6.3.0 (GCC)
libavutil      55. 34.101 / 55. 34.101
libavcodec     57. 64.101 / 57. 64.101
libavformat    57. 56.101 / 57. 56.101
libavdevice    57.  1.100 / 57.  1.100
libavfilter     6. 65.100 /  6. 65.100
libswscale      4.  2.100 /  4.  2.100
libswresample   2.  3.100 /  2.  3.100
libpostproc    54.  1.100 / 54.  1.100

A quick test showed the ffmpeg binary can cleanly decode H.265/HEVC video and also other stuff like FLAC, so it’s looking good! :)

May 102012
 

I have tested an sgi Altix 350 shared memory cluster with 10 Intel Itanium² CPUs once, running the [x264 benchmark] on it, and here’s another. Prof. Ludwig and Mr. Otto from the [Chair of Simulation and Modelling of Metallurgic Processes] (SMMP) at the University of Leoben have agreed to let me benchmark their even larger Altix 350 with 16 processors. Now while I have already done that successfully using the GNU C compiler (GCC), performance was a little bit sub-par and rather unsatisfactory, only slightly faster than its smaller counterpart, here [the filtered result]. Now on the previous sgi Altix machine I had access to the rather hairy ICC 10.1, the Intel C/C++ compiler. It did give around 10% performance boost back then after I finally managed to build x264 with it, so I wanted to try that once again.

Unfortunately, it’s not so easy to get access to ICC. The newest version 12.0 is not available for the IA64 (Itanium) architecture anymore, and you can’t even get to a proper trial license generator for Linux on Itanium. The latest version for Itanium is 11.1.080. Even the download is almost impossible to locate by regular means on Intels website, you can get it after logging in to [registrationcenter.intel.com] if you know what you’re looking for and have an ICC 12.0 trial license tied to that account already. So after some support emailing I registered at [premier.intel.com] (You get a link for that when downloading the regular ICC 12.0 trial for x86). There I opened a support ticket to get a proper trial license.

The supportsperson did his best to generate a license for me, but the compiler installer just wouldn’t accept them. In the end he found that he does not have the proper tools anymore to generate valid IA64 licenses, so he forwarded the issue to internal registration and license management within Intel. He said, they have to have the proper set up to still generate a valid trial serial number / license for Linux on Itanium.

There you see, the Itanium ship seems to really be sinking if you can’t even get any Intel software trials for it anymore. I still hope I can get the 11.1 compiler working as that would be probably the best Itanium² result we’re ever going to see from that kind of IA64 shared memory cluster platform.

Feb 092012
 

Silicon Graphics Altix 350After doing some testing on the Intel C compiler (ICC) and also compilation of libav/x264 without root privileges, I finally got access to the real deal! For that, my thanks go to Prof. Supancic and Mr. Flicker from the [Institute for Structural and Functional Ceramics] at the University of Leoben.

So, the machine: A Silicon Graphics Altix 350, equipped with 5 modules with 2 processors each. That makes for a total of 10 Intel “Madison” Itanium² processors clocked at 1.5GHz and packed with 4MB cache each. The memory subsystem consists of 56GB Reg. ECC DDR-I/333 memory and the storage backend is SCSI. The entire machine consumes roughly 5000W of power and runs on SuSE Linux Enterprise Server or SLES, version 10.

So much for the specification mumbo jumbo, for an idea how a fully packed Altix 350 half-height rack would look like, see the thumbnail picture. Yes, it’s big. So, was it easy to get x264 to work? Well, nah-ah, it wasn’t. Continue reading »