Wednesday, 8/Thursday, 9 February, 1995 @ 10.00 am
Mount Royal Hotel, London, W1
The members of the Workig Group present were as follows: Malcolm Rigg - ICL, Peter Dzwig - LPAC, Chairman, Heather Liddell - LPAC, Alistair McEwan - LPAC, Matthew Holford - LPAC, who took the minutes, Jonathan Poole - UCL, Philip Treleaven - UCL, Russel Winder - UCL, Denis Caromel - INRIA, Philippe Mussi - INRIA, Gavan Duffy and Richard Kaufmann of DEC Ltd attended via conference telephone.
Apologies were received from John Barr of Convex, Thomas Bemerl of INTEL and from Graham Roberts of UCL.
PED introduced the meeting and briefly outlined the situation in relation to Bull. PED stated that the aim of the meeting would be to create a specification to pass to the Applications and Implementations SIGs for approval/recommendations. Also to create a roadmap, to revise timescales and to extend and revise membership.
PT announced that he would be relinquishing the chair of the Architecture SIG and that, from that point on, HL would be chairing the group.
RW gave a presentation on UC++. He detailed the method through which UC++ was developed and said that he felt sure that there was little need to change UC++ in the process of making it into EUROPA ||C++. Should UC++ be adopted, it would be necessary for the Architecture SIG to define what sets of libraries were required.
Denis Caromel gave a presentation of the main features of Eiffel//: communication towards a process are syntactically equivalent to a routine call, polymorphism between objects and processes, systematic asynchronous communication between processes (with synchronous communication when needed), wait-by-necessity (automatic future: a process is automatically synchronized when trying to use the result of an asynchronous call, routines and requests are a weak version of first class objects.
At the end-user level, DC stressed the demand for reusability. As it is achieved in Eiffel//, Europa ||C++ should permit the reuse of sequential classes when programming a parallel system. The technique to achieve reuse in OO languages is clearly dynamic binding, and it is likely that we have to use this technique for concurrent programming as well.
At the lowest level of Europa ||C++, DC focussed on the need to manipulate routines, and requests issued to a process as first class objects. This implies the use of reification mechanisms as it is done in Eiffel//.
RW laid out philosophical starting points (see below) at which point PED suggest that these areas were for discussion in due course and guided the meeting towards the development of the roadmap. The contents of the roadmap were outlined (see below). The point was raised that we should identify our consitutents and decide how to approach them from and commercial and technical point of view.
PED detailed the requirements of the EC with regard to the completion of the membership documents. These membership documents would be drafted and distributed as soon as was reasonably possible after the meeting and wre to be completed and returned in similar fashion. Subject to approval, members would be able to draw funds for travel and subsistence.
PED stated that the group should endeavour to contact and subsequently involve the likes of Olivetti and certain divisions within INTEL.
It was argued that it was pointless having further meetings before it was confirmed that major players were going to be looking at parallel languages and getting involved as loss of credibility would result.
RW added that Hewlett Packard and DEC Ltd needed to be brought on board in order for the project to travel to the US. In addition, EUROPA's Architecture SIG would seek links with other C++ groups within the US and the rest of the world.
PED outlined the structure of the Working Group with regard to the Special Interest Groups (SIGs) working within it and their relationship to one another. He went on to detail the workflow relative to this structure (see Aims of SIGs, below).
The EUROPA Working Group on Parallel C++ will define a common, standard parallel C++ with an associated parallel abstract machine model. It will thus create a medium for the rapid prototyping and development of parallel applicaitons in C++ which will be widely portable.
The aim of the Architecture SIG was outlined as being to define the architecture for EUROPA ||C++ in a three-stage process via draft (which will be submitted to the Applications and Implementations SIGs for recommendations), revised and "final" versions.
This group will refine the architecture devised by the Architecture SIG to support real-world applications of the Application SIG's members.
The Implementations SIG will implement the work of both Architecture and Applications SIGs on real delivery systems.
The draft definition, defined by the Architecture SIG, once submitted for recommendations, will be discussed at a plenary meeting to be held in late May/early June, whereupon a draft definition will be presented to the whole world. Recommendations from the Applications SIG and Implementations SIG will be integrated by the implementors and submitted to standards bodies.
UC++ will be promoted as a basis for discussion only, without commitment to making EUROPA ||C++ identical to UC++. UC++ implies a particular model, an alternative model was proposed by INRIA. The following questions were raised.
3.1.1 Should we adopt a type or allocation style (ie a high level or low level approach with regard to semantics?
3.1.2 Given an idustry standard C++, should we add to that basic language (which would require changing the parser) or should we make semantic changes by using a filter (text deitor?) to detect additions to the basic language.
3.1.3 Do we need a kernel library of classes for parallelism or a library for abstraction of concurrency (implicit v explicit programming of processes?). Examples: Communications, queue manipulation, "service" routines. What other additions are required - eg replication, atomic classes.
3.1.4 Should we introduce overloading of functions for synchronous/asynchronous operation?
3.1.5 Should our primary aim be for usability or efficiency (of course, ideally we would want them both)?
3.1.6 Should we adopt a multi-thread or single-thread (quasi-parallel) approach? Note that the former could be built onto the latter but not vice versa.
3.1.7 Should there be a level of automatic mapping, which could be over-ridden? Can the user choose his/her own algorithm or a library-specific one?
3.1.8 Should a standard interface to libraries for Data Parallel classes be provided.
3.1.9 Do we need to define support for profilers and debuggers?
3.1.10 What are the requirements for an interface to systems such as MPI/PVM. Would all features of these need to be incorporated?
Links with other groups will be established; this will include other groups working on related projects within Europe and world-wide, particularly in the USA. In order to initiate the latter, Russel Winder of UCL will visit major groups in the USA known to be working on parallel versions of C++. Other persons from Europe interested in contributing to the EUROPA work will be invited to participate in the meetings of the Working Group and the plenary meeting, (see Section 5.0 below) together with people from the potential user communities (covering both Scientific/Industrial and Commercial).
The London and South East Centre for HPC (SEL-HPC), funded by JISC, is preparing a teaching package for Parallel C++, based upon UC++. This will consist of course notes, code and teaching materials. They will also give course based on this material.
A mailshot will be prepared relating to the course which is planned so that it will be available for use during the next academic year. Those interested in contributing are advised to contact Prof Heather Liddell or Mr John Steel at LPAC/SEL-HPC.
Those Higher Education Institutes who come under JISC will be eligible for free attendance at course and copies of course material. Further copies of course material may be made available through the Commission. However, SEL-HPC reserves the right to levy a small charge to conver its costs.
28 February, 1995: Draft discussion document - comments to be received by the end of March.
27/28 April, 1995 at INRIA in Nice: Revision of discussion document - to be carried out during the meeting of the ArchSIG.
May, 1995: Discussion documents - revised draft to be circulated.
Early July, 1995: Extended ArchSIG meeting.
June, 1995: Final specification to be drafted.
Late September, 1995 (in Brussels): Plenary meeting.
Definition of classes of application to be supported and their associated requirements. This will require work by the Applications SIG and discussion between the Architecture SIG and the Applications SIG.
There will be two classes of membership:
Full Members
Full members will have:
i Voting rights - one per organisation.
ii Shall be eligible for funding under the Governing Contract up to such limits as may from time to time be agreed.
iii The right to attend all meetings (Plenary and Technical) subject to such limits upon numbers as may be agreed and claim reimbursement for qualifying expenses under ii up to such funding limits as may from time to time be in place.
iv Access to all working documentation, etc, which shall be generated by the Working Group.
v Shall be required to sign a standard Confidentiality Agreement covering work undertaken and background information, subject to such limitations as may be imposed by the Governing Contract.
Members
Members:
i Shall not have voting rights.
ii Shall not be eligible for funding under the governing contract up to such limits as may from time to time be agreed.
iii Shall have the right to attend all meetings (Plenary and Technical).
iv Shall have access to all working documenation, etc, which shall be generated by the Working Group, subject to approval of its release by the full members.
v May be required to sign an undertaking of confidentiality.
A further category "Associate" has been added to the structure within the Prospectus. This will refer to those parties who are held on the group's mailing list.
The EC has requested that membership documents be distributed to all participating parties and completed and returned to LPAC. Subject to approval, members would be able todraw funds for travel and subsistence.
Architecture Menu