natgillin/translations-raw huggingface dataset:
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 reinitialised 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.
Exakta mätningar är möjliga på grund av räknare i hårdvara (inklusive räknare som ökas när tiden tickar), som tillhandahålls i moderna processorer, och som ökas så fort en händelse inträffar. Eftersom vi vill tilldela händelser till kodavsnitt, skulle vi behöva hantera varje händelse genom att öka en räknare för det aktuella kodavsnittet själva, om inte räknarna fanns. Att göra detta i programvara är förstås inte möjligt. Men med antagandet att distributionen av händelser i källkoden är liknande om man bara tittar på var n: e händelse istället för varje, har en mätmetod som är justerbar med avseende på tiden som går åt för mätningen skapats. Den kallas sampling. Tidsbaserad sampling (TBS) använder tidmätning för att regelbundet titta på programräknaren för att skapa ett histogram av programmets kod. Händelsebaserad sampling (EBS) utnyttjar hårdvaruräknarna i moderna processorer, och använder ett läge där en avbrottshanterare anropas när en räknare går förbi nollvärdet, och skapar ett histogram av motsvarande händelsefördelning. I avbrottshanteraren initieras räknaren alltid om till n i samplingsmetoden. Fördelen med sampling är att koden inte behöver ändras, men det är fortfarande en kompromiss: antagandet ovan är riktigare om n är litet, men ju mindre n är, desto större är tiden som går åt i avbrottshanteraren.
Another measurement method is to simulate things happening in the computer system when executing a given code, i. e. 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 practise. 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.
En annan mätmetod är att simulera det som händer i ett datorsystem när en given kod körs, dvs. körningsstyrd simulering. Simuleringen härleds alltid från en mer eller mindre noggrann modell av datorn. För mycket detaljerade modeller som är nära verkligheten, kan simuleringstiden dock vara oacceptabelt hög i praktiken. Fördelen med simulering är att godtyckligt komplex mätnings - och simuleringskod kan infogas i en given kod utan att störa resultaten. Att göra detta direkt innan körningen (vilket kallas instrumentering vid körning) med det ursprungliga binärprogrammet, är mycket bekvämt för användaren: Ingen omkompilering behövs. Simulering blir användbar om bara delar av en dator simulerats med en enkel modell. En annan fördel är att resultat som skapas av enkla modeller ofta är mycket enklare att förstå: problemet med riktig hårdvara är ofta att resultaten innehåller överlappande effekter från olika delar av datorn.
Profiling Tools
Profileringsverktyg
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 needed re-compilation step to prepare the executable, which has to be statically linked. The method used here is compiler-generated instrumention - 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, i. e. time spent in a function together with all functions called from it.
Mest känt är GCC: s profileringsverktyg gprof. Man måste kompilera programmet med väljaren - pg, köra programmet för att skapa filen gmon. out, som kan översättas till läsbar form med gprof. En nackdel är omkompileringssteget för att förbereda det körbara programmet, som också måste länkas statiskt. Metoden som används här är instrumentering skapad av kompilatorn, som mäter anrop som sker mellan funktioner och motsvarande antal anrop, tillsammans med tidsbaserad sampling, vilket ger ett histogram av tidsdistributionen i koden. Med båda typerna av information är det möjligt att heuristiskt beräkna samlad tid i funktioner, dvs. tiden som går åt i en funktion tillsammans med alla funktioner som anropas från den.
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).
För exakt mätning av händelser som inträffar, finns det bibliotek med funktioner som kan läsa ut hårdvaruprestandaräknare. Mest välkänd är programfixen PerfCtr för & Linux;, och de arkitekturoberoende biblioteken PAPI och PCL. Exakta mätningar behöver ändå instrumentering av koden, som tidigare beskrivits. Antingen använder man biblioteken själv, eller automatiska instrumenteringssystem som ADAPTOR (för instrumentering av FORTRAN källkod) eller DynaProf (kodinjicering via DynInst).
& oprofile; is a system-wide profiling tool for Linux using Sampling.
& oprofile; är ett systemprofileringsverktyg för & Linux; som använder sampling.
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.
I många avseenden är ett bekvämt sätt att utföra profilering att använda & cachegrind; eller & callgrind;, vilka är simulatorer som använder ramverket & valgrind; för instrumentering vid körning. Eftersom det inte finns något behov av att komma åt hårdvaruräknare (ofta svårt med dagens & Linux; - installationer), och binärprogram som ska profileras kan lämnas oförändrade, är det ett bra alternativt sätt jämfört med andra profileringsverktyg. Nackdelen med långsammare körning på grund av simuleringen kan reduceras genom att bara utföra simuleringen för intressanta programavsnitt, och kanske bara under några få iterationer av en snurra. Utan instrumentering för mätning och simulering leder & valgrind; s användning bara till en körning som är 3 till 5 gånger långsammare. Dessutom, om bara anropsdiagrammet och anropsantalen är intressanta, kan cachesimuleringen stängas av.
Cache simulation is the first step in approximating real times; as, on modern systems, 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.) & cachegrind; does cache simulation by catching memory accesses. The data produced includes the number of instruction/ data memory accesses and 1st/ 2nd 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.
Cachesimulering är det första steget i att approximera realtid, eftersom i moderna system är körtiden mycket känslig för hur så kallade cacher utnyttjas (små och snabba buffrar som snabbar upp upprepade åtkomster till samma celler i huvudminnet). & cachegrind; simulerar cacher genom att lagra minnesaccesser i cacherna. Den data som skapas omfattar antal åtkomster till instruktions - och dataminnet och cachemissar i första och andra nivåns cacher, och den relateras till källkodsrader och funktioner i programmet som kör. Genom att kombinera antal missar, och använda latenstider för missar för typiska processorer, kan en uppskattning av åtgången tid ges.
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.
& callgrind; är en utökning av & cachegrind; som bygger upp anropsträdet för ett program i farten, dvs. hur funktionerna anropar varandra och hur många händelser som inträffar när en funktion körs. Dessutom kan den profileringsdata som måste samlas in delas upp enligt trådar och anropskedjans sammanhang. Det kan tillhandahålla profileringsdata på instruktionsnivå för att göra det möjligt att kommentera disassemblerad kod.
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.
Profileringsverktyg skapar typiskt en stor mängd data. Önskan att snabbt bläddra uppåt och neråt i anropsdiagrammet, tillsammans med snabbt byte av sorteringsläge för funktioner och visning av olika händelsetyper, motiverar ett grafiskt gränssnitt för att utföra uppgiften.
& kappname; is an visualisation 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.
& kappname; är ett visualiseringsverktyg för profileringsdata som uppfyller dessa önskemål. Även om det först programmerats med bläddring i data från & cachegrind; och & calltree; i åtanke, finns det konverteringsprogram tillgängliga för att kunna visa profileringsdata som skapats av andra verktyg. I appendix ges en beskrivning av filformatet som används av & cachegrind; / callgrind;.
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 visualisation views for a selected function, namely
Förutom en lista med funktioner sorterade enligt mätetal över enskild eller samlad kostnad, eventuellt grupperade enligt källkodsfil, delat bibliotek eller C++ klass, erbjuder & kappname; diverse visualiseringsvyer för en vald funktion, närmare bestämt:
a call-graph view, which shows a section of the call graph around the selected function,
en anropsdiagramvy, som visar en del av anropsdiagrammet omkring den valda funktionen,
a tree-map view, which allows nested-call relations to be visualised, together with inclusive cost metric for fast visual detection of problematic functions,
en trädkarta, som gör det möjligt att visualisera anropsförhållanden i flera nivåer tillsammans med mätetal över samlad kostnad för snabb visuell detektering av problematiska funktioner,
source code and disassembler annotation views, allowing to see details of cost related to source lines and assembler instructions.
vyer för källkods - och assemblerkommentarer, som gör det möjligt att se kostnadsinformation relaterat till källkodsrader och assemblerinstruktioner.
Using & kcachegrind;
Att använda & kcachegrind;
Generate Data to Visualise
Skapa data att visualisera
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 visualise 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.
Först vill man skapa prestandainformation genom att mäta olika aspekter av ett programs beteende under körning, genom att använda ett profileringsverktyg. & kcachegrind; själv inkluderar inte något profileringsverktyg, men är bra på att användas tillsammans med & callgrind;, och kan också användas för att visualisera data som skapats av & oprofile;, genom att använda ett konverteringsprogram. Även om syftet med den här handboken inte är att dokumentera profilering med dessa verktyg, ger nästa avsnitt korta handledningar för att du snabbt ska komma igång.
& callgrind; is available from http: / /kcachegrind. sf. net. Note that it previously was called & calltree;, but that name was misleading.
& callgrind; är en del av valgrind;. Observera att det tidigare kallades & calltree; men det namnet var missvisande.
Most common use is to prefix the command line to start your application with callgrind, like in callgrind myprogram myargs At program termination, a file callgrind. out. pid will be generated which can be loaded into & kcachegrind;.
Den vanligaste användningen är att inleda kommandot för att starta ditt program med valgrind -- tool=callgrind, som med: valgrind -- tool=callgrind mitt_ program mina_ väljare När programmet avslutas skapas filen callgrind. out. pid, som kan laddas i & kcachegrind;.
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 rendering 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 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.
Mer avancerad användning är att lagra profileringsdata så fort en given funktion i programmet anropas. För att t. ex. bara se profileringsdata när en webbsida ritas upp i & konqueror;, skulle du kunna bestämma att lagra data så fort du väljer menyalternativet Visa Uppdatera. Det motsvarar ett anrop till KonqMainWindow:: slotReload. Använd valgrind -- tool=callgrind -- dump- before=KonqMainWindow:: slotReload konqueror Det skapar flera profileringsdatafiler med ett ytterligare sekvensnummer i slutet på filnamnet. En fil utan ett sådant nummer (som bara slutar med process- id) skapas också. Genom att ladda den filen i & kcachegrind;, så laddas alla övriga också, och kan ses i översikten över delar och i listan med delar.
& oprofile; is available from http: / /oprofile. sf. net. Follow the installation instructions on the web site; but, before you do, check if your distribution does not already provide it as package (like SuSE).
& oprofile; är tillgänglig från dess hemsida. Följ installeringsinstruktionerna på webbplatsen, men innan du gör det kontrollera om din distribution inte redan tillhandahåller det som ett paket (som & SuSE;).
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 directory / var/ lib/ oprofile/ samples/. To be able to visualise 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.
Profilering på systemnivå är bara tillåtet för systemadministratören, eftersom alla åtgärder i systemet kan observeras. Därför måste följande göras som systemadministratör. Anpassa först profileringsprocessen med det grafiska gränssnittet oprof_ start, eller kommandoradverktyget opcontrol. Standardinställningen ska vara tidsläge (TBS, se inledningen). För att starta mätningen, kör opcontrol - s. Kör därefter programmet du är intresserad av, och skriv efteråt opcontrol - d. Det skriver ut mätresultaten i filer under katalogen / var/ lib/ oprofile/ samples /. För att kunna visualisera data i & kcachegrind; gör följande i en tom katalog: opreport - gdf _BAR_ op2callgrind Det skapar många filer, en för varje program som kördes på systemet. Var och en kan laddas i & kcachegrind; för sig.
User Interface Basics
Grunderna i användargränssnittet
When starting & kcachegrind; with a profile data file as argument, or after loading one with File/ Open, you will see a sidebar containing the function list at the left; and, on the right the main part, an area with visualisations for a selected function. This visualisation area can be arbitrarily configured to show multiple visualisations at once.
När & kcachegrind; startas med en profileringsdatafil som argument, eller efter en fil har laddats med Arkiv Öppna, ser du en sidopanel som innehåller funktionslistan till vänster, och till höger huvudområdet för visualiseringar av den valda funktionen. Visualiseringsområdet kan ställas in godtyckligt för att visa flera visualiseringar samtidigt.
The active event type is important for visualisation: 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, and look at the call graph visualisation; there, you see calls happening 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.
Den aktiva händelsetypen är viktig för visualiseringarna: för & callgrind; är det till exempel cachemissar eller cykeluppskattningar, för & oprofile; är det timer i det enklaste fallet. Du kan ändra händelsetyp via en kombinationsruta i verktygsraden eller i vyn Händelsetyp. En första översikt över beteendet under körning bör ges när du väljer funktionen main i listan till vänster, och tittar på visualiseringen anropsdiagram. Där ser du anropen som sker i programmet. Observera att anropsdiagramvyn bara visar funktioner med ett högt händelseantal. Genom att dubbelklicka på en funktion i diagrammet ändras det så att anropade funktioner omkring den valda visas.
To explore the GUI further, in addition to this manual, also have a look at the documentation section on the web site http: / /kcachegrind. sf. net. Also, every widget in & kcachegrind; has What 's this help.
För att utforska det grafiska gränssnittet ytterligare, förutom den här handboken, ta också en titt på dokumentationsavsnittet på webbsidan. Förutom detta, har varje grafisk komponent i & kcachegrind; hjälp via Vad är det här?.
Basic Concepts
Grundläggande begrepp
This chapter explains some concepts of the & kcachegrind;, and introduces terms used in the interface.
Det här kapitlet förklarar några begrepp i & kcachegrind; och introducerar termer som används i gränssnittet.
The Data Model for Profile Data
Datamodellen för profileringsdata
Cost Entities
Kostnadsenheter
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 an code position where its allocation happened.
Kostnadsantal för händelsetyper (som L2 missar) tilldelas till kostnadsenheter, som är objekt med förhållanden till källkod eller datastrukturer i ett givet program. Kostnadsenheter kan inte bara vara enkla kod - eller datapositioner, utan också sammansatta positioner. Ett anrop kan till exempel ha en källa och ett mål, eller en dataadress kan ha en datatyp och en kodposition där data har skapats.
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.
Positionsinformation: Anrop från instruktionsadress till målfunktion. Anrop från källkodsrad till målfunktion. Anrop från källfunktion till målfunktion. (O) villkorligt hopp från käll - till målinstruktion. (O) villkorligt hopp från käll - till målrad. Hopp mellan funktioner tillåts inte, eftersom det inte är vettigt i ett anropsdiagram. Därför måste konstruktioner som undantagshantering och långa hopp i C översättas genom att gå bakåt i anropsstacken efter behov.
Event Types
Händelsetyper
Arbitrary event types can be specified in the profile data by giving them a name. Their cost related to a cost entity is a 64-bit integer.
Godtyckliga händelsetyper kan anges i profileringsdata genom att ge dem ett namn. Deras kostnad i förhållande till en kostnadsenhet är ett 64- bitars heltal.
Event types whose costs are specified in a profile data file are called real events. Additionally, one can specify formulae for event types calculated from real events, which are called inherited events.
Händelsetyper vars kostnad anges i en profileringsdatafil kallas verkliga händelser. Dessutom kan man ange formler för händelsetyper som beräknas från verkliga händelser, som kallas ärvda händelser.
Visualisation State
Visualiseringstillstånd