Technical Approaches for Babel to Support Microsoft and Cost/Effort Ramifications

1. Gary Kumfert Technical Approaches for Babel to Support Microsoft and Cost/Effort Ramifications Lawrence Livermore National Laboratory, P. O. Box 808, Livermore, CA 94551 This work performed under the auspices of the U.S. Department of Energy by Lawrence Livermore National Laboratory under Contract DE-AC52-07NA27344 UCRL-PRES-403107

2. We don’t have a Science customer demanding Windows. But Industry loses interest without any Windows support. • Their interest is “Blue-Collar Supercomputing” • Windows on desktop w/ cluster in back room • Interoperability in pure Windows environ is already met with Microsoft .NET/CLR technology • Interoperability with everything-but-Windows doesn’t solve their problem of interest

3. Pure Cygwin Cygwin hosted cross-compile SUA (fka SFU fka Interix) Visual Studio Project Files CMAKE nmake 1 time costs (e.g. adding code) augmenting scripts indirection in system layers (pthreads, BSDsockets -> winsock, locks, etc.) filesystem separate build system sustained costs testing & maintenance separate build system licensing issues Possible Approaches & Types of Cost

4. Sources.redhat.com/cygwin Linux emulation layer on top of Win32 Supports everything (32 & 64 bits) except WinCE Win95, 98, & Me will be discontinued soon. Robust package manager 1083 packages src and binaries any version thereof Can leverage existing build Can leverage existing code Speed cygwin1.dll is not lightweight Licensing issues cygwin.dll is GPL Red Hat exempts other OSI-compliant codes from infection Red Hat sells exemption licenses otherwise Pure Cygwin About Downsides

5. MinGW.org – Minimalist GNU for Windows GCC cross compiler MinGW runtime is public domain Can leverage existing build Website is under construction Wedded to GCC-3.4.x? a bit old Fortran 90? 64-bit apps? Different system API Cygwin hosted cross compile MinGW About Downsides

6. SUA (fka SFU fka Interix) About • Microsoft purchased technology • SUA = Subsystem for UNIX-based Applications • SFU = Services For UNIX • Peer to Win32 kernel, not an emulation layer • Crossover technology allows SUA and Win32 to interoperate • NEW for Server 2008, Server 2003R2 & Vista • Can leverage existing build • Can leverage existing code

7. Microsoft purchased technology SUA = Subsystem for UNIX-based Applications SFU = Services For UNIX Peer to Win32 kernel, not an emulation layer Crossover technology allows SUA and Win32 to interoperate NEW for Server 2008, Server 2003R2 & Vista Can leverage existing build Can leverage existing code Package manager is horrible% get no_such_thinggetting no_such_thing…done Vitality of effort is questionable < 200 packages many packages appear stale development is offshored Could not reproduce progress reported over phone by SUA expert SUA (fka SFU fka Interix) About Downsides

8. Microsoft gives away basic compilers Vocabulary Product: similar to make targets like libraries or executables Solution: collection of products Babel’s build has approx 344 libraries 441 driver programs This is BIG by VisualStudio standards Apparently Microsoft’s own Windows and Office groups don’t use VisualStudio They use scripts and nmake Parallel build environment to develop & maintain Visual Studio About Downsides

9. XML-based build tool Similar to ANT? Can be generated by external tools besides Studio Note: Projects at LLNL taking this dual-build approach do exist. Parallel build environment to develop and maintain. Requires new code Visual Studio Project Files About Downsides

10. Generates Makefiles, XCODE, MS Project, KDevelop3 or other files for builds. Replaces all of autotools? BSD License It isn’t its own build system, just generates input files for native build systems. Requires complete rewrite of build system Requires new code Cannot find examples of reported “easy to use configure-like framework” CMake About Downsides

11. Conclusions – If we had a big chunk of cash and time • CMake • Even if it does everything autotools did, we’d still have to rewrite/port/integrate custom assets • 59 custom M4 scripts (over 5000 loc total) • 679 Makefile.am & fragments (44 files > 100 loc) • 154 shell scripts • That’s just the build, we’d still have to virtualize all system API differences

12. Conclusions – If we had a meager but sustained funding • Project Files • Probably stay with autotools and assign someone to do a separate build system for Windows • VisIt folks do this • There’d be no Babel downtime • There’s a inherent synchronization problem between two separate builds

13. Conclusions – If we had any sway with Microsoft • SUA • This would provide the lowest cost option • Lack of vitality (other than blogs and MS propaganda) make this seem very risky • SUA isn’t recognized as critical to Microsoft’s HPC activities (disappointing) • SUA is counter to the Microsoft model • Its all about selling the Windows OS • “If you think moving to Windows is hard, try moving off of it.” –anonymous Microsoft employee

14. Then there are larger design choices • Add a Babel binding for Managed Code? • Should SCL files be converted to Registry? • Cross-platform BabelRMI implementation? • How to export Babel’s build constraints do downstream compilations • UNIX: babel-config, babel-libtool, compiler front-ends