360 likes | 465 Views
OpenTS for Windows Compute Cluster Server. Overview. Introduction OpenTS (academic) for Windows CCS T-converter T-microkernel OpenTS installer Building T++ applications OpenTS SDK User documentation Demo applications Conclusion Proposals for the next step. Introduction.
E N D
Overview • Introduction • OpenTS (academic) for Windows CCS • T-converter • T-microkernel • OpenTS installer • Building T++ applications • OpenTS SDK • User documentation • Demo applications • Conclusion • Proposals for the next step
Porting OpenTS parallel programming system to Windows Compute Cluster Server Platform • Goals: • to port academic OpenTS version under Windows • to develop a number of test applications (demos, test suite) • Duration: • 10 months: 01.2006—10.2006 • Over and Above the Plan: • Integration with Visual Studio 2005 • T-converter improvements • Auto C call support • Out of scope: • some features of the OpenTS were not included into academic OpenTS for Windows CCS
OpenTS (academic)for Windows CCS • OpenTS for Windows includes: • T-converter • T-microkernel • Installer for Windows • Software development kit • Integration with Visual Studio 2005 • User documentation and T++ language reference • Demo applications
T-converter • Ported onWindows • Based on OpenC++ • Updated for support ofVisual C++ special language constructions • Updated for proper support of: • “new” declaration: • int tptr p = new tval int [n]; • template classes: • vector<tval int> fa;
T-microkernel • Platform Abstraction Layer (PAL) developed: • contains system-related calls of WinAPI and POSIX interfaces • provides multiplatform OpenTS kernel code • Assembler code was rewritten to support fast context switching under Windows on AMD64 andx86 hardware platforms
OpenTS installer • InstallsCompute Cluster Pack SDK if it was not already installed • Integrates OpenTS with Visual Studio 2005 • Automatically testsOpenTS operability • Uninstalls OpenTS if it was not installed properly • Based on Nullsoft Scriptable Installation System (NSIS)
Building T++ applicationsfrom command line • Using command line: • t++ [options] [srcfile1 …srcfileN] • Options are: • /auto-c-call - allows T-application to call C-versions of T-functions. This may increase T-application productivity • /c - only compilation of source files without linking • /dbg - make debug build. It allows debugger to obtain information about program symbols in the case of application crush • /do - specify location for object files • /not - build application in sequential mode, all T++ keywords are ignored • /o - specify output executable • /p - pass option to used C/C++ compiler • /v - print commands before invocation
Building T++ applicationsin Visual Studio 2005 IDE A new item in “New Project” dialog: OpenTS Console Application A new item in “Add New Item” dialog: T++ File
OpenTS Software Development Kit • Can be installed independently • Contains OpenTS kernel source code • Allows development of extensions to OpenTS • Contains VS2005 project files for building of: • T++ runtime library • Fast context-switching library • T-applications execution tracer • Several simple T-applications • Created with NSIS
Demo applications written in T++ • POVRay and ALCMD were ported to Windows • A benchmark testing was made to prove the correctness of Windows OpenTS port • Both Windows and Linux were used in testing • Same hardware platform used: AMD64 • Same OpenTS kernel source code used (so-called cross-platform version of microkernel) • Same applications’ (POVRay and ALCMD) source code used for Windows and Linux
Benchmark notations • time(N) — execution time of T++ implementation that depends on a number N of processors used in test run (in seconds) • time_c — execution time of C implementation (in seconds, one processor used in test run) • time%(N) = time(N) / time_c • CoE = 1 / (N * time%(N)) — coefficient of efficiency
Sync/Async problem • Problem: CoE for POVRay is decreasing heavily under Windows • Reason: there is no support for asynchronous interaction between processes
Sync/Async conclusion • It is reasonable to implement asynchronous mode during the next project due to T-applications performance loss under Windows
Benchmark results • For POVRay: • its time is at the maximum only 12% greater than under Linux • its CoE is at the maximum only 14% less than under Linux • For ALCMD: • its time (in %) is always roughly the same as time under Linux • its CoE sometimes greater by 21% than under Linux
Conclusion • All planned goals are achieved • The work is done for the current project • There are good prospects for the further cooperation
Proposals for thenext step • Asynchronous support • SMP mode • T-program trace visualizer • Generating web-services for T-functions • DMPI support • Fault tolerance for T++ applications • Different schedulers • In future: OpenTS/.NET — T#
Thanks! … … Any questions? … …