DOCSLIB.ORG

IBM Business Process Manager V8.5 Performance Tuning and Best Practices

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
IBM Business Process Manager V8.5 Performance Tuning and Best Practices Front cover IBM® WebSphere® IBM Business Process Manager V8.5 Performance Tuning and Best Practices Learn valuable tips for tuning Get the latest recommendations See example settings Mike Collins Zi Hui Duan Andreas Fried Ben Hoflich Chris Richardson Torsten Wilms ibm.com/redbooks International Technical Support Organization IBM Business Process Manager V8.5 Performance Tuning and Best Practices February 2015 SG24-8216-00 Note: Before using this information and the product it supports, read the information in “Notices” on page ix. First Edition (February 2015) This edition applies to Version 8.5.5 of IBM Business Process Manager and Version 8.5.5 of IBM Business Monitor. © Copyright International Business Machines Corporation 2015. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . ix Trademarks . x IBM Redbooks promotions . xi Preface . xiii Authors . xiv Now you can become a published author, too! . xvii Comments welcome. xvii Stay connected to IBM Redbooks . xvii Chapter 1. Overview . 1 1.1 Products covered in this publication . 2 1.2 Publication structure . 3 Chapter 2. Architecture best practices . 5 2.1 Top tuning and deployment guidelines . 6 2.2 Modeling and developing applications . 8 2.2.1 Common best practices . 9 2.2.2 Process Designer architecture best practices. 9 2.2.3 Integration Designer best practices. 13 2.3 Topology . 16 2.3.1 Deploy appropriate hardware . 17 2.3.2 Deploy local modules in the same server . 18 2.3.3 Best practices for Deployment Environments . 18 2.3.4 Evaluate service providers and external interfaces. 19 2.4 Client environments. 21 2.4.1 Optimize the topology . 21 2.4.2 Use a high-performing browser. 23 2.4.3 Enable browser caching . 23 2.4.4 Physical location of servers. 23 2.4.5 Use modern desktop hardware . 23 2.5 Large business objects . 24 2.5.1 Factors affecting large business object size processing . 24 2.5.2 Large object design patterns. 25 2.5.3 Data management. 26 2.6 Use 64-bit JVMs . 27 2.7 Business Monitor. 27 2.7.1 Event processing. 27 © Copyright IBM Corp. 2015. All rights reserved. iii 2.7.2 Dashboard. 28 2.7.3 Database server . 28 2.7.4 Topology . 28 Chapter 3. Development best practices . 29 3.1 BPMN business process authoring best practices . 30 3.1.1 Clear variables in exposed human services . 30 3.1.2 Do not use multi-instance loops in system lane or batch activities . 31 3.1.3 Use conditional joins only when necessary. 32 3.1.4 Follow guidelines for error handling . 32 3.1.5 Use sequential system lane activities efficiently . 33 3.1.6 Ensure the Process Center is properly tuned and managed . 34 3.1.7 Use fast connection for Process Designer and Process Center . 34 3.1.8 Prevent WSDL validation from causing slow web service integration . 35 3.2 Case authoring best practices. 35 3.2.1 Use required and automatically started case activities . 36 3.2.2 Use case folder properties . 36 3.3 Integration Designer best practices. 36 3.3.1 Use share-by-reference libraries where possible . 36 3.3.2 Ensure content in Toolkits is needed for multiple applications . 37 3.3.3 Advanced Content Deployment considerations . 37 3.3.4 Business object parsing mode considerations . 39 3.3.5 Service Component Architecture considerations . 47 3.3.6 Business Process Execution Language business process considerations. 48 3.3.7 Human task considerations. 49 3.3.8 Business process and human tasks client considerations . 50 3.3.9 Transactional considerations . 51 3.3.10 Invocation style considerations . 53 3.3.11 Large object considerations . 56 3.3.12 Mediation Flow Component considerations . 57 3.4 Browser environment considerations . 59 3.5 WebSphere InterChange Server migration considerations . 60 Chapter 4. Performance tuning and configuration. 63 4.1 Tuning checklist. 64 4.2 Common tuning parameters . 66 4.2.1 Tracing and logging flags . 66 4.2.2 Java memory management tuning parameters. 67 4.2.3 Message-driven bean ActivationSpec. 68 4.2.4 Process Engine navigation thread pools. 69 4.2.5 Java Message Service connection pool sizes. 69 iv IBM Business Process Manager V8.5 Performance Tuning and Best Practices 4.2.6 Java Database Connectivity data source parameters. 70 4.2.7 Tuning the Virtual Member Manager LDAP cache . 71 4.2.8 Messaging engine properties . 73 4.2.9 Run production servers in production mode . 73 4.3 Process Portal tuning and usage . 73 4.3.1 Use a high-performing browser. 74 4.3.2 Enable browser caching . 74 4.3.3 Locate the Process Portal physically close to the Process Server . 74 4.3.4 Use the WORK tab to refresh the Task List . 74 4.3.5 Use modern desktop hardware . 74 4.3.6 Disable or uninstall add-ins or extensions. 75 4.3.7 Process Portal Dashboard . 75 4.4 Business Processing Modeling Notation business process tuning . 76 4.4.1 How to Change Configuration Settings for BPMN Processing . 76 4.4.2 Tune the Event Manager. 76 4.4.3 Tune Participant Groups . 80 4.4.4 Use fast disk subsystem for recovery logs and Lucene Task Search indexes . 81 4.4.5 Remove unnecessary snapshots from the Process Server . 81 4.4.6 Disable notifications and automatic task list refreshes if they are not required. 81 4.4.7 Tune cache parameters . 83 4.5 Process Center tuning. 84 4.6 Advanced tuning . 85 4.6.1 Trace and monitor considerations. 85 4.6.2 Tune for large objects . 86 4.6.3 Tune for maximum concurrency . 86 4.6.4 Clustered topology tuning . ..
Load more

