Mlucas problems on Linux Alpha
 

Hi, this is my first post here.
I was trying to run the Mlucas software on a dual Alpha machine running linux

[I]pd@shell bin $ uname -a
Linux shell 2.4.31 #10 SMP Thu Jul 21 14:49:25 CEST 2005 alpha EV67 GNU/Linux[/I]

the first thing I did was downloading the precompiled alpha binary from Ernst Mayer's site: [url]http://www.hogranch.com/mayer/README.html[/url].
Here's where the problems begin:

[I]pd@shell bin $ ls -al Mlucas_alfa
-rwxr-xr-x 1 pd users 1462864 Jan 15 14:10 Mlucas_alfa
pd@shell bin $ Mlucas_alfa
-bash: /home/pd/bin/Mlucas_alfa: cannot execute binary file[/I]

even if the file appears to be a regular linux executable

[I]pd@shell bin $ file Mlucas_alfa
Mlucas_alfa: COFF format alpha executable paged not stripped - version 3.13-14[/I]

so I tried to compile from source instead, and the following errors arose (I'm using the latest sources from the aforementioned site)

[I]pd@shell Mlucas_src $ gcc -O3 *.c -o Mlucas -lm
radix24_ditN_cy_dif1.c:1376:3: warning: no newline at end of file
/tmp/ccIeycj4.o(.text+0x1898): In function `qfmul':
: undefined reference to `__UMULH'
/tmp/ccIeycj4.o(.text+0x18b8): In function `qfmul':
: undefined reference to `__UMULH'
collect2: ld returned 1 exit status[/I]

ps: I don't have the compaq C compiler on this machine.

hopefully somebody here knows what I'm missing (and why the binary refuses to run).

regards,
Paul

[QUOTE=shackan]Hi, this is my first post here.
I was trying to run the Mlucas software on a dual Alpha machine running linux

[I]pd@shell bin $ uname -a
Linux shell 2.4.31 #10 SMP Thu Jul 21 14:49:25 CEST 2005 alpha EV67 GNU/Linux[/I]

the first thing I did was downloading the precompiled alpha binary from Ernst Mayer's site: [url]http://www.hogranch.com/mayer/README.html[/url].
Here's where the problems begin:

[I]pd@shell bin $ ls -al Mlucas_alfa
-rwxr-xr-x 1 pd users 1462864 Jan 15 14:10 Mlucas_alfa
pd@shell bin $ Mlucas_alfa
-bash: /home/pd/bin/Mlucas_alfa: cannot execute binary file[/I]

even if the file appears to be a regular linux executable

[I]pd@shell bin $ file Mlucas_alfa
Mlucas_alfa: COFF format alpha executable paged not stripped - version 3.13-14[/I]

so I tried to compile from source instead, and the following errors arose (I'm using the latest sources from the aforementioned site)

[I]pd@shell Mlucas_src $ gcc -O3 *.c -o Mlucas -lm
radix24_ditN_cy_dif1.c:1376:3: warning: no newline at end of file
/tmp/ccIeycj4.o(.text+0x1898): In function `qfmul':
: undefined reference to `__UMULH'
/tmp/ccIeycj4.o(.text+0x18b8): In function `qfmul':
: undefined reference to `__UMULH'
collect2: ld returned 1 exit status[/I]

ps: I don't have the compaq C compiler on this machine.

hopefully somebody here knows what I'm missing (and why the binary refuses to run).

regards,
Paul[/QUOTE]
Is . in your $PATH ?

What happens if you type "./Mlucas_alfa"

Paul

[QUOTE]
Is . in your $PATH ?
[/QUOTE]

yes

[QUOTE]
What happens if you type "./Mlucas_alfa"
[/QUOTE]

[I]
pd@shell pd $ cd bin
pd@shell bin $ ./Mlucas_alfa
-bash: ./Mlucas_alfa: cannot execute binary file
[/I]

Maybe, administrator has mounted /home with noexec?
But on x86 I get "permission denied" in that case... maybe alpha is different?

>Mlucas_alfa: COFF format alpha executable paged not stripped - version 3.13-14

Does Alpha linux use the COFF format for executables? I thought it'd use ELF... but maybe Tru64 uses COFF. Try the file command on a known good executable, i.e. /bin/ls. If that is ELF, you probably have to compile yourself.

Alex

yes, probably the file format is at fault, but I can't compile it either (read first post).

I did it, it took me a minute to spot an (apparent) mistake in the code, the lines:

[I]
#elif(defined(__GNUC__))
#define UMULH(x, y) \
[/I]

(lines 166-167 of qfloat.c), had to be replaced by

[I]
#elif(defined(__GNUC__))
#define __UMULH(x, y) \
[/I]

I'm going to contact the author to see if the problem lies in my build enviroment or in Mlucas.

happy number crunching to everybody!

[QUOTE=shackan]I did it, it took me a minute to spot an (apparent) mistake in the code, the lines:

[I]
#elif(defined(__GNUC__))
#define UMULH(x, y) \
[/I]

(lines 166-167 of qfloat.c), had to be replaced by

[I]
#elif(defined(__GNUC__))
#define __UMULH(x, y) \
[/I]

I'm going to contact the author to see if the problem lies in my build enviroment or in Mlucas.[/QUOTE]Indeed, it's a bug in the source - I didn't do a gcc build on Alpha/Linux prior to the last source release, since I've never found gcc to do a decent job at generating optimized code. I've made sure the above bug is not present in the code that will go into the Mlucas 3.0 release.

As for your situation, did the code build and run through self-tests (Mlucas -s m) successfully once you patched the above problem? If so, could you post the resulting mlucas.cfg file (just the FFT-length/timing lines at bottom) and your basic system specs? You can compare those data to the ones I give for Alpha on the [url=http://hogranch.com/mayer/README.html#alpha_unix
]README page[/url] to gauge how much performance gcc may be leaving on the table, as it were.

Lastly, if you have any way of getting a 30-day trial license for the DEC/Compaq/HP C compiler I would recommend that, since you're likely to get a much better-performing binary from it.

People more versed in the issue of exe-file formats will have to address that - the prebuilt binaries I posted for Alpha seem to run on most of the major linux distribs, but there are some (BSD, and yours - which distrib are you running, BTW? Your uname -a output doesn't tell me anything about the precise flavor of Linux) that apparently expect a different binary file format.

Thanks for your answer,
self tests worked fine, here are the timings

[QUOTE]
576 0 # sec/iter = 0.113; radices = 9 8 16 16 16
640 0 # sec/iter = 0.127; radices = 5 16 16 16 16
704 0 # sec/iter = 0.160; radices = 11 8 16 16 16
768 0 # sec/iter = 0.150; radices = 6 16 16 16 16
832 0 # sec/iter = 0.192; radices = 13 8 16 16 16
896 0 # sec/iter = 0.187; radices = 7 16 16 16 16
960 0 # sec/iter = 0.214; radices = 15 8 16 16 16
1024 0 # sec/iter = 0.207; radices = 8 8 8 8 8 16
1152 0 # sec/iter = 0.242; radices = 9 8 8 8 8 16
1280 0 # sec/iter = 0.271; radices = 10 8 8 8 8 16
1408 0 # sec/iter = 0.338; radices = 11 8 8 8 8 16
1536 0 # sec/iter = 0.323; radices = 12 8 8 8 8 16
1664 0 # sec/iter = 0.407; radices = 13 8 8 8 8 16
1792 0 # sec/iter = 0.407; radices = 14 8 8 8 8 16
1920 0 # sec/iter = 0.456; radices = 15 8 8 8 8 16
2048 0 # sec/iter = 0.444; radices = 8 8 8 8 16 16
[/QUOTE]

and comparing with your results, the gcc's binary seems TWICE as slow?! Heck I knew gcc wasn't the best at optimizing (caveat: maybe some compiler switch could have helped a bit, I just used a plain '-O3'), but this is really bad, especially considering the hardware setup seems similar..

[CODE]
pd@shell mlucas $ cat /proc/cpuinfo
cpu : Alpha
cpu model : EV67
cpu variation : 7
cpu revision : 0
cpu serial number :
system type : Tsunami
system variation : Catamaran
system revision : 0
system serial number : AY12214322
cycle frequency [Hz] : 666666666
timer frequency [Hz] : 1024.00
page size [bytes] : 8192
phys. address bits : 44
max. addr. space # : 255
BogoMIPS : 1204.44
kernel unaligned acc : 0 (pc=0,va=0)
user unaligned acc : 6 (pc=12001b358,va=11fffbef4)
platform string : COMPAQ AlphaServer DS20E 666 MHz
cpus detected : 2
cpus active : 2
cpu active mask : 0000000000000003
[/CODE]

Maybe your version is using _both_ cpus (and therefore the twofold speed improvement) ? But since Mlucas is not a multithreaded application (afaik), I highly doubt this is the case...

As for the last question this machine runs Gentoo (well, not the best choice if you ask me...) and apparently it refuses to run every executable but ELF-format files. Since it's unlikely for me to get a copy of ccc, what about shipping the binary as an ELF file along with the COFF executable for TruUnix ?

thanks again,
regards

Thanks for the timings, shackan. Actually, the performance of your gcc-built binary is not that bad - since your machine's clock speed is 2/3 that of the 1GHz ev68 I used for the timings on the Mlucas README page, you need to multiply the latter by 1.5 to get a fair comparison. Based on that, your binary is only about 15% slower on a per-cycle basis than the one built using the native C compiler - not bad at all. Note also that in the gcc builds (of this and other floating-point-heavy codes) I've done, I've found nothing that significantly improves on the simple -O3 optimization flag, same as you used. If anyone can suggest other flags they think would help, please let us know.

The DEC C manpages (at least the ones installed on the systems I do my builds on) indicate that COFF is the only available output format for that compiler. I'll look around a bit more online to see if I can find some more information about ELF-format binaries - maybe there's some kind of post-build translation tool available.