dataesr/scientific-paragraphs-categorization huggingface dataset:
PHARAON system design flow The targeted design flow in PHARAON drives the design from UML specifications to implementation of cross-compiled code onto the target platform. During this process, parallelization analysis, code synthesis and power management components are added to the original functional code in order to optimize the use of the target platform. As depicted in Fig. 2 , the proposed flow starts by modeling the top-level application architecture with a high level componentbased approach (UML/MARTE). The use of this methodology enables the PHARAON flow to separately map various application components to resources within homogeneous, heterogeneous and distributed platforms. In order to enable this, the business code for each component (C/C++ files) has to be provided. This approach enables a two level design approach, combining a coarse grain, and a fine grain level.
In a second stage, the parallelization tool allows the designer to understand the underlying computational structure of the C code, and use this to further parallelize the internal code of the component. Based on user decisions, the parallelization tool then generates code integrating OpenMP/OpenStream parallelization directives. In a third stage, the optimized code is simulated again on the performance evaluation tool both to evaluate the quality of the parallelization (and optionally improve it by using the parallelization tool again), and to obtain the information required for runtime optimization. Alternatively, the code can be implemented and measured onto the physical platform, if that is already available. Finally, different runtime managers (a reconfiguration manager and a low-power scheduler) are deployed on the physical platform in order to reduce power consumption while ensuring required application performance.
Code generator From the information included in the UML/MARTE graphical model, the inputs for the different tools of the flow are created. This generation process is performed in two steps. First, an Eclipse plugin has been developed, capable of transforming the graphical model into a set of XML files. From these files, the generator produces a set of C files that includes the code required to initialize all the components mapped to each memory space, the C wrappers that enable the communication among the application components, the different agents handling incoming communication requests, and the platform-specific compilation scripts. The interface wrappers use the facilities provided by a communication library that has been specifically developed to implement the various communication mechanisms.
The Pareon tool is a collection of command line interface (CLI) tools and a GUI. Within the PHARAON project the CLI tools are used in the automated toolchain, while the GUI enables human inspection of the modeling results. The input to the tools is the source code of a C or C++ program. The input program should comply with the ANSI C99 or ANSI C++98 standards and may contain selected POSIX function calls. In particular, parallel programs with POSIX threads such as pthread_create() and pthread_join() can be analyzed in terms of their timing and energy consumption. Furthermore, the latest release of Pareon supports OpenMP pragmas, in order to handle the fine grained parallelization strategy used in PHARAON. Overall, analysis of parallel code enables closing the loop in the PHARAON toolchain and optimizing already parallelized applications by looking at their performance and energy consumption estimates.
The vfcc compiler translates the input source code into a generic executable for an intermediate instruction set architecture, which is independent of the target processor. Then the generic executable is run in the Pareon simulator with the provided execution environment, including necessary test data, input files, environment variables, etc. During the execution various statistics such as instruction counts and memory behavior are collected. Finally, the Pareon report command converts these statistics into estimates for a particular hardware target platform and generates an XML output file with performance and power estimates of the input program, to be used by the parallelization tool. The internal Pareon toolflow for performance analysis is shown in Fig. 6  and an extensive documentation of the Pareon functionality is available online at  [10].
ParTools parallelisation toolset The ParTools toolset  [16, 17]  addresses the parallelization of legacy sequential C software that can include also complex control structures, pointer operations, and dynamic memory allocation. It can discover both task and data parallelization opportunities and can be used for any parallelization technique, including in particular both the UML/MARTE-based method used in the PHARAON flow for coarse grain parallelization the OpenMP/OpenStream pragmas used for fine grain parallelization. The toolset flow shown in Fig. 7     function calls) and edges representing the data dependencies. All elements are uniquified based on the execution call stack. In order to make the huge data dependency graph easy to visualize and understand, the nodes for complex program structures (e.
OpenMP extension for data-flow and stream parallelism OpenStream (http://www. di. ens. fr/OpenStream) is a stream programming language, designed as an incremental extension to the OpenMP parallel programming language  [12]. It allows expressing arbitrary task-level data flow dependence patterns. Programmers expose task parallelism and provide data-flow information to the compiler through compiler annotations (pragmas), used to generate code that dynamically builds a streaming program. The language supports nested task creation, modular composition, variable and unbounded sets of producers/consumers, and first-class streams. These features, enabled by an original GCC-based compilation flow, allow translating high-level parallel programming patterns into efficient data-flow code. Data-flow execution is essential to reduce energy consumption, one of the primary focuses of the PHARAON project, by reducing the severity of the memory wall.
This is achieved in two complementary ways: (1) thread-level data flow naturally hides latency; and (2) decoupled producer-consumer pipelines favor on-chip communication, bypassing global memory. Furthermore, Open-Stream has shown excellent performance in comparison with state-of-the-art parallel programming environments like StarSs, as illustrated in Fig. 11 , showing 1  the speedups achieved by Open-Stream (red) and StarSs (blue) against sequential execution for a block-sparse matrix LU factorization on a dual-socket AMD Opteron 6164HE machine with 2 Â 12 cores at 1. 7 GHz. Key to the efficient execution of OpenStream programs is our optimized runtime system, providing low-overhead synchronization and work-stealing scheduling. Work stealing is a central component of the OpenStream runtime library, allowing for efficient lock-free scheduling of lightweight tasks.
Data-flow synchronous programming of parallel embedded systems The PHARAON project also investigates longer-term research directions, such as the design and implementation of safety-critical embedded software running on parallel multicore processors. Heptagon is a data-flow synchronous language devoted to the design and implementation of embedded software. Its ancestors Lustre and Scade have met a large success in the field of safety-critical real-time systems, offering a clean semantics, with a robust, efficient, and traceable compilation flow, while enforcing bounded resource and bounded reaction-time guarantees. However, compilation schemes for such languages lead to very efficient, but sequential code. Various distribution and parallelization approaches can be applied a posteriori, at the price of performing a non-modular and hardly scalable static analysis of the generated code to guarantee efficiency and correctness.
Usual synchronous compilation leads to poor performance with the fast process waiting for the completion of the slower one, as seen in the first figure. To leverage all the advantages of Heptagon while allowing for parallel code generation, we extend it with futures. At the source code level, futures may be seen as simple annotations leaving the functional semantics of the program unchanged. During the compilation phase, they are key to enable asynchronous calls while preserving memory boundedness. As seen in the second figure, our example can be efficiently compiled to parallel code by adding lightweight, semantics-preserving future annotations. Operations on arrays are frequent in embedded applications, as example applications studied in the PHARAON project show. It is thus very important when designing a dedicated programming language to offer high-level support together with efficient compilation techniques.
In practice, this means reducing the number of  array copies. The Heptagon compiler implements original techniques to this aim, based on a programmer-guided, modular inter-procedural memory allocation procedure  [14]. Finally, we are now studying the marriage of the data-flow synchronous paradigm with computational models dedicated to highperformance regular algorithms, such as SDF/CSDF graphs, with the intuition that the result will be more than the sum of its parts. We believe that considering communication rates as a first class citizen of a language semantics is key to next generation tools for embedded platforms, reconciling programmer productivity, efficient and predictable compilers and analyzers, and parallel hardware.
Whereas the functional specification of an application mode is fixed, there may be several specific algorithms or implementations for a given task (e. g. a Fast Fourier Transform (FFT)). Additionally, to alleviate the run-time decision making, the RTPM must obtain information from design-time exploration. This exploration is performed per application on a representative set of available input data for all possible application modes, allowed QoS requirements, application parallelizations and data managements. This leads to a multi-dimensional set of Pareto-optimal application configurations, illustrated in Fig. 16. The average costs and the platform resource usage on this representative set are also reported in the multi-dimension set. The Pareto set of each application is an input for the RTPM.
Low power scheduler The low-power scheduler takes as an input the selected application configuration mode, defined by the RTPM. It takes into account a predefined SW configuration (application mode, associated deadlines, tables with the expected timing for various code segments) and HW configuration (number of active cores, voltage/frequency mode, task affinity to specific cores). The low-power scheduler developed in PHARAON actually combines a classical Earliest  As depicted in Fig. 17 , the power management policy relies on: (1) monitoring the application Actual Execution Time (AET) and (  2 ) comparing it with the Worst Case Execution Time (WCET). To reduce power consumption while still complying with the application deadline, the scheduler tries to minimize the core idle time by: (A) spreading tasks on as many active cores within the SMP as possible, and (B) lowering as much as possible the core voltages and frequencies.
It contains the names of all the segments in the application, together with their associated WCETs at the different core operating points and their deadlines. Implementation of this scheduler has been done in user space for portability reasons, but implementation in kernel space could also be possible. It requires a FIFO priority-based task scheduler, a hardware platform with DVFS capabilities and an application with POSIX threads. In PHARAON, experimentations will be done on a multicore Cortex-A9 platform with a Linux-SMP OS and the CPUfreq framework. Relying on CPUfreq, which provides a standard HW layer abstraction, allows the approach to be transparently compatible, among others, with future HMP platforms based on big. LITTLE architectures. In the scope of the PHARAON project, applications must be manually instrumented with the defined APIs.
Some results are shown in the next table (see Table  2 ). At the same time, the ParTools suite was used to discover the best parallelization candidates and to analyze their data dependencies for the stereo vision use case. Based on these results, two parallelization strategies were decided for a target architecture made of 2 i5 cores running at 1. 20 GHz (i5-3230 M): 1. Four data-parallel hotspots, using OpenMP. 2. Several SIMD conversions using the target architecture support for vector operations. The processing times of the test images of 1024Â768 pixels can be found in Table  3. As can be shown, the combined optimizations achieved a maximum speed-up of 4 times.
Model-based software engineering offers several attractive benefits for the implementation of protocols, including automated code generation for different platforms from design-level models. In earlier work, we have proposed a template-based approach using Coloured Petri Net formal models with pragmatic annotations for automated code generation of protocol software. The contribution of this paper is an application of the approach as implemented in the PetriCode tool to obtain protocol software implementing the IETF WebSocket protocol. This demonstrates the scalability of our approach to real protocols. Furthermore, we perform formal verification of the CPN model prior to code generation, and test the implementation for interoperability against the Autobahn WebSocket test-suite resulting in 97% and 99% success rate for the client and server implementation, respectively.
In CPNs, Petri Nets provide the primitives for modelling concurrency and synchronisation while the Standard ML programming language provides the primitives for modelling data and data manipulation. CPNs have been successfully applied for the modelling and verification of many protocols, including Internet protocols such as the TCP, DCCP, and DYMO protocols  [2, 11]. Formal modelling and verification have been useful in gaining insight into the operation of the protocols considered and have resulted in improved protocol specifications. However, earlier work has not fully leveraged the investment in modelling by also taking the step to automated code generation as a way to obtain an implementation of the protocol under consideration. In earlier work  [15] , we have proposed the PetriCode approach and developed a supporting software tool  [17]  for automatically generating protocol implementations based on CPN models.
The basic idea of the approach is to enforce particular modelling patterns and annotate the CPN models with code generation pragmatics. The pragmatics are bound to code generation templates and used to direct the model-to-text transformation that generates the protocol implementation. As part of earlier work, we have demonstrated the use of the PetriCode approach on small protocols. In addition, we have shown that our approach supports code generation for multiple platforms, and that it leads to code that is readable and also upwards and downwards compatible with other software  [16]. The main contribution of this paper is to demonstrate that our approach and tool scale to support an industrial-sized protocol by automatically generating code for the WebSocket  [5]  protocol for the Groovy  [7]  platform.
The WebSocket protocol is a relatively new protocol currently under development by the IETF. The WebSocket protocol makes it possible to upgrade an HTTP connection to an efficient message-based full-duplex connection. The WebSocket protocol address the performance problems of the HTTP protocol caused by the requestresponse interaction model and verbose headers. This is done by allowing HTTP to upgrade to a WebSocket connection in which a session is kept alive and messages may be transmitted in both directions freely with much lower overhead than with HTTP. WebSocket has already become a popular protocol for several web-based applications where bi-directional communication with low latency is needed such as games and media streaming services. The contributions of this paper include showing how we have been able to model the WebSocket protocol following the PetriCode modelling conventions, and to verify the model through state space exploration.
Furthermore, we demonstrate in this paper that the generated code is interoperable with other WebSocket implementations, and we test the our implementation using the Autobahn WebSocket test-suite  [18]. Outline. Section 2 presents the CPN model of the WebSocket protocol. In Sect. 3 we show how state space exploration was used to verify the operation of the model focusing on the proper establishment and termination of WebSocket connections. Section 4 describes the procedure to generate an implementation of the WebSocket protocol from the CPN model using the PetriCode tool. In Sect. 5, we present the results from testing the generated code by showing that it is interoperable with other WebSocket implementations and by employing the Autobahn WebSocket test-suite. Finally, in Sect. 6 we provide a discussion of related work, and sum up the conclusions and directions for future work.
Due to space limitations, we refer to  [8]  for a detailed introduction to CPN concepts. The CPN model of the WebSocket protocol follows the structure imposed by our code generation approach, and consists of a set of modules hierarchically organised into three levels: the protocol systems level, the principal level, and the service level. In the following, we present representative parts of the CPN model which was constructed using CPN Tools  [4]. Figure  1  shows the top-level module of the CPN model constituting the protocol system level. The protocol system consists of a Client and a Server principal as modelled by the two accordingly named substitution transitions drawn as rectangles with a double-lined border. These two substitution transitions are annotated with the principal code generation pragmatic to denote that they represent protocol principals.
CPNs have a formal semantics which makes it possible to conduct model simulation and model checking (verification) prior to code generation. This is a major advantage of an approach based on a formal modelling language as this can be used to eliminate design errors prior to code generation and testing of the generated protocol implementation. CPN Tools used for construction of the WebSocket CPN model supports model checking of behavioural properties by means of state space exploration. The basic idea of state space exploration is to explore all the reachable states of the model to determine whether a model satisfies a given property or not. This means that state space exploration will exhaustively explore (test) all the possible executions of the CPN model. As the CPN model specifies the behaviour of both the client and the server, the state space exploration exercises the client against all the possible behaviours of the server and visa versa.
Our aim has been to apply state space exploration of the CPN model as a first test to eliminate possible errors in the logical specification of the WebSocket protocol. For this, we adopted a lightweight approach where we consider the following behavioural properties P0, P1 and P2 of the CPN model: P0 From the initial state it is possible to reach states in which the WebSocket connection has been opened (i. e. , both the client and the server are in the open state). In the model this means that the places names OPEN in the Client and the Server modules each have one token and none of the other places other places modelling the life-cycle of the principals have a token. It should be noted that we cannot establish that the WebSocket connection will eventually be opened since the server side may initiate a close before the client side is in the open state.
P1 All terminal states (i. e. , states without enabled transitions) correspond to states in which the WebSocket connection has been properly closed (i. e. , both the client and the server are in the closed state). In the model this means that the places named CLOSED in the Client and Server modules each have one token and that none of the other places modelling the life-cycle of the principals have a token. P2 From any reachable state, it is always possible to reach a state in which the WebSocket connection has been properly closed. This means that independently of how messages are exchanged, it is always possible to properly close the WebSocket connection. In order to check that in all terminal states both the client and the server are in the closed state, we wrote a simple query in the Standard ML language using functions that are built into CPN Tools.
Automated Code Generation In this section we describe the code generation process for the WebSocket protocol targeting the Groovy platform and illustrate it with examples of code generation templates and code snippets. Groovy is also the implementation language of the PetriCode tool  [17]  and has been chosen because it has several features that makes it easy to implement and debug templates including dynamic typing, closures and iterators. The automatic code generation process, as implemented in the PetriCode tool, starts with a CPN model annotated with pragmatics. The model is first transformed into an intermediary representation in the form of an abstract template tree (ATT). The ATT reflects the hierarchical structure of the CPN model down to the service level. On the service level, the ATT contains blocks that are derived from the control flow path specified by the Id pragmatics of the service level modules.
Then the traversal continues to the child nodes of the principal. When the generation traverses child nodes of a principal and encounters a node containing a service or internal pragmatic it executes the service template. The code generation for the principal is completed by replacing a special tag, %%yield%% with the result for the service template for all underlying services. The generated code of the client with declaration and method bodies omitted is shown in Listing 1. 2. As can be seen when comparing with Fig 2, there is one method defined for each external and internal service. This comprises the API for the WebSocket client implementation with all the callable methods and their signature. The template for the service pragmatic is shown in Listing 1. 3. Lines 1-2 define a new method and its signature.
If the buffer is empty the variable given in the first parameter to the pragmatic is set to null. The generated code for the getMessage service is shown in 1. 5. Lines 1-4 and 21 are generated by the service template. The rest of the code, except from the return line, follows the template for getMessage where the first and second Listing 1. 4. The template for the getMessage pragmatic. parameters have been replaced with inBuffer and message respectively since those are the two parameters given to the pragmatic in Fig. 4. 1 if(${params[1]} != null && ${params[1]}. size() > 0){ 2 ${params[0]} = ${params[1]}. remove(0) 3 In order to generate code for the WebSocket protocol, we reused 10 templates from the library of templates provided by PetriCode. In addition, 22 new templates were needed, including two templates that override existing templates.
Testing the Generated WebSocket Implementation We validated the operation and interoperability of the generated code in two ways. First, we created test drivers for the generated WebSocket implementation to connect to the example chat server and client  [1]  that comes with the GlassFish Listing 1. 6. The code for the client runner. Application Server  [14]. Secondly, we submitted the generated implementation to the Autobahn Testsuite  [18]  version 0. 5. 5 1. Chat Application. The code for the chat client using the generated API (cf. Listing 1. 2) is shown in Listing 1. 6. The chat client uses the generated WebSocket protocol as an API given the signatures of the principal level. The client begins by creating a Client object from the generated code and opens a WebSocket connection to the server.