Recommended publications
  • 20 Linux System Monitoring Tools Every Sysadmin Should Know by Nixcraft on June 27, 2009 · 315 Comments · Last Updated November 6, 2012
    About Forum Howtos & FAQs Low graphics Shell Scripts RSS/Feed nixcraft - insight into linux admin work 20 Linux System Monitoring Tools Every SysAdmin Should Know by nixCraft on June 27, 2009 · 315 comments · Last updated November 6, 2012 Need to monitor Linux server performance? Try these built-in commands and a few add-on tools. Most Linux distributions are equipped with tons of monitoring. These tools provide metrics which can be used to get information about system activities. You can use these tools to find the possible causes of a performance problem. The commands discussed below are some of the most basic commands when it comes to system analysis and debugging server issues such as: 1. Finding out bottlenecks. 2. Disk (storage) bottlenecks. 3. CPU and memory bottlenecks. 4. Network bottlenecks. #1: top - Process Activity Command The top program provides a dynamic real-time view of a running system i.e. actual process activity. By default, it displays the most CPU-intensive tasks running on the server and updates the list every five seconds. Fig.01: Linux top command Commonly Used Hot Keys The top command provides several useful hot keys: Hot Usage Key t Displays summary information off and on. m Displays memory information off and on. Sorts the display by top consumers of various system resources. Useful for quick identification of performance- A hungry tasks on a system. f Enters an interactive configuration screen for top. Helpful for setting up top for a specific task. o Enables you to interactively select the ordering within top. r Issues renice command.
    [Show full text]
  • Thread Management for High Performance Database Systems - Design and Implementation
    Nr.: FIN-003-2018 Thread Management for High Performance Database Systems - Design and Implementation Robert Jendersie, Johannes Wuensche, Johann Wagner, Marten Wallewein-Eising, Marcus Pinnecke, Gunter Saake Arbeitsgruppe Database and Software Engineering Fakultät für Informatik Otto-von-Guericke-Universität Magdeburg Nr.: FIN-003-2018 Thread Management for High Performance Database Systems - Design and Implementation Robert Jendersie, Johannes Wuensche, Johann Wagner, Marten Wallewein-Eising, Marcus Pinnecke, Gunter Saake Arbeitsgruppe Database and Software Engineering Technical report (Internet) Elektronische Zeitschriftenreihe der Fakultät für Informatik der Otto-von-Guericke-Universität Magdeburg ISSN 1869-5078 Fakultät für Informatik Otto-von-Guericke-Universität Magdeburg Impressum (§ 5 TMG) Herausgeber: Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Der Dekan Verantwortlich für diese Ausgabe: Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Marcus Pinnecke Postfach 4120 39016 Magdeburg E-Mail: [email protected] http://www.cs.uni-magdeburg.de/Technical_reports.html Technical report (Internet) ISSN 1869-5078 Redaktionsschluss: 21.08.2018 Bezug: Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Dekanat Thread Management for High Performance Database Systems - Design and Implementation Technical Report Robert Jendersie1, Johannes Wuensche2, Johann Wagner1, Marten Wallewein-Eising2, Marcus Pinnecke1, and Gunter Saake1 Database and Software Engineering Group, Otto-von-Guericke University
    [Show full text]
  • Concurrency & Parallel Programming Patterns
    Concurrency & Parallel programming patterns Evgeny Gavrin Outline 1. Concurrency vs Parallelism 2. Patterns by groups 3. Detailed overview of parallel patterns 4. Summary 5. Proposal for language Concurrency vs Parallelism ● Parallelism is the simultaneous execution of computations “doing lots of things at once” ● Concurrency is the composition of independently execution processes “dealing with lots of thing at once” Patterns by groups Architectural Patterns These patterns define the overall architecture for a program: ● Pipe-and-filter: view the program as filters (pipeline stages) connected by pipes (channels). Data flows through the filters to take input and transform into output. ● Agent and Repository: a collection of autonomous agents update state managed on their behalf in a central repository. ● Process control: the program is structured analogously to a process control pipeline with monitors and actuators moderating feedback loops and a pipeline of processing stages. ● Event based implicit invocation: The program is a collection of agents that post events they watch for and issue events for other agents. The architecture enforces a high level abstraction so invocation of an agent is implicit; i.e. not hardwired to a specific controlling agent. ● Model-view-controller: An architecture with a central model for the state of the program, a controller that manages the state and one or more agents that export views of the model appropriate to different uses of the model. ● Bulk Iterative (AKA bulk synchronous): A program that proceeds iteratively … update state, check against a termination condition, complete coordination, and proceed to the next iteration. ● Map reduce: the program is represented in terms of two classes of functions.
    [Show full text]
  • Java Bytecode Manipulation Framework
    Notice About this document The following copyright statements and licenses apply to software components that are distributed with various versions of the OnCommand Performance Manager products. Your product does not necessarily use all the software components referred to below. Where required, source code is published at the following location: ftp://ftp.netapp.com/frm-ntap/opensource/ 215-09632 _A0_ur001 -Copyright 2014 NetApp, Inc. All rights reserved. 1 Notice Copyrights and licenses The following component is subject to the ANTLR License • ANTLR, ANother Tool for Language Recognition - 2.7.6 © Copyright ANTLR / Terence Parr 2009 ANTLR License SOFTWARE RIGHTS ANTLR 1989-2004 Developed by Terence Parr Partially supported by University of San Francisco & jGuru.com We reserve no legal rights to the ANTLR--it is fully in the public domain. An individual or company may do whatever they wish with source code distributed with ANTLR or the code generated by ANTLR, including the incorporation of ANTLR, or its output, into commerical software. We encourage users to develop software with ANTLR. However, we do ask that credit is given to us for developing ANTLR. By "credit", we mean that if you use ANTLR or incorporate any source code into one of your programs (commercial product, research project, or otherwise) that you acknowledge this fact somewhere in the documentation, research report, etc... If you like ANTLR and have developed a nice tool with the output, please mention that you developed it using ANTLR. In addition, we ask that the headers remain intact in our source code. As long as these guidelines are kept, we expect to continue enhancing this system and expect to make other tools available as they are completed.
    [Show full text]
  • AIX Version 7.2: Performance Tools Guide and Reference About This Document
    AIX Version 7.2 Performance Tools Guide and Reference IBM AIX Version 7.2 Performance Tools Guide and Reference IBM Note Before using this information and the product it supports, read the information in “Notices” on page 315. This edition applies to AIX Version 7.2 and to all subsequent releases and modifications until otherwise indicated in new editions. © Copyright IBM Corporation 2015, 2018. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents About this document ......... v The procmon tool ............ 212 Highlighting .............. v Overview of the procmon tool....... 212 Case-sensitivity in AIX ........... v Components of the procmon tool...... 212 ISO 9000................ v Filtering processes........... 215 Performing AIX commands on processes ... 215 Performance Tools Guide and Reference 1 Profiling tools ............. 215 The timing commands ......... 215 What's new in Performance Tools Guide and The prof command .......... 216 Reference ............... 2 The gprof command .......... 217 CPU Utilization Reporting Tool (curt) ...... 2 The tprof command .......... 219 Syntax for the curt Command ....... 2 The svmon command .......... 226 Measurement and Sampling ........ 3 Security .............. 227 Examples of the curt command ....... 4 The svmon configuration file ....... 227 Simple performance lock analysis tool (splat) ... 32 Summary report metrics......... 227 splat command syntax.......... 32 Report formatting options ........ 228 Measurement and sampling ........ 33 Segment details and -O options ...... 230 Examples of generated reports ....... 35 Additional -O options ......... 234 Hardware performance monitor APIs and tools .. 50 Reports details ............ 238 Performance monitor accuracy ....... 51 Remote Statistics Interface API Overview .... 259 Performance monitor context and state .... 51 Remote Statistics Interface list of subroutines 260 Performance monitoring agent ......
    [Show full text]
  • How to Maintain Happy SAS® Users
    NESUG 2007 Administration & Support How to Maintain Happy SAS ® Users Margaret Crevar, SAS Institute Inc., Cary, NC ABSTRACT Today’s SAS ® environment has high numbers of concurrent SAS processes and ever-growing data volumes. It is imperative to proactively manage system resources and performance to keep your SAS community productive and happy. We have found that ensuring your SAS applications have the proper computer resources is the best way to make sure your SAS users remain happy. INTRODUCTION There is one common thread when working with the IT administration staff at a SAS customer’s location with regard to what they can do to maintain happy SAS users, and that is to ensure that underlying hardware is properly configured to support the SAS applications. This is not a trivial task since different SAS applications need to have the hardware configured differently and depending on where you are with your understanding of how SAS will be used will help you evaluate options for the hardware, operating, and infrastructure (mid-tier) configuration. This is easier for existing SAS customers and more difficult with new SAS customers or new SAS applications at an existing SAS customer site. In this paper we will: • discuss briefly how SAS works, especially from an IO perspective • give some guidance on how to initially configure hardware for SAS usage • give some guidance on how to monitor the hardware to avoid running out of a computer resource • discuss if you should run all your SAS components under a single operating system or split them across multiple operating system This paper pulls together information that has been presented in recent SAS Global Forum and SUGI papers.
    [Show full text]
  • UNIX OS Agent User's Guide
    IBM Tivoli Monitoring Version 6.3.0 UNIX OS Agent User's Guide SC22-5452-00 IBM Tivoli Monitoring Version 6.3.0 UNIX OS Agent User's Guide SC22-5452-00 Note Before using this information and the product it supports, read the information in “Notices” on page 399. This edition applies to version 6, release 3 of IBM Tivoli Monitoring (product number 5724-C04) and to all subsequent releases and modifications until otherwise indicated in new editions. © Copyright IBM Corporation 1994, 2013. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Tables ...............vii Solaris System CPU Workload workspace ....28 Solaris Zone Processes workspace .......28 Chapter 1. Using the monitoring agent . 1 Solaris Zones workspace ..........28 System Details workspace .........28 New in this release ............2 System Information workspace ........29 Components of the monitoring agent ......3 Top CPU-Memory %-VSize Details workspace . 30 User interface options ...........4 UNIX OS workspace ...........30 UNIX Detail workspace ..........31 Chapter 2. Requirements for the Users workspace ............31 monitoring agent ...........5 Enabling the Monitoring Agent for UNIX OS to run Chapter 4. Attributes .........33 as a nonroot user .............7 Agent Availability Management Status attributes . 36 Securing your IBM Tivoli Monitoring installation 7 Agent Active Runtime Status attributes .....37 Setting overall file ownership and permissions for AIX AMS attributes............38
    [Show full text]
  • Model Checking Multithreaded Programs With
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Illinois Digital Environment for Access to Learning and Scholarship Repository Model Checking Multithreaded Programs with Asynchronous Atomic Methods Koushik Sen and Mahesh Viswanathan Department of Computer Science, University of Illinois at Urbana-Champaign. {ksen,vmahesh}@uiuc.edu Abstract. In order to make multithreaded programming manageable, program- mers often follow a design principle where they break the problem into tasks which are then solved asynchronously and concurrently on different threads. This paper investigates the problem of model checking programs that follow this id- iom. We present a programming language SPL that encapsulates this design pat- tern. SPL extends simplified form of sequential Java to which we add the ca- pability of making asynchronous method invocations in addition to the standard synchronous method calls and the ability to execute asynchronous methods in threads atomically and concurrently. Our main result shows that the control state reachability problem for finite SPL programs is decidable. Therefore, such mul- tithreaded programs can be model checked using the counter-example guided abstraction-refinement framework. 1 Introduction Multithreaded programming is often used in software as it leads to reduced latency, improved response times of interactive applications, and more optimal use of process- ing power. Multithreaded programming also allows an application to progress even if one thread is blocked for an I/O operation. However, writing correct programs that use multiple threads is notoriously difficult, especially in the presence of a shared muta- ble memory. Since threads can interleave, there can be unintended interference through concurrent access of shared data and result in software errors due to data race and atom- icity violations.
    [Show full text]
  • Lecture 26: Creational Patterns
    Creational Patterns CSCI 4448/5448: Object-Oriented Analysis & Design Lecture 26 — 11/29/2012 © Kenneth M. Anderson, 2012 1 Goals of the Lecture • Cover material from Chapters 20-22 of the Textbook • Lessons from Design Patterns: Factories • Singleton Pattern • Object Pool Pattern • Also discuss • Builder Pattern • Lazy Instantiation © Kenneth M. Anderson, 2012 2 Pattern Classification • The Gang of Four classified patterns in three ways • The behavioral patterns are used to manage variation in behaviors (think Strategy pattern) • The structural patterns are useful to integrate existing code into new object-oriented designs (think Bridge) • The creational patterns are used to create objects • Abstract Factory, Builder, Factory Method, Prototype & Singleton © Kenneth M. Anderson, 2012 3 Factories & Their Role in OO Design • It is important to manage the creation of objects • Code that mixes object creation with the use of objects can become quickly non-cohesive • A system may have to deal with a variety of different contexts • with each context requiring a different set of objects • In design patterns, the context determines which concrete implementations need to be present © Kenneth M. Anderson, 2012 4 Factories & Their Role in OO Design • The code to determine the current context, and thus which objects to instantiate, can become complex • with many different conditional statements • If you mix this type of code with the use of the instantiated objects, your code becomes cluttered • often the use scenarios can happen in a few lines of code • if combined with creational code, the operational code gets buried behind the creational code © Kenneth M. Anderson, 2012 5 Factories provide Cohesion • The use of factories can address these issues • The conditional code can be hidden within them • pass in the parameters associated with the current context • and get back the objects you need for the situation • Then use those objects to get your work done • Factories concern themselves just with creation, letting your code focus on other things © Kenneth M.
    [Show full text]
  • An Enhanced Thread Synchronization Mechanism for Java
    SOFTWARE—PRACTICE AND EXPERIENCE Softw. Pract. Exper. 2001; 31:667–695 (DOI: 10.1002/spe.383) An enhanced thread synchronization mechanism for Java Hsin-Ta Chiao and Shyan-Ming Yuan∗,† Department of Computer and Information Science, National Chiao Tung University, 1001 Ta Hsueh Road, Hsinchu 300, Taiwan SUMMARY The thread synchronization mechanism of Java is derived from Hoare’s monitor concept. In the authors’ view, however, it is over simplified and suffers the following four drawbacks. First, it belongs to a category of no-priority monitor, the design of which, as reported in the literature on concurrent programming, is not well rated. Second, it offers only one condition queue. Where more than one long-term synchronization event is required, this restriction both degrades performance and further complicates the ordering problems that a no-priority monitor presents. Third, it lacks the support for building more elaborate scheduling programs. Fourth, during nested monitor invocations, deadlock may occur. In this paper, we first analyze these drawbacks in depth before proceeding to present our own proposal, which is a new monitor-based thread synchronization mechanism that we term EMonitor. This mechanism is implemented solely by Java, thus avoiding the need for any modification to the underlying Java Virtual Machine. A preprocessor is employed to translate the EMonitor syntax into the pure Java codes that invoke the EMonitor class libraries. We conclude with a comparison of the performance of the two monitors and allow the experimental results to demonstrate that, in most cases, replacing the Java version with the EMonitor version for developing concurrent Java objects is perfectly feasible.
    [Show full text]
  • Designing for Performance: Concurrency and Parallelism COS 518: Computer Systems Fall 2015
    Designing for Performance: Concurrency and Parallelism COS 518: Computer Systems Fall 2015 Logan Stafman Adapted from slides by Mike Freedman 2 Definitions • Concurrency: – Execution of two or more tasks overlap in time. • Parallelism: – Execution of two or more tasks occurs simultaneous. Concurrency without 3 parallelism? • Parts of tasks interact with other subsystem – Network I/O, Disk I/O, GPU, ... • Other task can be scheduled while first waits on subsystem’s response Concurrency without parrallelism? Source: bjoor.me 5 Scheduling for fairness • On time-sharing system also want to schedule between tasks, even if one not blocking – Otherwise, certain tasks can keep processing – Leads to starvation of other tasks • Preemptive scheduling – Interrupt processing of tasks to process another task (why with tasks and not network packets?) • Many scheduling disciplines – FIFO, Shortest Remaining Time, Strict Priority, Round-Robin Preemptive Scheduling Source: embeddedlinux.org.cn Concurrency with 7 parallelism • Execute code concurrently across CPUs – Clusters – Cores • CPU parallelism different from distributed systems as ready availability to shared memory – Yet to avoid difference between parallelism b/w local and remote cores, many apps just use message passing between both (like HPC’s use of MPI) Symmetric Multiprocessors 8 (SMPs) Non-Uniform Memory Architectures 9 (NUMA) 10 Pros/Cons of NUMA • Pros Applications split between different processors can share memory close to hardware Reduced bus bandwidth usage • Cons Must ensure applications sharing memory are run on processors sharing memory 11 Forms of task parallelism • Processes – Isolated process address space – Higher overhead between switching processes • Threads – Concurrency within process – Shared address space – Three forms • Kernel threads (1:1) : Kernel support, can leverage hardware parallelism • User threads (N:1): Thread library in system runtime, fastest context switching, but cannot benefit from multi- threaded/proc hardware • Hybrid (M:N): Schedule M user threads on N kernel threads.
    [Show full text]
  • Assessment of Barrier Implementations for Fine-Grain Parallel Regions on Current Multi-Core Architectures
    Assessment of Barrier Implementations for Fine-Grain Parallel Regions on Current Multi-core Architectures Simon A. Berger and Alexandros Stamatakis The Exelixis Lab Department of Computer Science Technische Universitat¨ Munchen¨ Boltzmannstr. 3, D-85748 Garching b. Munchen,¨ Germany Email: [email protected], [email protected] WWW: http://wwwkramer.in.tum.de/exelixis/ time Abstract—Barrier performance for synchronizing threads master thread on current multi-core systems can be critical for scientific applications that traverse a large number of relatively small parallel regions, that is, that exhibit an unfavorable com- fork putation to synchronization ratio. By means of a synthetic and a real-world benchmark we assess 4 alternative barrier worker threads parallel region implementations on 7 current multi-core systems with 2 up to join 32 cores. We find that, barrier performance is application- and data-specific with respect to cache utilization, but that a rather fork na¨ıve lock-free barrier implementation yields good results across all applications and multi-core systems tested. We also worker threads parallel region assess distinct implementations of reduction operations that join are computed in conjunction with the barriers. The synthetic and real-world benchmarks are made available as open-source code for further testing. Keywords-barriers; multi-cores; threads; RAxML Figure 1. Classic fork-join paradigm. I. INTRODUCTION The performance of barriers for synchronizing threads on modern general-purpose multi-core systems is of vital In addition, we analyze the efficient implementation of importance for the efficiency of scientific codes. Barrier reduction operations (sums over the double values produced performance can become critical, if a scientific code exhibits by each for-loop iteration), that are frequently required a high number of relatively small (with respect to the in conjunction with barriers.
    [Show full text]