the Omnisc'IO Approach

15 Pages·2016·3.26 MB·English

Using Formal Grammars to Predict I/O Behaviors in
HPC: the Omnisc’IO Approach
Matthieu Dorier, Shadi Ibrahim, Gabriel Antoniu, Robert Ross
To cite this version:
Matthieu Dorier, Shadi Ibrahim, Gabriel Antoniu, Robert Ross. Using Formal Gram-
mars to Predict I/O Behaviors in HPC: the Omnisc’IO Approach. IEEE Transactions on
Parallel and Distributed Systems, Institute of Electrical and Electronics Engineers, 2016,
<10.1109/TPDS.2015.2485980>. <hal-01238103>
HAL Id: hal-01238103
https://hal.inria.fr/hal-01238103
Submitted on 4 Dec 2015
HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est
archive for the deposit and dissemination of sci- destin´ee au d´epˆot et `a la diffusion de documents
entific research documents, whether they are pub- scientifiques de niveau recherche, publi´es ou non,
lished or not. The documents may come from ´emanant des ´etablissements d’enseignement et de
teaching and research institutions in France or recherche fran¸cais ou ´etrangers, des laboratoires
abroad, or from public or private research centers. publics ou priv´es.
1
Using Formal Grammars to Predict I/O
Behaviors in HPC: the Omnisc’IO Approach
Matthieu Dorier,∗‡ Shadi Ibrahim,† Gabriel Antoniu,† Rob Ross‡
∗ENS Rennes, IRISA, Rennes, France
†Inria, Centre de Rennes Bretagne-Atlanique, France, {shadi.ibrahim,gabriel.antoniu}@inria.fr
‡Argonne National Laboratory, Argonne, IL 60439, USA, {mdorier,rross}@mcs.anl.gov
Abstract—Theincreasinggapbetweenthecomputationperformanceofpost-petascalemachinesandtheperformanceoftheirI/O
subsystemhasmotivatedmanyI/Ooptimizationsincludingprefetching,caching,andscheduling.Inordertofurtherimprovethese
techniques,modelingandpredictingspatialandtemporalI/OpatternsofHPCapplicationsastheyrunhasbecomecrucial.
InthispaperwepresentOmnisc’IO,anapproachthatbuildsagrammar-basedmodeloftheI/ObehaviorofHPCapplicationsanduses
ittopredictwhenfutureI/Ooperationswilloccur,andwhereandhowmuchdatawillbeaccessed.Toinfergrammars,Omnisc’IOis
basedonStarSequitur,anovelalgorithmextendingNevill-Manning’sSequituralgorithm.Omnisc’IOistransparentlyintegratedintothe
POSIXandMPII/Ostacksanddoesnotrequireanymodificationinapplicationsorhigher-levelI/Olibraries.Itworkswithoutanyprior
knowledgeoftheapplicationandconvergestoaccuratepredictionsofanyNfutureI/Ooperationswithinacoupleofiterations.Its
implementationisefficientinbothcomputationtimeandmemoryfootprint.
IndexTerms—HPC,Storage,I/O,Prediction,Grammar,Omnisc’IO
(cid:70)
1 INTRODUCTION
EXISTING petascale computing platforms often fail to goodprediction;hence,theyeitherneedlongexecutiontime
meettheI/Operformancerequirementsofapplications (several runs in some cases) [9] or are doomed to offline
running at scale. This weakness of the I/O system relative trace-basedtraining[10]inordertoconverge.
tocomputingcapabilitiesispartofatrendthatisworsening Ourworkaddressesthelimitationsofcurrentprediction
as we develop ever more capable computing platforms, systems and takes a step toward intelligent I/O manage-
and we expect the next generation of systems to have an mentofHPCapplicationsinnext-generationpost-petascale
even larger gap [1]. Moreover, most HPC applications ex- supercomputers[11]thatiscapableofrun-timeanalysisand
hibitaperiodicbehavior,alternatingbetweencomputation, adaptationtotheI/Obehaviorofapplications.Tothisend,
communication, and I/O phases. The I/O phases are com- wepresentthedesignandimplementationofOmnisc’IO,a
monlyusedforcoordinatedcheckpointingand/oranalysis grammar-based approach for modeling and predicting the
or visualization output. They produce bursts of activity in I/ObehaviorofHPCapplications.
the underlying storage system [2], [3] that further limit the
The intuition behind Omnisc’IO is that, while statistical
overall scalability of the HPC application and potentially
models are appropriate mostly for phenomena that exhibit
interfere with other applications running concurrently on
a random behavior, the (mostly) deterministic behavior of
theplatform[4].
HPCapplications,inherentfromtheircodestructureandthe
To alleviate the performance penalty of the I/O bottle- absenceofinteractivitywithanend-user,makesotherrepre-
neck in petascale systems, researchers have explored tech- sentationsoftheirI/Obehaviorpossible.Formalgrammars,
niquessuchasprefetching,caching,andscheduling[4],[5], asnaturalmodelstorepresentasequenceofsymbols,have
[6]. The effectiveness of such techniques strongly depends been widely applied to areas of text compression, natural
on a certain level of knowledge of the I/O access patterns: language processing, music processing, and macromolec-
prefetching and caching indeed require the location of fu- ular sequence modeling [12] [13]. Therefore, an approach
ture accesses (i.e., spatial behavior), while I/O scheduling based on formal grammars is suitable for I/O behavior
leveragesestimationsofI/Orequestsinterarrivaltime(i.e., modeling, since it detects the hierarchical and periodic
temporal behavior), and the location of accesses in terms nature of the code that produced the I/O patterns, with its
of storage targets. The key challenges inherent in these nestedloopsandstacksoffunctioncalls.
techniquesincludethepropercomprehensionandexploita-
Contributions: Omnisc’IO builds a grammar-based model
tion of the application’s I/O behavior within the I/O stack
of the I/O behavior of any HPC application and uses it to
itself [7], [5]. Hence, modeling and predicting application I/O
predict when future I/O operations will occur (i.e., predict
behaviorareofutmostimportance.
theinterarrivaltimebetweenI/Orequests),aswellaswhere
While predicting the I/O patterns of HPC applications and how much data will be accessed (i.e., predict the file
haslongbeenanimportantgoalinlarge-scalesupercomput- being accessed as well as the location –offset and size– of
ers, researchers have investigated statistical methods (e.g., the data within this file). It learns its model at run time
hiddenMarkovmodels(HMM)[8]andARIMAmodels[6]), usinganalgorithmderivedfromSequitur[14].Sequiturwas
or non-statistical methods based on frequent patterns de- designed to build a grammar from a sequence of symbols
tection [9], [7]. These approaches often focus exclusively and has been used mainly in the area of text compression.
on either spatial or temporal I/O behaviors. Furthermore, TheuseofSequiturinthecontextofpredictingI/Obehav-
they require a large number of observations to accomplish iors in HPC raised two challenges. First, Sequitur had to
2
be turned into an algorithm capable of making predictions.
Second, some optimizations to Sequitur were required to
make the resulting grammar’s size bounded. In this respect,
our algorithmic contribution is much more general than its
application to I/O pattern prediction. We call StarSequitur
ournewSequitur-basedalgorithm.
Omnisc’IOistransparentlyintegratedintothePOSIXand
MPI I/O stacks and does not require any modification in
applications or higher-level I/O libraries. It works without
any prior knowledge of the application, and it converges
to accurate predictions within a couple of iterations. Its
implementation is efficient both in computation time (less
thanafewmicrosecondstoupdatethemodelonarecentx86
hardware)andinmemoryfootprint.Omnisc’IOisevaluated
withfourrealHPCapplications–CM1,Nek5000,GTC,and (a) ArchitectureofOmnisc’IO
LAMMPS– using a variety of I/O backends ranging from
simple POSIX to Parallel HDF5 on top of MPI-I/O. Our
experiments show that Omnisc’IO achieves from 79.5% to
100%accuracyinspatialprediction(percentageofmatching
between the predicted segment and the accessed segment)
and an average precision of temporal predictions (absolute
difference between the predicted and the actual date of
the next accesses) ranging from 0.2 seconds to less than a (b) IntegrationofOmnisc’IOintheI/Ostack
millisecond.
Finally as a side effect of this work, we show exactly how Fig.1:OverviewoftheOmnisc’IOapproach.
predictableHPCcodescanbe.
Goals: The primary goal for Omnisc’IO, and the focus 2) A grammar-based model of the stream of context sym-
of this paper, is to model the I/O behavior of any HPC bols (upper-right part of Figure 1(a)) is updated by using
StarSequitur a new algorithm derived from Sequitur. Se-
application and use this model to accurately predict the
quiturhasbeenappliedtotextcompressioninthepast[12]
spatial and temporal characteristics of future I/O opera-
because of its ability to detect several occurrences of sub-
tions. Omnisc’IO can therefore be applied at the core of
strings in a text and to store them into grammar rules. We
manyI/Ooptimizations,includingprefetching,caching,or
haveadaptedittomodeltherepetitivebehaviorofanHPC
scheduling.
application,representedasastreamofcontextsymbols.The
In order not to undermine the generality of our ap-
application of Sequitur to the field of application behavior
proach, this paper does not present the use of Omnisc’IO
modelingisnovelandconstitutespartofourcontribution.
inaparticularcontext(i.e.,prefetching,caching,orschedul-
3) Spatial(size,offset,file)andtemporal(interarrivaltime)
ing). Others have already demonstrated the benefits of ap-
access patterns are recorded in tables associating context
plying I/O predictionsto enhance the performance ineach
symbolsortransitionsamongsymbolswithaccesspatterns
of these techniques [8], [6], [9], [10]. We focus our study on
(lower-left part of Figure 1(a)). The intuition is (for the
thepredictioncapabilitiesofOmnisc’IO.
example of the access size) that a given context symbol
Thispaperextendsourpreviouswork[15]by(1)propos- will often be associated with the same access size or with
ing StarSequitur, an extension to Nevll-Manning’s Sequitur a reduced number of sizes whose sequence can also be
that keeps the grammar size bounded in case of periodic learned.Thisintuitionhasbeenexperimentallyverified,and
sequences,andisabletopredictfuturincomingsymbols,(2) meanlystemfromthefactthatagivencontextsymboloften
makingOmnisc’IOcapableofpredictinganynumberoffuture uniquely corresponds to the access to a particular part of a
I/O operations, (3) improving Omnisc’IO’s predictions capa- givenvariable.
bility by weighting predictions when several are available 4) We improved on the Sequitur grammar-inference algo-
and (4) we performed extensive experiments that demon- rithm and propose StarSequitur to (1) make predictions of
strate the substantial benefit of StarSequitur, including the futurecontext symbolsand(2) reducethe grammarincase
accuratepredicationofanysequenceofN futureoperations, of periodic behaviors. It then becomes easy to predict the
andboundedgrammarsizes. characteristics of future accesses by looking up the access
patterns associated with the predicted context symbols in
the aforementioned tables (lower-right part of Figure 1(a)).
2 THE OMNISC’IO APPROACH
Additionally,weimplementedaweightingsystemtorepre-
Figure 1 presents an overview of Omnisc’IO. Omnisc’IO sent the relative confidence our model has on its different
captureseachatomicrequesttothefilesystem(open,close, predictions. Beyond its use in the context of HPC I/O, our
read,write,etc.)inatransparentmanner,withoutrequiring new StarSequitur algorithm constitutes another important
any change in the application or I/O libraries. At each partofourcontribution.
operation,Omnisc’IOoperatesasfollows.
Themainideaofthepredictionprocessusingourmodel
1) The context in which the operation is executed is ex- is as follows: using the grammar, Omnisc’IO is able to
tractedbyrecordingthecallstackoftheprogram(upper-left recognize that the current I/O operation (or a pattern of
partofFigure1(a)).Thisisaknowntechnique[16]thathelps consecutive operations) was already observed in the past.
capturethestructureofthecodeissuingtheI/Ooperations. It thus provides the position in the grammar where this
Thecontextisabstractedasacontextsymbol(ainthefigure). pattern is stored. Reading the grammar from this position
3
TABLE1:Examplesofcontext-freegrammars.Lowercaselettersrepresenttermi-
allows to reconstitute the previously observed pattern as nalsymbols,whileuppercaselettersrepresentrulesandtheirinstances.Example
wellasalltheoperationsthatfollowedit. 1iscorrectfromaSequiturperspective.Example2violatestheruleutility(rule
Aisusedonlyonce;itshouldbedeletedanditsonlyinstanceshouldbereplaced
withitscontent).Example3violatesthedigramuniqueness(digramabappears
twice;anewruleB→abcanbecreatedtoreplaceit).
3 ALGORITHMIC AND TECHNICAL DESCRIPTION
Example1 Example2 Example3
As shown in Figure 1(b), Omnisc’IO is integrated within S→abAAe S→abAe S→ababAAe
the POSIX I/O layer and the ADIO layer in MPI-I/O. In A→cd A→cd A→cd
the following, we provide more details on the four steps
finitesetofnonterminalsymbolsdisjointfromΣ;Risafinite
describedabove. relationfromVto(V∪Σ)∗,usuallywrittenasasetofrules
in the form A → x1...xk, where xi ∈ (V∪Σ); and S ∈ V
3.1 Trackingapplicationsbehavior is a starting symbol. In the following, we call xi the nested
symbolsofA.
To give a context to each atomic I/O operation, we use
the libc backtrace function to retrieve the list of stacked Nevill-Manning’s Sequitur builds a context-free gram-
program counters (array of void* pointers). When called marfromastreamofsymbolsbyupdatingthegrammarat
within a function f, this list of addresses characterizes the eachinput.ItstartswithasingleruleS.Ateachnewinput
series of return addresses that leads from f back to main. x,itappendsxtotheendofruleS andrecursivelyenforces
Different calls to f in distinct places in the program (or twoconstraints:
libraries) lead to different call stack traces. Omnisc’IO calls
backtrace within wrappers of I/O functions and asso- Digram uniqueness: Any sequence of two symbols ab ∈
(V ∪ Σ)2 (digram) cannot appear more than once in all
ciates the returned array with a unique integer, such that
rules. If one does, a new rule R → ab is created, and the
two I/O calls with the same stack trace will be associated
constraintsareenforcedrecursively.
with the same integer. In the following, such integers are
calledcontextsymbolsandrepresentthecontextinwhichan
I/Ooperationoccurs.
Omnisc’IO is based on the observation that (1) a partic- Ruleutility:Allrulesshouldbeinstantiatedatleasttwice.
ularcontextislikelytobeassociatedwithfixedparameters Ifaruleappearsonlyonce,itsinstanceisreplacedwiththe
(e.g., two calls to write within the same context are likely contentoftherule,theruleisdeleted,andtheconstraints
toinvolvethesameamountofdata);(2)transitionsbetween areenforcedrecursively.
two contexts can also be associated with fixed parameters
(trackingtheevolutionoftheoffsetcanbedonebytracking Examplesofcontext-freegrammarsaregiveninTable1,
transitionsbetweencontexts)andwithlittle-varyingtransi- some of which violate the Sequitur constraints. In the fol-
tion times; and, most important, (3) the stream of context lowing, the grammar built from the context symbols is
symbols is eventually predictable, and a model of it can be calledthemaingrammarofOmnisc’IO.Sequiturhasalinear
builtatruntime. worst-casecomplexitybothinspaceandintime.
In our prototype, we overloaded the POSIX I/O func-
tions (write, read...) and the libc functions (fwrite,
3.1.2 Optimizingthegrammar’ssize
fread...) using a preloaded shared library. In MPI-I/O
we added an intermediate layer within the ADIO layer The size of a grammar built by Sequitur is linked to
in ROMIO, a popular implementation of MPI-I/O [17], the compressibility of the input sequence. At best, such a
to track the lowest-level I/O functions that access files grammar’s size grows logarithmically with the size of the
metadata (open, close...) and atomic functions that access input sequence. This scenario occurs when the sequence is
contiguous blocks of data and are used by more elaborate periodic.
I/O algorithms. The reason for adding this layer in ADIO Tooptimizethesizeoftheresultinggrammarsandmake
is that ROMIO does not necessarily use POSIX calls at its it bounded in case of periodic input sequences (recall that
lowestlevel.Forexample,usingPVFS(asinourevaluation), most HPC application have a periodic behavior), we built
requestsaresentthroughthePVFSAPI. on Sequitur to provide a way to express symbols exponen-
While working at the lowest level of the I/O stack is tiation.Ournewalgorithm,thatwecallStarSequitur,stores
necessary to capture the I/O behavior at a fine grain (i.e., symbols with an exponent, for instance a3 instead of aaa.
a series of atomic requests to the file system), the use of Todoso,itleveragesathirdconstraint:
backtraces lets Omnisc’IO have information also on the
upperlayersthatissuedtheI/O,includingI/Omiddleware, Twins removal: Any digram of the form aiaj should
libraries,andtheapplicationitself. be replaced with ai+j, and the constraints are enforced
recursivelyifnecessary.
3.1.1 Learningthegrammaroftheapplication
While capturing a stream of symbols representing the be- To illustrate the advantage of our new algorithm over
havioroftheapplication,weaimtopredictthenextsymbols Sequitur,Table2showsthegrammarsbuiltbySequiturand
given past observations. Omnisc’IO models the stream of byouralgorithmfromasimpleperiodicsequence.
symbols using a context-free grammar. This grammar is Although our experiments will show that even without
learned at run time using an algorithm inspired by Nevill- this optimization the memory footprint of Omnisc’IO is
ManningandWitten’sSequituralgorithm[14]. rather small (in the order of a few hundreds of KB), we
Asbackground,acontext-freegrammarGisaquadruple note that (1) the complexity of the algorithms presented
(Σ,V,R,S), where Σ is a finite set of terminal symbols (in in the following section depend on this size and (2) with
ourcasethesymbolsdefinedbythecallstacktraces);Visa smaller sizes, Omnisc’IO’s grammars could be more easily
4
TABLE 2: Grammars built by Sequitur and StarSequitur from the sequence TABLE3:Predictorsincrementationmatchingagiveninput.Thepredictorsare
abababababababab. markedinredandunderlined.Inthefirstinput,adoesnotmatchanddisappears
from the set of predictors, c matches and is incremented to d, and A stays a
predictor.Inthesecondexample,dmatchesbuthasnosuccessorinruleA;thus
Sequitur StarSequitur AisincrementedtoeinruleS.Theresultingmodelscorrespondtothegrammars
S→AA beforetheinputisappendedandSequitur’sconstraintsareapplied.
A→BB S→A8
B→CC A→ab
BeforeUpdate Input AfterUpdate
C→ab
S→aeAbAe c S→aeAbAe
A→cd A→cd
transferred to entities (e.g., schedulers or file systems) that S→aeAbAec d S→aeAbAec
A→cd A→cd
couldmakeuseofit.
TABLE4:Discoveryofnewpredictorsmatchingthelastinput(b,appendedat
theendofruleS).Thepredictorsaremarkedinredandunderlined.Thesymbol
3.1.3 Predictionsusingthegrammarmodel bbecomesapredictorwhereveritappears,andrecursivelyanyrulethatleads
toanoccurrenceofbbecomesapredictor.Thepredictorsarethenupdatedto
Sequitur and StarSequitur build a grammar from a stream predictthenextexpectedinput(herecore).
of symbols, but they do not predict the next incoming
symbolsfrompastobservations.Therefore,weenrichedour BeforeDiscovery AfterDiscovery AfterUpdate
algorithmtobeabletomakesuchaprediction. S→aeAbAeb S→aeAbAeb S→aeAbAeb
A→cdb A→cdb A→cdb
This improvement works by marking some of the ter-
minal symbols in the grammar as predictors. Intuitively, a
unmarkingallterminalpredictorsthatdidnotcorrectly
symbol marked as a predictors in the grammar represents
predict the last input, enforcing the predictor’s con-
a position in grammar corresponding to a pattern that
straints, and then incrementing all remaining terminal
Omnisc’IO “thinks” we are currently encountering again.
predictors.Ifapredictoristhelastsymbolofarule,then
Assuming that Omnisc’IO is right, reading the grammar
nonterminalpredictorsthatreferenceitareincremented
from such a symbol will lead to a sequence of predictions
recursively. Examples of this operation are shown in
thatactuallymatchesfutureobservations.
Table3,wherepredictorsymbolsaremarkedinredand
This predictor characteristic is extended to nonterminal underlined.Forsimplicityreasons,theexamplesdonot
symbolsbyusingthefollowingconstraints: includesymbolswithexponents.
Discoveringpredictors: If all predictors have been re-
Predictor nesting: A nonterminal can be a predictor only movedbecausenoneofthemcorrectlypredictedthelast
ifatleastoneofitsnestedsymbolsisapredictor. input,anewstepisnecessarytorebuildasetofpredic-
tors. This step is completed by navigating through the
grammarandsettingaspredictorsallsymbolsmatching
withthelastsymbolofruleS (afterinsertionofthelast
Predictorutility:Ifsymbolx(terminalornot)isapredic-
input),andwithinthesesymbols,alloccurences.Parent
tor in rule Y, then if Y (cid:54)= S, there exists at least one rule
rulesarealsosetaspredictorsrecursivelywhereverthey
Z suchthataninstanceofY isapredictorinZ.
appear. Note that the last symbol of rule S may be a
nonterminal,whichforcesnewpredictorstobesearched
These constraints enforce that (1) if the grammar con- only within the context of its corresponding rule and
tains at least one predictor, then rule S contains at least thus reduces the number of predictors and narrows
one predictor, and (2) all the terminal predictors of the down the prediction. An example of this operation is
grammar can be reached from a predictor in S (proofs of showninTable4.Againforsimplicitywedon’tpresent
thesepropertiesaretrivial).Therelationslinkingpredictors the case of symbols carrying an exponent. After the
togetherformadirectacyclicgraphwithinthetreestructure discoveryofthesenewpredictors,anupdateisnecessary.
of thegrammar. These two structuralproperties have tobe
carefullypreservedwhenupdatingthegrammar.
3.1.4 Weightingpredictions
IntheparticularcontextofStarSequitur,wedonotonly
need to mark a symbol as a “predictor”, but also at which Thepredictionofthemodelcorrespondstothesetofterminal
occurrence(s)thissymbolisapredictor.Forinstance,symbol symbols marked as predictors after inserting a new input,
a7,whichreprensesthesequenceaaaaaaa,couldbemarked updatingthepredictors,andenforcingtheconstraints.Each
as a predictor only for its second and fifth occurrences such symbol is associated with a weight. The prediction
(aaaaaaa). A non-terminal symbol marked as a predictor made by Omnisc’IO for the next symbol thus consists of a
for some of its occurrences should keep track of its nested setofpairs(contextsymbol,weight).Theweightisdefinedas
predictorsforeachoftheseoccurrences. the number of paths (taking exponents into account) from rule S
In order to make predictions from the set of predictors, downtothepredictorsthroughthenestedpredictorsrelationship.
twooperationsaredefined,respectively,toupdatethesetof Theideabehindthisweightingsystemisthefollowing:ifa
predictorsandtofindnewones. symbolismarkedasapredictorinarulethatisoftenused
in the grammar, then it should be given a greater weight
Updatingpredictors: Forasymboloftheformx(terminal
thanasymbolappearinginarulethatismoreseldomused.
ornot,withoutexponent)markedasapredictor,wecall
Forinstance,inthefollowinggrammar
incrementingxtheoperationthatconsistsofunmarkingx
andmarkingasapredictorthesymbolthatimmediately S →ad3eAbAec A→cd,
follows it in the rule where x appears. For a symbol of
theformxnmarkedasapredictoratanoccurrencei≤k, eismarkedasapredictorinS,itsweightis1.dismarked
it consists of unmarking the occurrence i and marking as a predictor in A which is used twice as a predictor,
occurrence i + 1, or marking the symbol immediately and assuming all of its 3 occurences are marked in S, d’s
following if i = k. Updating predictors consists of first weightis1×2+3×1=5.Thisweightingsystemismore
5
elaborate than that of our previous version of Omnisc’IO, If the number of different access sizes observed for a
in which only the number of occurrences of the terminal given symbol is too large (typically larger than a config-
predictorswastakenintoaccount,regardlessofthenumber urableconstantS),thelocalsizegrammarisreplacedwitha
ofoccurrencesofitsparent,non-terminalpredictors. simple average, variance, minimum and maximum values,
that are updated whenever the context symbol is encoun-
tered.Forourexperiments,afteranalyzingthedistributions
3.1.5 From1toN predictions
ofdifferentaccesssizespersymbol,wechooseS =24.
Theterminalsymbolsmarkedaspredictorsinthegrammar More elaborate methods could be implemented to pre-
at a given moment give the set of predicted upcoming dicttheaccesssizesforcontextsymbolsthatexhibitappar-
(next) operations. For Omnisc’IO to be useful in HPC I/O entlyrandomsizes.WeshowinSection4,however,thatthe
optimizations, it should be able to predict any N future threecasespresentedabovehavebeensufficienttocoverthe
operations.Todoso,webuilditeratorsthatstartatcurrent behaviorofallourapplications.
predictorsandreadthegrammarfromthem.Theseiterators
are based on a stack of symbols. The top of the stack is 3.2.2 Trackingoffsets
always a terminal symbol, and the symbols that follow in
Many prefetching systems, including those implemented
the stack are instances of rules within which the symbol
in the Linux kernel [18], are based on the assumptions of
above them is read. When incrementing the iterator, the
consecutive accesses; that is, the next operation is likely to
top of the stack is popped, incremented, and the result
start from the offset where the previous one ended. As we
of this incrementation is pushed back on the stack. If the
will show in our experiments, this assumption is held for
top symbol was the last of its rule, it cannot be increment,
thePOSIX-basedapplicationsthatwetested,butitfailsfor
thereforenoresultispushedbackonthestack.Instead,the
applicationsthatuseahigher-levellibrarysuchasHDF5.In-
nextelementispoppedandincremented,andsoforthuntil
deed such libraries often move the offset pointer backward
anelementthatcanbeincrementedisfound.Whenpushing
orforwardtowriteheaders,footers,andmetadata.
a new symbol on top of the stack, if this element is a non-
terminal,thefirstsymbolofitsruleispushedonthestack, To predict the offset of the next operation, we define
and so forth until reaching a terminal. To give an example, the notion of offset transformation. An offset transformation
inthefollowinggrammar: can (1) leave the offset as it was at the end of the pre-
vious operation (consecutive access transformation), (2) set it
S →aeAbAec A→cd to a specific absolute value (absolute transformation), or (3)
set it to a value relative to the offset after the previous
thestackbuiltfrompredictorsis[d,A,S].Whenincrement- operation (relative transformation). Since it is not possible
ing it, d is the last of its rule, it is therefore popped out at low level to distinguish between absolute and relative
of the stack, which becomes [A,S]; the next top, A, can transformations, Omnisc’IO uses absolute transformations
be incremented to e, thus the next stack becomes [e,S]. only for operations that reset the offset to 0 (open and
Hence the prediction that follows d is e (and continuing, close).Allothernonconsecutiveoffsettransformationsare
thepredictionthatfollowseisc). consideredrelativetothepreviousoffset.
Note that when reaching the end of the grammar, it Omnisc’IO associates transitions between context sym-
is possible to keep making new predictions by taking any bols with offset transformations the same way it associates
iteratorbuiltfromcurrentpredictorsandreadingitagain. contextsymbolswithaccesssizes.Forinstance,ifsymbolb
followsaintheexecutionandalefttheoffsetatavaluefrom
which b starts, then the transition a → b is associated with
3.2 Context-awareI/Obehavior a sequential transformation. When a transition encounters
different types of offset transformations, Omnisc’IO builds
The final step in Omnisc’IO is the actual bookkeeping of
a local offset grammar for the transition. Local offset gram-
per-contextaccessbehavior.Thisisdonedifferentlyforeach
mars are the counterpart of local size grammars for offset
typeoftrackedmetrics.
transformations.Ifthegrammarassociatedwithatransition
growstoolarge(morethan24symbolsinourexperiments),
3.2.1 Trackingaccesssizes Omnisc’IO switches back to always predicting a sequential
offsettransformationforthistransitionofcontextsymbols.
Access sizes are tracked on a per-context symbol basis, so
that predicting the next context symbol helps in predicting 3.2.3 Trackingfilespointers
the next access size. As shown in Section 4, most context
symbols are always associated with the same access size For the prediction of offsets to work properly, Omnisc’IO
each time they are encountered in an execution, making it needstoknowthattwoconsecutiveoperationsworkonthe
easy to predict the exact size of the next accesses given a same file or that an operation works on a new file or a file
correctpredictionofthenextcontextsymbols. that has already been accessed earlier. This is particularly
important when accesses to multiple files interleave. The
For the minority of symbols associated with several
prediction of files accessed is done by recording opened
access sizes, Omnisc’IO keeps track of all access sizes en-
filepointersandassociatingtransitionsbetweensymbolsto
countered and builds a grammar from this sequence of
changes of file pointers. Since in our experiments the case
sizes. The sizes constitute the terminal symbols of this
of interleaved accesses to different files did not appear, we
grammar, which we call a local size grammar. The local
willnotstudythisparticularaspectfurther.
size grammar associated with a context symbol is updated
wheneverthecontextsymbolisencountered,anditevolves
3.2.4 Trackinginterarrivaltimes
independently of the main grammar and independently of
local size grammars attached to other symbols. It can then To keep track of the time between the end of an operation
beusedtomakepredictionsofthesize. and the beginning of the next one, Omnisc’IO uses a table
6
TABLE5:ListofapplicationsusedandtheirI/Obackends.
associatingtransitionsbetweencontextsymbolstostatistics
onthemeasuredtime.Thesestatisticsincludetheminimum
Application Field I/OMethod(s)
andmaximumobserved,theaverage,andthevariance.We
HDF5+POSIX
prefer these statistics rather than keeping only the average CM1 Climate HDF5+MPI-I/O
becausetheyrepresenttheminimumrequiredtoanswer(1) HDF5+Gzip
whether an operation will immediately follow (maximum, GTC Fusion POSIX
Nek5000 FluidDynamics POSIX
minimum, average, and variance close to 0); (2) whether
LAMMPS MolecularDynamics POSIX
the next operation will follow in a predictable amount of
time(maximum,minimum,andaverageclosetoeachother,
I/O schedulers of future incoming requests, properly al-
small variance); or (3) whether the time before the next
locating burst buffer resources as a response to predicted
operation is more unpredictable or depends on parame-
bursts,orenablingbetterprefetching.
ters that are not captured by our system (large minimum-
maximum interval, large variance). Thus, these statistics,
while minimal, give us a measure of the confidence in the 4 EVALUATION
predicted interarrival time, which may be important in the
contextofscheduling,forexample. Inthissection,weevaluateOmnisc’IOonrealapplications.
We first assess its capability to predict the next context
To quickly react to changes in interarrival times, Om-
symbols, and we show how the grammar grows in size
nisc’IO also keeps a weighted interarrival average time, up-
as the application continues to run with the base Sequitur
datedeverytimethetransitionbetweensymbolsisencoun-
algorithmandwithourStarSequitur.WethenevaluateOm-
teredbyusingthefollowingformula,
nisc’IO’sperformanceinpredictingthespatialandtemporal
characteristicsofthenextoperations.
T(cid:98)weighed+T
T(cid:98)weighed ← x→y , (1)
x→y 2
4.1 Platformandapplications
where x → y is the observed transition between context
symbols x and y and T is the measured interarrival time. All our experiments are carried out at the Nancy site of
This weighted average is more effective at making predic- the French Grid’5000 testbed [19]. The applications run on
tions of interarrival time, especially in a context where this a Linux cluster consisting of 92 Intel Xeon L5420 nodes
interarrivaltimevariesalotbetweendifferentobservations (8 cores per node, 736 cores in total), using MPICH 3.0.4.
ofthesametransition. The OrangeFS 2.8.7 parallel file system [20] is deployed
on a separate set of 12 Intel Xeon X3440 nodes. All nodes,
includingthefilesystem’s,areinterconnectedthrougha20G
3.3 OverallpredictionprocessandAPI InfiniBandnetwork.
The list of applications used is presented in Table 5.
Ateachoperation,Omnisc’IOupdatesitsmodels(themain
These applications are real-world codes representative of
grammar and the tables of access sizes, offset transforma-
applications running on current supercomputers (for in-
tions and interarrival times). It then updates its predictors
stance, CM1 has been used on NCSI’s Kraken and NCSA’s
andbuildsthesetofpossiblenextcontextsymbols(thisset
Blue Waters, GTC and LAMMPS are commonly used on
often consists of a single prediction). From these possible
ORNL’sTitan,andNek5000isusedbyscientistsatANLon
next symbols, a set of triplets (size, offset, date) is formed
theMirasupercomputer).
thatcanthenbeusedbyscheduling,prefetching,orcaching
systems. For the experiments in this paper, the applications are
run on 512 cores of Grid5000, except for Nek5000, which
To use Omnisc’IO, any software aiming at optimizing
runs on 32 cores. These applications are written in Fortran
I/O simply needs to be linked against the Omnisc’IO C++
exceptforLAMMPS(C++).MostofthemuseaPOSIXI/O
libraryandtocallthefollowingfunctions(intheomniscio
interface.
namespace):
To show the generality of our approach with respect to
• set<pair<iterator,int>> predict()returnsaset higher-levelI/Olibraries,CM1[21],[22]usestheHDF5[23]
of iterators to read the grammar from current terminal
I/O library over the default (POSIX) I/O driver, as well as
predictors.Eachiteratorisassociatedwithaweight(int);
the MPI-I/O driver offered by pHDF5, and Gzip compres-
• Given an iterator it: it->type(), it->size(), sionoverthedefaultPOSIXdriver.CM1writesonefileper
it->offset(), and it->elapsed() respectively re-
processperI/Ophase.ThedomaindecompositioninCM1
turn the predicted type of operation, access size, offset
issuchthattheamountofdataremainsthesameovertime
andtimebetweenthisoperationandthepreviousone.
and across processes. The use of compression exemplifies
the case of varying data size in a nonvarying domain
decomposition. CM1 exhibits a periodic I/O behavior as it
3.4 UsingOmnisc’IOatExascale
alternates between computation and write phases. We can
We envision Omnisc’IO to be integrated in more complex thereforeexpectburstsofI/Ooperations(shortinterarrival
systems by software developers, rather than exploited by time) separated by long (several minutes) phases without
application users themselves. Omnisc’IO can be easily in- any I/O. In terms of spacial pattern, the use of the HDF5
tegrated into low-level I/O interfaces such as POSIX or library produces a large number of seek operations. For
MPI-I/O, as shown in this work, and could thus be used instance with the POSIX backend, 35% of I/O operations
to improve the performance of these layers thanks to the arecallstolseek64,while63%correspondtowrite.The
predictionitprovides.Someexamplesofsuchusageinclude remaining2%aresharedbyopen,closeandreads.
automaticallyconfiguringthebackendfilesystemtopartic- GTC [24] writes one file per node per iteration, but
ular I/O patterns that the application exhibits, informing the amount of data varies between files as particles move
7
from one process to another. Each individual write is con- grammar model does not converge as fast and as perfectly
tiguous to the previous one and writes one particle. GTC astheotherapplications.InvestigatingthecodeofNek5000,
alsoexhibitsaperiodibehaviorwithburstofI/Oactivities wefoundthatthisisduetocodebranchesthatprocessdata
separatedbycomputationphases. in a different way depending on its content and then write
Like CM1, the domain decomposition in Nek5000 [25] it in an identical manner, leading to the creation of several
doesnotvaryovertime,buttheI/Ophaseisexecutedonly symbols that are actually interchangeable in the grammar.
by the rank 0 after a reduce phase. Nek5000 includes a first Moving the write call outside the branches would help
readphasetoloadinitialconditions. remove this indeterminism. Because we claimed our so-
lution works with no prior knowledge of the application
Like GTC, LAMMPS [26], [27] is a particle simulation,
and without the involvement of the application developer,
but the way the particles are written out differes. In the
we did not apply this code modification. The weakness of
configuration that we used, LAMMPS processes send their
Omnisc’IO in dealing with Nek5000’s behavior is however
data to the rank 0 process only, which writes them in
greatly mitigated by the use of our new weighting system.
batches contiguously in a single file. Each batch contains a
Weillustratedthisbyaddingtheresultswithouttheweight-
potentiallydifferentnumberofparticles,andthereforeeach
ingsystemingraylineFigure2.
writeisassociatedwithapotentiallydifferentsize.
We also observe a drop in prediction quality at the end
Although all processes write data in CM1 and GTC, we
oftheLAMMPSandNek5000runs.Thisdropisduetothe
considertheresultsofOmnisc’IOonlyonprocessrank0(for
final results being output in a section of the code different
applications that issue I/O from all processes, these results
from the one used for the periodic checkpoints. Thus these
are in fact identical in all processes since they exhibit the
symbols, which appear the first time at the end of the
same behavior). We first evaluate how well our algorithm
execution,couldnothavebeenpredictedbyanymodel.
predictsfuturecontextsymbolsbasedonpastobservations.
WethenevaluatetheabilityofOmnisc’IOtopredictthelo-
cation(offsetandsizeinthefile)ofthenextI/Ooperations. 4.2.2 PredictionofN nextsymbols
We also evaluate its ability to predict when future accesses In our next set of experiments, we aim to measure how
willhappen. far ahead Omnisc’IO can make predictions, using its iter-
ator functionality. That is, at a given operation, we ask
Omnisc’IO for an iterator over the next predicted symbols.
4.2 Contextprediction
Given that Omnisc’IO can provide several iterators asso-
ciated with weights, we only consider the iterator with
To measure context prediction capabilities, we run each
the highest weight here. We report how many of the pre-
application,andateachI/OoperationweuseOmnisc’IOto
dicted symbols are correct, up to either the first incorrect
predict the context symbols associated with the next ones.
prediction, or the end of the run. Results are reported in
We first show how well Omnisc’IO can predict the context
Figure3.Thegreylineinthesefiguresrepresentthenumber
symbol that will immediately follow the current operation.
of remaining symbols until the end of the application’s
We then show how many next context symbols Omnisc’IO
run. When the blue line (corresponding to the number of
cancorrectlypredict.
correctly predicted future symbols) reaches this grey line,
it means that Omnisc’IO is able to perfectly predict the
4.2.1 Immediatecontextprediction
futurebehavioruptotheendofrun.Asshowninthefigures,
this happens very quickly: after one I/O phase, Omnisc’IO
We use a sliding window of 10 operations and report the
has converged to a model that can correctly predict the
percentageofcorrectpredictions.WhenOmnisc’IOpredicts
future behavior of the application up to its end. It shows
severalpossiblenextsymbols,weusetheweightingsystem
that Omnisc’IO is not only capable of predicting the very next
described in Section 3.1.4 to turn weights into percentages.
symbol; it has, in most cases, fully understood the logic behind
Forinstance,ifOmnisc’IOpredictsthatthenextsymbolwill
be either a or b with respective weights 1 and 5, and the the application’s I/O behavior, and can predict any N future
observedsymbolisb,thispredictionisvalued100× 5 × 1 contextsymbols.Nek5000appearstobelesspredictable,as
6 10 alreadynoticedintheprevioussection.
(given the 10-symbol sliding window). For CM1 and GTC,
which run for long periods of time, we show only several
iterationsstartingfromthebeginningoftherun. 4.2.3 Costofafailedprediction
Results are shown in Figure 2. For all three configura- Afailedpredictionleadstosearchingnewpredictorswithin
tionsofCM1aswellasforLAMMPSandGTC,Omnisc’IO thegrammar,insteadofsimplyupdatingexistingones.This
converges to a perfect (steady 100%) prediction of symbols operation is linear in the size of the grammar (number
after the first iteration. The variation observed during the of symbols). Thus, reducing the grammar’s size thanks to
firstiterationcorrespondstothemomentthegrammarstarts StarSequitur helps mitigating this cost. A failed prediction
detectingtheinnermostloops. alsohasaneffectonthesystemthatleveragestheprediction.
Omnisc’IO seems to learn GTC’s behavior (Figure 2(e)) For instance, a prefetching algorithm would read unneces-
fast: the reason is that GTC’s I/O phase consists of a loop sarydataand/orfailtoreadthedatathatisactuallyneeded
over all particles, which is easily modeled in the grammar by the program. The real cost would therefore depend on
after the first two particles are written out. The predic- how much the incorrect operation consumes resources that
tion quality drops at the end of the first iteration when couldbeusedmoreproductively.
Omnisc’IO does not predict the end of this loop and the
file being closed. This mistake is never repeated in later
4.3 Grammarsize
iterations.ThesamepatternappearsinLAMMPS.
The case of Nek5000 is more interesting: although it Figure 4 shows the evolution of the size of the main
writes periodically the exact same amount of data, the grammar as a function of the number of operations. For
8
% 100 % 100 % 100
n 80 n 80 n 80
ctio 60 ctio 60 ctio 60
di 40 di 40 di 40
Pre 20 Pre 20 Pre 20
0 0 0
0 200 400 600 800 1000 1200 1400 1600 0 200 400 600 800 1000 1200 1400 0 1000 2000 3000 4000 5000 6000 7000 8000
Operations Operations Operations
(a) CM1+POSIX (b) CM1+Gzip (c) CM1+MPI-I/O
% 100 % 100 % 100
Prediction 24680000 Prediction 2468 00000 Prediction 24680000
0 0 2000 4000 6000 800 01000 01200 01400 016000 1000 02000 03000 04000 05000 06000 07000 08000 0900 010000000 0 0 5000 10000 15000 20000 25000
Operations Operations Operations
(d) Nek5000 (e) GTC (f) LAMMPS
Fig.2:ContextpredictioncapabilityofOmnisc’IOforthenextcontextsymbolonly,overtherunofeachapplication.Configurations(a),(b),(c),(e),and(f)exhibita
clearlearningphaseafterwhichOmnisc’IOmakesperfectpredictions((e)and(f)exhibitadropofpredictionattheendofthefirstiteration).In(d)thegraycurve
correspondstotheresultsfromourpreviouswork,withouttheweightingsystem.
ngth 11460000 ngth 11240000 ngth 78000000
e 1200 e 1000 e 6000
n L 1 800000 n L 800 n L 45000000
edictio 246000000 edictio 246000000 edictio 123000000000
Pr 0 0 200 400 600 800 1000 1200 1400 1600 Pr 0 0 200 400 600 800 1000 1200 1400 Pr 0 0 1000 2000 3000 4000 5000 6000 7000 8000
Operations Operations Operations
(a) CM1+POSIX (b) CM1+Gzip (c) CM1+MPI-I/O
h h h
engt 678000000000 engt 344505000000000 engt 2205000000
diction L 12345000000000000000 diction L 11223 505050000000000000000000 diction L 11 505000000000
Pre 0 0 2000 4000 6000 800 01000 01200 01400 016000 Pre 0 0 500 01000 01500 02000 02500 03000 03500 040000 Pre 0 0 5000 10000 15000 20000 25000
Operations Operations Operations
(d) Nek5000 (e) GTC (f) LAMMPS
Fig.3:NumberofsymbolsthatOmnisc’IOcorrectlypredictsoverthecourseofeachapplication’srun.ThisnumberisboundedbytheremainingnumberofI/O
operations(materializedbythegreyline).GiventhecomputationcostofperformingpredictionsuptotheendofthesimulationforeachI/Ooperations,wereduced
thelengthofGTC’sruninthisexperimentsto40000operations(3I/Ophases)ratherthan100000previously.
comparison,weshowingraythegrammarsizewhenusing Thememoryfootprintisdirectlylinkedtothesizeofthe
the“base”Sequitur,asopposedtoStarSequitur,hereinblue. main grammar (a symbol in our implementation is a 100-
One can clearly distinguish a first learning phase during byte C++ object, making the grammar consume 25 KB in
whichOmnisc’IOdiscoversthebehavioroftheapplication. the case of CM1+POSIX, for example), and the number of
This phase corresponds to the first iteration (potentially entriesinthetables(oneentrypersymbolorpertransition,
preceded by an input phase). It is followed by a stationary accountingalsoforafewbytes.CM1+POSIXuses198sym-
regime during which the model is updated. While this sta- bols, for example). This part of the memory footprint does
tionaryregimeledtoalogarithmically-increasinggrammar notincreaseafterthelearningphase.Thememoryfootprint
size with Sequitur, our StarSequitur algorithm allows the of Omnisc’IO is thus correlated mainly with the grammar
size to remain bounded in most of the cases. The highest size and does not exceed a few hundreds of kilobytes.
improvement in grammar size is visible with GTC, which StarSequitur ensures that this grammar size stays bounded
previously finished its run with a 450-symbol grammar, inmostcases.
while it now leads to a bounded, 27-symbol grammar.
While Nek5000’s grammar is not bounded, StarSequitur
stylemanagestooptimizeitssizeby31%.
9
TABLE6:Statisticsonaccesssizesbyeachapplication.
300 250
250 200 Application Min Max Average Std.dev.
mar Size 125000 StarSSeeqquuiittuurr mar Size 150 StarSSeeqquuiittuurr CCCMMM111(((PGMOzPiSIp-I)IX/)O) 444BBB 5256862.21..55KKKBBB 2511.0529..K95BKKBB 2126018.90..28KKKBBB
m m 100
Gra 1 5000 Gra 50 NGTekC5000 44BB 986.0.0KKBB 270.8.1KKBB 2190.07.0KBB
LAMMPS 3B 2.70MB 851.1KB 1.24MB
0 0
0 200 400 600 800 1000 1200 1400 1600 0 200 400 600 800 1000 1200 1400
Operations Operations |size −size |
(a) CM1+POSIX (b) CM1+Gzip Esize = spize o , (2)
o
450 450 where sizep is the predicted size and sizeo is the observed
400 400 size. Intuitively, if the predictions are always such that
mmar Size 223305050000 StarSSeeqquuiittuurr mmar Size 223305050000 (cEionsvizaeercat≤hcehi(cid:15)nn,egtehsdeynfsoteramltlho,ecfoantreinexxgtaom1pep+rlae(cid:15)t)iowtinmi.lleaslwthaeyspbreedeinctoeudghsiztoe
Gra 110500 Gra 110500 Figure 5 shows the relative error observed for all six
50 50 StarSSeeqquuiittuurr cases. In all but Nek5000, the error goes to 0 or close to 0
0 0 1000 2000 3000 4000 5000 6000 7000 8000 0 0 2000 4000 6000 800 01000 01200 01400 016000 athfteerintchoerlreeacrtnpinregdpichtaiosne.sEorfrocrosnotebxstersvyemdbionlsN.eInk5L0A00MmMaPtcSh,
Operations Operations the prediction is very close but not equal to 0. The reason
(c) CM1+MPI-I/O (d) Nek5000 is that the number of particles written (and thus the size
of each write) varies slightly from one write to another.
500 180 Thus,aftertryingtobuildalocalsizegrammaroutofthose
450 160 random sizes, Omnisc’IO falls back to keeping track of the
Grammar Size 112233405050500000000 StarSSeeqquuiittuurr Grammar Size 111 468024000000 StarSSeeqquuiittuurr aeservrveoeNrraroagolteeftoth5hno,aluytw.stahhneedrgesra.aspFhtohsreairnoebsctsauentrcvdeeo,dwifnerOtroomrasnmicsaacxn’IiOmbuepmroefrdeuilcapttsivtoae
5 00 1000 02000 03000 04000 05000 06000 07000 08000 0900 010000000 2 00 0 5000 10000 15000 20000 25000 wonrliyt2eboyrte5s,,0t0h0ebryetleastivweheirlerotrhiesa2p,4p9l9ic.ation actually writes
To put these relative errors in perspective, Table 6 pro-
Operations Operations
videsstatisticsonthesizesaccessedbyeachoperation.Note
(e) GTC (f) LAMMPS
that the standard deviation is often close to or even larger
than the average access size, making this average a poor
Fig.4:Evolutionofmaingrammarsize(sumofthelengthofeachrule,innumber
ofsymbols). estimatorifweweretouseitinaprediction.
4.4 Spatialprediction
4.4.2 Predictionofoffsets
SofarwehaveshownthatOmnisc’IOcanmodelandpredict
We consider that an offset prediction is either correct or
thebehavioroftheprogramintermsofitssequencesofcall
incorrect. When our algorithm makes several predictions
stacks.Inthissection,wefirstanalyzehowwelloursolution
for the next context symbol (and therefore several predic-
predictsthesizeandtheoffsetofthenextoperation.Wethen
tions of offset), correct predictions are weighed according
combinethesetwopredictionstocomputeahitratio.
to our weighting system. We compare our solution with
theclassicalcontiguousaccessestimation[18],whichconsists
4.4.1 Predictionofsizes of always predicting that the next offset will follow the
previousaccess.Table7showstheproportionofcontiguous
We analyzed how many different access sizes were asso-
accessesinoursetofapplicationsaswellastheproportion
ciated with each context symbol. We found that the vast
of correct predictions made by Omnisc’IO. In all cases,
majority of symbols were associated with just one size,
Omnisc’IO achieves a better prediction of offsets than does
potentiallydifferentforeachsymbol(171symbolsoutof183
thenaiveapproximationbasedoncontiguousaccesses.Itis
forCM1usingHDF5areassociatedwithonesize,andsim-
especiallybettersuitedwhenusingahigh-levelI/Olibrary
ilar numbers with GZIP and pHDF5, 12 out of 17 for GTC,
suchasHDF5inCM1,sinceitmanagestomodelandpredict
and all 38 of them for Nek5000). LAMMPS had the most
theportionofaccessesthatarenoncontiguous.Inparticular,
interestingdistribution,with123symbolsassociatedwitha
thepredictionofoffsetinCM1usingHDF5goesfrom47.4%,
unique size (yet potentially different for each symbol), and
when using a contiguous access estimation, to 92.2% with
oneuniquesymbolassociatedwithadifferentsizeatalmost
Omnisc’IO.
everyappearance.Thisdistributionisduetothefactthatall
nprocessessendtheirsetofparticlestotherank0process,
which writes them into a file in n successive write calls. 4.4.3 Hitratio
As the number of particles varies between processes and Wealsocombinethepredictionofsizesandoffsetstomea-
betweencheckpoints,thisleadstothevariationinobserved surehowaccuratelyoursolutioncanpredictthelocationof
sizes. thenextaccess.Thisinformationformsapredictedsegment
Toevaluatethepredictionofsizes,weusethefollowing S = xstart,xend . The segment effectively accessed by the
relativeerrorasametric: next (cid:74)I/O operatio(cid:75)n is denoted S0 = ystart,yend . The hit
(cid:74) (cid:75)