natgillin/translations-raw huggingface dataset:
The documentation for & kbugbuster; was not finished when & kde; was installed on this computer.
Документацію для & kbugbuster; не було завершено до часу, коли на цьому комп’ ютері було встановлено & kde;.
If you need help, please check The & kde; Website for updates, or by submitting your question to The & kde; User Mailing list.
Якщо вам потрібна довідка, будь ласка, перевірте, чи немає оновлень на Веб- сайті & kde; або задайте питання у списку листування користувачів & kde;.
The & kcachegrind; Handbook
Підручник з & kcachegrind;
Original author of the documentation
Перший автор документації
Updates and corrections
Оновлення і виправлення
& kcachegrind; is a profile data visualization tool, written using the & kde; environment.
& kcachegrind; — це інструмент для візуалізації даних профілювання, створений з використанням середовища & kde;.
Profiling
Профілювання
& kappname; is a browser for data produced by profiling tools. This chapter explains what profiling is for, how it is done, and gives some examples of profiling tools available.
& kappname; — програма, призначена для перегляду даних, створених інструментами для профілювання. У цій главі ми обговоримо призначення профілювання, способи його виконання, також наведемо приклади можливих інструментів профілювання.
When developing a program, one of the last steps often involves performance optimizations. As it makes no sense to optimize functions rarely used, because that would be a waste of time, one needs to know in which part of a program most of the time is spent.
Під час розробки програми одним з останніх кроків часто є оптимізація швидкодії. Оскільки оптимізація функцій, які використовуються рідко не має великого сенсу, потрібно знати кількість процесорного часу, яку споживає кожна з частин програми.
For sequential code, collecting statistical data of the programs runtime characteristic like time numbers spent in functions and code lines usually is enough. This is called Profiling. The program is run under control of a profiling tool, which gives the summary of an execution run at the end. In contrast, for parallel code, performance problems typically are caused when one processor is waiting for data from another. As this waiting time usually cannot easily attributed, here it is better to generate timestamped event traces. & kcachegrind; cannot visualize this kind of data.
Для послідовного коду збирання статистичних даних щодо характеристик запущеної програми, зокрема час, витраченого на виконання функцій і рядків, зазвичай, достатньо. Збирання таких даних називається профілюванням. Програма запускається під керуванням інструменту профілювання, це надає резюме щодо виконання наприкінці. Навпаки, для розпаралеленого коду проблеми з швидкодією може бути спричинено очікуванням одного процесора на передавання даних від іншого процесора. Оскільки цей час очікування, зазвичай, важко пов’ язати з кодом, у такому випадку краще створити трасування подій з часовими позначками. & kcachegrind; не може створити візуальний відповідник цього типу даних.
After analyzing the produced profile data, it should be easy to see the hot spots and bottlenecks of the code: for example, assumptions about call counts can be checked, and identified code regions can be optimized. Afterwards, the success of the optimization should be verified with another profile run.
Після аналізу створених даних профілю ви маєте з легкістю виявити прогалини і вузькі місця у коді: наприклад, можна перевірити припущення щодо кількості викликів, виявлені діапазони коду може бути оптимізовано. Після цього ви можете перевірити результати оптимізації за допомогою повторного запуску профілювання.
Profiling Methods
Способи профілювання
To exactly measure the time passed or record the events happening during the execution of a code region (eg; a function), additional measurement code needs to be inserted before and after the given region. This code reads the time, or a global event count, and calculates differences. Thus, the original code has to be changed before execution. This is called instrumentation. Instrumentation can be done by the programmer itself, the compiler, or by the runtime system. As interesting regions usually are nested, the overhead of measurement always influences the measurement itself. Thus, instrumentation should be done selectively and results have to be interpreted with care. Of course, this makes performance analysis by exact measurement a very complex process.
Щоб точно виміряти час на виконання або записати події, які сталися під час виконання певного діапазону коду (наприклад, функції), слід вставити додатковий код для вимірювання перед і після вказаного діапазону. Цей код зчитує час або загальну кількість подій, а потім обчислює різниці. Отже, перед виконанням початкового коду його слід змінити. Така зміна називається інструменталізацією. Інструменталізацію може виконати сам програміст, компілятор або система запуску. Оскільки цікаві діапазони коду зазвичай є вкладеними, накладання інструментів вимірювання завжди впливає на самі виміри. Таким чином, інструменталізацію слід виконувати вибірково, а результати слід сприймати з певною поправкою. Звичайно ж, це робити аналіз швидкодії точним виміром дуже складним процесом.
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.
Точне вимірювання можливе, оскільки у сучасних процесорах передбачено апаратні лічильники (зокрема збільшення лічильників за один тік процесора), які збільшують значення кожного разу, коли трапляється подія. Оскільки нам потрібно пов’ язати події з діапазонами коду, без лічильників нам би довелося обробляти кожну з подій шляхом збільшення значення лічильника для самого поточного діапазону коду. Виконання цього завдання у програмному забезпеченні, звичайно ж, неможливе; але, за припущення, що розподіл подій у вихідному коді є подібним до того, який ми отримуємо під час аналізу кожної 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, & 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.
Ще одним методом вимірювання є імітація процесу, який відбувається у комп’ ютерній системі під час виконання вказаного коду, тобто імітацією, заснованою на виконанні. Імітація завжди виконується на допомогою більшою чи меншою мірою точної моделі комп’ ютера; але, якщо модель комп’ ютера буде дуже детальною і даватиме дуже близькі до реальних дані, час імітації буде неприйнятно великим. Перевагою імітації є те, що ви можете додавати у вказаний код код вимірювання/ імітації довільної складності без впливу на результати. Виконання цього додавання перед виконанням (це називається інструменталізацію виконання) за допомогою початкового виконуваного файла є дуже зручним для користувача: не потрібне ніяке перезбирання. Імітація стає придатною для використання за імітації лише частин комп’ ютера за допомогою простої моделі; іншою перевагою є те, що результати, створені за допомогою простих моделей часто простіше зрозуміти: часто проблеми, пов’ язані зі справжнім апаратним забезпечення (обладнанням), є те, що у отриманих результатів буде включено ефекти, які є наслідком роботи різних частин комп’ ютера.
Profiling Tools
Інструменти профілювання
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.
Найвідомішим є інструмент профілювання 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, 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.
Імітація кешу є першим кроком у наближенні справжніх часів, оскільки у сучасних комп’ ютерах виконання дуже чутливе до використання так званих кешів (маленьких і швидких буферів пришвидшує повторний доступ до тих самих комірок основної пам’ яті). & 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;, яке будує граф викликів програми на льоту, тобто граф, на якому буде показано спосіб, у який функції викликають одна одну, та кількість подій, які трапилися під час виконання функції. Крім того, дані профілю, які буде зібрано, може бути розподілено між потоками і контекстами ланцюжків викликів. Цей інструмент може надати дані профілювання на рівні інструкцій, що забезпечить коментування дизасембльованого коду.
Visualization
Візуалізація
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 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.
& 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 views for a selected function, namely:
Окрім списку функцій, впорядкованого відповідно до вимірів включеної і виключної вартості, який за бажання можна згрупувати за файлами вихідних кодів, спільними бібліотеками або класами C++, уkappname; передбачено різноманітні режими візуалізації для вибраної функції, зокрема
a call-graph view, which shows a section of the call graph around the selected function,
перегляд графу викликів, на якому буде показано частину графу викликів навколо вибраної функції,
a tree-map view, which allows nested-call relations to be visualized, together with inclusive cost metric for fast visual detection of problematic functions,
перегляд деревоподібної карти, за допомогою якого можна переглянути взаємозв’ язки вкладених викликів разом з виміром включеної вартості для пришвидшення візуального виявлення проблемних функцій,
source code and disassembler annotation views, allowing to see details of cost related to source lines and assembler instructions.
перегляди вихідного коду і коментарів дизасемблера, за допомогою якого можна переглянути подробиці щодо пов’ язаних з вартістю рядків вихідних кодів і інструкцій асемблера.
Using & kcachegrind;
Користування & kcachegrind;
Generate Data to Visualize
Створення даних для візуалізації
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.
Першим, у чому виникне потреба є створення даних щодо швидкодії шляхом вимірів характеристик виконання програми за допомогою інструменту профілювання. У самому & kcachegrind; не передбачено інструменту профілювання, але ця програма непогано пристосована для показу даних & callgrind; або, за допомогою інструменту перетворення, даних & oprofile;. Хоча предметом цього підручника не є документування профілювання за допомогою цих інструментів, у наступному розділі наведено короткі початкові настанови щодо роботи з ними.
& callgrind; is a part of valgrind;. Note that it previously was called & calltree;, but that name was misleading.
& callgrind; є частиною valgrind;. Зауважте, що раніше програма називалася & calltree;, але ця назва не відповідала призначенню програми.
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;.
Найпоширенішим способом використання є додавання перед командою запуску програми рядка 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 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.
Додатковою можливістю є створення дампів даних профілювання за виклику вказаної функції вашої програми. Наприклад, для того, щоб отримати дані профілювання для інструменту показу веб- сторінки у & konqueror;, вам може знадобитися створення дампу даних під час вибору пункту меню Перегляд Перезавантажити. Цей пункт відповідає виклику KonqMainWindow:: slotReload. Віддайте команду valgrind tool=callgrind -- dump- before=KonqMainWindow:: slotReload konqueror Буде створено декілька файлів з даними для профілювання з додатковим послідовним номером наприкінці назви файла. Крім того, буде створено файл без такого номера наприкінці назви (його назва завершуватиметься PID процесу); після завантаження цього файла до & kcachegrind;, буде завантажено і всі інші файли, — їх можна переглянути у огляді частин і списку частин.
& 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;).
& oprofile; можна звантажити з його домашньої сторінки. Виконайте настанови зі встановлення з веб- сайта; але, перш ніж виконувати ці настанови пошукайте відповідний пакунок у вашому дистрибутиві (наприклад, & SuSE;).