dataesr/scientific-paragraphs-categorization huggingface dataset:
Related work Tasks scheduling and memory mapping are extensive topics in computer science research work. Default policies are mainly focused on load-balancing, placing locality and affinity aside, which are of paramount importance in NUMA architectures. Different proposals can be found in the literature, each one with advantages and disadvantages. A considerable amount of proposals aim for Linux kernel modifications or modules to improve memory or thread placement. Carrefour, introduced by Dashti et al. [10] , proposes a modification of the kernel to prevent and alleviate memory congestion for NUMA systems, achieving improvements up to 3. 6× compared to the original kernel and other popular modifications like AutoNUMA  [11]. Carrefour uses hardware counters to measure performance, and, according to the authors, it takes global decisions to migrate memory pages, while letting the Operating System deal with the thread placement.
Again, thread mapping is entrusted to the OS. With this approach, BWAP improves up to 66% the performance of the system. User space tools for thread and memory mapping is the least explored approach, but there are interesting works, like Asym-Sched, by  Lepers et al. [18]. This tool implements a dynamic thread and memory placement algorithm in Linux to improve performance in non-symmetric NUMA systems. Using hardware counters information during runtime, AsymSched computes the best thread and memory location every second, just focusing on maximising the bandwidth for communicating threads. This approach obtains important performance improvements in single and multiple application workloads. The experiments are done in AMD processors, that lack some features present in Intel architectures, like the measurement of memory accesses latency, which should help in improving memory transactions.
DeLoc  [19]  is a tool that computes the optimal mapping after an initial profile phase where the communication and memory data are gathered and recorded. The computed mapping tries to improve the locality and reduce memory congestion. With this approach, the authors claim that performance can be improved by 61% compared to the AutoNUMA Linux policy. Finally, it should be mentioned that thread mapping is not limited to NUMA systems, since multi-core systems can benefit from this kind of strategies too. In  [20] , an affinity and architecture-aware thread mapping technique is proposed to optimise data reuse, remote communications, and cache coherency costs of multi-threaded applications. Application-specific data dependency signatures are created, collecting data from previous executions, and they are used to determine the appropriate thread mapping of application for a given architecture.
A score is assigned to each candidate migration involving threads in such a way that a higher score means a more likely improvement in performance. For memory pages, an analysis of the latency of every memory page and the average latency of the system is performed with a double purpose: first, look for NUMA nodes that present high latencies (considering them too busy) to balance workload, and to determine if a memory page can be placed in another node that lowers the latency of its accesses. This approach introduces low overhead and does not need previous profiling phases, nor modification of the Linux kernel or the target code. A comparison of the most relevant proposals with ours is included in Table  1  showing the most important features.
Kernel and user space migrations There are two ways of implementing thread and memory migration strategies, by either using kernel or user space. Both have advantages and disadvantages that are worth discussing. Algorithms in kernel space benefit from having all the information of the system available, like used CPU-time, the current location of memory pages, number of page faults, etc. Also, all the processes of the system are in disposition to have their threads or memory pages migrated, with no restriction on permissions. This gives full control over the system, and with great power comes great responsibility. Nevertheless, those algorithms require modifications of the Linux kernel, implying some disadvantages. Modifying the kernel might be an expensive task in terms of programming time to make the algorithms work, solving bugs and so on, thus slowing down the research work.
Also, for final users, those patches might not be available due to compatibility issues (like different kernel versions) or, mainly, restrictions in permissions to install and use those patches or modules. User space tools, on the other hand, work with a limited amount of information, mostly restricted to what is available in /proc directory and the information available through performance profiling. They are also limited to migrating user-level threads and their memory pages due to how Linux permissions work. Note that this should not be a big issue since kernel threads are light processes in terms of computational demands. Also, user space tools are a step behind the operating system since the migration tool can reallocate resources only after the initial allocation is decided by the OS.
$ thanos [options] <target> where target is the program whose threads and memory pages will be controlled by the migration tool. If you want to include more than one program, they must be included in a shell script that will serve as target. Note that the tool will only migrate the threads and memory pages of the target program or script. The rest of the threads and memory pages in the system are not affected nor taken into account by this tool. The only requirement for this tool to work resides in the content of the file perf_event_paranoid, which must be set to a negative integer value or zero to allow the collection of the hardware counters samples.
• Â (ψ i , ν n , τ t ) is the number of accesses performed by all threads running in the node ν n to data located in the memory page ψ i. • L ( θ ij , ν n , τ t ) is the average latency of the memory operations performed by thread θ ij while running in the node ν n. • L (ψ i , ν n , τ t ) is the average latency of the accesses performed by all threads running in the node ν n to data located in the memory page ψ i. • L (ν n , τ t ) is the average latency of the accesses performed by all threads running in the node ν n to data located in any memory page. 1 Software available at https://gitlab. citius. usc. es/ruben. laso/migration. • L (ψ i , τ t ) is the average latency of the accesses performed by all threads running in the system to data in the memory page ψ i. • L (τ t ) is the average latency of the accesses performed by all threads in the system to all memory pages.
Experimental environment The experiments described in this section have been carried out using two NUMA servers with different topologies and different values for memory access latencies and memory bandwidth. Latency and bandwidth matrices shown in Tables  2  and 3  were obtained with Intel Memory Latency Checker  [29] : • Server HPL (High Penalty on Latency): A Debian GNU/Linux 9, kernel version 5. 1. 15 composed of four nodes with Intel Xeon E5-4620 v4 processors with 10 cores each (40 in total), Broadwell-EP architecture, 25 MB L3 cache, 2. 1 GHz-2. 6 GHz, and 256 GB of RAM. Server topology is shown in Fig. 1a , and all available memory channels are used for each node. In this server, remote accesses have a latency more than 3× higher than local accesses (see Table  2a ), while its bandwidth is reduced by 79% (see Table  2b ).
Note that memory operations requiring 2-hop communications (for example, between nodes 0 and 2) have a slightly higher latency than the other remote accesses. • Server LPL (Low Penalty on Latency): A Debian GNU/Linux 9, kernel version 4. 18. 0 composed of four nodes with Intel Xeon Gold 6248 with 20 cores each (80 in total), Cascade Lake architecture, 27. 5 MB L3 cache, 2. 50 GHz-3. 9 GHz, and 1 TB of RAM. Server topology is shown in Fig. 1b. All memory channels are in use and all memories are interconnected with each other, so all remote accesses have similar latencies. As reported by Table 3a and b, remote accesses have about 1. 7× higher latency, while the bandwidth is decreased by 78% approximately. Given the characteristics of both servers, we can state that data and thread placement is more critical in Server HPL than LPL, and therefore more susceptible to improving its performance using our algorithms.
Experiments description For the experimental validation of our proposal, we have designed three experiments with the NAS parallel benchmarks  [30]  version 3. 4. 1 and the LevelDB benchmark  [31]  version 1. 0. 2 included in the Phoronix Test Suite  [32]. With these benchmarks, we measured performance improvements in two extremely important areas, namely HPC and databases. This is the list of used benchmarks: • BT: Block Tri-diagonal solver based on a CFD pseudo-application. • CG: Conjugate Gradient solver based on a CFD pseudoapplication. • DC: Arithmetic Data Cube computations focused on data movement across cores. • EP: Embarrassingly Parallel. Kernel designed to provide an estimate of the upper achievable limits of floating-point performance. • FT: 3-D Fast Fourier Transform computations with all-to-all communication.
• IS: Integer Sort algorithm with random memory accesses. • LU: Lower-Upper Gauss-Seidel solver factorisation. • MG: Multi-Grid on a sequence of meshes, long-and shortdistance communication. Memory intensive benchmark. • SP: Scalar Penta-diagonal solver based on a CFD pseudoapplication. • UA: Unstructured Adaptive mesh with dynamic and irregular memory accesses. • LevelDB: database application developed by Google. This benchmark includes several read and write operations, namely: Rand Delete, Fill Rand, Fill Seq, Fill Sync, Overwrite, Hot Read, Read Rand, and Seek Rand. Fig. 2  shows the roofline information obtained with Intel Advisor  [33]  for all the benchmarks used in the experiments with their proportion of last level cache (LLC) misses obtained with perf  [34]. With this information, we can classify the benchmarks according to their rate of LLC misses: • Low (0%-20%): BT, EP, CG, and IS.
4. This is the experiment where the potential improvement due to thread and memory migrations is higher. Reducing the execution time of a task implies launching the following tasks earlier. Also, the chances of improving performance are greater due to the high number of processes in the system. Different conditions and configurations have been considered in the execution of the benchmarks. The first three configurations in the following list are commonly used in the literature as a reference for validation purposes. The others correspond to the proposed algorithms, used individually or combining thread and page migration. • Baseline: Thread and memory mapping are under the control of the operating system. Linux default policies are used with AutoNUMA enabled, so the Linux option numa_balancing is set to 1.
Experiment A Figs. 5  and 6  show results for the Server HPL, while Figs. 7  and 8  show the results for Server LPL. As mentioned before, little improvement can be expected in this experiment, since the benchmarks used are state-of-the-art implementations of their respective routines. In general terms, little overhead is introduced with the migration tool, about 8% of the total execution time. This overhead is compensated in most cases, even for LMMA which was expected to be ballasted by the inefficient Linux memory migration mechanism. Only the CIMAR algorithm produces significant performance losses in this scenario. Together with the NAS benchmarks, other Linux commands like time and scripts for automating the tests are running. Although these scripts imply negligible computation time, it is enough to trigger the flaws of the CIMAR regarding work-balance, and so increasing the execution time of the target code.
With the NIMAR algorithm, those problems are alleviated, and results are generally better and more stable. Though, CIMAR makes important improvements in those tests with LevelDB databases with more LLC cache misses, that also rely massively on L1 cache hits, more than 90% of L1 cache accesses are valid. Since CIMAR pins the threads to the individual CPUs, the cache memory is kept in a ''hot'' state, producing a massive improvement when the L1 cache is used in such an intensive way. In NIMAR, the OS is free to move threads within a node, so whenever a thread is moved, the content of the L1 is no longer valid and some time is wasted retrieving back this information. In addition, read operations are further benefited because the hardware counters available on Intel platforms focus on data read transactions.
• By migrating memory pages, LMMA manages to improve system stability, and even improve performance in some scenarios. Once that the aforementioned inefficiency of Linux memory migration  [18, 28]  is improved, results of LMMA are expected to improve too. • User space tools are a feasible option in terms of managing thread and memory mapping. Even though they introduce some overhead (under 8% in our tool), it can be compensated up to a point where system performance is improved, up to 60% in our tests. Future work will be focused on the improvement of the memory migration algorithms. While performance has been improved in codes and systems in which latency is critical, there is room for improvements on those which require high bandwidth. The bandwidth of the system should be analysed and incorporated into the algorithms of memory migrations in order to achieve this objective.
Acknowledgements This research work has received financial support from the  Ministerio de Ciencia e Innovación, Spain  within the project  PID2019-104834GB-I00. It was also funded by the  Consellería de Cultura, Educación e Ordenación Universitaria of Xunta de Galicia  (accr. 2019-2022 ,  ED431G 2019/04  and reference competitive group  2019-2021 ,  ED431C 2018/19 ). Thanks to the people working at CESGA (https://www. cesga. es) for sharing with us anonymous data of the use of their systems.
Creating homogeneous groups (clusters) of patients from medicoadministrative databases provides a better understanding of health determinants. But in these databases, patients have truncated care pathways. We developed an approach based on patient networks to construct care trajectories from such truncated data. We tested this approach on antithrombotic treatments prescribed from 2008 to 2018 contained in the échantillon généraliste des bénéficiaires (EGB). We constructed a patient network for each patients' age (years from birth). We then applied the Markov clustering algorithm in each network. The care trajectories were finally constructed by matching clusters identified in two consecutive networks. We calculated the silhouette score to assess the performance of this network approach compared to three existing approaches.
Introduction Finding homogeneous groups (clusters) of patients in medico-administrative databases helps to better understand health determinants and improve patient prognosis. But the longitudinal and multidimensional data of each patient are available at different times of their life in these databases, thus forming truncated care pathways. Clustering such data is therefore challenging. There are three types of approaches for clustering longitudinal data  [1]. But the number of clusters must be specified, missing values are not handled or must be imputed and only one longitudinal factor at a time can be considered. We developed an approach to construct care trajectories based on patient networks. Patient networks have the advantage of handling heterogeneous and missing data, preserving patient privacy and not requiring to prespecify the number of clusters  [2].
A C T Infant electroencephalography (EEG) presents several challenges compared with adult data: recordings are typically short and heavily contaminated by motion artifacts, and the signal changes throughout development. Traditional data preprocessing pipelines, developed mainly for event-related potential analyses, require manual steps. However, larger datasets make this strategy infeasible. Moreover, new analytical approaches may have different preprocessing requirements. We propose an Automated Pipeline for Infants Continuous EEG (APICE). APICE is fully automated, flexible, and modular. The use of multiple algorithms and adaptive thresholds for artifact detection makes it suitable across age groups and testing procedures. Furthermore, the preprocessing is performed on continuous data, enabling better data recovery and flexibility (i.
e. , the same preprocessing is usable for different analyzes). Here we describe APICE and validate its performance in terms of data quality and data recovery using two very different infant datasets. Specifically, (1) we show how APICE performs when varying its artifacts rejection sensitivity; (2) we test the effect of different data cleaning methods such as the correction of transient artifacts, Independent Component Analysis, and Denoising Source Separation; and (3) we compare APICE with other available pipelines. APICE uses EEGLAB and compatible custom functions. It is freely available at https://github. com/neurokidslab/eeg_preprocessing, together with example scripts.
Second, the power spectrum  (Eisermann et al. , 2013; Marshall et al. , 2002)  and the properties of the evoked responses  (Kushnerenko et al. , 2002; Nelson and Monk, 2001)  evolve throughout development due to maturational changes. More specifically, infant background activity is rich and ample in low frequencies, and the signal variability between trials is much higher in infants than in adults  (Naik et al. , 2021). Third, exogenous artifacts vary according to infants' age (e. g. , fewer blinks and less motion in younger infants). Lastly, most developmental datasets do not include electrocardiogram (ECG) and electromyogram (EMG) recordings usually used to identify non-cortical activity contaminating the EEG. Due to all these factors, the methods developed for adult EEG are ill-suited for infant studies, and no agreement has been reached on the most appropriate preprocessing procedures for infant EEG.
, 2009). Although straightforward, this method presupposes setting arbitrarily fixed thresholds, weighing the risk of a high rejection rate that might leave too few trials to obtain an ERP free of background activity and a low rejection rate that might retain an artifactual signal in the ERP. Setting an adequate fixed threshold is usually not possible because the signal's amplitude depends on the distance between the channel and the reference; thus, fixed thresholds are more or less able to detect artifacts, likely being too sensitive for distant electrodes and not enough for close electrodes. Furthermore, given the changes in EEG amplitude as a function of age and sleep-wakefulness stages, fixed thresholds need to be re-adjusted for each particular dataset. Another drawback of the traditional approach is that artifacts' detection is done on segmented data, limiting its applicability on analysis requiring longer data segments.
The use of multiple algorithms and adaptive thresholds makes APICE applicable without modifications across different ages and protocols. It also makes it easily adaptable to adult EEG datasets. The early detection of artifacts in the continuous data enables the experimenter to decide how to deal with artifacts before further preprocessing steps (e. g. , rereferencing the data to the average, blind source separation methods). Additionally, the detection and correction of artifacts on continuous data increase data recovery by avoiding rejecting data segments containing transient voltage jumps. Finally, APICE is highly flexible, allowing the experimenter to use the same preprocessed data for many kinds of analysis. Note that we built this pipeline to suit the needs of cognitive studies using high-density nets.
Then, we evaluate whether incorporating additional data cleaning methods described in the literature provides any improvement. Specifically, we tested ICA coupled with automatic rejection of components using iMARA  (Haresign et al. , 2021)  and Denoising Source Separation (DSS)  (De Cheveigné and Parra, 2014; de Cheveigné and Simon, 2008). Finally, we validated APICE by comparing it with a standard widely used preprocessing pipeline and with MADE  (Debnath et al. , 2020). We chose MADE between the available pipelines for developmental EEG because it allows ERPs analysis and has already been implemented in published infant EEG studies (e. g. ,  Hwang et al. , 2021; Troller-Renfree et al. , 2020). We performed the validation on two datasets with very different properties, an auditory experiment in asleep neonates and a visual experiment in awake 5-month-olds.
APICE is implemented in MATLAB, and it uses the EEGLAB toolbox and custom functions compatible with the EEGLAB structure  (Delorme and Makeig, 2004). It is freely available at https://github. com/neuroki dslab/eeg_preprocessing, together with example scripts. APICE is modular, allowing functions to be easily recombined to meet different requirements. APICE also provides toolkit functions to modify events, correct event timings using Digital Input events (DINs), add information about trial features, and obtain average ERPs.
2). APICE is our full preprocessing pipeline, including correcting transient artifacts on continuous data (see Section 2. 4). APICE + W-ICA is APICE with the addition of ICA. APICE+DSS is APICE with the addition of DSS. It is important to note that all the functions and steps are modular, offering flexibility to the user. Although we propose a recipe to perform the different steps in a specific order to obtain optimal results, the functions can be re-combined according to particular needs. Based on our research and clinical experience in infant EEG data, we propose the following steps for preprocessing infant EEG data (Fig. 1 ). 1. Importing the data to EEGLAB. 2. Minimal filtering of the data. 3. Detecting artifacts. 4. Correcting artifacts when possible. 5. Re-detecting artifacts. 6. Applying ICA (optional).
Importing the data APICE is based on EEGLAB (a free MATLAB toolbox)  (Delorme and Makeig, 2004). We provide the codes to import the data exported from the EGI system (Electrical Geodesics, Inc) in the EEGLAB format. However, APICE can be implemented on any data imported to the EEGLAB format. It is worth noticing that in many systems, such as EGI, voltages of all electrodes are recorded relative to a single electrode, the reference (e. g. , the mastoids, the vertex). With systems using an active and a passive electrode to generate a common-mode voltage (e. g. , Biosemi), the data needs to be referenced to one of the electrodes (e. g. , the mastoids, the vertex) when imported to remove the common-mode signal.
For most EEG analyses, it is imperative to reduce this contamination. However, extensive filtering (above 0. 1 Hz) can introduce critical distortions in the data  (de Cheveigné and Nelken, 2019). While alternatives to high-pass filtering exist, such as local detrending methods (de Cheveigné and Arzounian, 2018), we have not observed better performance of these methods. Therefore, we apply a high pass filter at 0. 1 Hz at this early stage of preprocessing, which should not introduce critical distortions in the data but remove the main drifts. Using a very low high-pass filter at the initial stage brings flexibility since the same continuous preprocessed data can be used for analysis requiring different filtering levels. We use the pop_eegfiltnew EEGLAB function, which uses the FIRfilt plugin, to perform a non-causal Finite Impulse Response (FIR) filter.