natgillin/translations-raw huggingface dataset:
Præcis måling er mulig fordi hardwaretællere (inklusive tællere der optælles én gang pr. klokpuls), som er til rådighed i moderne processorer, optælles hver gang der sker en begivenhed. Da vi gerne vil henføre begivenheder til kodeområder, ville vi uden tællerne, være nødt til at håndtere hver eneste begivenhed, ved selv at skulle optælle en tæller for kodeområdet. At gøre dette i software er naturligvis ikke muligt. Under antagelsen af at der er en ens fordeling af begivenheder i kildekoden, når man kun ser på hver n' te begivenhed i stedet for hver eneste, har vi konstrueret en målemetode som er mulig at finindstille mht. omkostninger. Dette kaldes at sample. Tidsbaseret sampling benytter en tæller til jævnligt at se på programtælleren til at lave et histogram af programkoden. Begivenhedsbaseret sampling udnytter hardwaretællere i moderne processorer og bruger en tilstand hvor en interrupt håndtering kaldes ved tællerunderløb, hvorved der genereres et histogram af den tilsvarende fordeling f begivenheder. I håndteringen gen- initialiseres begivenhedstælleren altid til samplingmetodens n. Fordelen ved sampling er at koden ikke skal ændres. Det er dog stadig et kompromis. Den ovenstående antagelse bliver mere korrekt når n er et lille tal, men jo mindre værdi af n, jo højere er omkostningerne til interrupthåndteringen.
Exact measurement is possible because of hardware counters (including counters incrementing on a time tick) provided in modern processors, which are incremented whenever an event is happening. As we want to attribute events to code regions, without the counters, we would have to handle every event by incrementing a counter for the current code region ourself. Doing this in software is, of course, not possible; but, on the assumption that the event distribution over source code is similar when looking only at every n-th event instead of every event, a measurement method whose overhead is tunable has been developed: it is called Sampling. Time Based Sampling (TBS;) uses a timer to regularly look at the program counter to create a histogram over the program code. Event Based Sampling (EBS;) exploits the hardware counters of modern processors, and uses a mode where an interrupt handler is called on counter underflow to generate a histogram of the corresponding event distribution: in the handler, the event counter is always reinitialized to the n of the sampling method. The advantage of sampling is that the code does not have to be changed, but it is still a compromise: the above assumption will be more correct if n is small, but the smaller the n, the higher the overhead of the interrupt handler.
Endnu en målemetode er at simulere det der sker i computersystemet når noget given kildekode eksekveres, dvs. kørselsdrevet simulering. Denne simulering er naturligvis altid afledt af en mere eller mindre præcis model af maskinen. Til meget detaljerede modeller, der kommer meget tæt på virkeligheden, kan simuleringstiden i praksis være uacceptabelt stor. Fordelen er at vilkårligt kompleks målings - og simuleringskildekode kan indsættes i noget given kildekode uden at påvirke resultaterne. At gøre dette lige før kørslen (kaldes, kørselstidsinstrumentering), ved at bruge den oprindelige kørbare, er meget komfortabelt for brugeren. Metoden er brugbar når man kun simulerer dele af en maskine og med en simpel model. Desuden er resultater produceret af en simpel model meget lettere at tolke. Problemet med rigtig hardware, er at resultaterne ofte viser overlappende effekter fra forskellige dele af maskinen.
Another measurement method is to simulate things happening in the computer system when executing a given code, & ie; execution driven simulation. The simulation is always derived from a more or less accurate machine model; however, with very detailed machine models, giving very close approximations to reality, the simulation time can be unacceptably high in practice. The advantage of simulation is that arbitrarily complex measurement/ simulation code can be inserted in a given code without perturbing results. Doing this directly before execution (called runtime instrumentation), using the original binary, is very comfortable for the user: no re-compilation is necessary. Simulation becomes usable when simulating only parts of a machine with a simple model; another advantage is that the results produced by simple models are often easier to understand: often, the problem with real hardware is that results include overlapping effects from different parts of the machine.
Mest kendt er GCC' s profileringsværktøj gprof. Du skal kompilere programmet med flaget - pg, køre programmet for at oprette filen gmon. out, som kan oversættes til læsbar form med gprof. En ulempe er kompileringsskridtet for at forberede det kørbare program, som også skal linkes statisk. Denne metode kaldes oversættergenereret instrumentering. Den måler kaldbuer der sker blandt funktioner og i henhold til kaldtællinger i forbindelse med tidsbaseret sampling, der giver et histogram over tidsfordelingen i koden. Ved at udnytte begge typer oplysninger, er det muligt, heuristisk at beregne iberegnet tid i funktioner, dvs. tiden forbrugt i en funktion inklusive alle funktioner der kaldes fra denne funktion
Most known is the GCC profiling tool gprof: one needs to compile the program with option -pg; running the program generates a file gmon. out, which can be transformed into human-readable form with gprof. One disadvantage is the required re-compilation step to prepare the executable, which has to be statically linked. The method used here is compiler-generated instrumentation, which measures call arcs happening among functions and corresponding call counts, in conjunction with & TBS;, which gives a histogram of time distribution over the code. Using both pieces of information, it is possible to heuristically calculate inclusive time of functions, & ie; time spent in a function together with all functions called from it.
For præcis måling af begivenheder, eksisterer der biblioteker med funktioner, der er i stand til at udlæse hardwareydelsestællere. De mest kendte her er PerfCtr patchen til & Linux; og de arkitekturuafhængige biblioteker PAPI og PCL. Der er dog stadig behov for præcise målinger som forklaret i det ovenstående. Enten benytter man bibliotekerne for sig selv eller også benytter man automatiserede instrumenteringssystemer som ADAPTOR (til FORTRAN kildekodedokumentation) eller DynaProf (kodeindsættelse via. DynInst).
For exact measurement of events happening, libraries exist with functions able to read out hardware performance counters. Most known here is the PerfCtr patch for & Linux;, and the architecture independent libraries PAPI and PCL. Still, exact measurement needs instrumentation of code, as stated above. Either one uses the libraries itself or uses automatic instrumentation systems like ADAPTOR (for FORTRAN source instrumentation) or DynaProf (code injection via DynInst).
& oprofile; er et profileringsværktøj til & Linux;. Det benytter sampling.
& oprofile; is a system-wide profiling tool for & Linux; using Sampling.
På mange måder er brug af & cachegrind; eller & callgrind;, en behagelig måde at udføre profilering på. De er begge simulatorer der benytter kørselstidsinstrumenteringsskelettet & valgrind;. Fordi der ikke er noget behov for at tilgå hardwaretællere (ofte vanskeligt med dagens & Linux; - distributioner) og fordi de binære filer der skal profileres ikke behøver ændringer, er det et godt alternativ til andre profileringsværktøjer. Ulempen ved hastighedstab ved simulering, kan reduceres ved at udføre simuleringen, kun på de interessante steder i programmet og måske kun i et par iterationer af en løkke. Uden målings - eller simuleringsinstrumentering, ses der ved brug af & valgrind; kun et hastighedstab i størrelsesordenen 3- 5. Når der kun benyttes kaldgrafen og kaldtælling kan cachesimulatoren slås helt fra.
In many aspects, a comfortable way of Profiling is using & cachegrind; or & callgrind;, which are simulators using the runtime instrumentation framework & valgrind;. Because there is no need to access hardware counters (often difficult with today's & Linux; installations), and binaries to be profiled can be left unmodified, it is a good alternative to other profiling tools. The disadvantage of simulation - slowdown - can be reduced by doing the simulation on only the interesting program parts, and perhaps only on a few iterations of a loop. Without measurement/ simulation instrumentation, & valgrind; 's usage only has a slowdown factor in the range of 3 to 5. Also, when only the call graph and call counts are of interest, the cache simulator can be switched off.
Cachesimulering er det første skridt på vejen til ca. realtider, eftersom kørselstiden på moderne systemer, er meget følsom overfor udnyttelsen af cache, små hurtige buffere, som accelererer gentagen tilgang til samme hukommelsesceller. & cachegrind; udfører cachesimulering ved at opfange hukommelsestilgang. De data der produceres, omfatter antallet af instruktioner, adgange til instruktion/ datahukommelse og ikke ramt cache i første og andetniveaus cacher og relaterer det til kildekodelinjer og funktioner i programmet som kører. Ved at kombinere disse ikke ramt- tællinger ved brug af typisk ikke ramt- latens, kan den forbrugte tid estimeres.
Cache simulation is the first step in approximating real times, since runtime is very sensitive to the exploitation of so-called caches, small and fast buffers which accelerate repeated accesses to the same main memory cells, on modern systems. & cachegrind; does cache simulation by catching memory accesses. The data produced includes the number of instruction/ data memory accesses and first- and second-level cache misses, and relates it to source lines and functions of the run program. By combining these miss counts, using miss latencies from typical processors, an estimation of spent time can be given.
& callgrind; er en udvidelse af & cachegrind; der opbygger kaldgrafen for et program uden videre & ie; hvordan funktionerne kalder hinanden og hvor mange begivenheder der sker mens en funktion køres. Desuden kan de profildata der skal indsamles, blive adskilt af tråde og kaldkæde- sammenhænge. Den kan sørge for profilering af data på instruktionsniveau for at tillade annotering af disassembled kode.
& callgrind; is an extension of & cachegrind; that builds up the call graph of a program on-the-fly, & ie; how the functions call each other and how many events happen while running a function. Also, the profile data to be collected can separated by threads and call chain contexts. It can provide profiling data on an instruction level to allow for annotation of disassembled code.
Visualisering
Visualization
Profileringsværktøjer producerer typisk store mængder af data. Ønsket om nemt at kunne browse op og ned i kaldgrafen, sammen med hurtig skift i sorteringen af funktioner og visning af forskellige begivenhedstyper, tilskynder til et program med en grafisk brugerflade.
Profiling tools typically produce a large amount of data. The wish to easily browse down and up the call graph, together with fast switching of the sorting mode of functions and display of different event types, motivates a & GUI; application to accomplish this task.
& kappname; er visualisering af profildata og opfylder dermed disse ønsker. Selvom det er oprindelig er programmeret med browsing af data fra & cachegrind; og & calltree; in mente, er der konvertere til rådighed der kan vise profildata fra andre værktøjer. I appendikset gives der en beskrivelse af & cachegrind; / callgrind; filformatet.
& kappname; is a visualization tool for profile data fulfilling these wishes. Despite being programmed first with browsing the data from & cachegrind; and & calltree; in mind, there are converters available to be able to display profile data produced by other tools. In the appendix, a description of the & cachegrind; /callgrind; file format is given.
Udover en liste af funktioner sorteret i henhold til eksklusiv - eller inklusivomkostningsmetrik og efter valg, grupperet efter kildefil, delt bibliotek eller C++- klasser, & kappname; er der også mulighed for forskellige grafvisninger for en valgt funktion.
Besides a list of functions sorted according exclusive or inclusive cost metrics, and optionally grouped by source file, shared library or C++ class, & kappname; features various views for a selected function, namely:
en træ- kort- visning som tillader en at visualisere indlejrede kaldrelationer til hinanden, med inklusivomkostningsmetrik til hurtig visuel detektion af problemfyldte funktioner,
a tree-map view, which allows nested-call relations to be visualized, together with inclusive cost metric for fast visual detection of problematic functions,
Opret data til visning
Generate Data to Visualize
Først vil man generere ydelsesdata, ved at måle aspekter af et programs karakteristik ved kørsel, ved at bruge et profileringsværktøj. & kcachegrind; indeholder ikke noget profileringsværktøj, men udmærker sig når det bruges i kombination med & callgrind;. Det kan også, ved at anvende en konverter, bruges til at visualisere data produceret af & oprofile;. Selvom dette ikke er denne manuals opgave at dokumentere profilering med disse værktøjer, får næste sektion dig hurtigt i gang med en kort guide.
First, one wants to generate performance data by measuring aspects of the runtime characteristics of an application, using a profiling tool. & kcachegrind; itself does not include any profiling tool, but is good in being used together with & callgrind;, and by using a converter, also can be used to visualize data produced with & oprofile;. Although the scope of this manual is not to document profiling with these tools, the next section provides short quickstart tutorials to get you started.
& callgrind; er til rådighed fra http: // kcachegrind. sf. net Læg mærke til at det tidligere hed & calltree;, men dette navn var misvisende.
& callgrind; is a part of valgrind;. Note that it previously was called & calltree;, but that name was misleading.
Normalt bruges callgrind som præfiks på kommandolinjen når du starter dit program, således: til præfiks kommando linje til start program tommer program a fil Indlæstkcachegrind;.
The most common use is to prefix the command line to start your application with valgrind --tool=callgrind, as in: valgrind --tool=callgrind myprogram myargs At program termination, a file callgrind. out. pid will be generated, which can be loaded into & kcachegrind;.
Mere avanceret brug ville være at dumpe profildata hver gang en given funktion i din applikation bliver kaldt. F. eks. for konqueror for at se profildata kun for optegning af en netside, kunne man vælge at dumpe data hver gang man vælger vis/ genopfrisk. Dette svarer til at kalde KonqMainWindow:: slotReload. Brug callgrind -- dump- before=KonqMainWindow:: slotReload konqueror. Dette producerer flere profildatafiler med et ekstra sekventielt nummer i slutningen af filnavnet. En fil uden et sådant nummer (som kun ender på proces- PID) produceres også. Ved at indlæse filen i & kcachegrind;, indlæses alle de andre også og kan ses i partoversigten og partlisten.
More advanced use is to dump out profile data whenever a given function of your application is called. E. g. for & konqueror;, to see profile data only for the rendering of a Web page, you could decide to dump the data whenever you select the menu item View Reload. This corresponds to a call to KonqMainWindow: :slotReload. Use: valgrind --tool=callgrind --dump-before=KonqMainWindow: :slotReload konqueror This will produce multiple profile data files with an additional sequential number at the end of the filename. A file without such an number at the end (only ending in the process PID) will also be produced; by loading this file into & kcachegrind;, all others are loaded too, and can be seen in the Parts Overview and Parts list.
& oprofile; er tilgængelig fra http: // oprofile. sf. net. Følg installationsinstruktionerne på siden. Kontrollér dog først om ikke din distribution allerede har en pakke til rådighed (som & SuSE;).
& oprofile; is available from its home page. Follow the installation instructions on the Web site, but, before you do, check whether your distribution does not already provide it as package (like & SuSE;).
Profilering af hele systemet er kun tilladt for root, fordi alle handlinger på systemet kan observeres. Derfor skal man gøre det følgende som root. Først konfigureres profileringsprocessen, vha. & GUI; oprof_ start eller med kommandolinjeværktøjet opcontrol. Standardkonfigurationen bør være timertilstand (se introduktionen). For at begynde målingen køres opcontrol - s. Dernæst køres applikationen du er interesseret i og bagefter udføres opcontrol - d. Dette udskriver måleresultaterne til filer under kataloget / var/ lib/ oprofile/ samples. For at kunne visualisere dataene i & kcachegrind; udføres dette i et tomt katalog: opreport - gdf _BAR_ op2callgrind. Dette producerer en masse filer, en for hvert program der kørte på systemet. Filerne kan indlæses i & kcachegrind; hver for sig.
System-wide profiling is only permitted to the root user, as all actions on the system can be observed; therefore, the following has to be done as root. First, configure the profiling process, using the & GUI; oprof_start or the command-line tool opcontrol. Standard configuration should be timer mode (TBS;, see introduction). To start the measurement, run opcontrol -s. Then run the application you are interested in and, afterwards, do a opcontrol -d. This will write out the measurement results into files under folder / var/ lib/ oprofile/ samples/. To be able to visualize the data in & kcachegrind;, do in an empty directory: opreport -gdf _BAR_ op2callgrind This will produce a lot of files, one for every program which was running on the system. Each one can be loaded into & kcachegrind; on its own.
Når & kcachegrind; starter med en profildatafil som argument eller efter at have indlæst en med Fil/ Åbn, vil du se en sidebar med funktionslisten til venstre og hovedparten, et område med grafer, til højre. Grafområdet kan indstilles arbitrært, så det kan vise flere grafer på én gang.
When starting & kcachegrind; with a profile data file as argument, or after loading one with File Open, you will see a navigation panel containing the function list at the left; and, on the right the main part, an area with views for a selected function. This view area can be arbitrarily configured to show multiple views at once.
Vigtigt for visualiseringen er den aktive begivenhedstype. For & callgrind; er den f. eks. ikke- ramt cache eller cyklusestimering. For & oprofile; er den "Timer" i den simpleste form. Du kan ændre begivenhedstypen via en kombinationsboks i værktøjslinjen eller i begivenhedstypevisningen. Når du vælger funktionen main og ser på kaldgrafen, vises der et overblik over kørselstidskarakteristikken. Der kan du se kald der sker i dit program. Læg mærke til at kaldgrafen kun viser funktioner med et højt antal begivenheder. Ved at dobbeltklikke på funktionen i grafen, ændres den så der vises kaldte funktioner omkring den markerede.
The active event type is important for visualization: for & callgrind;, this is, for example, cache misses or cycle estimation; for & oprofile;, this is Timer in the simplest case. You can change the event type via a combobox in the toolbar or in the Event Type view. A first overview of the runtime characteristics should be given when you select function main in the left list; look then at the call graph view. There, you see the calls occurring in your program. Note that the call graph view only shows functions with high event count. By double-clicking a function in the graph, it will change to show the called functions around the selected one.
For at udforske grænsefladen yderligere, bør du, udover at se i denne håndbog, også se nærmere på dokumentationen på hjemmesiden http: // kcachegrind. sf. net. Derudover har hver kontrol i & kcachegrind; Hvad er dette hjælp.
To explore the & GUI; further, in addition to this manual, also have a look at the documentation section on the Web site. Also, every widget in & kcachegrind; has What's this help.
Omkostningsoptælling af begivenhedstyper (som ikke- ramt L2) skyldes omkostningsentiteter i forbindelse med kildekode eller datastrukturer i et givet program. Omkostningsentiteter kan være ikke blot simpel kode eller datapositioner, men også positionstupler. F. eks. et kald har en kilde og et mål eller en dataadresse kan have en datatype og en kodeposition hvor allokeringen er foregået.
Cost counts of event types (like L2 Misses) are attributed to cost entities, which are items with relationship to source code or data structures of a given program. Cost entities not only can be simple code or data positions, but also position tuples. For example, a call has a source and a target, or a data address can have a data type and a code position where its allocation happened.
Positionstupler: Kald fra instruktionsadresse til målfunktion. Kald fra kildelinje til målfunktion. Kald fra kildefunktion til målfunktion. (U) betinget spring fra kilde til målinstruktion. (U) betingent spring fra kilde til mållinje. Spring mellem funktioner er ikke tilladte eftersom det ikke giver nogen mening i en kaldgraf. Derfor skal kontruktioner som undtagelseshåndtering og lange hop, oversættes til at poppe på kaldstakken når behovet opstår.
Positions tuples: Call from instruction address to target function. Call from source line to target function. Call from source function to target function. (Un)conditional jump from source to target instruction. (Un)conditional jump from source to target line. Jumps between functions are not allowed, as this makes no sense in a call graph; thus, constructs like exception handling and long jumps in C have to be translated to popping the call stack as needed.
Begivenhedstyper hvis omkostninger er angivet i profildatafilen, kaldes ægte begivenheder. Yderligere kan man angive formler for begivenhedstyper beregnet ud fra reelle begivenheder. De kaldes arvede begivenheder.
Event types whose costs are specified in a profile data file are called real events. Additionally, one can specify formulas for event types calculated from real events, which are called inherited events.
Graftilstand
Visualization State
Visualiseringtilstande i & kcachegrind; inkluderer: primær og sekundær begivenhedstype valgt til visning, funktionsgrupperingen (brugt i funktionsprofillisten og entitetsfarvelægningen), profilpartene hvis omkostninger skal inkluderes i visningen, en aktiv omkostningsentitet (f. eks. en funktion markeret i den dokbare funktionsprofil), en markeret omkostningsentitet. Denne tilstand påvirker visningerne.
The visualization state of a & kcachegrind; window includes: the primary and secondary event type chosen for display, the function grouping (used in the Function Profile list and entity coloring), the profile parts whose costs are to be included in visualization, an active cost entity (eg; a function selected from the function profile sidedock), a selected cost entity. This state influences the views.
Visualiseringer vises altid for en, den aktive, omkostningsentitet. Når en given visualisering ikke er giver mening for en omkostningsentitet, deaktiveres den. F. eks. når man vælger et & ELF; - objekt i gruppelisten ved at dobbeltklikke, giver kildekommentar til et & ELF; - objekt ingen mening.
Views are always shown for one cost entity, the active one. When a given view is inappropriate for a cost entity, it is disabled: when selecting & eg; an & ELF; object in the group list, source annotation makes no sense.
F. eks. for en aktiv funktion, viser kalderlisten alle funktionerne der kaldes fra den aktive. Man kan vælge en af disse funktioner uden at gøre den aktiv. Vises kaldgrafen ved siden af, vælges den samme funktion automatisk.
For example, for an active function, the callee list shows all the functions called from the active one: one can select one of these functions without making it active. Also, if the call graph is shown beside, it will automatically select the same function.
Elementer i brugerfladen
Parts of the & GUI;