[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::decc

Title:	DECC
Notice:	General DEC C discussions
Moderator:	TLE::D_SMITHNTE

Created:	Fri Nov 13 1992
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	2212
Total number of notes:	11045

2148.0. "Looking for parallel C code" by DECC::VOGEL () Wed Apr 09 1997 22:35

    As part of Digital's effort to return to leadership in the 
    high-performance technical market, we have been adding multiprocessing 
    directives to the DEC C compiler for Digital UNIX.  These are directives 
    which allow the programmer to write code which can run concurrently on 
    multiple processors without restructuring/rewriting the basic
    sequential C source code that embodies the algorithm.  E.g. directives
    identify loops to have their iterations performed in parallel without
    changing the ANSI C language "for" loop or its body as they appear in
    the sequential implemention. We expect that correct use of these directives 
    could greatly improve the run-time performance of certain kinds of 
    applications by allowing that code to execute simultaneously on different 
    processors of a multi-processor machine.  The directives are new 
    #pragmas which are  modeled after the #pragmas available in SGI's Power C 
    compiler which in turn, are modeled after the unfinished work of the 
    ANSI X3H5 committee which attempted to standardize a model of directed 
    parallel decomposition for both C and Fortran a few years back.

    We hope to make an early field test compiler available soon.
    We are currently looking for "real world" test programs we could
    use to test the compiler and run-time system.  Ideally these
    would be C source programs containing SGI's Power C directives
    which would also run on Digital UNIX.  We would also accept source 
    programs that run on Digital UNIX that might be good candidates
    for parallelization - that is, we could easily identify sections
    of code which could be run in parallel, and we could insert the
    directives ourselves.  At this point in time, we are only talking
    about a compiler that processes the directives and generates code
    that would work with a supplied field test run-time library.  We are
    not currently talking about automatically parallelizing sequential
    code or providing other analysis or debugging tools directly supporting
    this kind of code.

    If the source code is very small, it could be posted as a reply.
    If it is larger, a pointer to it could be posted, or mailed to me.

    We are also looking for potential internal field test sites.  
    Internal sites can contact me or post a reply here.

    We do have a working draft of a product spec for the new #pragmas 
    available.  Please contact me if you are interested.

						Thank you,

						Ed Vogel
						DEC C Engineering



    Cross-posted in DECC, DIGITAL_UNIX and KAP_USERS

T.R	Title	User	Personal Name	Date	Lines
2148.1	DECthreads (Kernel Threads?) on OpenVMS?	XDELTA::HOFFMAN	Steve, OpenVMS Engineering	`Thu Apr 10 1997 14:25`	2
	Dare I ask if (when?) DEC C might start using OpenVMS kernel threads?
2148.2	Ask the C and Fortran PMs	DECCXL::OUELLETTE	temerity time	`Thu Apr 10 1997 20:20`	3
	No plans yet in GEM ... per the engineering manager. For them it's purely a business descision & so any information about demand for it should be routed at product management.
2148.3	and we have KAP for now	DECCXL::OUELLETTE	temerity time	`Thu Apr 10 1997 20:32`	7
	Also... There is nothing in the implementation within the compiler that would prevent it from moving to VMS (so I've been told). Yes, the LIBOTS3 would need to be provided on VMS, and the tuning and testing would be the larger effort.
2148.4	Compiler doesn't care, but users might	WIBBIN::NOYCE	Pulling weeds, pickin' stones	`Fri Apr 11 1997 08:57`	3
	Actually there is one feature that VMS is missing. If you want to have thread-local static data (or, in FORTRAN, thread-local COMMON blocks), we would want some help from the OS.
2148.5	A test program and a question	TAV02::GLASS	Yossi Glass, 882-3254	`Wed Apr 16 1997 13:33`	17
	A silly question, and a pointer to a customer's test program (molecular modeling code) is attached: Question -------- So, what will be the difference between using KAP directives and using DEC Parallel C, in the quality of \|\|ization: in other words, if somebody is using KAP directives today, why would he start using DEC C parallel directives? Test Program ------------ The test program may be found in KAP-USERS note 365. Thx, Y.
2148.6	Choosing KAPC or the parallelization pragmas	GEMGRP::CRAIG	Plan, lead, and deliver	`Wed Apr 16 1997 18:28`	41
	The parallel C compiler consists of DECC with pragmas that allow the user to tell the compiler what pieces of their program to run in parallel. Our implementation of these pragmas is substantially identical to SGI's Power C. KAPC provides automatic parallelization. This means that KAPC does the job automatically, and takes responsibility for getting the same answer as the original serial program. What the pragmas provide is manual decomposition. This means that the programmer directly tells the compiler that specified pieces of code MUST be executed in parallel, and the user takes responsibility for determining that the program will give the correct answers when executed in parallel. Basically the pragmas are for users that want to specify in their source code what will be executed in parallel. Often they would do this because automatic parallelization failed, but they may also prefer the pragmas because they document what is expected to run in parallel, or because they prefer not to buy and/or depend upon KAPC. The other difference is that the pragmas allow control over some details that KAPC does not. For example, if a loop is to be executed in parallel, the pragmas allow the user to specify different methods for assigning iterations of the loop to the threads that will execute them. KAPC uses a simple method for assigning iterations to threads that works well for most loops. But if the user knows that different iterations of a loop take very different lengths of time to execute, then they can improve performance by specifying a dynamic method for assigning iterations that gives better load balancing. Finally, the pragmas allow the user to specify arbitrary blocks of code to be executed in parallel. KAPC will only consider executing iterations of a loop in parallel. By the way: the parallelization pragmas are not currently supported or even announced. This information should be considered Digital Confiential. However, our implementation is pretty far along, and with a proper nondisclosure agreement signed, we can talk about these features with customers.