Phronix does another speed test

Compiler Benchmarks Of GCC, LLVM-GCC, DragonEgg, Clang - Phoronix as
of version 2.8, LLVM is generating slower code than the newer GCCs but generates
the code more quickly.

There has not been much analysis apart from John-the-ripper issue (it's a scheduler deficiency). It would be nice if people can analyze the individual tests and file detailed bugs.

Evan

I would be more concerned about the 'unable to compile', or 'compiled
code not working correctly' issues. It would help if they filed bugs.

I don't know what is wrong with the BYTE benchmark for example, I
thought its part of the LLVM test suite.

Best regards,
--Edwin

Hi Edwin,

Compiler Benchmarks Of GCC, LLVM-GCC, DragonEgg, Clang - Phoronix
as of version 2.8, LLVM is generating slower code than the newer GCCs
but generates the code more quickly.

I would be more concerned about the 'unable to compile', or 'compiled
code not working correctly' issues. It would help if they filed bugs.

I analysed the dragonegg compile failures. The graphicsmagick,
imagemagick, lame and x264 failures were all failures to link,
due undefined references to builtin_lfoor and/or builtin_lceil.
Recent gcc turns calls to floor/ceil followed by a cast to long
or long long into a call to an lfloor/lceil builtin. These were
not being recognised by dragonegg, so were just being passed on
as is, resulting in the link failures. I just added support for
these builtins and now all of the above programs compile on x86-64
linux.

All of the remaining failures (crafty, libgcrypt11 and openssl) were
due to using FD_ZERO which on some linux systems like mine uses a rather
bogus inline asm which dragonegg rejects:
   error: unsupported inline asm: input constraint with a matching output constraint of incompatible type!
The reason that this is not seen with llvm-gcc is that llvm-gcc uses
a fix-includes to correct the definition of FD_ZERO. Adding support for
this kind of funky asm is PR3373. It was done already in clang, but not
yet in llvm-gcc or dragonegg.

Ciao,

Duncan.

Compiler Benchmarks Of GCC, LLVM-GCC, DragonEgg, Clang - Phoronix
as of version 2.8, LLVM is generating slower code than the newer GCCs
but generates the code more quickly.

I would be more concerned about the 'unable to compile', or 'compiled
code not working correctly' issues. It would help if they filed bugs.

It is claimed that the Byte Unix benchmarks compile with llvm-gcc but do not work. They built and worked fine for me with TOT on Darwin X86-64. (I could not find version 3.6; 3.11 is in common use, and has been since at least 2003. There are some comments in the code that call it 3.6, however, and others [dated 1991] that call it 3.9, so I think we're talking about the same thing. But maybe not.)

It's also claimed they don't build with Clang. This is true:

./src/hanoi.c:65:3: error: non-void function 'mov' should return a value
      [-Wreturn-type]
                return;
                ^
The function in question is logically void but is declared without a return type (thus implicit int), a style that was common pre-C89 but is now rare. It's clearly legal in both C89 and C99, but last time this came up there was sentiment that rejecting it anyway was the best thing for users. Whatever you think of that, it means we can't build this benchmark.

Now that I've hunted a little harder in the Phoronix site, I see they do have a downloadable copy of the benchmarks:

Their harness, unfortunately, is GPL3, which means I can't use it.