Presentation is loading. Please wait.

Presentation is loading. Please wait.

Java for High Performance Computing Multithreaded and Shared-Memory Programming in Java Instructor:

Similar presentations


Presentation on theme: "Java for High Performance Computing Multithreaded and Shared-Memory Programming in Java Instructor:"— Presentation transcript:

1 Java for High Performance Computing Multithreaded and Shared-Memory Programming in Java Instructor: Bryan Carpenter Pervasive Technology Labs Indiana University

2 Java as a Threaded Language u In C, C++, etc it is possible to do multithreaded programming, given a suitable library. –e.g. the pthreads library. u Thread libraries provide one approach to doing parallel programming on computers with shared memory. –Another approach is OpenMP, which uses compiler directives. This will be discussed later. u Unlike these (traditional HPC) languages, Java integrates threads into the basic language specification in a much tighter way. –Every Java Virtual Machine must support threads. u Although this close integration doesn’t exactly make multithreaded programming in Java easy, it does help avoid common programming errors, and keeps the semantics clean.

3 Features of Java Threads u Java provides a set of synchronization primitives based on monitor and condition variable paradigm of C.A.R. Hoare. –Underlying functionality is similar to POSIX threads, for example. u Syntactic extension for threads is (deceptively?) small: –synchronized attribute on methods. –synchronized statement. –volatile keyword. –Other thread management and synchronization captured in the Thread class and related classes. u But the presence of threads has a more wide-ranging effect on the language specification and JVM implementation. –e.g., the Java memory model.

4 Contents of this Lecture Set u Introduction to Java Threads. –Mutual Exclusion. –Synchronization between Java Threads using wait() and notify(). –Other features of Java Threads. u Shared Memory Parallel Computing with Java Threads –We review select parallel applications and benchmarks of Java on SMPs from the recent literature. u Special Topic: JOMP –JOMP is a prototype implementation of the OpenMP standard for Java. u Suggested Exercises

5 Java Thread Basics

6 Creating New Threads in a Java Program u Any Java thread of execution is associated with an instance of the Thread class. Before starting a new thread, you must create a new instance of this class. u The Java Thread class implements the interface Runnable. So every Thread instance has a method: public void run() {... } u When the thread is started, the code executed in the new thread is the body of the run() method. –Generally speaking the new thread ends when this method returns.

