MLucas on IBM Mainframe

[ewmayer]

Originally Posted by Batalov

How about this (in get_fft_radices.c, lines 1443-1446):

                case 7 :
                        numrad = 6; rvec[0] = 16; rvec[1] =  8; rvec[2] =  8; rvec[3] =  8; rvec[4] =  8; rvec[5] = 16; break;
          #ifndef USE_ONLY_LARGE_LEAD_RADICES
                case 7 :
                        numrad = 5; rvec[0] =  8; rvec[1] = 16; rvec[2] = 16; rvec[3] = 32; rvec[4] = 16; break;

[linux1@rhel7-3 build]$ gcc -Os ../src/get_fft_radices.c
../src/get_fft_radices.c: In function ‘get_fft_radices’:
../src/get_fft_radices.c:1446:3: error: duplicate case value
   case 7 :
   ^
../src/get_fft_radices.c:1443:3: error: previously used here
   case 7 :
   ^

Their gcc compiler is a bit stricter than on x86_64 (I've built it before -- no problems were reported, only warnings).

Yes, that bug in the unthreaded scalar-C builds has been fixed in my dev-branch code, users who run into it should just 'do the needful' in their local copy of the file.

A bit later (in TRICKY section)

../src/util.c: In function ‘print_host_info’:
../src/util.c:1071:106: error: ‘OS_BITS’ undeclared (first use in this function)

so add -DOS_BITS=64 to the compiler line.

After polishing these two little blemishes, runs like a clock.

As long as it's a 64-bit OS - that would be 'yes' - your hack is fine. Note OS_BITS is set (or better, attempted-to-set) in platform.h - you can turn on a bunch of diagnostics for that file by adding -DPLATFORM_DEBUG to your compile command, say for just a single tiny source file like br.c.

[alexvong1995]

I managed to set up a s390x chroot! So I don't need to rely on QEMU image anymore (They are pretty hard to find and make). I can now build a "fresh" debian rootfs from scratch.

For curious people, this is how it is done (the following commands need root privilege):

# apt-get install binfmt-support qemu qemu-user-static

Then, manually download debootstrap and install it by

# dpkg -i debootstrap_1.0.73~bpo8+1_all.deb

Note we cannot install the latest version because it has a bug which prevents the two-stage bootstrap from working. (It takes me a looong time to figure this out, the error message isn't so obvious.)

qemu-debootstrap --arch=s390x --include=emacs-nox,less,build-essential,autogen --variant=buildd sid debian-s390x

and we are done! You can now chroot into the chroot. This should works for any architecture that is supported by QEMU user mode emulation. In particular, armel (used by your phone) is supported.

[Batalov]

I dropped my compilation yesterday, but today I tried some more...

#define COMPILER_TYPE_GCC 1

in ../src/platform.h

And Bob's your mother's closest living relative or something like that...

[ewmayer]

OK, I got both un-and-multithreaded builds (all manual compile and link) to work, via the following hacks to platform.h:

o Got rid of these undefs at top - these (duh!) make it impossible for use of PLATFORM_DEBUG as intended, no clue WTF I was thinking with these undefs:

#undef PLATFORM_DEBUG
#undef OS_DEBUG
#undef OS_BITS_DEBUG
#undef CPU_DEBUG
#undef CMPLR_DEBUG

o Instead of initially undefing the following 3 things I now init them to 'unknown' (the not-defined CPU_NAME was hosing the util.c compile):

#define CPU_TYPE "Unknown CPU type"
#define CPU_NAME "Unknown CPU name"
#define CPU_SUBTYPE_NAME "Unknown CPU subtype"

o Changed

#ifndef CPU_TYPE
#error platform.h : CPU_TYPE not defined!
#endif

to a #warning. (OS_TYPE and COMPILER_TYPE are still required to be defined during preprocessing of the platform.h file, though.)

o Added a #elif for the case of Unknown hardware platform, but under Linux/GCC.

Fiddled version of the header attached. I only did a pair of quick spot-checks of the 2 binaries @FFT length 128K via './Mlucas -fftlen 128 -iters 100' in each of my 2 build dirs (one for unthreaded, one with pthreading). All the normal Linux thread-affinity stuff seems to be working, though no clue how much || scaling one can expect in these puny guest-accounts. (My virtual setup shows just 2 cores.)

[alexvong1995]

Hi Ernst,

I have added 2 new CPU_TYPE CPU_IS_S390 and CPU_IS_S390X to platform.h, does it passes the spot-check and self-test on your VM? The platform.h I use is the old one on my repo, not the one you have just posted . I will rebase my change on the latest platform.h if it works.

By the way, could you post the latest version of get_fft_radices.c on your dev branch? I think I run into the duplicate case problem reported by Batalov when building with singlethread.

Thanks people!

[ewmayer]

Hi, Alex - I will diff your platform.h and try it on the Cloud when I'm home later today and have a secure connection.

Being paranoid I manage my dev-branch code privately, so here is the current version of the file you asked for - should be a drop-in replacement (md5 of the *gz = db5d2504d58897229d0366f4749b4131):

[ewmayer]

Also, do we have any easy way of determining what underlying compute hardware is being used, or is the whole point of the 'generic' cloud setup to obfuscate that?

My gcc predefines-dump shows no obvious clues to the CPU type.

[ewmayer]

Originally Posted by alexvong1995

Hi Ernst,

I have added 2 new CPU_TYPE CPU_IS_S390 and CPU_IS_S390X to platform.h, does it passes the spot-check and self-test on your VM? The platform.h I use is the old one on my repo, not the one you have just posted . I will rebase my change on the latest platform.h if it works.

By the way, could you post the latest version of get_fft_radices.c on your dev branch? I think I run into the duplicate case problem reported by Batalov when building with singlethread.

Thanks people!

Alex, I integrated your additions into my latest, and also made a few tweaks to my yesterday work - the 3 predefines to "Unknown" (in place of the previous #undef) I used lead to preprocessor warnings on platforms where the variables do end being set to a specific platform-associated value:

../platform.h:1222:10: warning: 'CPU_NAME' macro redefined
        #define CPU_NAME "x86_64"
                ^
../platform.h:130:9: note: previous definition is here
#define CPU_NAME                        "Unknown CPU name"

so I fiddled those to set to the "unknown" values only if they are still undef'd by the time we reach the end of the platform.h file.

But note I fubared my key-creation on the cloud, so to save time was using Serge's already-setup image with his unzip of the 14.1 packaged code. He has since blown his stuff away. If your instance is still up, could you try auto-build with the merged platform.h file attached below?

Thanks, and happy lunar new year! I guess the celebrations have already started in Asia. (Or will within the next few hours.)

[Lorenzo]

After i replaced platform.h:

[linux1@lorenzoibm mlucas-14.1]$ ./mlucas

    Mlucas 14.1

    http://hogranch.com/mayer/README.html

INFO: testing qfloat routines...
CPU Family = S390x, OS = Linux, 64-bit Version, compiled with Gnu C [or other compatible], Version 4.8.5 20150623 (Red Hat 4.8.5-4).
INFO: Using inline-macro form of MUL_LOHI64.
INFO: MLUCAS_PATH is set to ""
INFO: using 53-bit-significand form of floating-double rounding constant for scalar-mode DNINT emulation. 
INFO: testing IMUL routines...
INFO: System has 2 available processor cores.
INFO: testing FFT radix tables...
 looking for number of threads to use in nthreads.ini file...
Using NTHREADS = #CPUs = 2.
 looking for worktodo.ini file...
 worktodo.ini file found...checking next exponent in range...
ERROR: at line 245 of file ./src/get_preferred_fft_radix.c
Assertion failed: CONFIGFILE = mlucas.cfg: open failed!

[Lorenzo]

Ohhh.Sorry. It's working!!! Amazing!!!
P.S. Forgot about perfomance tunes (mlucas -s m).

[ET_]

Originally Posted by Lorenzo

Ohhh.Sorry. It's working!!! Amazing!!!
P.S. Forgot about perfomance tunes (mlucas -s m).

Can you tell us anything about its performances? I guess it's running with 2 threads...

Luigi