dataesr/scientific-paragraphs-categorization huggingface dataset:
Static Baseline We first determine the set of optimal metrics for each node in both datasets as described in Section 4. 5. To estimate variability, we repeat each experiment twice, and compare the two sets of results node by node. 43. 75% of the nodes report the same optimal metrics across both runs. Of those that do not, 35. 43% list optimal metrics that overlap across the two runs. In total, 79. 18% of nodes' optimal metrics match either perfectly or partially across runs. Figure  7  depicts the distribution obtained in the first run for both datasets.
It would be interesting to see how this modifier behaves on a dataset with a more balanced distribution of optimal metrics than the two we consider here. incPrevRounds, unlike detCurrAlgo, increases precision by 12. 57% and recall by 24. 75% with respect to basic Similitude, while improving stability by 55. 92%. The number of nodes reaching an optimal metric improves by 18. 81%. As expected, incPrevRounds greatly improves the stability of the system; it even enhances every evaluation metric we use. The large reduction in the number of unstable nodes, and the small increase in that of nodes reaching their optimal metrics suggest that incPrevRounds causes nodes to settle on a metric faster, whether or not that metric is optimal. One possible explanation is that, if one metric performs especially well in a round with a particular set of neighbours, all future rounds will be affected by the score of this round.
MovieLens Results Figures 15 and 16 show the effect of Similitude on precision and recall with the different modifiers using the MovieLens dataset. The results are similar to those obtained with Twitter (Figures  8  and 9 ). As with the Twitter dataset, basic Similitude outperforms HeterRand in precision by 24. 52% and in recall by 21. 02%. By the end of the simulations, 59. 95% of the nodes reach an optimal metric and 15. 73% still switch metrics. The behaviour of the modifiers compared to basic Similitude is also similar. detCurrAlgo degrades precision by 7. 58%, recall by 9. 86%, the number of nodes on optimal metrics by 7. 07%, and the number of nodes switching metrics by 33. 40%. incPrevRounds improves precision by 21. 02%, recall by 31. 19%, the number of nodes on optimal metrics by 20.
52%, and the number of nodes switching metrics by 62. 08%. incSimNodes improves precision by 15. 75%, recall by 17. 38%, the number of nodes on optimal metrics by 15. 12%, and the number of nodes switching metrics by 28. 61%. All modifiers improves precision by 29. 11%, recall by 43. 99%, the number of nodes on optimal metrics by 32. 51%, and there are no nodes switching metrics after the first 25 rounds. As with the Twitter dataset, activating all the modifiers makes all the nodes use the similarity metric which is optimal for the majority of the system: FrereJacc. The number of nodes reaching optimal metrics (79. 44%) and the number of nodes with FrereJacc as optimal metric (81. 40%) are almost identical. Without cool-off, Similitude even reaches 80. 57% nodes on an optimal metric, getting even closer to that last number.
Complete System We now compare the results of the best Similitude variant (all the modifiers and 0 cool-off, noted Similitude (optimised)) with the six static configurations we introduced in Section 4. 5. For the Twitter dataset, Figure  17  shows that our adaptive system outperforms the static random allocation of metrics by 73. 06% in precision, and overcomes all but one static homogeneous metrics, FrereJacc, which is on par with Similitude (optimised). For the MovieLens dataset, Figure  18  shows very similar results where Similitude (optimised) has a higher precision than Het-erRand by 65. 85%, is on par with FrereJacc, and has a slightly lower precision than HeterOpt (-2. 6%). Selecting FrereJacc statically would however require knowing that this metric performs best, which may not be possible in evolving systems (in which FrereJacc might be replaced by another metric as users' behaviours change).
Next, we observe that nodes appear to optimise their neighbourhood depending on their current metric, as opposed to basing their metric choice on their neighbourhood. This may lead to local optima because metrics perform notably better in neighbourhoods they have themselves refined. Our initial attempt at avoiding such local optima with the detCurrAlgo proved unsuccessful, but further investigation could result in rewarding future work. For example, we are considering decoupling the choice of the metric from the choice of the neighbourhood. Nodes may compare the performance of metrics using randomly selected neighbourhoods, and then move to the clustering process only using the best-performing metric. Finally, it would be interesting to see how detCurrAlgo, incSimNodes and more generally Similitude behave on a dataset with a more balanced distribution of optimal metrics since their effects and results highly depend on it.
Conclusion We have presented Similitude, a decentralised overlay-based recommender that is able to adapt at runtime the similarity used by individual nodes. Similitude demonstrates the viability of decentralised adaptation for very large distributed systems, and shows it can compete against static schemes. Although promising, our results shows there is still room for improvement. In particular, we would like to see how a dataset with a more balanced distribution of optimal metrics affects Similitude and its modifiers. We also think that the detCurrAlgo and incSimNodes modifiers could benefit from further improvements, and thus bring the performance of Similitude closer to that of a static optimal-metric allocation.
Introduction The second run of the Large Hadron Collider (LHC)  [1]  brings several computing and software challenges to the ATLAS experiment  [2]. Higher luminosity will mean more data and hence more disk usage. Analyses will grow in complexity compared to Run-1. Any latencies in the analysis chain due to computing resource shortage or difficulties with software will slow down productivity. Thus, it will be highly beneficial to have a well-optimized analysis model which uses resources efficiently and does not hinder analysts' ability to publish results in a timely manner. The analysis model in Run-1 had some issues which would not be sustainable for the future of ATLAS. The original intended model involved the use of the Athena framework  [3]  to analyze an Athena-based EDM (AODs)  [4]. However, during Run-1 most analysts were predominantly analyzing simpler ROOT-readable n-tuples (D3PDs) with non-Athena code.
Overview of the Run-2 analysis model The ATLAS Run-2 analysis model, shown in Figure  1  consists of the following components: The new xAOD EDM brings some powerful features to the analyzer which can be exploited when writing analysis software. The separation between the object interface and the variable payload makes the EDM flexible and dynamic. Variables can be added and removed as desired by the user. A specialized type of auxiliary store allows for shallow copies of object containers. When an object container is shallow-copied, auxiliary variables are only duplicated when modified. Otherwise, when requested, they are taken from the original container. This feature is illustrated in Figure  2. Shallow copies are very useful for applying object corrections and systematic variations in an analysis workflow, which is described further in Section 5.
Systematics interface All systematics tools implement the ISystematicsTool abstract interface, which harmonizes the handling of systematics across all tools for the user. This interface allows to configure a tool for a particular SystematicSet, to query which systematics affect a given tool, and to query which subset of those systematics are recommended to be evaluated in a given analysis. The application of the systematics in the analysis job is done in the event loop. Usually the user has a list of SystematicSet objects and some per-event code which needs to be run for each set. The user passes a requested SystematicSet to their tools via the ISystematicsTool interface. Each tool filters the requested systematics with its own affecting systematics, and then updates its internal configuration according to the filtered result.
The tools return a status code signifying success or failure. Next, the user applies the tools to xAOD objects via the dedicated tool interfaces, and the tools operate on the data according to their current systematic settings. The filtering and configuration lookups in the tools are very efficient thanks to the SystematicSet's cached hash value and use of hash maps. This process is illustrated in Figure  4. The initialization phase occurs once at the beginning of a job, while the application procedure is performed for every event and every systematic variation.
Analysis workflows The flexibility of the dual-use tool model means that analyzers can design their software workflows in a variety of ways. However, as illustrated in Figure  1 , it is expected that most analysis workflows will have the same general features. An application reads an input xAOD (typically a derivation), applies CP tools, and writes out some "final" analysis n-tuple which can be subsequently used for making plots and other results. As mentioned in Section 2, shallow copies can be used to represent variations on objects in an intuitive way but with minimal memory cost. Thus, a popular model for analysis code is to generate shallow copies of each object type for each systematic variation, and then apply the various correction, selection, and efficiency tools to the objects with the appropriate systematics settings for each shallow copy.
Morphological measurements. For comparison, thin blood films of cultured parasite samples were made at various time points following sorbitol synchronization and stained with Field's stain. Pictures were taken under the same conditions for the 3D7 (parent) strain and the 3D7 L272F line and analyzed with a Nikon Eclipse TE2000 inverted microscope. Areas were measured using ImageJ 1. 44o software and the ratio was expressed as A FV /A Parasite. No image manipulations were carried out after recording. For micrographs of FCB and FCB C101F , thin films from parasite cultures were stained with 2% (v/v) modified Giemsa (Karyomax ® ; Gibco) for 30 min. Slides were washed for 60 s in flowing distilled water, air-dried and mounted with coverslips. Images were photographed in bright field, using a Lexica DMI4000 inverted microscope under a 100X objective lens.
Images were compiled in Adobe Photoshop CS5. 1 and processed equally with a warming photo filter. Live parasite cultures were placed under coverslips and photographed under a 100X objective, using a Leica DM750 light microscope equipped with ICC50 HD digital camera. Images were adjusted for white balance with the Leica Application Suite software and cropped in Adobe Photoshop CS5. 1. For experiments with Dd2 parasites, thin blood smears were fixed with methanol, stained for 20 min in 10% (v/v) Giemsa (Invitrogen), washed, and air-dried. Images were taken with an Olympus DP12 digital camera attached to an Olympus CX 41 light microscope with a 100X objective (N. A 1. 4x). Images were cropped and corrected for white balance using Adobe Lightroom 3. Electron microscopy. Samples of 3D7, 3D7 L272 , Dd2 Dd2 and Dd2 Dd2 L272F , synchronized at the mature trophozoite stage were fixed in 4% (v/v) glutaraldehyde in 0.
All of the slices taken from oocytes expressing a PfCRT variant displayed a fluorescent band above the pigment layer (consistent with the localization of PfCRT to the plasma membrane) that was not present in non-injected oocytes. The preparation of oocyte membranes and the semi-quantification of PfCRT protein was carried out using a protocol described in detail elsewhere  32. Protein samples prepared from oocyte membranes were separated on a 4-14% bis-Tris SDS-polyacrylamide gel (Life Technologies) and transferred to nitrocellulose membranes. The membranes were probed with rabbit anti-PfCRT antibody (1:4,000) followed by horseradish peroxidase-conjugated goat anti-rabbit antibody (1:8,000; Life Technologies). The PfCRT band for each variant was detected by chemiluminescence (Pierce), quantified using the Image J software  70  , and expressed as a percentage of the intensity measured for the PfCRT Dd2 band.
Acknowledgments This work was supported by the  European Community 's  Seventh Framework Programme ,  FP7/2007-2013  ( Marie Curie-funded Initial Training Network InterMal ,  215281-2  to SK and NanoMal, 304948 to SK and HMS), the  NIH  ( R01 AI50234  to DAF and  R01 AI071121  to RAC), the  Australian National Health and Medical Research Council  (Grant  1007035  and  Fellowship 1053082  to REM) and the  Burroughs Wellcome Fund -Investigators in Pathogenesis of Infectious Disease award  ( 1007041. 02to ML).
In the Gavarnie-Heas dome (central Pyrenees), ultramafic, mafic and intermediate rocks form three massifs several kilometers in size emplaced within the anatectic series: (i) the Gloriettes massif, which mostly consists of norites with enclaves of ultramafic rocks; (ii) the Troumouse massif, which comprises intermediate rocks (gabbrodiorite and diorite) with norite enclaves, and (iii) the Aguila massif, which consists of intermediate rocks with hornblendite enclaves. U-Pb zircon geochronology (first data for these rock types in the Axial Zone of the Pyrenees) revealed an age of 294 Ma for the diorite crystallization and correlatively for the crystallization of the anatectic granite. This new radiometric age allows us to suggest that the Variscan orogeny continued at least until the Early Permian and spread over around 30 Ma.
Petrography and geochemistry The compositions of the major minerals are listed as supplementary data in Table  A. UM rocks occur as enclaves ranging in size from a meter to several tens of meters mostly within the norites of the Gloriettes massif and more rarely within the Aguila massif. UM rocks always display the same mineral species (olivine, orthopyroxene, amphibole, and spinel), but with distinct modal proportions leading to distinguish peridotites, orthopyroxenites, and hornblendites. These UM consist of rounded olivine (Fo 89- 94 ) and orthopyroxene (En 84 ) both included in abundant oikocrystic amphibole (MgO: 19 wt. % and Cr 2 O 3 : 4 wt. %). The UMs of the Gloriettes massif show the following chemical composition: SiO 2 (43. 6-47. 9 wt. %), Al 2 O 3 (7. 5-9. 6 wt. %), MgO (18-23.
Moreover, with regard to similar mafic rocks derived from mantle-originated magmas occurring in some North Pyrenean massifs (Saleix massif, with low ( 87 Sr/ 86 Sr) i ratios, between 0. 70349 and 0. 70676, and high e Nd values, ranging from -5. 3 to +2. 2;  Pin, 1989) , there is a notable contrast between our data and these values. 1984, obtained an age based on Rb-Sr whole-rock isochron at 282 AE 5 Ma (MSDW = 3. 3) from the study of 14 samples of magmatic rocks taken from the Albera massif. Vilaet al. (2005, page 114)  proposed the same age for the same massif, based on an Rb/Sr isochron, but did not totally exclude an age of 300 Ma by comparison with the age of the Querigut granitic massif  (Roberts et al. , 2000). Our new La-ICPMS zircon U-Pb isotopic analyses revealed an age of 294 AE 1 Ma for the diorite crystallization in the Aguila and Troumouse massifs.
The multiplication of the number of cores inside embedded systems has raised the pressure on the memory hierarchy. The cost of coherence protocol and the scalability problem of the memory hierarchy is nowadays a major issue. In this paper, a specific data management for read-only data is investigated because these data can be duplicated in several memories without being tracked. Based on analysis of standard benchmarks for embedded systems, we show that readonly data represent 62% of all the data used by applications and 18% of all the memory accesses. A specific data path for read-only data is then evaluated by using simulations. On the first level of the memory hierarchy, removing read-only data of the L1 cache and placing them in another read-only cache improve the data locality of the read-write data by 30% and decrease the total energy consumption of the first level memory by 5%.
This solution aims to be transparent for the user and generic to embedded systems. In order to use this system transparently, some steps are to be considered during compilation. Compiler has to detect read-only data, and may use some user information, such as those provided in parallel languages like OpenCL, or OpenACC. This study considered several scenarios where read-only data are removed from the original memory organization and handled in a different one. The special management of read-only data is not optimized yet and will be considered in future work. Firstly, read-only data are detected and quantified for a whole set of applications. Secondly, by using simulation, different data management are tested and compared in terms of energy consumption and data locality. The rest of the paper is organized as follow: Section 2 describes a quantification on read-only data.
READ-ONLY DATA ANALYSIS The first step of the evaluation is to show that read-only data count for a significant part of the working set of applications in embedded systems. This analysis is a trace-driven analysis on the standard Mibench benchmark  [10]. Mibench is studied because it is a representative set of applications used in embedded systems. All the applications of the benchmark are compiled on a x86 platform and are used with their default input data set given with the applications. The memory access analysis is performed through traces. A trace records the flow of memory access occurring during an execution of the application (including those done in external libraries and in the stack). the Study focuses only on data, instruction fetches are not recorded. The trace allows to launch several simulations on the same flow of memory accesses to compare different memory hierarchies and data management policy.
Second, the proposed detection focuses on big areas of read access with data reuse, detecting data structures or data regions more than individual data accesses. After experimentations, read areas are kept for this study only if more than 128 memory access are done on this area. According to the defined classification, on Mibench benchmarks, the repartition shows that on average, 17. 8% of all memory accesses are accesses to read-only data and 6. 9% are accesses to read areas. The remainging 75. 3% of the memory accesses are not concerned by the solution.
Since read areas are detected on read-write data, the data in read areas take both paths depending on the timing. During simulations, the specific memory is modeled as a simple memory cache. In order to simulate these scenarios, five memory traces are generated, one for each memory of each scenario. The original full trace of the application is used for the scenario n°1 as a reference. For scenarios 2 and 3, partial memory traces are generated from the original trace, accesses are removed according to the data management policy, in order to form the memory access flow for each memory. If no read area is detected, scenarios 2 and 3 are the same. This case happens for 10 out of 26 benchmarks tested. The L2 cache is unified for all the data. For the rest of the paper, the first level cache for read-only data will be called the RO cache and the first level cache for read-write data will be called RW cache.
Analysis To allow a meaningful comparison of different scenarios, the average stack distances always compared separatly for read-only and read-write data. Three steps are followed for the analysis: In a first step, for each application of Mibench, the stack distances are computed on the full memory trace of the scenario 1. Once the stack distances are computed for all accesses, the average stack distance is computed separately for accesses to read-only data and accesses to read-write data (read area accesses are included in the accesses to read-write data). For all the applications, the average stack distance of read-only data is 16 times higher than the average stack distance of read-write data. So, the difference of locality is very significant, and means that read-only data are less reused and pollute the classic L1 cache.
Energy Consumption Model The energy consumption of the cache is computed with a simple energy model. The CPU is not modeled and the study focuses only on the dynamic energy of the first level memories of the memory hierarchy. For each cache, the dynamic energy consumption is determined as follow:  The underlined terms are ignored for the moment. The energyCPUStall is the energy consummed when the is stalled while waiting for the memory system to provide data and the energyCacheBlockFill is the energy for writing a block into the cache. The energyPerAccessL1 and ener-gyPerAccessL2 are determined with Cacti v6. 5  [13]  and the cacheHitsL1 and cacheMissL1 are determined by simulations with the cache simulator dineroIV  [8]. For the scenario 2 and 3, the energy consumption of the first level hierarchy is the addition of the energy consumption of the RW cache and the RO cache.
Analysis The energy consumption of all the of the Mibench benchmarks is studied. To simulate with dineroIV and Cacti the described scenarios, cache designs have to be chosen. First, the scenario 1 is explored extensively in order to determine the most efficient design of the classic cache. The cache's design that minimizes the average energy consumption on Mibench is a cache of 16KB with 2-way set associativity. The energy consumption of the scenarios 2 and 3 is compared to this reference. To do a fair comparison between scenarios, an equivalent storage at the first level of the memory hierarchy for each scenario has to be used. In Section 4, it has been pointed out that read-only data have a weak locality, it suggests that the RO cache must have an important size relatively to the number of memory access it will handle.
Then, the energy consumption of each application is added for each scenario. As shown in Fig. 6  energy consumptions in scenarios 2 and 3 are approximately the same. There is an improvement of 6. 5% of energy for scenario 2 and 5. 0% for scenario 3 compared to the scenario 1. It shows that read-only data can be handled in a different memory without adding energy overhead. Indeed, even with conventional caches for the specific readonly memory, there is no overhead when dividing L1-cache. For scenario 3, the cost of switching read accesses between the RW and the RO cache has been ignored for the moment so the energy consumption for scenario 3 is probably under-evaluated compared to a real situation.
At the first level of the memory hierarchy, a specific read-only cache is added in parallel to a shared memory and a private L1 cache. The developer or the compiler needs to indicate the data that will go through the read-only cache. Another solution is proposed by Guo et al  [9] , on a VS-SPM (virtually shared scratchpad memories) architecture which proposes a solution of data management for shared data is proposed. The proposed algorithm allows the duplication of read-only data in several scratchpads if the duplication comes with an energy reduction.
CONCLUSION The paper has an analysis of the opportunity to handle in different caches, data that is read-only, either for the whole application or a limited amount of time. The results show that there are some optimization potentials for specific data management for read-only data. Even if the memories where read-only data are placed do not yet exploit the read-only property, simulations show that the division between read-only and read-write data on the first level of memory hierarchy improves the data locality (in average, 30% on Mibench benchmarks) and does not introduce energy consumption overhead. The main interest of exploiting read-only data appears in a multi-core environment, since they can be shared without being handled by a costly coherence protocol. The future work will focus on optimizing the read-only sub-hierarchy in an actual multi-core environment.