7 Making Thread Instances u There are two ways to create a thread instance (and define the thread run() method). Choose at your convenience: 1.Extend the Thread class and override the run() method, e.g.: class MyThread extends Thread { public void run() { System.out.println(“Hello from another thread”) ; }... Thread thread = new MyThread() ; 2.Create a separate Runnable object and pass it to the Thread constructor, e.g.: class MyRunnable implements Runnable { public void run() { System.out.println(“Hello from another thread”) ; }... Thread thread = new MyThread(new MyRunnable()) ;

8 Starting a Thread u Creating the Thread instance does not in itself start the thread running. u To do that you must call the start() method on the new instance: thread.start() ; This operation causes the run() method to start executing concurrently with the original thread. u In our example the new thread will print the message “Hello from another thread” to standard output, then immediately terminate. u You can only call the start() method once on any Thread instance. Trying to “restart” a thread causes an exception to be thrown.

9 Example: Multiple Threads class MyThread extends Thread { MyThread(int id) { this.id = id ; } public void run() { System.out.println(“Hello from thread ” + id) ; } private int id ; }... Thread [] threads = new Thread [p] ; for(int i = 0 ; i < p ; i++) threads [i] = new MyThread(i) ; for(int i = 0 ; i < p ; i++) threads [i].start() ;

10 Remarks u This is one way of creating and starting p new threads to run concurrently. u The output might be something like (for p = 4): Hello from thread 3 Hello from thread 4 Hello from thread 2 Hello from thread 1 Of course there is no guarantee of order (or atomicity) of outputs, because the threads are concurrent. u One might worry about the efficiency of this approach for large numbers of threads (massive parallelism).

11 JVM Termination and Daemon Threads u When a Java application is started, the main() method of the application is executed in a singled-out thread called the main thread. u In the simplest case—if the main method never creates any new threads—the JVM keeps running until the main() method completes (and the main thread terminates). –If the JVM was started with the java command, the command finishes. u If the main() method creates new threads, then by default the JVM terminates when all user-created threads have terminated. u More generally there are system threads executing in the background, concurrent with the user threads (e.g. threads might be associated with garbage collection). These threads are marked as daemon threads— meaning just that they don’t have the property of “keeping the JVM alive”. So, more strictly, the JVM terminates when all non-daemon threads terminate. u Ordinary user threads can create daemon threads by applying the setDaemon() method to the thread instance before starting it.

12 Mutual Exclusion

13 Avoiding Interference u In any non-trivial multithreaded (or shared-memory-parallel) program, interference between threads is an issue. u Generally interference (or a race condition) occurs if two threads are trying to do operations on the same variables at the same time. This often results in corrupt data. –But not always. It depends on the exact interleaving of instructions. This non-determinism is the worst feature of race conditions. u A popular solution is to provide some kind of lock primitive. Only one thread can acquire a particular lock at any particular time. The concurrent program can then be written so that operations on a given group of variables are only ever performed by threads that hold the lock associated with that group. u In POSIX threads, for example, the lock objects are called mutexes.

14 Example use of a Mutex (in C) pthread_mutex_lock(&my_mutex) ; /* critical region */ tmp1 = count ; count = tmp1 + 1 ; pthread_mutex_unlock(&my_mutex) ; pthread_mutex_lock(&my_mutex) ; pthread_mutex_unlock(&my_mutex) ; Blocked Thread AThread B /* critical region */ tmp2 = count ; count = tmp2 - 1 ;

15 Pthreads-style mutexes u In POSIX threads, a mutex is allocated then initialized with pthread_mutex_init(). u Once a mutex is initialized, a thread can acquire a lock on it by calling e.g. pthread_mutex_lock(). While it holds the lock it performs some update on the variables guarded by the lock (critical region). Then the thread calls pthread_mutex_unlock() to release the lock. u Other threads that try to call pthread_mutex_lock() while the critical region is being executed are blocked until the first thread releases the lock. u This is fine, but opportunities for error include: –There is no built-in association between the lock object (mutex) and the set of variables it guards—it is up to the program to maintain a consistent association. –If you forget to call pthread_mutex_unlock() after pthread_mutex_lock(), deadlocks will occur.

16 Monitors u Java addresses these problems by adopting a version of the monitors proposed by C.A.R. Hoare. u Every Java object is created with its own lock (and every lock is associated with an object—there is no way to create an isolated mutex). In Java this lock is often called the monitor lock. u Methods of a class can be declared to be synchronized. u The object’s lock is acquired on entry to a synchronized method, and released on exit from the method. –Synchronized static methods need slightly different treatment. u Assuming methods generally modify the fields (instance variables) of the objects they are called on, this leads to a natural and systematic association between locks and the variables they guard: viz. a lock guards the instance variables of the object it is attached to. u The critical region becomes the body of the synchronized method.

17 Example use of Synchronized Methods … call to counter.increment() … // body of synchronized method tmp1 = count ; count = tmp1 + 1 ; … counter.increment() returns … … call to counter.decrement() … … counter.decrement() returns … Blocked Thread AThread B // body of synchronized method tmp2 = count ; count = tmp2 - 1 ;

18 Caveats u This approach helps to encourage good practices, and make multithreaded Java programs less error-prone than, say, multithreaded C programs. u But it isn’t magic: –It still depends on correct identification of the critical regions, to avoid race conditions. –The natural association between the lock of the object and its fields relies on the programmer following conventional patterns of object oriented programming (which the language encourages but doesn’t enforce). –By using the synchronized construct (see later), programs can break this association altogether. –There are plenty more insidious ways to introduce deadlocks, besides accidentally forgetting to release a lock! u Concurrent programming is hard, and if you start with the assumption Java somehow makes concurrent programming “easy”, you are probably going to write some broken programs!

19 Example: A Simple Queue public class SimpleQueue { private Node front, back ; public synchronized void add(Object data) { if (front != null) { back.next = new Node(data) ; back = back.next ; } else { front = new Node(data) ; back = front ; } public synchronized Object rem() { Object result = null ; if (front != null) { result = front.data ; front = front.next ; } return result ; }

20 Remarks u This queue is implemented as a linked list with a front pointer and a back pointer. u The method add() adds a node to the back of the list; the method rem() removes a node from the front of the list. u The Node class just has a data field (type Object) and a next field (type Node). u The rem() method immediately returns null when the queue is empty. u The following slide gives an example of what could go wrong without mutual exclusion. It assumes two threads concurrently add nodes to the queue. –In the initial state, Z is the last item in the queue. In the final state, the X node is orphaned, and the back pointer is null.

21 The Need for Synchronized Methods back.next = new Node(X) ; back = back.next ; Thread A: add(X) Thread B: add(Y) back.next = new Node(Y) ; back = back.next ; Z null back Z null back X Z null back X null Y Z back X null Y Z back X null Y Corrupt data structure!

22 The synchronized construct u The keyword synchronized also appears in the synchronized statement, which has syntax like: synchronized (object) { … critical region … } u Here object is a reference to any object. The synchronized statement first acquires the lock on this object, then executes the critical region, then releases the lock. u Typically you might use this for the lock object, somewhere inside a none-synchronized method, when the critical region is smaller than the whole method body. u In general, though, the synchronized statement allows you to use the lock in any object to guard any code.

23 Performance Overheads of synchronized u Acquiring locks obviously introduces an overhead in execution of synchronized methods. See, for example: “Performance Limitations of the Java Core Libraries”, Allan Heydon and Marc Najork (Compaq), Proceedings of ACM 1999 Java Grande Conference. u Many of the utility classes in the Java platform (e.g. Vector, etc) were originally specified to have synchronized methods, to make them safe for the multithreaded environment. u This is now generally thought to have been a mistake: newer replacement classes (e.g. ArrayList) usually don’t have synchronized methods—it is left to the user to provide the synchronization, as needed, e.g. through wrapper classes.

24 General Synchronization

25 Beyond Mutual Exclusion u The mutual exclusion provided by synchronized methods and statements is an important special sort of synchronization. u But there are other interesting forms of synchronization between threads. Mutual exclusion by itself is not enough to implement these more general sorts of thread interaction (not efficiently, at least). u POSIX threads, for example, provides a second kind of synchronization object called a condition variable to implement more general inter-thread synchronization. u In Java, condition variables (like locks) are implicit in the definition of objects: every object effectively has a single condition variable associated with it.

26 A Motivating Example u Consider the simple queue from the previous example. u If we try to remove an item from the front of the queue when the queue is empty, SimpleQueue was specified to just return null. u This is reasonable if our queue is just meant as a data structure buried somewhere in an algorithm. But what if the queue is a message buffer in a communication system? u In that case, if the queue is empty, it may be more natural for the “remove” operation to block until some other thread added a message to the queue.

27 Busy Waiting u One approach would be to add a method that polls the queue until data is ready: public synchronized Object get() { while(true) { Object result = rem() ; if (result != null) return result ; } u This works, but it may be inefficient to keep doing the basic rem() operation in a tight loop, if these machine cycles could be used by other threads. –This isn’t clear cut: sometimes busy waiting is the most efficient approach. u Another possibility is to put a sleep() operation in the loop, to deschedule the thread for some fixed interval between polling operations. But then we lose responsiveness.

28 wait() and notify() u In general a more elegant approach is to use the wait() and notify() family of methods. These are defined in the Java Object class. u Typically a call to a wait() method puts the calling thread to sleep until another thread wakes it up again by calling a notify() method. u In our example, if the queue is currently empty, the get() method would invoke wait(). This causes the get() operation to block. Later when another thread calls add(), putting data on the queue, the add() method invokes notify() to wake up the “sleeping” thread. The get() method can then return.

29 A Simplified Example public class Semaphore { int s ; public Semaphore(int s) { this.s = s ; } public synchronized void add() { s++ ; notify() ; } public synchronized void get() throws InterruptedException { while(s == 0) wait() ; s-- ; }

30 Remarks I u Rather than a linked list we have a simple counter, which is required always to be non-negative. –add() increments the counter. –get() decrements the counter, but if the counter was zero it blocks until another thread increments the counter. u The data structures are simplified, but the synchronization features used here are essentially identical to what would be needed in a blocking queue (left as an exercise). u You may recognize this as an implementation of a classical semaphore—an important synchronization primitive in its own right.

31 Remarks II u wait() and notify() must be used inside synchronized methods of the object they are applied to. u The wait() operation “pauses” the thread that calls it. It also releases the lock which the thread holds on the object (for the duration of the wait() call: the lock will be claimed again before continuing, after the pause). u Several threads can wait() simultaneously on the same object. u If any threads are waiting on an object, the notify() method “wakes up” exactly one of those threads. If no threads are waiting on the object, notify() does nothing. u A wait() method may throw an InterruptedException (rethrown by by get() in the example). This will be discussed later. u Although the logic in the example doesn’t strictly require it, universal lore has it that one should always put a wait() call in a loop, in case the condition that caused the thread to sleep has not been resolved when the wait() returns (a programmer flaunting this rule might use if in place of while).

32 Another Example public class Barrier { private int n, generation = 0, count = 0 ; public Barrier(int n) { this.n = n ; } public synchronized void synch() throws InterruptedException { int genNum = generation ; count++ ; if(count == n) { count = 0 ; generation++ ; notifyAll() ; } else while(generation == genNum) wait() ; }

33 Remarks u This class implements barrier synchronization—an important operation in shared memory parallel programming. u It synchronizes n processes: when n threads make calls to synch() the first n-1 block until the last one has entered the barrier. u The method notifyAll() generalizes notify(). It wakes up all threads currently waiting on this object. –Many authorities consider use of notifyAll() to be “safer” than notify(), and recommend always to use notifyAll(). u In the example, the generation number labels the current, collective barrier operation: it is only really needed to control the while loop round wait(). –And this loop is only really needed to conform to the standard pattern of wait()-usage, mentioned earlier.

34 Concluding Remarks on Synchronization u We illustrated with a couple of simple examples that wait() and notify() allow various interesting patterns of thread synchronization (or thread communication) to be implemented. u In some sense these primitives are sufficient to implement “general” concurrent programming—any pattern of thread synchronization can be implemented in terms of these primitives. –For example you can easily implement message passing between threads (left as an exercise…) u This doesn’t mean these are necessarily the last word in synchronization: e.g. for scalable parallel processing one would like a primitive barrier operation more efficient than the O(n) implementation given above.

35 Other Features of Java Threads

36 Other Features u This lecture isn’t supposed to cover all the details—for those you should look at the spec! u But we mention here a few other features you may find useful.

37 Join Operations u The Thread API has a family of join() operations. These implement another simple but useful form of synchronization, by which the current thread can simply wait for another thread to terminate, e.g.: Thread child = new MyThread() ; child.start() ; … Do something in current thread … child.join() ; // wait for child thread to finish

38 Priority and Name u Thread have properties priority and name, which can be defined by suitable setter methods, before starting the thread, and accessed by getter methods.

39 Sleeping u You can cause a thread to sleep for a fixed interval using the sleep() methods. u This operation is distinct from and less powerful than wait(). It is not possible for another thread to prematurely wake up a thread paused using sleep(). –If you want to sleep for a fixed interval, but allow another thread to wake you beforehand if necessary, use the variants of wait() with timeouts instead.

40 Deprecated Thread Methods u There is a family of methods of the Thread class that was originally supposed to provide external “life-or-death” control over threads. u These were never reliable, and they are now officially “deprecated”. You should avoid them. u If you have a need to interrupt a running thread, you should explicitly write the thread it in such a way that it listens for interrupt conditions (see the next slide). –If you want to run an arbitrary thread in such a way that it can be externally killed and cleaned by an external agent, you probably need to fork a separate process to run it. u The most interesting deprecated methods are: –stop() –destroy() –suspend() –resume()

41 Interrupting Threads u Calling the method interrupt() on a thread instance requests cancellation of the thread execution. u It does this in an advisory way: the code for the interrupted thread must be written to explicitly test whether it has been interrupted, e.g.: public void run() { while(!interrupted()) … do something … } Here interrupted() is a static method of the Thread class which determines whether the current thread has been interrupted u If the interrupted thread is executing a blocking operation like wait() or sleep(), the operation may end with an InterruptedException. An interruptible thread should catch this exception and terminate itself. u Clearly this mechanism depends wholly on suitable implementation of the thread body. The programmer must decide at the outset whether it is important that a particular thread be responsive to interrupts—often it isn’t.

42 Thread Groups u There is a mechanism for organizing threads into groups. This may be useful for imposing security restrictions on which threads can interrupt other threads, for example. u Check out the API of the ThreadGroup class if you think this may be important for your application.

43 Thread-Local Variables u An object from the ThreadLocal class stores an object which has a different, local value in every thread. u For example, suppose you implemented the MPI message- passing interface, mapping each MPI process to a Java thread. You decide that “world communicator” should be a static variable of the Comm class. But then how do you get the rank() method to return a different process ID for each thread, so this kind of thing works?: int me = Comm.WORLD.rank() ; u One approach would be to store the process ID in the communicator object in a thread local variable. –Another approach would be to use a hash map keyed by Thread.currentThread(). u Check the API of the ThreadLocal class for details.

44 Volatile Variables u Suppose a the value of a variable must be accessible by multiple threads, but for some reason you decided you can’t afford the overheads of synchronized methods or the synchronized statement. –Presumably effects of race conditions have been proved innocuous. u In general Java does not guarantee that—in the absence of lock operations to force synchronization of memory—the value of a variable written by a one thread will be visible to other threads. u But if you declare a field to be volatile: volatile int myVariable ; the JVM is supposed to synchronize the value of any thread-local (cached) copy of the variable with central storage (making it visible to all threads) every time the variable is updated. u The exact semantics of volatile variables, and the Java memory model in general, is still controversial, see for example: “A New Approach to the Semantics of Multithreaded Java”, Jeremy Manson and William Pugh,

45 Thread-based Parallel Applications and Benchmarks

46 Threads on Symmetric Multiprocessors u Most modern implementations of the Java Virtual Machine will map Java threads into native threads of the underlying operating system. –For example these may be POSIX threads. u On multiprocessor architectures with shared memory, these threads can exploit multiple available processors. u Hence it is possible to do true parallel programming using Java threads within a single JVM.

47 Select Application Benchmark Results u We present some results, borrowed from the literature in this area. u Two codes are described in “High-Performance Java Codes for Computational Fluid Dynamics” C. Riley, S. Chatterjee, and R. Biswas, ACM 2001 Java Grande/ISCOPE u LAURA is a finite-volume flow solver for multiblock, structured grids. u 2D_TAG is a triangular adaptive grid generation tool.

48 Parallel Speedup of LAURA Code

49 Parallel Speedup of 2D_TAG Code

50 Remarks u LAURA speedups are generally fair, and are outstanding with the Jalapeno JVM on PowerPC (unfortunately this is the only JVM that isn’t freely available.) –LAURA is “regular”, and the parallelization strategy needs little or no locking. u 2D_TAG results are only reported for PowerPC (presumably worse on other platforms). This code is very dynamic, very OO, and the naïve version uses many synchronized methods, hence poor performance. –The two optimized versions cut down the amount of locking by partitioning the grid, and only using locks in accesses to edge regions. u As noted earlier, synchronization in Java is quite expensive.

51 CartaBlanca u CartaBlanca, from Los Alomos National Lab, is a general purpose non- linear solver environment for physics computations on non-linear grids. “Parallel Operation of CartaBlanca on Shared and Distributed Memory Computers” N. Padial-Collins, W. VanderHeyden, D. Zhang, E. Dendy, D. Livescu ACM Java Grande/ISCOPE conference. u It employs an object-oriented component design, and is pure Java. u Parallel versions are based on partitioned meshes, and run either in multithreaded mode on SMPs, or on networks using a suitable high performance RMI. Here we are interested in the former case (multithreaded approach). u Shared memory results are for an 8-processor Intel SMP machine with 900 MHz chips. –The following results are from a pre-publication version of the paper cited, and should presumably be taken as indicative only.

52 Broken Dam Problem u Two immiscible fluids, side by side. u 3D tetrahedral mesh.

53 Broken Dam Benchmark Results Best speedup: 3.65 on 8 processors

54 Heat Transfer Problem u Solves transient heat equation on a square domain. Best speedup: 4.6 on 8 processors

55 NAS Parallel Benchmarks u The NAS parallel benchmark suite contains a set of kernel applications based on CFD codes. u In Implementation of the NAS Parallel Benchmarks in Java Michael A. Frumkin, Matthew Schultz, Haoqiang Jin, and Jerry Yan NAS Technical Report NAS the OpenMP versions of the following codes: –BT, SP, LU: Simulated CFD applications. –FT: Kernel of a 3-D FFT. –MG: Multigrid solver for 3-D Poisson equation. –CG: Conjugate Gradient method to find eigenvalues of sparse matrix. were translated to Java using Java threads.

56 Timings on IBM p690

57 Timings for Origin2000

58 Timings for SUN Enterprise10000

59 Remarks on NAS Benchmark Results u In this paper the comparisons with Fortran are not flattering to Java (in fact this was the main conclusion of the authors). –It seems the SGI Java is particularly slow. –Generally speaking Java fares much better on Linux or Windows platforms—not represented here. u Nevertheless, concentrating here on parallel aspects, all cases show useful or excellent speedup. –These results are for the largest problem size.

60 Special Topic: JOMP

61 OpenMP and Java u OpenMP (www.openmp.org) is a well-known standard for parallel programming on shared-memory computers. u It consists of a series of directives and libraries embedded in a base language, typically Fortran or C/C++. –The directives allow definition of parallel regions, executed by a thread-team, work-sharing directives, which typically define how iterations of a loop are divided between the thread team, and synchronization features like barriers and critical regions. u For scientific programming, the OpenMP paradigm can be considerably more concise and expressive than using generic thread libraries. u Although it doesn’t seem to have been widely taken up, there is an interesting implementation of OpenMP for Java from Edinburgh Parallel Computing Center—namely, JOMP.

62 JOMP Execution Model u A Java program annotated with JOMP directives is written in a source file with filename extension.jomp. u This file is fed to the JOMP compiler, which outputs a cryptic.java file, including calls to a runtime library responsible for managing Java threads to handle parallel regions, partitioning work-shared loops, doing barrier synchronizations, etc. –In the most straightforward case the run-time library is implemented on top of the standard Java thread library. –The intermediate.java file is compiled by a standard javac. u One simply executes the resulting class file by, e.g. java -Djomp.threads=10 MyClass

63 JOMP Directives u JOMP directives are syntactically Java comments. –Note however that OpenMP does not automatically have a property of HPF and related dialects of Fortran, namely that removing directives leaves a sequential program with the same semantics. –In general OpenMP directives will change the behavior and results of a program. So the fact the directives have the syntax of comments is, arguably, slightly misleading. –It is nevertheless possible, and presumably good practice, to write OpenMP programs in such a way that they do execute the same under a sequential compiler. u In JOMP the typical syntax of a construct is: //omp directive Java-statement where the Java-statement is most often a compound statement, like a for statement, or a block in braces, { }. u Other JOMP directives stand alone, and are not associated with a following Java block (e.g. the barrier directive).

64 JOMP Directives: parallel u The parallel construct has basic form: //omp parallel Java-statement u The effect is to “create a thread team”. The original thread becomes master of the team. Master and all other team members execute the Java-statement, which will nearly always be some compound statement. u There is an implicit barrier synchronization at the end of the parallel region. u There are various optional clauses, e.g.: //omp parallel shared(vars1) private(vars2) … Java-statement Here vars1, vars2 are lists of variable names. These clauses control whether the specified variables are shared or private to threads within the parallel region.

65 JOMP Directives: for u The for construct has basic form: //omp for for(integer-type var = expr ; test-var ; incr-var) Java-statement u A for construct must appear nested (lexically or “dynamically”) inside a parallel construct—the iterations are divided amongst the active thread team. u The form of the enclosed Java for statement is restricted so that the number of iterations can be computed before the loop starts (it must be basically equivalent to a traditional FORTRAN DO loop). u There is an implicit barrier synchronization at the end of the for construct; this can be disabled by using the nowait clause: //omp for nowait … Java-for-statement u The way the iterations are partitioned can be controlled by a schedule clause: //omp for schedule(mode, chunk-size) … Java-for-statement

66 JOMP Directives: master, critical, barrier u The master construct has the form: //omp master Java-statement This appears inside a parallel construct. The Java-statement is only executed by the master thread. u The critical construct has the form: //omp critical [name] Java-statement This appears inside a parallel construct, and defines a critical region. The optional name specifies a lock (if omitted, the default lock is used). u The barrier directive has the form: //omp barrier This appears inside a parallel construct. It is treated like an executable statement and specifies a barrier synchronization at the point it appears in the program.

67 Other Features u There are various other directives and clauses in OpenMP and JOMP that we didn’t cover, but we gave a flavor. u It is up to the programmer to ensure that all threads in a thread team encounter work-sharing constructs, and other constructs that imply barrier synchronization, in the same order.

68 An Example u We describe an example from the JOMP release, a CFD code taken from the JOMP version of the Java Grande Benchmark suite. u The code Tunnel (presumably short for “Java Wind Tunnel”), in the JG JOMP benchmarks folder section3/euler/, solves the Euler equations for 2-dimensional inviscid flow.

69 The Euler Equations (in one slide) u Euler equations are a family of conservation equations for (in 2D) 4 quantities: matter (or mass), 2 components of momentum, total energy: Flow variables (f, g) related to dependent variables U by: ρ = density, (u, v) = velocity, E = energy, H = enthalpy. With equations of state, can easily compute (f, g) as a function of U.

70 Finite Volume Discretization u A finite volume approach: divide space into a series of quadrilaterals, and integrate over a single cell using Gauss’ theorem: where Ω is cell volume and: Note U and (f, g) are defined in the centers of the cells. The face values of (f, g) are computed as averages between neighboring cells. So R(U) ends up involving values from neighboring cells.

71 Runge Kutta Integration u Now we have a large set of coupled ordinary differential equations that can be integrated by, e.g., a Runge-Kutta scheme. In the variant used here a single integration step is a sequence of four stages each of the form: where the αs are small constants. u We skipped over some important details (e.g. boundary conditions, artificial damping) but the equations above summarize the core algorithm implemented by the Tunnel program.

72 Organization u So the program Tunnel involves a sequence of steps like: 1.Calculate p, H from current U components (using equations of state for fluid). 2.Calculate f from U, p, H. 3.Calculate g from U, p, H. 4.Calculate R from (f, g). 5.Update U. u Parallelizing in JOMP is very straightforward. u The operations above are called from the method called doIteration(). A simplified, schematic form is given on the next slide.

73 Main Driver void doIteration() { int i, j ; //omp parallel private(i, j) { … calculateStateVar(pg1, tg1, ug1) ; calculateF(pg1, tg1, ug1) ; calculateG(pg1, tg1, ug1) ; calculateR() //omp for for(i = 1; j < imax ; i++) for(j = 1 ; j < jmax ; ++j) { ug1[i][j].a = ug[i][j].a – 0.5*deltat/a[i][j]*(r[i][j].a – d[i][j].a) ; ug1[i][j].b = ug[i][j].b – 0.5*deltat/a[i][j]*(r[i][j].b – d[i][j].b) ; ug1[i][j].c = ug[i][j].c – 0.5*deltat/a[i][j]*(r[i][j].c – d[i][j].c) ; ug1[i][j].d = ug[i][j].d – 0.5*deltat/a[i][j]*(r[i][j].d – d[i][j].d) ; } … Three other similar stages } … }

74 Remarks u The arrays ug, ug1 hold states of the four components of U (in fields a, b, c, d of their elements). u The arrays pg, and tg are pressure and temperature. The array a is cell volume. u The array d holds artificial viscosity, which we didn’t discuss. u We have shown one work-sharing construct within this method—a for construct. u Much of the real work is in the routines calculateR(), etc, which are called inside the parallel construct.

75 Calculation of R private void calculateR() { double temp; int j; //omp for for (int i = 1; i < imax; i++) for (j = 1; j < jmax; ++j) { …Set fields of r[i][j] to zero… /* East Face */ temp = 0.5 * (ynode[i][j] - ynode[i][j-1]); r[i][j].a += temp*(f[i][j].a + f[i+1][j].a); r[i][j].b += temp*(f[i][j].b + f[i+1][j].b); r[i][j].c += temp*(f[i][j].c + f[i+1][j].c); r[i][j].d += temp*(f[i][j].d + f[i+1][j].d); temp = - 0.5*(xnode[i][j] - xnode[i][j-1]); r[i][j].a += temp * (g[i][j].a+g[i+1][j].a); r[i][j].b += temp * (g[i][j].b+g[i+1][j].b); r[i][j].c += temp * (g[i][j].c+g[i+1][j].c); r[i][j].d += temp * (g[i][j].d+g[i+1][j].d); …Add similar contributions of N, S, W faces… }

76 Remarks u This is the practical implementation of the mathematical definition of R given on the earlier slide about discretization. –We average cell-centered flow values because they are formally evaluated on the faces of the cell. –The arrays xnode, ynode contain coordinates of the vertices of the grid. u The for directive here is not in the lexical scope of a parallel construct. It is called an orphaned directive. –It is in the dynamic scope of a parallel construct—i.e. this method is called from the body of a parallel construct. u Those of us conditioned by distributed-memory, domain- decompositions tend to think of the accesses to neighbors as communications. Of course this is wrong here. There is no fixed association between array elements and threads. –Note, on the other hand, there is an implicit thread synchronization associated with the barrier finishing every for construct (by default).

77 General Observations on JOMP u In the example we borrowed, parallelization of code was very easy compared with most other approaches. u The automatic work-sharing of the for construct is very convenient. –One limitation is that it only naturally applies to the outer loop of a multidimensional loop nest—doesn’t generally support multidimensional blocking. u It relies on a good implementation of the OpenMP synchronization primitives. Not obvious a priori that the frequent, implicit barriers will translate efficiently to standard Java thread operations. u Lack of implementations: –Sources of the prototype JOMP compiler, etc are not available at the EPCC Web site? Will anybody use the software if it’s non-standard and closed source??

78 Suggested Exercises

79 1. Java Thread Synchronization u Following the pattern of the Semaphore class, complete the implementation of a queue with a get() operation that blocks when the queue is empty, using wait() and notify(). u Extend this to implement send() and recv() primitives for communicating between threads by message-passing. –Try implementing other features of the MPI standard for communication between threads, e.g. synchronous mode sends (where both sender and receive block until both are ready to communicate). Avoid “busy-waiting” or polling solutions. –Define an MPI_Comm_Rank-like function using a ThreadLocal variable.

80 2. Experiment with JOMP u Download and install the JOMP software from ( This just involves downloading a.jar file and adding it to your CLASSPATH.) u You may also want to download the JOMP version of the Java Grande benchmarks from the same location. u Implement your favorite parallel algorithm in Java using the JOMP implementation of OpenMP. –Do you encounter any implementation limits of the compiler or runtime? –Do you get parallel speedup on multiprocessor machines? –Tell us your results!


Download ppt "Java for High Performance Computing Multithreaded and Shared-Memory Programming in Java Instructor:"

Similar presentations


Ads by Google