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.
Точне вимірювання можливе, оскільки у сучасних процесорах передбачено апаратні лічильники (зокрема збільшення лічильників за один тік процесора), які збільшують значення кожного разу, коли трапляється подія. Оскільки нам потрібно пов’ язати події з діапазонами коду, без лічильників нам би довелося обробляти кожну з подій шляхом збільшення значення лічильника для самого поточного діапазону коду. Виконання цього завдання у програмному забезпеченні, звичайно ж, неможливе; але, за припущення, що розподіл подій у вихідному коді є подібним до того, який ми отримуємо під час аналізу кожної n- ої події замість кожної події, можна створити метод вимірювання з контрольованим рівнем помилки: такий метод називається вибірковим контролем. Заснований на часі вибірковий контроль (Time Based Sampling або & TBS;) використовує таймер для регулярного стеження за лічильником програм для створення гістограми коду програми. Заснований на подіях вибірковий контроль (Event Based Sampling або & EBS;) використовує апаратні лічильники сучасних процесорів, а також режим, за якого лічильник подій зменшує значення шляхом виклику інструменту переривання на час створення гістограми відповідного розподілу подій: у інструменті переривання лічильник подій завжди переініціалізується на значення n - ого кроку вибіркового контролю. Перевагою вибіркового контролю є те, що код змінювати не потрібно, але цей спосіб все ж проміжним: використане під час обґрунтування методу припущення буде точнішим, якщо n достатньо мале, але, чим меншим буде n, тим вищою буде кількість додаткових викликів інструменту переривання.
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.
Ще одним методом вимірювання є імітація процесу, який відбувається у комп’ ютерній системі під час виконання вказаного коду, тобто імітацією, заснованою на виконанні. Імітація завжди виконується на допомогою більшою чи меншою мірою точної моделі комп’ ютера; але, якщо модель комп’ ютера буде дуже детальною і даватиме дуже близькі до реальних дані, час імітації буде неприйнятно великим. Перевагою імітації є те, що ви можете додавати у вказаний код код вимірювання/ імітації довільної складності без впливу на результати. Виконання цього додавання перед виконанням (це називається інструменталізацію виконання) за допомогою початкового виконуваного файла є дуже зручним для користувача: не потрібне ніяке перезбирання. Імітація стає придатною для використання за імітації лише частин комп’ ютера за допомогою простої моделі; іншою перевагою є те, що результати, створені за допомогою простих моделей часто простіше зрозуміти: часто проблеми, пов’ язані зі справжнім апаратним забезпечення (обладнанням), є те, що у отриманих результатів буде включено ефекти, які є наслідком роботи різних частин комп’ ютера.
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.
Найвідомішим є інструмент профілювання GCC, gprof: для його використання вам потрібно зібрати програму з параметром - pg; після запуску програми буде створено файл gmon. out, який можна перетворити у придатну для читання форму за допомогою команди gprof. Одним з недоліків є потреба у перезбиранні для підготовки виконуваного файла, який має бути зв’ язаним з бібліотеками статично. Тут використано створену компілятором інструменталізацію, — за якої буде виміряно час переходу викликів між функціями і відповідну кількість викликів з використанням & TBS;, — таким чином буде отримано гістограму розподілу часу у коді. З використанням обох цих джерел інформації можна виконати евристичне обчислення включеного часу функцій, тобто часу на обробку функції разом з усіма функціями, які було викликано з цієї функції.
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).
Для точного вимірювання для подій, які сталися, існують бібліотеки з функціями, які можуть читати дані з апаратних лічильників швидкодії. Найвідомішим у цьому плані є латка PerfCtr для & Linux; та архітектурно незалежні бібліотеки PAPI і PCL. Крім того, як ми про це говорили раніше, для точних вимірів потрібна інструменталізація коду. Можна використовувати або самі бібліотеки або автоматичні системи інструменталізації на зразок ADAPTOR (для інструменталізації вихідних кодів на FORTRAN) або DynaProf (вставка коду за допомогою DynInst).
& oprofile; is a system-wide profiling tool for Linux using Sampling.
& oprofile; — це загальносистемний інструмент для профілювання для & Linux;, у якому використано опитування.
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.
У багатьох аспектах зручним способом профілювання є використання & cachegrind; або & callgrind;, які є імітаторами, які використовують оболонку інструменталізації & valgrind;. Оскільки за такої схеми немає потреби у доступі до апаратних лічильників (який є ускладненим у сучасних дистрибутивах & Linux;), а виконувані файли, які профілюватимуться, залишаться незмінними, такий спосіб є непоганою альтернативою іншим інструментам профілювання. Наслідки недоліку імітації, — сповільнення, — можна зменшити імітацією лише цікавих частин програми або зменшенням кількості ітерацій під час циклу. Без інструменталізації вимірювання/ імітації використання & valgrind; коефіцієнт уповільнення змінюватиметься у діапазоні від 3 до 5. Крім того, якщо вас цікавлять лише граф викликів і кількість викликів, імітатор кешу можна вимкнути.
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.
Імітація кешу є першим кроком у наближенні справжніх часів, оскільки у сучасних комп’ ютерах виконання дуже чутливе до використання так званих кешів (маленьких і швидких буферів пришвидшує повторний доступ до тих самих комірок основної пам’ яті). & cachegrind; виконує імітацію кешу перехопленням доступу до пам’ яті. Серед створеного потоку даних буде кількість доступів до інструкцій/ даних у пам’ яті і промахів кешу першого/ другого рівнів, і співвідносить їх з рядками вихідних кодів і функціях запущеної програми. Комбінуванням цих кількостей промахів з використанням латентностей промахів від типових процесорів можна дістати оцінку витраченого часу.
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; є розширенням & cachegrind;, яке будує граф викликів програми на льоту, тобто граф, на якому буде показано спосіб, у який функції викликають одна одну, та кількість подій, які трапилися під час виконання функції. Крім того, дані профілю, які буде зібрано, може бути розподілено між потоками і контекстами ланцюжків викликів. Цей інструмент може надати дані профілювання на рівні інструкцій, що забезпечить коментування дизасембльованого коду.
Visualisation
Візуалізація
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; 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; є інструментом візуалізації даних профілювання, який створено саме з вказаною вище метою. Незважаючи на те, що програму було від початку створено для перегляду даних з & cachegrind; і & calltree;, у ній передбачено інструменти перетворення, які призначено для показу даних профілювання, створених іншими інструментами. У додатку цього підручника ви зможете знайти опис формату файлів & 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
Окрім списку функцій, впорядкованого відповідно до вимірів включеної і виключної вартості, який за бажання можна згрупувати за файлами вихідних кодів, спільними бібліотеками або класами C++, уkappname; передбачено різноманітні режими візуалізації для вибраної функції, зокрема
a tree-map view, which allows nested-call relations to be visualised, together with inclusive cost metric for fast visual detection of problematic functions,
перегляд деревоподібної карти, за допомогою якого можна переглянути взаємозв’ язки вкладених викликів разом з виміром включеної вартості для пришвидшення візуального виявлення проблемних функцій,
Generate Data to Visualise
Створення даних для візуалізації
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.
Першим, у чому виникне потреба є створення даних щодо швидкодії шляхом вимірів характеристик виконання програми за допомогою інструменту профілювання. У самому & kcachegrind; не передбачено інструменту профілювання, але ця програма непогано пристосована для показу даних & callgrind; або, за допомогою інструменту перетворення, даних & oprofile;. Хоча предметом цього підручника не є документування профілювання за допомогою цих інструментів, у наступному розділі наведено короткі початкові настанови щодо роботи з ними.
& callgrind; is available from http: / /kcachegrind. sf. net. Note that it previously was called & calltree;, but that name was misleading.
& callgrind; є частиною valgrind;. Зауважте, що раніше програма називалася & calltree;, але ця назва не відповідала призначенню програми.
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;.
Найпоширенішим способом використання є додавання перед командою запуску програми рядка valgrind -- tool=callgrind, наприклад, valgrind -- tool=callgrind myprogram myargs Після переривання роботи програми буде створено файл callgrind. out. pid, який можна завантажити у & 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.
Додатковою можливістю є створення дампів даних профілювання за виклику вказаної функції вашої програми. Наприклад, для того, щоб отримати дані профілювання для інструменту показу веб- сторінки у & konqueror;, вам може знадобитися створення дампу даних під час вибору пункту меню Перегляд Перезавантажити. Цей пункт відповідає виклику KonqMainWindow:: slotReload. Віддайте команду valgrind tool=callgrind -- dump- before=KonqMainWindow:: slotReload konqueror Буде створено декілька файлів з даними для профілювання з додатковим послідовним номером наприкінці назви файла. Крім того, буде створено файл без такого номера наприкінці назви (його назва завершуватиметься PID процесу); після завантаження цього файла до & kcachegrind;, буде завантажено і всі інші файли, — їх можна переглянути у огляді частин і списку частин.
& 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; можна звантажити з його домашньої сторінки. Виконайте настанови зі встановлення з веб- сайта; але, перш ніж виконувати ці настанови пошукайте відповідний пакунок у вашому дистрибутиві (наприклад, & 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.
Загальносистемне профілювання можна виконувати лише користувачеві root. Оскільки за такого профілювання можна спостерігати за всіма діями у системі, слід виконувати наступні дії від імені користувача root. Спочатку, налаштуйте процес профілювання за допомогою графічного інтерфейсу oprof_ start або інструменту командного рядка opcontrol. За стандартних налаштувань буде використано режим таймера (TBS;, див. вступ). Щоб розпочати вимірювання, виконайте команду opcontrol - s. Після цього запустіть програму, яка вас цікавить, і виконайте команду opcontrol - d. Ця команда запише всі результати вимірювання до файлів у теці / var/ lib/ oprofile/ samples /. Для того, щоб мати змогу візуалізувати дані у & kcachegrind;, виконайте таку команду у порожній теці: opreport - gdf _BAR_ op2callgrind Ця команда призведе до створення багатьох файлів, по одному файлу на кожну з програм, які було запущено у системі. Кожен з цих файлів можна окремо завантажити до & kcachegrind;.
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.
Після запуску & kcachegrind; з аргументом у вигляді назви файла даних профілювання або після завантаження цього файла за допомогою пункту меню Файл Відкрити... ви побачите панель навігації, на якій міститиметься список функцій, розташовану ліворуч, праворуч же буде показано основну частину з даними візуалізації обраної функції. Цю область візуалізації можна налаштувати довільним чином так, щоб у ній було показано декілька візуалізацій одночасно.
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.
Для візуалізації є важливим вибір активного типу подій: для & callgrind; це є, наприклад, промахи кешу або оцінка циклічності; для & oprofile; це є « Таймер » у найпростішому випадку. Ви можете змінити тип події за допомогою спадного списку на панелі інструментів або у перегляді типу подій. Перший огляд характеристик запуску можна отримати, якщо ви оберете функцію main у списку, розташованому ліворуч. Погляньте на візуалізацію графу виклику; там ви зможете побачити виклики, які було здійснено у вашій програмі. Зауважте, що у перегляді графу викликів буде показано лише функції з високими значеннями кількості подій. Подвійне клацання на позначках функцій на графі, перегляд буде змінено так, щоб було показано функції викликані вибраною вами функцією.
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.
Щоб краще вивчити можливості графічного інтерфейсу програми на додачу до цього підручника, зазирніть до розділу документації на веб- сайті. Крім того, кожен з віджетів & kcachegrind; має довідку Що це?.
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.
Лічильники вартості типів подій (на зразок промахів L2) пов’ язано з елементами вартості, які є елементами відносно вихідних кодів або структур даних вказаної програми. Елементи вартості можуть бути не лише прості позиції у коді або даних, але і пари позицій. Наприклад, у виклику є джерело і призначення або адреса у даних може мати тип даних і позицію у коді, з якої було викликано її виділення.
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.
Пари позицій: Виклик з адреси інструкції до функції призначення. Виклик з рядка вихідних кодів до функції призначення. Виклик з функції вихідних кодів до функції призначення. (Без) умовний перехід з вихідних кодів до інструкції призначення. (Без) умовний перехід з вихідних кодів до рядка призначення. Переходи між функціями заборонено, оскільки такі переходи не мають сенсу у графі викликів; таким чином, конструкції на зразок обробки виключень і довгих переходів у C слід перетворити, за потреби, на виштовхування стеку викликів.
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.
Типи подій, чию вартість вказано у файлі даних профілювання, називаються справжніми подіями. Крім того, ви можете вказати формули для типів подій, обчислені на основі справжніх подій, які називаються успадкованими подіями.
Visualisation State
Стан візуалізації