dataesr/scientific-paragraphs-categorization huggingface dataset:
We present a source-to-source auto-generating framework that enables a large programmer community to easily and safely implement parallel stencil codes within the framework of Ordered Read-Write Locks (ORWL). It meets the specific needs of the application at a high level of abstraction. ORWL is an inter-task synchronization model for iterative data-oriented parallel and distributed algorithms that uses strict FIFO ordering for the access to all resources. It guarantees equity, liveness and efficiency for a wide range of applications. The main hurdle for using ORWL lies in its initialization phase, where the programmer has to specify the access scheme between tasks and resources and the initial positions of the tasks in the FIFOs. We provide a userfriendly interface based on a Domain-Specific Language (DSL) that captures domain semantics and automatically generates ORWL parallel high-performance stencil code.
Génération automatique de programmes pour des calcul multi-dimensionnels de type stencil Résumé : Nous présentons un outil de génération automatique source-à source de code qui permet à une grande communauté de programmeurs d'implémenter des codes stencils dans le cadre des verous ordonnés de lecture-écriture (ORWL), et ceci de façon facile et sûre. L'outil proposé remplit les besoins spécifiques pour permettre un niveau d'abstraction élevé. ORWL est un modèle de synchronisation entre tâches pour des calculs itératifs qui sont centrés sur les données. Il utilise un ordonnocement strict imposé par des files d'attentes qui sont associées à toutes les resources. Ainsi, il garantit l'égalité, la vivacité et l'efficacité pour une large catégorie d'applications. L'obstacle majeur pour l'utilisation d'ORWL est sa phase d'initialisation, où le programmeur doit spécifier le schéma d'accès entre tâches et resources, ainsi que les positions initiales des tâches dans les files d'attente.
Our approach is to add a layer, based on an implicitly parallel domain-specific language (DSL),  [7]  on top of ORWL. On one hand, DSLs offer appropriate domain-specific notations, constructs and abstractions, improve the expressiveness and thus the productivity in the particular domain they are designed for, compared with general-purpose programming languages (GPL). On the other hand, DSLs achieve code efficiency thanks to the incorporated domain-specific knowledge. DSLs usually provide acceptable performance and can sometimes reach the performance levels that are attained by hand-coded implementations. Thereby, they allow to balance RR n°8928 programmability and performance. Not surpisingly, in recent years, DSLs have been widely used in parallel programming to spare the user the details and the complexity related to parallel programming.
In particular, numerous research efforts have adopted DSL solutions to optimize stencil computations. Some of them, suggest autotuning frameworks for multicore architectures  [8]  and GPU accelerators within DSLs  [9, 10]. Others suggest DSL-based stencil compiler transformations to generate efficient code for GPUs and multicore processors  [11]. The Pochoir stencil compiler  [12] , for example, uses cache-oblivious parallelograms for parallel execution on shared-memory systems to produce high-perfomance code for stencils. With this work, we propose a DSL-based solution to make stencil implementations within the ORWL framework simpler and more user-friendly. By that, we bridge the gap between productivity and high performance. We aim to allow scientific domain experts or average programmers to develop ORWL stencil codes that meet their specific application needs without becoming experts in parallel programming in general nor in ORWL in particular.
Our main contributions are: • We provide a user-friendly interface based on a Domain-Specific Language (DSL) that captures high level stencil abstractions and automatically generates ORWL parallel high-performance stencil code. • We present a pattern for ORWL that we call ComUP, that is relevant for all ORWL implementations not only for stencil computations. It ensures expressiveness, deadlock-freeness and better performance for ORWL programs. • We show that the DSL achieves a huge progress in terms of programmer productivity without sacrificing the performance. We expose the complexity of the generated code and the amount of complex details the DSL spares the user. • We present experiments that prove the efficiency and scalability of the generated code that outperforms hand-crafted code. The remainder of this paper is organized as follows.
ORWL Overview ORWL (Ordered Read-Write Locks) is an inter-task synchronization paradigm for resource-oriented parallel and distributed algorithms. It provides synchronization methods that allow an implicit deadlock-free and equitable control of protected resources. Here, a resource can be an abstraction of data, hardware or software on which tasks interact. ORWL provides a way to control the execution order of tasks based on their data dependencies. It is based on the following features: 1. An access queue (FIFO) for each such lock. 2. An explicit association of a lock with each resource. 3. A distinction between locking for writing (exclusive) and locking for reading (inclusive). 4. A three-step lock operation by a sequence of request (queue insertion), acquire (blocking until first in queue) and then release.
An implementation of the ordered read-write lock paradigm using standard languages and interfaces (C and POSIX), has been presented in  [13] , together with its basic use patterns. It can be used in shared, distributed or mixed contexts. Listing 2 -A critical section operating on one resource, accessed iteratively, through an orwl_handle2. /* bind the pair of handles to the resource */ o r w l _ w r i t e _ r e q u e s t Experiments have shown that ORWL is a powerful synchronization tool that guarantess liveness, equity and efficiency for a wide range of applications. It also presents a valid choice for out-of-core computation  [14].
A programming paradigm with a local view An ORWL program is specified as a local description of a set of equivalent tasks that compose the application and that are to be executed concurrently. Each task has a set of resources it "owns" and it executes its specific program code. A task can refer to one of its own resources (local) or those of other tasks (remote). The tasks interact through communication and synchronization operations via the locks they subsequently hold for these resources. This includes all operations executed on the locally owned resources. The tasks are realized by threads (local execution) and processes (remote execution) and the operations on the resources are implemented in shared memory, when possible, or through network communications on the socket level.
They have to define the ORWL data locations explicitly, allocate their associated buffers and write the update operations. These programming tasks are by far longer and more involved than the computational kernel they serve. Additionally, it is very likely that the programmer makes mistakes when writing the indices in the complex update operations that have to be specified by using the halo margin offsets in each direction of the problem grid. The more dimensions the main data has, the more complex the indices become and the higher is the risk of making mistakes. With our DSL, we spare the programmer from writing complex indices and error-prone parts, by fully generating them. Apart from that, it is difficult for non-experienced developers to achieve good parallel performance results, be it by using ORWL or any other programming framework.
RR n°8928 Listing 3 -Livermore Kernel 23. for ( i = 1; i < N -1; ++ i ) { for ( j = 1; j < M -1; ++ j ) { q = data [i -1][ j ] * zb [ i ][ j ] + data [ i ][ j -1] * zv [ i ][ j ] + data [ i ][ j +1] * zu [ i ][ j ] + data [ i +1][ j ] * zr [ i ][ j ] + zz [ i ][ j ] -data [ i ][ j ]; data [ i ][ j ] += 0. 175 * q ; } } • Game of life: a 2D 9-point stencil. • Livermore Kernel 23. The Livermore Kernel 23, a classic benchmark taken from LINPACK, has always been considered as a refernce benchmark for ORWL. As shown in Listing 3, it is a 5-point Stencil. Each element is updated by the element at the same position from the previous iteration and 4 neighbors offset by 1 on each direction. This stencil algorithm is cache-unfriendly. It has the partcicularity that data grows quickly in memory, as it requires a set of five coefficient grids (zb, zv, zu, zr and zz) in addition to the main data grid, which makes the overall memory footprint bigger.
An ORWL pattern for stencil applications The aim of this work is to automate the generation of multidimensional stencil code within the ORWL platform. To this end, deep knowledge of the domain semantics was needed. We had first to analyze ORWL stencil implementations and extract the contraints they must meet in order to define a generalized use pattern that fulfills the deadlock-freeness and liveness proprieties for ORWL stencils. The pattern was extracted from 2D and 3D implementations and generalized for multidimensional stencils.
The CompUp form To enhance the expressiveness of our tool and make code generation easier, we agreed to express ORWL programs in a form that we named CompUp. Here, we cast an ORWL program in the form of three types of operations: local update, global update and compute. 1. The compute operation performs the computation. It reads the data that is imported by global update operations and saved on local buffers. Then, it executes the computation kernel and writes the results on the main location. 2. The local update operation ensures the data transfer between different resources of the same task. It reads the updated data from the main location and stores it in buffers to make it available for neighboring tasks. 3. The global update operation ensures the external communication between the current task and other tasks.
RR n°8928 5 Dido: a DSL for ORWL stencils Our DSL is intended to generate ORWL code following the pattern we have described above (cf. Section 4). Therefore, additional parameters have to be provided by the user, specifying the topology and size of their specific problem instance. Our framework enables the description of those parameters in a concise and intuitive syntax. The user provides specifications written in the introduced language. These are parsed in order to extract stencil features that are used, in a second step, to generate the corresponding ORWL code. The DSL enables a natural description of the parallel computation, where the compute kernel itself is specified in the form of a conventional (sequential) C function. The name of a header file that contains this function is specified within the DSL.
This choice is made on purpose. It allows to handle all types of stencil computations, makes it possible to combine different types of statements that may be needed by the user, and allows to reuse legacy code, easily. Listing 4 shows a specification of a 2D stencil computation within the DSL. The main data (see Line 1) is specified by its name (here za), dimension (2D), and names for the problem axes (x and y). The auxiliary data, for their part, are specified by their names. According to a naming convention, these names will be used for the generation of the ORWL location and task identifiers. The convention has been chosen carefully in order to guarantee the readability and expressiveness of the generated code. The user has to provide a header file (here "type. h") that contains all types, data structures and scalar contstants that are necessary for the application on the level of the C code (see Line 9).
This header file will then be included in the generated C code of the ORWL program. They also have to specify the data type of the main data elements (see  Line 14). It can be either a basic type (float, double, char, etc. ) or an aggregate data type that has to be defined in the specified type header file. Additionally, to be able to handle high order stencils, the halo of the computation has to be specified (see  Line 10) , as well as the number of previous iterations involved in the computation (see  Line 11). The latter is needed, because in the computate kernel the user may reuse data elements from previous iterations. There is also one crucial element to be specified, which is whether the computation involves other elements or not. Furthermore, to match the needs of real applications, we provide different ways to specify the boundary conditions.
They can either be a constant value for borders (as in the example, Line 12) or define a specific function to compute element values on the edges. In order to save compile time and efforts, the DSL is divided into two parts: The first part encompasses structural parameters of the application. Those parameters define the problem and enable the generation of the most complex parts of the ORWL code. This includes the data locations, the operations, the handle initializations and the initial positions in the FIFOs and the critical sections. The compilation time of the ORWL code generated by this part of the DSL could be moderately long. The second part consists of the execution parameters for a particular problem instance. Here, the user should specify a header file (here "init. h") that contains initialization functions for the main and.
RR n°8928 Listing 4 -ORWL 2D Stencil specification within the suggested DSL. auxiliary data. A stopping criterion should also be provided. It can be either an iteration number (cf. Line 17) or a convergence criterion. They also have to specify the global size of the main data as well as the block sizes (see Line 18) into which it is partitioned. Finally, they have to specify the number of nodes on which the computation is deployed as well as the number of tasks per node (see Line 19-20). The code resulting from the structural part of the DSL can be used for different problem instances. The user has the option to generate all the code from scratch or just the main function depending on the execution parameters specified in the instantial part. Prior to code generation, the framework verifies that all the specified parameters within the DSL are coherent.
Structure of Generated Code Given a stencil specification that does not exceed a few lines of trivial code, the DSL generates handreds of lines of ORWL parallel code. It consists of C code with includes of both P99 1. and ORWL libraries. Apart from being correct and error-free, the generated code is well indented and readable thanks to the well-chosen naming conventions that are used to name the different tasks and locations. Listing 5 -Main function of ORWL genrated parallel code. int main ( int argc , char ** argv ) { orwl_init (); for ( s i z e t i = 0; i < orwl_ll ; i ++) { task_thread * task = P99_NEW ( task_thread ); * task = ( task_thread ) {. n = n ,. iterations = iterations ,. global_y = global_y , }; t a s k _ t h r e a d _ o p e r a t i o n ( task , orwl_locids [ i ]); } return EXIT_SUCCESS ; }.
An ORWL program: a loop over locations As an immediate result of the canonical form, the main function of an ORWL program is nothing but a loop over all ORWL locations as shown in Listing 5. For each location, an operation is automatically generated. That operation is then instantiated at run time by a separate thread. The type and structure of the operation, whether it is a global update, local update or compute, depends on the identifier of the associated location as shown in Listing 6.
Programmer Productivity The DSL was designed to improve the programmer productivity by sparing them from writing the complex parts of ORWL parallel code. Given a stencil specification that does not exceed a few lines of straightforward code, bare of any details needed for parallelization, hundreds of lines of code are generated. The generated code is guaranteed to be correct and error-free. Table  1  depicts the number of hand-written lines compared to the number of generated code lines for the considered benchmarks. The number of lines to be written by the user, in the case of 3D Jacobi for example, is reduced by 96%. We estimate this to be a considerable improvement in terms of programmer productivity. This measurement of a gain in productivity uses a comparison to explicit hand coding with ORWL.
We think that the result would not be much different if we would compare to coding with other paradigms for parallel computation, as long as these involve explicit creation of buffer space, data communications or access locks. Not only does the DSL reduces the number of hand-coded lines, but it also avoids to manually write complex and error-prone parts such as the halo region update operations. A lot of time and effort is saved by automatically generating the indexing expressions and communication statements. Table  2  list the number of complex programming details such as communication statements and indexing operations that are automatically generated by the DSL. For example, if the user had to write the ORWL parallel code of a 3D Jacobi without the aid of the DSL, they would have to handle 13 data locations.
Average computation time per matrix element The aim of this experiment is to study the variation of the average execution time per data element depending on the blocks' number and size. For the case of Livermore Kernel 23, we consider problems of 4, 16, 36, 64 and 100 blocks, where one compute node is reserved for each block. For each configuration, we increase the global problem size, until we reach the maximum size per block that fits into the RAM of the target machines. As shown in Figure  3 , the computation time per data element decreases when the problem size increases. It tends to a lower limit. The times for different block partitions are almost indistinguishable, especially for large block sizes. This proves that the overhead for subdividing into more blocks is negligible.
3D Jacobi This last experiment has been conducted on the grisou cluster of the Grid'5000 experimental testbed. Each node is composed of two CPUs, each having 8 cores at 2. 4 GHz, 126 GiB of memory and a Gigabit Ethernet interconnection network. We place 2 tasks per node on 8, 16, 24, 32, 40 and 48 nodes. Each task computes a 1000 3 block. Results are shown in Figure  6. We can notice from previous experiments that increasing the over-all problem size does not increase the average computation time per iteration, if we provide a proportional amount of compute nodes. Thus, the ORWL stencil modeling we have presented in Section 4 allows us to construct sizable applications. The DSL does not have any negative impact on the sizability of the generated ORWL stencil code. We have presented Dido, an implicitly parallel DSL for ORWL stencil code generation that achieves both productivity and performance benefits.
It allows a large programmer community to implement parallel multidimensional stencil computations and take advantage, at a low cost, of properties of the ORWL paradigm. It meets the needs of real applications by suppporting multiple data types and boundary conditions. The DSL captures high-level stencil abstractions written by the user in a simple syntax and generates all the complex parts such as the shadow region updates and the lock handle positions in the FIFOs. This presents a considerable improvement in terms of programmer productivity. Additionally, experiments have shown that productivity and performance, often considered as antagonistic, can be reconciled when using Dido. The generated code achieves competitive performance that is comparable with hand-crafted code. This is due to the domain-specific knowledge about ORWL that went into the defined patterns.
It has to be noted that the CompUp form that we have presented can be used for different ORWL applications not only for stencil computations. It ensures expressiveness, deadlock-freeness and better performance of ORWL programs. In the future, we plan to take the execution architecture into consideration such that architecture-adapted code can be generated. ORWL runtime can then ensure a better placement of the tasks, close to the resources. Later, we aim to enhance our first-cut design in order to cover a wider range of applications. One promising direction are sparse matrices and applications. This type of algorithms is in widespread use by scientific communities and lacks user-friendly specific tools.
Thus, the tools selected for this study were QlikView [7], Palo BI Suite  [8] , Jaspersoft BI  [9] , Tableau Public  [10] , Spago BI  [11] , and Pentaho BI Suite  [12]. The analysis of this type of software emerged during a project that included the development of a BI platform in Maternity Care to visualize clinician and management indicators, as well as integrating Data Mining (DM) predictive models. All the tools were tested using real data provided by the Centro Hospital do Porto (CHP) and Centro Materno Infantil do Norte (CMIN). With this study, it is intended to select the BI tool that best suits the healthcare sector by using a practical case. Besides the introduction, this article includes eight sections. The second section provides an approach to the background and related work, in which the concept of Business Intelligence is addressed and an introduction to the case study is presented.
Some of the Voluntary Interruption of Pregnancy Key Performance Indicators (KPIs) that health professionals have interest in are the following: All the information recorded in the CHP is stored in different systems, taking as an example the Nursing Support System (SAPE), where a portion of the data recorded in the VIP module is stored, and the Electronic Health Record (EHR), where all the patient data are stored. The Medical Information Integration, Dissemination and Storing Agency (AIDA) guarantees the interoperability of these systems. AIDA is a system of intelligent agents that allows communication between different information systems in CHP  [22, 23].
Applications of Open-Source BI Tools in Healthcare With the computerization of clinical processes in healthcare organizations, the storage of clinical data in databases has been increasing exponentially. However, a lack of technology to gather, analyze, and distribute the most relevant information makes these organizations rich in data but extremely poor in information  [3]. Nonetheless, forward-thinking healthcare organizations are aware that the data and its treatment through the Business Intelligence (BI) technology are essential for an informed and accurate decision-making process, as well as necessary to improve services and ensure the future of these organizations. Cases of adoption of open-source BI tools by healthcare organizations are scarce. However, the great benefits arising from its implementation in other areas have led to the introduction of BI technology in healthcare environments.
• Connection to the database: it is very important that the BI tool enables a connection to be established to different databases so that it is possible to integrate information from different data sources. There are tools where the only possibility of connection is inherent to data visualization, others in which the connection can be made via the ETL process and via data display, and, lastly, those in which the connection is made only via the ETL process. In a hospital, this is also a key feature because, normally, these organizations have interoperable systems, and it is common to have different databases with clinical information. Thus, in order to facilitate the construction of the data warehouse (DW), we must choose a specific tool for the construction of the DW and, subsequently, a tool of BI is used to create OLAP cubes in order to visualize performance indicators.