Visualisatie van many-coresimulaties Mathijs...

Mathijs Rogiers

Visualisatie van many-coresimulaties

Academiejaar 2012-2013Faculteit Ingenieurswetenschappen en ArchitectuurVoorzitter: prof. dr. ir. Jan Van CampenhoutVakgroep Elektronica en Informatiesystemen

Master in de ingenieurswetenschappen: computerwetenschappen Masterproef ingediend tot het behalen van de academische graad van

Begeleiders: dr. ir. Wim Heirman, Trevor CarlsonPromotor: prof. dr. ir. Lieven Eeckhout

i

Dankwoord

Een masterproef is een werk van lange adem en de afsluiter van de opleiding. Ik wil

dan ook graag een aantal mensen bedanken die me gesteund en gestimuleerd hebben de

afgelopen vijf jaar en dit laatste jaar in het bijzonder.

Dankzij de continue begeleiding van Trevor E. Carlson en dr. ir. Wim Heirman heeft dit

werk een mooi resultaat opgeleverd. Zonder hun werk aan Sniper, de vele meetings en de

feedback was dit zeker onmogelijk. Dat ze mijn werk integreerden in de simulator gaf mij

veel voldoening.

Het was hard werken dit jaar, maar dankzij het enthousiasme en de constructieve feed-

back van mijn promotor prof. dr. ir. Lieven Eeckhout bleef deze masterproef leuk om aan

te werken. Ik wil hem hiervoor dan ook bedanken.

De mensen van het Intel Exascience Lab in Leuven verdienen ook een vermelding. Ik ben

er twee maal langs geweest om er ideeen op te doen en feedback te krijgen. Enkele ideeen

zullen ze alvast herkennen in dit werk.

Na vijf jaar studeren wil ik zeker ook mijn ouders bedanken voor hun steun. In het bij-

zonder wil ik mijn moeder bedanken voor het nalezen van dit werk.

Tot slot bedank ik ook mijn vrienden voor de vijf fantastische jaren die we in onze geliefde

stad Gent hebben beleefd. Na vijf jaar begint een nieuw hoofdstuk en ik wens iedereen

succes toe.

Mathijs Rogiers, juni 2013

iii

Toelating tot bruikleen

“De auteur geeft de toelating deze masterproef voor consultatie beschikbaar te stellenen delen van de masterproef te kopieren voor persoonlijk gebruik. Elk ander gebruikvalt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot deverplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit dezemasterproef.”

Mathijs Rogiers 3 juni 2013

Visualisatie van many-coresimulaties

door

Mathijs Rogiers

Promotor: prof. dr. ir. Lieven Eeckhout

Begeleiders: dr. ir. Wim Heirman, M. Sc. Trevor E. Carlson

Masterproef ingediend tot het behalen van de graad van

Master in de ingenieurswetenschappen: computerwetenschappen

Vakgroep Elektronica en Informatiesystemen

Voorzitter: prof. dr. ir. Jan Van Campenhout

Faculteit Ingenieurswetenschappen en Architectuur

Academiejaar 2012–2013 Universiteit Gent

Trefwoorden: Visualisatie, many-coresimulatie, optimalisatie

Visualization of many-core simulationsMathijs Rogiers

Supervisor(s): prof. dr. ir. Lieven Eeckhout, dr. ir. Wim Heirman, M. Sc. Trevor E. Carlson

Abstract—How does architecture influence performance? How does theapplication behave during the execution? How can the architecture andsoftware be optimized? And what about energy? A part of the solutioncomes from Sniper, the multi-core simulator. Sniper can simulate many-core architectures in a fast and accurate way. The statistics that Snipergives are not readable for the researchers to answer the above questions. Inthis work, visualizations are built that use the output data from Sniper andshow the data in a way that is more insightful. The first set of visualizationsfocus on the time dimension. By adding this dimension, it is more clear howthe application behaves over time. A second set of visualizations are func-tion based. They show the behavior of functions and give suggestions for op-timization. These visualizations will help the researcher answer questionsabout running software on the simulated many-core architecture. All thevisualizations are web-based. This results in a highly portable, lightweightand interactive solution.

Keywords—Visualization, many-core simulation, optimization

I. INTRODUCTION

SNIPER [1], [2], [3] is a fast and accurate multi-core sim-ulator, based on the Graphite simulation infrastructure [4].

Both hardware and software researchers can use Sniper to sim-ulate multi-core architectures. Hardware researchers use Sniperto search for efficient architectures over a wide design space.Software developers can anticipate new architectures by testingtheir parallel software on the simulated hardware. This way,software/hardware co-design is possible.

But good visualizations are mandatory to better understandSniper’s results. This work presents a set of visualizations thatwill help the researcher answer questions about the execution ofapplications on the simulated hardware. The visualizations willgive a better insight in where the application or hardware can beimproved to get better results. There is a visualization that willpresent automatic suggestions for optimization that will give thesoftware researcher some hints about where he should optimizethe code.

The visualizations are web-based and this results in a highlyportable, lightweight and interactive solution.

The choice for a web-based visualization will be elaboratedin Section II. Section III and IV discuss the two groups of vi-sualizations: visualizations as a function over time and functionbased visualizations. Scalability will be tested in Section V.

The visualizations as a function over time use a time dimen-sion to get an understanding about how the execution of the soft-ware on the simulated hardware behaves over time. The secondgroup are function based visualizations where a set of visualiza-tions is presented that will show information about the functionsand give hints to optimize them.

II. WEB-BASED VISUALIZATIONS

A set of specifications has been composed before choos-ing the visualization software. The visualizations should beuser friendly, easily modifiable, highly interactive, portable andlightweight. Data should be separated from the visualizations.

And preferably, the visualizations can be shown without havingto use specific software.

The question rises why existing software is not sufficient. Thevisualization and profiling tools that have been investigated areVAMPIR [5], Paraver [6], TMProf [7], HPCToolkit [8] and In-tel VTune [9]. They all have interesting ideas, some of theseideas will be used in this work, but none of them meet all thespecifications.

Modern web browsers have increasing support for vectordrawing and many open source JavaScript libraries are avail-able for web-based visualizations. Using a web-based solutionresults in a highly portable and lightweight solution that allowsus to meet the above specifications.

Generating the visualizations discussed in next sections alluse the same workflow. First, the application runs inside Sniper.The micro-architectural simulator generates statistics, whichwill be processed by the visualization scripts. The visualizationscripts convert the simulator output to JSON (JavaScript ObjectNotation) files that will serve as the basis for the visualizations.

III. VISUALIZATIONS AS A FUNCTION OVER TIME

The first visualization version that was already present inSniper showed a static representation of the average cycle stackafter the whole run of the application. This section describesadding the time dimension. This will allow the user to see howthe program behaves during its execution on the simulated hard-ware.

A. Cycle stacks as a function over time

In [10] cycle stacks are introduced to understand scaling bot-tlenecks in multi-threaded applications. Cycle stacks show thenumber of cycles lost to some characteristics of the system.Generating cycle stacks is possible with Sniper. But these cyclestacks are static. They only show information after the wholerun of the application.

To add a time dimension to cycle stacks, periodic informationmust be gathered by Sniper. A cycle stack is generated for eachof these snapshots. When all cycle stacks are placed next to eachother, a cycle stack as a function over time is created.

To interactively and user friendly visualize this data, an opensource JavaScript library has been used: Rickshaw [11]. Anexample is shown in Figure 1.

There are some options available. The cycle stack can benormalized or absolute. Simple or detailed components can beused. There is also an option to show an IPC-graph over time.IPC (Instructions Per Cycle) is the inverse of CPI (Cycles Per In-struction) and shows how much progress an application makesduring a certain period. This is especially useful when usingthe normalized cycle stack, as this does not show absolute CPIvalues. Zooming is possible. The software developer can add

Fig. 1. Cycle stacks as a function over time. The y-axis shows the cycles (%),the x-axis shows time. The normalized and detailed option is used.

Fig. 2. 3D Visualization of time-cores-IPC. The x- and z-axis show the timeand cores. The y-axis shows the IPC.

markers to the program, these will be shown on a line belowthe visualization. This can be useful to map the visualization tosource code.

B. McPAT output over time

McPAT (Multi-core Power, Area, and Timing) [12] is an inte-grated power, area, and timing modeling framework for many-core architectures. The integration of McPAT and Sniper is dis-cussed in [13]. The same idea of Section III-A can be used withthe results that McPAT generates. The time dimension is addedand the result is that the user can see how the energy usage ofthe application running on the simulated hardware evolves dur-ing time.

As it is very similar to the visualization in Section III-A, thesame JavaScript library has been used here.

C. 3D visualization of time-cores-IPC

IPC is a measure for how much progress an application makesduring a time span. It is interesting to see how the IPC evolvesduring the execution time of the application. In the cycle stacksas a function over time, information was aggregated over allcores. In this section the core dimension is added, resulting inthree dimensions: time, cores and IPC.

‘JavaScript Surface Plot’ [14] is the JavaScript library that hasbeen used to construct this visualization. It is possible to zoomand rotate. The result can be seen in Figure 2.

functionspeak floating point performancepeak memory bandwidth

Logscale

Roofline

Roofline Model

0

1

2

4

8

16

0.01

0.02

0.03

0.06

0.13

0.25

0.5

0 1 2 4 8 16 32 64 128 256 5120.01 0.02 0.03 0.06 0.13 0.25 0.5 1,024 2,048 4,096 8,19216,384

16

16,384

Function InfoFig. 3. Roofline model [16]. Functions are plotted in function of their floatingpoint performance and the number of floating point instructions per byte.The roofline is composed by the peak floating point performance line andthe peak memory bandwidth line.

IV. FUNCTION BASED VISUALIZATIONS

The visualizations in Section III are mostly helpful for hard-ware researchers. This section will focus on solutions for soft-ware developers. Sniper provides an option to generate functionbased statistics. These statistics can provide useful informationabout the functions. It is even possible to generate automaticsuggestions for optimization.

The visualizations presented in the next sections are stronglyconnected with each other. Clicking on a function somewhere,will cause the selection of the same function in the other visual-izations as well.

A. Functions: instructions versus time

A first function based visualization is a scatter plot wherefunctions are plotted in function of their number of executedinstructions and the execution time. The expectation is that theexecution time ascends with the number of instructions that areexecuted. If the execution time is much longer than expected,an outlier will be noticed quickly.

The JavaScript library used for this visualization is Flot [15].

B. Roofline model

The roofline model was introduced in [16]. The idea is that anapplication or function is bound by the maximum floating pointperformance or the peak memory bandwidth. The y-axis on theroofline model shows the floating point performance (GFLops/s)of the function. The x-axis shows the operational intensity(Flops/byte). This is the number of floating point instructionsthat has been executed per byte that has been loaded from mem-ory. An example of the roofline model is shown in Figure 3.

The roofline model shows whether the function is memory orfloating point performance bound and how much room for im-provement the function has. In the next section we will discusshow the functions can be improved so that they get closer to theroofline.

C. Automatic suggestions for optimization

As Sniper provides detailed information on the functions, thisallows generating automatic suggestions for optimization if wecollect the right data. These suggestions can be linked to the

Overall Combined ILP TLP Branch NonFP Vectorization Memory PercentOfDataUtilized

Top 10 overall optimizations

Function Optimization Application

speedup

#1 VListInteraction NonFP x1.255

#2 VListInteraction TLP x1.164

#3 VListInteraction ILP x1.111

#4 UListInteraction ILP x1.095

#5 UListInteraction TLP x1.087

#6 XListInteraction ILP x1.082

#7 UListInteraction NonFP x1.081

#8 XListInteraction NonFP x1.070

#9 XListInteraction TLP x1.069

#10 WListInteraction NonFP x1.067

Suggestions for Optimization

Functions: instructions versus timeRoofline ModelFunction Info

Fig. 4. Automatic suggestions for optimization. A top 10 list of optimizationsis shown, together with a bar that represents the application speedup that canbe gained by implementing this optimization. On the right hand side thereare links to the other function based visualizations.

roofline model of Section IV-B. Some suggestions will makefunctions less memory bandwidth dependent. Others will getthe functions closer to the peak floating point performance. Andthe third group will move the peak floating point performance toa higher level.

There are a number of data items about the functions that canbe collected. For each function the name, the source, the in-struction count, the elapsed time, the L3 cache miss rate, de-tailed statistics about the floating point instructions, the numberof bits extracted from memory and CPI data can be stored. Bycombining and selecting a number of these data items, it will bepossible to calculate possible speedups and generate suggestionsfor optimizations.

C.1 Implementation

Function based statistics are generated by Sniper. Then theautomatic suggestions for optimization scripts use this informa-tion and pass it to the optimization modules. Each module hasa function as input and returns the function with some changedproperties that allow to calculate the speedup gained by this op-timization. The focus is on modularity so that it is very easyto add and change modules to improve the estimations in thefuture.

In the next sections, more information about the modules isprovided.

C.2 ILP Module

ILP (Instruction-Level Parallelism) is a measure for the num-ber of instructions that can be executed in parallel. To calcu-late the best theoretical performance of a function that can bereached by using ILP, the base CPI component of that functionis set to 1

dispatch width .The ILP module brings the function closer to the maximum

floating point performance of the roofline model.

C.3 TLP Module

TLP (Thread-Level Parallelism) allows executing multiplethreads in parallel. This module uses Amdahl’s Law to calculatethe maximum speedup that can be gained using ILP. Amdahl’s

Law says that the speedup by parallelism is limited by the se-quential part of the program.

The TLP module moves the maximum floating point perfor-mance of the roofline model to a higher level.

C.4 Branch Predictor Module

Branches can have a high cost when branch predictor misseshappen. This module calculates the speedup that can theoreti-cally be gained by removing branch instructions. The softwaredeveloper can avoid branch instructions using loop unrolling forexample.

The Branch Predictor module brings the function closer to themaximum floating point performance of the roofline model.

C.5 Percentage of Data Utilized Module

Loading data from the LLC (Last-Level Caches) or DRAM(Dynamic Random-Access Memory) has a big cost associatedwith it. That is why loading data from memory should be veryefficient. In the best case, no bytes are wasted. Bytes can bewasted by loading a whole cache line while only one element isneeded. This module calculates the speedup that can be gainedwhen only the used bytes are loaded from memory. The softwaredeveloper can avoid wasting bytes by using a technique called‘AOS to SOA’ (Array of Structures to Structures of Arrays) forexample.

The Percentage of Data Utilized module makes the functionless memory bandwidth limited.

C.6 Vectorization Module

With vectorization, a single instruction can be executed overmultiple data elements in one clock cycle. The data Sniper re-turns, contains information about the type of instructions thatare executed. That way, this vectorization module can calcu-late the amount of speedup that can be achieved when applyingvectorization.

The vectorization module moves the maximum floating pointperformance of the roofline model to a higher level.

C.7 Remove non-Floating Point Instructions Module

The goal is to reach the top of the roofline. This can only beachieved by removing all non-floating point instructions. Thismodel calculates the speedup that can be gained by removingthese instructions.

The module brings the function closer to the peak floatingpoint performance of the roofline model.

C.8 Memory Module

The Memory module calculates the speedup that can begained when there are no more cycles lost to memory compo-nents. The function is now not memory bandwidth limited any-more.

C.9 Combining optimization modules

It might be useful for the software developer to see what thebest combination of optimizations is. That way multiple opti-mizations can be implemented at once. An example of the visu-alization of these combined optimizations is shown in Figure 5.The combinations are visualized as a horizontal stacked bar.


Top 10 combined optimizations


speedup

#1 VListInteraction x1.362

#2 UListInteraction x1.166

#3 XListInteraction x1.132

#4 WListInteraction x1.104

#5 ShiftLocalExp x1.034

#6 ShiftMPExp x1.031

#7 ComputeMPExp x1.029

#8 ComputeSelfInteraction x1.023

#9 EvaluateLocalExp x1.022

#10 ldexp x1.011



Fig. 5. Automatic suggestions for optimization: combined. Each color of thehorizontally stacked bar represents an optimization. The length of the barrepresents the speedup that can be gained when implementing all optimiza-tions.

Function name VListInteraction

EIP 0x408420

Source interactions.c:362

Calls 1,340

Instruction count 20,433,930

Core elapsed time 3,872,130 ns

Nonidle elapsed time 3,872,130 ns

Add/Sub FP ops 3,111,480

Mul/Div FP ops 3,324,540

L3 cache misses 16

CPI 0.504

Optimizations Optimization Speedup

NonFP x1.255

TLP x1.164

ILP x1.111

Vectorization x1.062

Branch x1.050

Memory x1.001

PercentOfDataUtilized x1.001

Function Info

2%

41%

30%

31%

34%

31%

2%

Fig. 6. Detailed information about each function. Some properties are shown,together with suggestions for optimization. It is possible to navigate throughfunctions by the values of the properties by using the arrows.

D. Function Info

If the user wants detailed information about a function, he canuse the function info section as shown in Figure 6. Some prop-erties are shown, together with suggestions for optimization.

It is possible to navigate through functions by the values ofthe properties by using the arrows.

If available, a link to Doxygen is shown as well. Doxygen[17] can generate documentation from source code and it can beused by this visualization to link the function to its source code.

V. SCALABILITY

Both time and space scalability have been investigated. Theextra options that Sniper requires to generate the periodic andfunction based information do cause some overhead, but thisoverhead becomes relatively smaller when the simulation timeincreases. The execution time of the scripts that convert the in-formation of Sniper to the JSON format that serves as an inputto the visualizations is much smaller than the simulation time.Only the script that calculates the input data for the McPAT out-put over time visualization can take a relatively large amount oftime.

Storing extra periodic and function based data has an impacton the size of the database where Sniper stores the data. Theincrease can be as high as 5x. But it remains scalable becausethe number of snapshots that is stored is limited.

VI. FUTURE WORK

Each of the discussed visualizations can still be improved andelaborated but there are also some completely other ideas. Ex-amples are visualizing communication between cores, visualiza-tion of multiple nodes, clustering of data, making an interactivefunction call graph, visualizing multiple executions and so on.

VII. CONCLUSION

This work presents a set of visualizations that help the hard-ware and software researcher in understanding the results theyget from running an application on hardware simulated bySniper.

Two groups of visualizations are presented. The first group,visualizations as a function over time, uses a time dimension thatallows the user to see how the execution of the application onthe simulated hardware behaves over time. The second group,function based visualizations, concentrates on the functions andpresents the user suggestions for optimizations.

The visualizations are web-based and this results in a highlyportable, interactive and lightweight solution.

REFERENCES

[1] Trevor E. Carlson, Wim Heirman, Kenzo Van Craeynest, Lieven Eeck-hout, and Ibrahim Hur, “The Sniper Multi-Core Simulator,” http://snipersim.org/, apr 2013.

[2] Trevor E. Carlson, Wim Heirman, and Lieven Eeckhout, “Sniper: Explor-ing the level of abstraction for scalable and accurate parallel multi-coresimulations,” in International Conference for High Performance Comput-ing, Networking, Storage and Analysis (SC), nov 2011.

[3] Wim Heirman, Trevor Carlson, Souradip Sarkar, Pieter Ghysels, WimVanroose, and Lieven Eeckhout, “Using fast and accurate simulation toexplore hardware/software trade-offs in the multi-core era,” in Parco 2011,Proceedings, 2011, p. 8.

[4] J.E. Miller, H. Kasture, G. Kurian, C. Gruenwald, N. Beckmann, C. Celio,J. Eastep, and A. Agarwal, “Graphite: A distributed parallel simulator formulticores,” in High Performance Computer Architecture (HPCA), 2010IEEE 16th International Symposium on, 2010, pp. 1–12.

[5] W. E. Nagel, A. Arnold, M. Weber, H.-Ch. Hoppe, and K. Solchenbach,“VAMPIR: Visualization and analysis of MPI resources,” Supercomputer,vol. 12, pp. 69–80, 1996.

[6] Vincent Pillet, Vincent Pillet, Jesus Labarta, Toni Cortes, Toni Cortes,Sergi Girona, Sergi Girona, and Departament Darquitectura De Computa-dors, “Paraver: A tool to visualize and analyze parallel code,” Tech. Rep.,In WoTUG-18, 1995.

[7] Justin E. Gottschlich, Maurice P. Herlihy, Gilles A. Pokam, and Jeremy G.Siek, “Visualizing transactional memory,” in Proceedings of the 21st inter-national conference on Parallel architectures and compilation techniques,New York, NY, USA, 2012, PACT ’12, pp. 159–170, ACM.

[8] L. Adhianto, S. Banerjee, M. Fagan, M. Krentel, G. Marin, J. Mellor-Crummey, and N. R. Tallent, “HPCToolkit: tools for performance analysisof optimized parallel programs,” Concurr. Comput. : Pract. Exper., vol.22, no. 6, pp. 685–701, apr 2010.

[9] Intel, “Intel vtune,” http://software.intel.com/en-us/intel-vtune-amplifier-xe, apr 2013.

[10] W. Heirman, Trevor E. Carlson, Shuai Che, K. Skadron, and L. Eeckhout,“Using cycle stacks to understand scaling bottlenecks in multi-threadedworkloads,” in Workload Characterization (IISWC), 2011 IEEE Interna-tional Symposium on, nov. 2011, pp. 38 –49.

[11] “Rickshaw is a JavaScript toolkit for creating interactive time se-ries graphs,” http://code.shutterstock.com/rickshaw/,jan 2013.

[12] Sheng Li, Jung Ho Ahn, R.D. Strong, J.B. Brockman, D.M. Tullsen, andN.P. Jouppi, “Mcpat: An integrated power, area, and timing modeling

framework for multicore and manycore architectures,” in Microarchitec-ture, 2009. MICRO-42. 42nd Annual IEEE/ACM International Symposiumon, dec. 2009, pp. 469 –480.

[13] Wim Heirman, Souradip Sarkar, Trevor E. Carlson, Ibrahim Hur, andLieven Eeckhout, “Power-aware multi-core simulation for early designstage hardware/software co-optimization,” in PACT, 2012, pp. 3–12.

[14] Greg Ross, “JavaScript Surface Plot, 3D surface plot-ting in JavaScript,” http://code.google.com/p/javascript-surface-plot/, oct 2012.

[15] IOLA and Ole Laursen, “Flot, attractive JavaScript plotting for jQuery,”http://www.flotcharts.org/, mar 2013.

[16] Samuel Williams, Andrew Waterman, and David Patterson, “Roofline: aninsightful visual performance model for multicore architectures,” Com-mun. ACM, vol. 52, no. 4, pp. 65–76, apr 2009.

[17] Dimitri van Heesch, “Doxygen, generate documentation from sourcecode,” http://doxygen.org, mar 2013.

INHOUDSOPGAVE xiii

Inhoudsopgave

1 Inleiding 11.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Doel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Uitdagingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Bijdragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

I Literatuurstudie 5

2 Overzicht van bestaande visualisatiesoftware 92.1 VAMPIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Paraver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3 TMProf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4 HPCToolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.5 Intel VTune . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.6 Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 Sniper: De multi-coresimulator 213.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2 Doel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3 Mogelijkheden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.4 Gebruik van Sniper in dit werk . . . . . . . . . . . . . . . . . . . . . . . . 22

II Visualisaties in functie van de tijd 23

4 Cycle stacks in functie van de tijd 274.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2 Cycle stacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.3 Doel en specificaties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.4 Implementatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.5 Visualisatie genereren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.6 Resultaat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.7 Schaalbaarheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.8 Portabiliteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.9 Mogelijke verbeteringen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.10 Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

xiv INHOUDSOPGAVE

5 McPAT-output in functie van de tijd 41

5.1 McPAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.2 Power stacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.3 Problemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.4 Doel en specificaties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.5 Implementatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.6 Visualisatie genereren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.7 Resultaat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.8 Schaalbaarheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.9 Mogelijke verbeteringen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.10 Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6 3D-Visualisatie van tijd-cores-IPC 47

6.1 IPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.2 Doel en specificaties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.3 Implementatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.4 Integratie in Sniper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.5 Resultaat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.6 Praktisch nut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.7 Schaalbaarheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50


6.9 Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

III Functiegebaseerde visualisaties 53

7 Functies: instructies versus tijd 57

7.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.2 Implementatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57


7.4 Resultaat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7.5 Praktisch nut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7.6 Schaalbaarheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

7.7 Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

8 Roofline model 65

8.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

8.2 Implementatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65


8.4 Resultaat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

8.5 Praktisch nut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

8.6 Schaalbaarheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68


8.8 Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

INHOUDSOPGAVE xv

9 Automatische suggesties voor optimalisatie 699.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699.2 Aanverwant werk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709.3 Implementatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709.4 ASO-modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719.5 Visualisatie genereren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759.6 Resultaat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759.7 Praktisch nut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779.8 Schaalbaarheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779.9 Mogelijke verbeteringen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799.10 Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

IV Besluit 81

10 Besluit 83

11 Toekomstig werk 8511.1 Visualisatie van communicatie . . . . . . . . . . . . . . . . . . . . . . . . . 8511.2 Visualisatie van meerdere nodes . . . . . . . . . . . . . . . . . . . . . . . . 8511.3 Visualisatie van meerdere draden . . . . . . . . . . . . . . . . . . . . . . . 8611.4 Visualisatie van functie-oproepen . . . . . . . . . . . . . . . . . . . . . . . 8611.5 Clusteren van cores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8811.6 Gebruik van machinaal leren en data mining technieken . . . . . . . . . . . 8811.7 Visualisatie van meerdere uitvoeringen . . . . . . . . . . . . . . . . . . . . 88

Referenties 88

Lijst van figuren 91

Gebruikte afkortingen

AJAX Asynchronous JavaScript and XML

AOS to SOA Array of Structures to Structures of Arrays

ASO Automatische Suggesties voor Optimalisatie

BSD Berkeley Software Distribution

CPI Cycli Per Instructie

DRAM Dynamic Random-Access Memory

DVFS Dynamic Voltage and Frequency Scaling

FLOP Floating Point Operations

HTML HyperText Markup Language

ILP Instruction-Level Parallelism

IPC Instructies Per Cyclus

JSON JavaScript Object Notation

LLC Last-Level Cache

MIT Massachusetts Institute of Technology

MLP Memory-Level Parallelism

MPI Message Passing Interface

MULPD Packed Double-Precision Floating Point Multiply

MULPS Packed Single-Precision Floating Point Multiply

MULSD Scalar Double-Precision Floating Point Multiply

MULSS Scalar Single-Precision Floating Point Multiply

SIMD Single Instruction Multiple Data

SSE Streaming SIMD Extensions

TLP Thread-Level Parallelism

INLEIDING 1

Hoofdstuk 1

Inleiding

In dit inleidend hoofdstuk wordt de context van deze masterproef geschetst en wordenprobleemstelling en doel uiteengezet. Verder worden ook enkele uitdagingen vermeld diein dit werk aan bod komen.

1.1 Context

1.1.1 Supercomputers

De Titan, een supercomputer gefabriceerd door Cray, stond in november 2012 als nummer1 in de top-500 [1] van de snelste supercomputers ter wereld. 560.640 processorkernenzorgen voor een theoretische rekenkracht van 27 petaFlops (27 biljard vlottende-komma-instructies per seconde). Deze gigantische rekenkracht vereist een vermogen van 8,2 me-gawatt. Deze supercomputer is een petascale-computer. Men verwacht binnen minderdan 10 jaar de intrede van exascale-computers die nog 1000 maal krachtiger zijn dan dehuidige top van supercomputers.

Deze supercomputers vormen het onderwerp van heel wat onderzoek want er zijn veelvragen te beantwoorden. Hoe kunnen programma’s geschreven worden die voldoendeparallel zijn om optimaal van deze rekenkracht, die voorzien wordt door het gebruikvan duizenden processorkernen, gebruik te maken? Wat zijn de implicaties voor hetvermogenverbruik wanneer het systeem nog krachtiger wordt? Wat is de impact vanmicro-architecturale beslissingen op de uitvoeringstijd van de programma’s?

Deze masterproef kadert in de context van het onderzoek naar exascale-computing. Erwordt gefocust op een node van een supercomputer. In de toekomst kan dit werk uitge-breid worden om antwoorden te bieden voor een supercomputer, bestaande uit duizendenvan deze nodes.

1.1.2 Simulatie

In het onderzoek met betrekking tot many-coresystemen is het noodzakelijk om aan simu-latie te doen. Om voorbereid te zijn op het exascale-tijdperk kunnen dergelijke systemeneerst gesimuleerd worden om allerlei vragen te kunnen beantwoorden.

Een tweede argument om aan simulatie te doen is de trend in de wereld van de compu-terarchitectuur en de software-ontwikkeling om aan co-design te doen. Het is belangrijk

2 1.2 Probleemstelling

voor software-ontwikkelaars dat ze hun software kunnen testen op de allernieuwste hard-ware. Sterker nog, het liefst willen ze hun software geoptimaliseerd hebben voor nieuwehardware, nog voor deze in productie is gegaan. Sommige hardware wordt speciaal ge-bouwd om optimaal te werken voor bepaalde software. Het zou uiteraard zeer duur zijnom telkens hardware te fabriceren en uit te testen. Hoe kunnen deze twee problemenaangepakt worden? Simulatie biedt een oplossing. Software-ontwikkelaars kunnen hunsoftware testen op gesimuleerde hardware. Hardware-onderzoekers kunnen software la-ten draaien op verschillende gesimuleerde hardwareconfiguraties om zo een optimum tevinden.

Aan de vakgroep Elektronica en Informatiesystemen in de onderzoeksgroep ComputerSystems Lab wordt in samenwerking met het Intel Exascience Lab een multi-coresimulatorontwikkeld: Sniper [2, 3, 4]. Deze simulator gebruikt een intervalmodel en kan daaromeen goede afweging maken tussen precisie enerzijds en snelheid anderzijds. Een meeruitgebreide bespreking van Sniper volgt in Hoofdstuk 3.

1.2 Probleemstelling

Sniper simuleert de volledige hardware van een many-coresysteem, dus de hoeveelheidstatistieken die gegenereerd wordt is enorm. De statistieken bevatten een schat aan infor-matie gaande van globale informatie zoals de totale uitvoeringstijd tot zeer gedetailleerdeinformatie zoals het aantal verkeerd voorspelde sprongen. Enkel met doordachte visuali-saties kan deze brede waaier aan resultaten geınterpreteerd worden.

Een ander probleem dat zich stelt is de subjectiviteit van het begrip ‘een goede visu-alisatie’. De eindgebruikers kunnen in twee groepen verdeeld worden. Enerzijds zijn erde hardware-ontwikkelaars en -onderzoekers, anderzijds is er de groep van de software-ontwikkelaars. Waar de eerste groep er van uitgaat dat de software vast ligt en de hard-ware kan varieren, gaat de tweede groep uit van het tegendeel. Dit zorgt ervoor dat eenvisualisatie zeer bruikbaar kan zijn voor de ene groep en minder bruikbaar voor de andere.

1.3 Doel

Het doel van deze masterproef is om visualisaties te construeren die op een doordachtemanier de statistieken die Sniper genereert weer te geven zodat de gebruiker een beterinzicht krijgt in de manier waarop de uitvoering van een applicatie op de gesimuleerdehardware verloopt. De visualisaties zullen een antwoord bieden op vragen die zowel dehardware- als de software-onderzoeker zich kan stellen. Voorbeelden van deze vragen zijnde volgende. Hoe gedraagt het programma zich tijdens de uitvoering? Wat is de invloedvan de architectuur op de prestatie? Wat zijn de bottlenecks? Zijn er suggesties vooroptimalisatie? En wat met het vermogenverbruik?

De verschillende vragen zullen beantwoord moeten worden door verschillende typesvan visualisaties. Sommige data is rechtstreeks beschikbaar in de statistieken die Snipergenereert. Andere data, zoals suggesties voor optimalisatie van code, is niet rechtstreeksbeschikbaar en moet worden afgeleid uit beschikbare data. De afsluiter van dit werkhandelt over deze suggesties voor optimalisatie van code. Het doel is dat de software-ontwikkelaar ziet welke functies de grootste optimalisatiemogelijkheden bieden en welkeoptimalisaties voorgesteld worden om de uitvoeringstijd van deze functies te reduceren.

1.4 Uitdagingen 3

Enkele doelstellingen met betrekking tot de visualisaties zelf zijn de volgende. De vi-sualisaties moeten in de eerste plaats gebruiksvriendelijk zijn. Om ze te kunnen bekijkenmag er geen extra software nodig zijn en de visualisaties zijn bij voorkeur platformon-afhankelijk. Om gemakkelijk uitbreidingen te kunnen maken en aanpassingen door tevoeren is een scheiding tussen data en presentatie gewenst en wordt open-source softwaregeprefereerd. Het combineren en het laten interageren van de visualisaties met elkaar iseveneens een doelstelling.

1.4 Uitdagingen

Technische uitdagingen Om doordachte visualisaties te genereren moet de juiste datagehaald worden uit de uitgebreide statistieken die Sniper genereert. Een van de ideeenis om tijdsgebaseerde visualisaties te maken, die het verloop van de uitvoering in detijd weergeven en hiervoor zijn periodieke statistieken nodig. De afweging moet wordengemaakt tussen granulariteit, opslagcapaciteit en vlotheid van de visualisatie.

De grootste uitdagingen schuilen in het vinden en construeren van zinvolle visualisaties.Welke visualisaties bieden een antwoord op de vragen die hardware- en softwareonderzoe-kers kunnen stellen? Op welke manier kunnen visualisaties gemaakt worden die zoweleenvoudig te begrijpen zijn als genoeg detail bevatten? Wat is de beste manier om eengrote hoeveelheid data voor te stellen in verschillende dimensies? Hoe kunnen suggestiesvoor optimalisaties voorgesteld worden vanuit de statistieken die Sniper genereert?

Er is dus een visualisatietool nodig die zeer flexibel kan zijn. Bestaat er een visualisa-tietool die aan alle specificaties uit Sectie 1.3 voldoet?

Meta-uitdagingen Een werk maken over visualisaties biedt ook verschillende meta-uitdagingen. Het begint al bij het brainstormen. Er ontstaan zeer veel ideeen, maar in depraktijk zullen slechts een aantal ideeen nuttig zijn voor de eindgebruiker. Een goed ideeimpliceert echter nog niet meteen een bruikbare implementatie. Ook zijn er uiteraardveel meer ideeen dan dat er tijd is voor een persoon om tijdens een academiejaar teimplementeren. Het selecteren van goede ideeen is al een eerste uitdaging.

Het grote voordeel van dit onderwerp is dat zelfs mensen die minder op de hoogte zijnvan de technische achtergrond, ook met interessante ideeen op de proppen kunnen komen.Het nadeel is dat er een grondige selectie van de ideeen gemaakt moet worden.

In dit werk werden de meest bruikbare ideeen geselecteerd en geımplementeerd. Maarde overige ideeen worden verder ook nog besproken. Na elk hoofdstuk worden verbete-ringen aan de visualisaties uit dat hoofdstuk vermeld. In Hoofdstuk 11, toekomstig werk,komen compleet nieuwe ideeen aan bod.

1.5 Bijdragen

Hardware- en software-onderzoekers willen bepaalde vragen, zoals vermeld in Sectie 1.3,kunnen beantwoorden over de uitvoering van applicaties op de gesimuleerde hardware.

De simulatie kan worden uitgevoerd op Sniper. De statistieken die Sniper genereertzijn echter moeilijk rechtstreeks te interpreteren door de onderzoeker. De bijdrage vandeze masterproef bestaat er in dat visualisaties worden ontworpen om op een gebruiks-vriendelijke, efficiente en interactieve wijze antwoorden te bieden op de gestelde vragen.

4 1.5 Bijdragen

De visualisaties zijn webgebaseerd en gemaakt met open-source software. Dit zorgt er-voor dat ze gemakkelijk uitbreidbaar en aanpasbaar zijn. Verder leidt dit ook tot eenplatformonafhankelijke oplossing waarbij er een scheiding van presentatie en data is.

In het eerste deel worden visualisaties aangeboden die eerder bedoeld zijn voor dehardware-onderzoeker. Het tweede deel zal eerder voer zijn voor de software-ontwikkelaar,die onder andere suggesties voor optimalisaties van functies voorgesteld krijgt.

5

Deel I

Literatuurstudie

7

In Deel I van dit werk wordt de bestaande literatuur besproken. Eerst wordt ingegaanop de mogelijkheden en beperkingen van bestaande visualisatiesoftware. Daarna volgteen bespreking van de Sniper simulator. De visualisaties die in dit werk worden gemaakt,maken gebruik van de data die Sniper genereert.

OVERZICHT VAN BESTAANDE VISUALISATIESOFTWARE 9

Hoofdstuk 2

Overzicht van bestaandevisualisatiesoftware

In dit hoofdstuk wordt een overzicht gegeven van bestaande software voor visualisatievan werklasten. Voor elke tool wordt beschreven waarvoor het gebruikt wordt en welkeideeen interessant zijn in het kader van deze masterproef. Uiteraard is dit geen com-plete lijst, maar door enkele tools en softwarepakketten te bespreken, worden al heel watideeen aangehaald en worden de mogelijkheden en beperkingen van bestaande softwareaangetoond.

2.1 VAMPIR

2.1.1 Inleiding

VAMPIR (Visualization and Analysis of MPI Resources) [5, 6] is een raamwerk voorprestatie-analyse van parallelle programma’s die op many-coresystemen uitgevoerd wor-den. Het werd oorspronkelijk ontwikkeld voor de analyse van software die gebruik maaktvan MPI (Message Passing Interface). VAMPIR vertaalt een traceringsbestand in ver-schillende visualisaties zoals activiteitendiagrammen, tijdslijnen en statistieken. VAMPIRheeft verder krachtige inzoommogelijkheden om problemen op elk niveau van detail teidentificeren. Om het voordeel van MPI maximaal te benutten zijn een krachtige prestatie-analysesoftware en een eenvoudig te gebruiken visualisatietool van groot belang.

2.1.2 Visualisatie

De prestatie-analyse en programma-optimalisatie van VAMPIR is gebaseerd op verschil-lende categorieen van systeemvisualisaties:

– SysteemsnapshotsPanelen die de systeemactiviteit op een bepaald punt in de tijd tonen.

– AnimatiesEen optie om te kijken naar een sequentie van systeemsnapshots om het dynamischgedrag te bekijken.

– StatistiekenDe component die het gedrag van het systeem samenvat.

10 2.1 VAMPIR

– TijdslijnGedetailleerd beeld van systeemactiviteiten, die gevisualiseerd worden op een tijdsas.

Tijdslijnen

De tijdslijnweergave, zoals in Figuur 2.1, toont gedetailleerde informatie van de processengetoond op een tijdsas. Het biedt informatie over uitgevoerde functies, communicatie ensynchronisatie-operaties. Bepaalde groepen van functies worden gegroepeerd in eenzelfdekleur.

De procestijdslijnen tonen de verschillende niveaus van functie-oproepen in een gesta-pelde staafgrafiek. In tegenstelling tot de globale tijdslijnweergave is het hier mogelijk omprocesspecifieke gegevens te tonen, bijvoorbeeld de teller ‘PAPI FP OPS’ in Figuur 2.2.Het idee dat er een aparte visualisatie bestaat voor een proces is ook interessant.

In de traceringsbestanden kunnen metingen van tellers bijgehouden worden. In detellerdatatijdslijnvisualisatie, afgebeeld in Figuur 2.3, wordt de data van een enkele teller,zoals het aantal cachemissers of het aantal vlottende-kommabewerkingen voor meerdereprocessen getoond op een tijdsas. In tegenstelling tot de vorige visualisatie wordt hier eenteller getoond voor verschillende processen. Bij de processpecifieke tijdslijnweergave zijndat meerdere tellers voor een proces.

Overzichten

Communicatiestatistieken worden getoond in een matrix. Zoals getoond in Figuur 2.4,worden de verzendende processen in de rijen aangeduid en de ontvangende processenin de kolommen. De vierkanten in de matrixelementen kunnen bijvoorbeeld het aantalberichten zijn die verzonden werden of de minimum/maximum duur.

Een overzicht van de tijd, gebruikt door verschillende functies, wordt voorgesteld alseen staafgrafiek, zoals in Figuur 2.5. Deze visualisatie is zeer aanpasbaar. Dit beeld doetuiteraard denken aan cycle stacks, waarin het aantal cycli verbruikt door een instructie,wordt ingedeeld in verschillende componenten.

2.1.3 Nuttige ideeen

VAMPIR biedt zeker enkele nuttige ideeen. Hier worden ze nog eens op een rij gezet:

– Er wordt een tijdsdimensie gebruikt om de evolutie van een bepaald proces en zijneigenschappen/tellers in de tijd te visualiseren.

– De communicatie tussen verschillende processen wordt gevisualiseerd.– Er wordt veel gebruik gemaakt van kleuren, zowel om bepaalde functies of eigen-

schappen te groeperen als om de intensiteit van een eigenschap te visualiseren.– Communicatie tussen processen wordt gevisualiseerd in een matrix.– Er wordt gevisualiseerd vanuit verschillende standpunten. Enerzijds, vanuit een

globaal standpunt, kan een bepaalde eigenschap gevisualiseerd worden voor alleprocessen. Anderzijds, vanuit een lokaal standpunt, kan een overzicht van de eigen-schappen voor een proces opgevraagd worden.

– Het onderscheid wordt gemaakt tussen een statische en een dynamische visualisatie.In het statische geval wordt een overzicht gegeven van de data na een bepaalde tijd

2.1 VAMPIR 11

Figuur 2.1: Globale tijdslijnweergave. Deze visualisatie toont gedetailleerde informatie van deprocessen op een tijdsas. Bron: [5]

Figuur 2.2: Processpecifieke tijdslijnweergave. De procestijdslijnen tonen de verschillende ni-veaus van functie-oproepen in een gestapelde staafgrafiek. Bron: [5]

12 2.1 VAMPIR

Figuur 2.3: Tellerdatatijdslijnweergave. Data van een enkele teller wordt gevisualiseerd voor deverschillende processen. Bron: [5]

Figuur 2.4: Communicatiestatistieken tonen de communicatie tussen de processen in een matrix.De verzendende processen worden getoond in de rijen, de ontvangende processen in de kolommen.Bron: [5]

2.2 Paraver 13

Figuur 2.5: Overzicht van het tijdsverbruik door de verschillende functies. Bron: [5]

(bijvoorbeeld na afloop van de hele trace). De dynamische visualisatie geeft eenoverzicht op een bepaald tijdstip.

– De data wordt opgeslagen in aparte traceringsbestanden. Dergelijke scheiding vandata en presentatie is ook gewenst in dit werk.

2.1.4 Beperkingen

VAMPIR heeft enkele beperkingen waardoor het niet gebruikt zal worden in dit werk:

– De software is bedoeld voor MPI. Eventueel zou het wel mogelijk zijn om aanpas-singen te doen zodat informatie over cores in plaats van informatie over processenkan weergegeven worden. Maar de beperkingen die hierdoor zouden ontstaan zijnlegio. Een ander aspect is dat de communicatie tussen processen in MPI-systemenwerkt door het uitwisselen van berichten. In de many-coresystemen die in dezemasterproef gesimuleerd worden, wordt gecommuniceerd via gedeeld geheugen.

– De code van deze software is niet vrij beschikbaar. Zowel het praktisch als het legaalaspect zou hier een belemmering vormen.

– Om de visualisaties te bekijken is de software noodzakelijk. Een derde persoon kande visualisaties niet zomaar bekijken zonder de software.

2.2 Paraver

2.2.1 Inleiding

Paraver [7, 8] werd ontwikkeld om via een visuele inspectie van de applicatie inzicht teverwerven in de interne werking van die applicatie en op die manier te kunnen focussenop een gedetailleerde analyse van de problemen.

14 2.2 Paraver

Paraver is niet gebonden aan een programmeermodel. De modellen die ondersteundworden zijn MPI, OpenMP, pthreads, OmpSs en CUDA.

Belangrijke features van Paraver zijn zijn expressieve kracht, flexibiliteit en moge-lijkheid om grote traceringsbestanden efficient te behandelen. Paraver is zeer modulairopgebouwd en kan op die manier deze features verwezenlijken.

2.2.2 Visualisatie

Paraver biedt een minimale set van visualisaties aan. Verschillende types van visualisatiesmoeten enkel ondersteund worden als ze echt verschillende types van informatie tonen.

Informatie over prestatie wordt in Paraver getoond in twee hoofdvisualisaties die tweeverschillende soorten informatie tonen.

Tijdslijnvisualisatie

De tijdslijn toont het gedrag van het programma in de tijd. Op die manier kan de gebruikerhet gedrag van de applicatie begrijpen en fasen en patronen identificeren. Elke horizontalelijn op het diagram stelt een object voor, bijvoorbeeld een processor. Zoals te zien inFiguur 2.6 kunnen bepaalde functie-oproepen in een bepaalde kleur worden weergegevenen kan de communicatie tussen de objecten gevisualiseerd worden. De gebruiker kan in-en uitzoomen om de traces in elk gewenst detail te inspecteren.

Statistiekvisualisatie

De statistiekvisualisatie toont een numerieke analyse van de data. Zo kunnen conclusiesgetrokken worden over waar en hoe er geoptimaliseerd kan worden. Deze visualisatieis in principe niet meer dan een gekleurde tabel. Maar zoals uit Figuur 2.7 blijkt, kandoor de flexibiliteit van het programma ook bijvoorbeeld een visualisatie van cachemissersgemaakt worden. Dit is een uitstekend voorbeeld van hoe Paraver zowel heel eenvoudigmaar ook flexibel kan zijn.


Paraver biedt enkele interessante ideeen:

– Het gedrag van het programma in de tijd wordt gevisualiseerd op een tijdslijn.– Er zijn in- en uitzoommogelijkheden om het gewenste detail te verkrijgen.– Er wordt gewerkt met kleuren als een extra dimensie in de visualisatie.

2.2.4 Beperkingen

Paraver biedt slechts een beperkte set van visualisaties aan. De visualisaties kunnen nietgetoond worden zonder Paraver zelf te gebruiken. Het is wenselijk dat de visualisatiesgetoond kunnen worden aan derden, zonder dat zij programma’s moeten installeren.

2.3 TMProf 15

Figuur 2.6: Tijdslijnvisualisatie van Paraver. Elke lijn stelt een CPU voor. De communicatietussen de processoren wordt weergegeven. Bron: [8]

Figuur 2.7: Statistiekvisualisatie van Paraver om cachemissers voor te stellen. Dit is een voor-beeld van hoe Paraver zowel zeer eenvoudig maar ook flexibel kan zijn. Bron [8]

2.3 TMProf

2.3.1 Inleiding

TMProf [9] is een profiler voor transactioneel geheugen. De profiler is gebaseerd op drievisualisatieprincipes:

– Precieze grafische representatie van de interactie tussen transacties– Soft-real time playback visualisatie van transacties die tegelijk uitgevoerd worden– Dynamische visualisaties van meerdere uitvoeringen

De belangrijkste functie van een profiler voor transactioneel geheugen is de mogelijkheidom een duidelijk beeld te scheppen van de oorzaken van een annulering van transacties.

16 2.3 TMProf

2.3.2 Visualisatie

Visualisatie van een uitvoering

De visualisatie die een enkele uitvoering toont, laat zien hoe transacties tussen verschil-lende draden met elkaar interageren. Een voorbeeld is te zien in Figuur 2.8. Elke draadwordt getoond als een horizontale bar en de verschillende kleuren tonen de conflicten tus-sen de transacties. In elke draad zitten drie barsegmenten. De buitenste laten zien of eentransactie toegevoegd werd (groen) of geannuleerd werd (ander kleur). De binnenste bartoont het transactie type bij de annulatie. Groen is een alleen-lezen-transactie, grijs eenlees-schrijf-transactie en zwart een alleen-schrijven-transactie. Als een transactie wordtgeannuleerd, wordt ofwel een blauwe kleur getoond als een transactie die zichzelf annu-leerde, ofwel wordt de kleur van een andere draad getoond die de transactie annuleerdedoor een conflict.

Figuur 2.8: TMProf: visualisatie van een enkele uitvoering. Het laat zien hoe transacties tussenverschillende draden met elkaar interageren. Bron: [9]

Visualisatie van meerdere uitvoeringen

De visualisatie die meerdere uitvoeringen van hetzelfde programma toont, laat zien hoeeen verandering in het programma de prestatie beınvloedt. Een voorbeeld is te zien inFiguur 2.9.

Figuur 2.9: TMProf: visualisatie van meerdere uitvoeringen. Dit kan aantonen hoe een veran-dering in het programma de prestatie beınvloedt. Bron: [9]

2.4 HPCToolkit 17


TMProf is uiteraard bedoeld voor transactioneel geheugen. Maar Sniper kan ook synchronisatie-traces genereren en we kunnen de principes en ideeen voor het visualiseren van transac-tioneel geheugen ook gebruiken voor het visualiseren van synchronisatietraces.

De volgende ideeen zijn interessant voor de masterproef:

– Ook in deze visualisatiesoftware wordt handig gebruik gemaakt van kleuren ombepaalde gebeurtenissen aan te duiden. De kleuren vormen als het ware een nieuwedimensie van de visualisatie.

– Het vergelijken van twee uitvoeringen met een verschillende setup komt ook hier invoor.

– De events van het transactioneel geheugen worden op een tijdslijn aangeduid.

2.3.4 Beperkingen

TMProf werd ontwikkeld voor transactioneel geheugen. De visualisaties zijn niet recht-streeks bruikbaar en zouden dus aangepast moeten worden. Maar de software is nog nietvrij beschikbaar.

2.4 HPCToolkit

2.4.1 Inleiding

HPCToolkit [10] is een suite van tools die metingen, analyse en presentatie van appli-catieprestatie ondersteunt. Het programma ondersteunt metingen en analyse van serielecode, meerdradige code (bijvoorbeeld met pthreads of OpenMP), MPI en hybride paral-lelle code (bijvoorbeeld MPI in combinatie met het gebruik van draden). HPCToolkit kanschaalbaarheidsbottlenecks in parallelle applicaties identificeren en kwantificeren, waarbijer een overhead is van slechts enkele procenten.

2.4.2 Visualisatie

HPCToolkit biedt twee presentatietools aan, HPCViewer en HPCTraceview.

HPCViewer

De gebruikersinterface van HPCViewer presenteert prestatiemetrieken, gecorreleerd aande structuur van het programma. Deze structuur wordt gemapt op de broncode van hetprogramma. HPCViewer biedt drie verschillende visualisaties van prestatiemetrieken dieberekend worden aan de hand van call path profiling.

– Calling context viewDit is een top-down visualisatie en associeert de dynamische oproepcontexten methun kosten. Met deze visualisatie kan men zien hoeveel een functie kost wanneerdie in een bepaalde context wordt opgeroepen.

18 2.4 HPCToolkit

– Callers viewDeze bottom-up visualisatie laat toe om opwaarts in een oproeppad te kijken. Ditis vooral handig voor het begrijpen van de prestatie van componenten of proceduresdie in meer dan een context gebruikt worden.

– Flat viewIn deze visualisatie wordt prestatiedata getoond in functie van de statische structuurvan het programma.

HPCTraceview

HPCTraceview genereert tijdsruimtediagrammen die tonen hoe de parallelle uitvoering inde tijd verloopt. Een voorbeeld wordt getoond in Figuur 2.10.

Figuur 2.10: HPCToolkit: geannoteerde screenshot van HPCTraceview. Verschillende visuali-saties die de informatie vanuit een ander niveau tonen worden samengebracht. Bron: [11]


De meest relevante tools in HPCToolkit gerelateerd aan deze masterproef zijn de presen-tatietools. Vooral HPCTraceview is interessant omdat het op een overzichtelijke manierdata van honderden processen kan visualiseren in functie van de tijdsdimensie. Verderis het idee om verschillende visualisatieniveaus onder te brengen in een overkoepelendevisualisatie, waarbij de verschillende delen met elkaar kunnen interageren. Ook het ideedat functies gevisualiseerd worden is nuttig.

2.5 Intel VTune 19

2.4.4 Beperkingen

HPCToolkit heeft weinig beperkingen. Het blijft wel onmogelijk om de visualisaties tebekijken zonder de software.

2.5 Intel VTune

2.5.1 Inleiding

Intel VTune [12] is een prestatieprofiler voor C, C++, C#, Fortran, Assembly en Java. Denadruk ligt op gebruiksgemak, diversiteit en productiviteit. In de volgende sectie wordenenkele visualisaties van Intel VTune besproken.

2.5.2 Visualisatie

Visualisatie van CPU-tijd Intel VTune maakt het mogelijk om in een oogopslag tetonen hoeveel tijd de CPU aan een functie heeft moeten spenderen. Men gebruikt hiervooreen bar. Een voorbeeld wordt getoond in Figuur 2.11.

Figuur 2.11: Visualisatie van CPU-tijd in Intel VTune. Bron: [12]

Visualisatie van gedrag van draden Het is interessant om te zien hoe draden zichgedragen over de tijd. In Figuur 2.12 wordt getoond hoe Intel VTune deze visualisatieaanpakt.

Figuur 2.12: Visualisatie van het gedrag van draden in Intel VTune. Bron: [12]

Gebruik van tijdslijnen Om resultaten te filteren gebruikt Intel VTune tijdslijnen.Dit wordt geıllustreerd in Figuur 2.13.

Figuur 2.13: Gebruik van tijdslijnen in Intel VTune. Bron: [12]

20 2.6 Besluit


De mogelijkheden van Intel VTune zijn zeer uitgebreid. Hieronder worden enkele nuttigeideeen opgesomd.

– Er is een directe mapping van resultaten op de broncode.– Om de resultaten te filteren worden tijdslijnen gebruikt.– Het gedrag van draden wordt gevisualiseerd.– Er worden optimalisaties voorgesteld.– Het gebruikt vermogen wordt geanalyseerd.

2.5.4 Beperkingen

De grootste beperking aan Intel VTune is dat de software niet vrij beschikbaar is. Visu-alisaties bekijken zonder deze software is ook onmogelijk.

2.6 Besluit

Elke tool die besproken werd, biedt zeker nuttige ideeen. De belangrijkste worden hiernog eens opgesomd.

– Zinvol gebruik maken van kleuren, ze kunnen een nieuwe dimensie toevoegen aande visualisatie

– Gebruik van de tijdsdimensie in visualisaties– Visualisatie van communicatie tussen processen en draden– Visualisatie dient te gebeuren vanuit verschillende standpunten die elk hun eigen

visie op de data kunnen tonen– Scheiding van data en presentatie– Visualisatie van meerdere uitvoeringen– De link leggen tussen broncode en visualisatie– Voorstellen van optimalisaties om de software-ontwikkelaar te helpen– Analyse van energiegebruik– Functiegebaseerde visualisaties

Maar deze softwarepakketten hebben ook elk hun beperkingen. Daarom wordt in dit werkgeen van voorgaande tools gebruikt en worden eigen visualisaties ontwikkeld.

De beperking dat de software niet vrij beschikbaar of gemakkelijk aanpasbaar is, wordtin deze masterproef vermeden door het gebruik van vrije open-source software.

Om te voorkomen dat visualisaties enkel getoond kunnen worden binnen het visualisa-tieprogramma wordt gebruik gemaakt van webgebaseerde visualisaties die elke gebruikerin zijn browser kan bekijken.

De combinatie van webgebaseerde visualisaties en open-source softwarebibliothekenom deze te construeren zorgt ervoor dat de visualisaties onbeperkt kunnen worden aan-gepast, uitgebreid en samengesteld. Met dezelfde data kunnen verschillende visualisatiesgegenereerd worden. Dergelijke uitbreidbaarheid en mogelijkheden tot aanpassingen ont-breken in de bestaande visualisatiesoftwarepakketten die hierboven besproken werden.

SNIPER: DE MULTI-CORESIMULATOR 21

Hoofdstuk 3

Sniper: De multi-coresimulator

3.1 Inleiding

Om toekomstige multi-core-architecturen, en software die op deze hardware draait, teevalueren bestaat een nood aan nauwkeurige maar snelle simulatie. Nauwkeurigheid, zo-als die behaald wordt in de cyclusgetrouwe simulatoren, staat vaak haaks op snelheid,zoals behaald in simulatoren die slechts een instructie per cyclus uitvoeren. De eerste isnauwkeurig maar traag, de tweede is snel maar onnauwkeurig. De multi-coresimulatorSniper [2, 3, 4], gebaseerd op de Graphite simulatie-infrastructuur [13], biedt een com-promis tussen snelheid en nauwkeurigheid door gebruik te maken van een intervalmodel.Intervalsimulatie zorgt voor een hogere abstractie in de architecturale simulatie. In dezevorm van simulatie wordt gesprongen tussen misserevents. Deze sprongen vormen dan deintervallen. Dit wordt geıllustreerd in Figuur 3.1.

Figuur 3.1: Het intervalmodel dat door Sniper gebruikt wordt. Intervalsimulatie zorgt voor eenhogere abstractie in de architecturale simulatie. In deze vorm van simulatie wordt gesprongentussen misserevents. Bron: [4]

3.2 Doel

Het doel van Sniper is tweeledig. Enerzijds biedt het de mogelijkheid voor hardware-ontwikkelaars om verschillende configuraties uit te testen. Sniper is zowel snel als accuraaten dit leidt ertoe dat een zeer grote ontwerpruimte doorzocht kan worden op zoek naareen optimale architectuur. Anderzijds is Sniper ook een handig hulpmiddel voor software-ontwikkelaars die hun parallelle programma’s willen testen op multi-corehardware. Zokunnen software-ontwikkelaars anticiperen op toekomstige hardware.

22 3.3 Mogelijkheden

De doelstelling van Sniper is dus om aan software-hardware co-design te kunnen doenen dit door op een snelle, accurate en schaalbare manier architecturen te simuleren.

3.3 Mogelijkheden

Omdat Sniper een volledige multi-core-architectuur simuleert, zijn de mogelijkheden le-gio. Dankzij de simulatie wordt het mogelijk om data te genereren die met standaardprofilers en prestatiesoftware, die op echte hardware draaien, onmogelijk te achterhalenis. Een voorbeeld dat in dit werk gebruikt zal worden, is de mogelijkheid om CPI-stackste genereren. Deze tonen aan door welke karakteristieken van het systeem cycli verlorenzijn gegaan gedurende de loop van het programma. Een ander voorbeeld is de integratiemet McPAT (Multicore Power, Area, and Timing), besproken in [14]. McPAT [15] is eenraamwerk dat vermogen kan modelleren. Dankzij de integratie met Sniper wordt het dusmogelijk om uit een multi-coresimulatie te bepalen hoeveel energie de opstelling verbruiktna het uitvoeren van een werklastprogramma. Ook dit zal terugkomen in dit werk en hettoont aan hoe divers en uitgebreid de mogelijkheden van Sniper zijn.

Sniper wordt actief ontwikkeld waardoor er steeds nieuwe onderdelen en opties wordentoegevoegd die ervoor zorgen dat de simulatie nog nauwkeuriger wordt.

3.4 Gebruik van Sniper in dit werk

In Hoofdstuk 1 werden de probleemstelling en het doel van deze masterproef uitgelegd.Sniper past in dit plaatje omdat deze simulator zal zorgen voor de input van de visuali-saties die zullen worden ontwikkeld om een hulpmiddel te zijn voor zowel de hardware-en software-ontwikkelaar in hun zoektocht naar optimalisaties voor hardware en software.De informatie die door Sniper gegenereerd kan worden is enorm uitgebreid, dus de moge-lijkheden voor visualisaties zijn quasi onbeperkt.

Sniper is open-source software en dit zorgt ervoor dat waar nodig, gemakkelijk aan-passingen aangebracht kunnen worden. Het doel is om de visualisaties te integreren in desimulator.

In elk hoofdstuk over visualisaties zal vermeld worden hoe de integratie met Sniperverloopt. Ook wordt er aandacht geschonken aan de overhead die bepaalde opties voorvisualisatie met zich mee kunnen brengen.

23

Deel II

Visualisaties in functie van de tijd

25

Deel II van dit werkt beschrijft het eerste deel van de visualisaties die gemaakt werden:

– Hoofdstuk 4: Cycle stacks in functie van de tijd– Hoofdstuk 5: McPAT-output in functie van de tijd– Hoofdstuk 6: 3D-Visualisatie van tijd-cores-IPC

Deze drie visualisaties hebben de tijdsdimensie gemeenschappelijk. Ze werden gecreeerdvanuit de behoefte om de gebruiker inzicht te verschaffen over de uitvoering van zijnprogramma op de Sniper simulator. Initieel bestonden al enkele eenvoudige visualisaties,maar deze ontbraken aan interactiviteit en de tijdsdimensie. De tijdsdimensie is noodza-kelijk als niet alleen een statische samenvatting van prestatietellers gewenst is, maar ookeen weergave van het verloop van het programma in de tijd.

Deze visualisaties zijn uniek doordat ze nauw samenhangen met Sniper en zo infor-matie kunnen weergeven die door de gebruikelijke instrumentatiesoftware niet getoondkan worden. Sniper simuleert de volledige hardware en dit zorgt voor een grote schat aaninformatie.

Software-ontwikkelaars kunnen hun software aanpassen aan gegeven hardware metde inzichten die verkregen worden dankzij de visualisaties, of omgekeerd, hardware-ontwikkelaars kunnen de gesimuleerde hardware aanpassen aan de gegeven software. Hoe-wel bedoeld voor zowel de software- als hardware-onderzoeker, zal dit deel eerder toegan-kelijk zijn voor de hardware-ontwikkelaar. In Deel III komen dan visualisaties aan boddie nuttiger zullen zijn voor de software-ontwikkelaar.

CYCLE STACKS IN FUNCTIE VAN DE TIJD 27

Hoofdstuk 4

Cycle stacks in functie van de tijd

4.1 Inleiding

In dit hoofdstuk wordt de eerste visualisatie, ‘Cycle stacks in functie van de tijd’, uitde doeken gedaan. Deze visualisatie is gebaseerd op het concept van ‘cycle stacks’. Ditconcept wordt besproken in Sectie 4.2. In de daaropvolgende secties worden achtereenvol-gens het doel en de specificaties van deze visualisatie, de implementatie, het resultaat, deschaalbaarheid, de portabiliteit en de mogelijke verbeteringen besproken. In de volgendetwee hoofdstukken zal vaak verwezen worden naar dit hoofdstuk omdat bijvoorbeeld deimplementatie, de specificaties en de schaalbaarheid vrij analoog zijn.

4.2 Cycle stacks

Het is voor de lezer van dit werk onontbeerlijk om het concept cycle stacks te begrijpenaangezien in dit hoofdstuk een uitbreiding wordt gemaakt van een cycle stack. Daaromwordt in de volgende subsecties ingegaan op wat het concept cycle stack inhoudt en watwe er uit kunnen leren. Eerst wordt getoond hoe een cycle stack gegenereerd kan wordenin de Sniper simulator. Op basis van dit resultaat wordt uitgelegd welke componenten tezien zijn. Daarna wordt besproken welke mogelijkheden en welk doel cycle stacks hebben.Om dan te besluiten welke problemen gepaard gaan met dit ontwerp en waarom in ditwerk een uitbreiding op cycle stacks wordt gemaakt.

4.2.1 Cycle stacks genereren in Sniper

De Sniper simulator bevat een script waarmee cycle stacks gegenereerd kunnen worden.Zoals te lezen staat in de handleiding van deze simulator [16], kan een cycle stack gecreeerdworden met het cpistack.py script, zie Commando 4.1. Als dit script uitgevoerd wordtin de directory waar de outputbestanden van de simulatie staan, bekomt men een cyclestack, zoals in Figuur 4.1. In deze cycle stack zien we bijvoorbeeld dat het aandeel vanmem-dram, de component die toegangen tot het DRAM-geheugen (Dynamic Random-Access Memory) voorstelt, aanzienlijk is. De focus voor optimalisaties van dit programmakan dan in dit voorbeeld liggen op het verminderen van deze geheugentoegangen om deuitvoeringstijd te reduceren. Wat de verschillende componenten precies betekenen wordtvoorgesteld in [17].

28 4.2 Cycle stacks

Commando 4.1: Standaard cycle stack genereren

. / s n i p e r / t o o l s / c p i s t a c k . py −−aggregate

De gebruikte simulatieresultaten werden verkregen door Helsim, een programma datontwikkeld wordt aan het Intel Exascience Lab, uit te voeren met de simulator.

Figuur 4.1: Genormaliseerde cycle stack van Helsim, een programma ontwikkeld aan het IntelExascience Lab. De informatie over de verschillende cores werd geaggregeerd.

4.2.2 Mogelijkheden en doel van cycle stacks

De mogelijkheden en het doel van deze cycle stacks worden omschreven in [17]. Het aan-tal cycli dat een programma nodig heeft om uit te voeren op een processor kan verdeeldworden onder een aantal componenten. Enerzijds hebben we een basiscomponent, dit zijncycli die sowieso nodig zijn om de instructies uit te voeren, anderzijds zijn er componen-ten die de verloren cycli uitdrukken, bijvoorbeeld door verkeerde sprongvoorspellingen ofdoordat data niet meteen beschikbaar is in de caches. De cycle stack krijgt zijn naamomdat het traditioneel wordt voorgesteld als een histogram waarbij de verschillende com-ponenten geplaatst worden op een stapel, met de basiscomponent aan de onderkant.

Cycle stacks laten toe om bottlenecks tijdens de uitvoering van een programma op eenbepaalde architectuur te identificeren. Deze bottlenecks kunnen bijvoorbeeld ontstaanwanneer de werklast over verschillende processorkernen verdeeld wordt. De winst doorhet parallelliseren kan bijvoorbeeld teniet gedaan worden door de wachttijd tijdens hetsynchroniseren. Deze bottlenecks, die dan de grootste componenten zullen zijn in decycle stack, kunnen een hint zijn voor de gebruiker om enerzijds de architectuur aan tepassen aan de software, dit is het standpunt van de hardware-onderzoeker, anderzijdsom de software aan te passen aan de hardware, dit is het standpunt van de software-ontwikkelaar.

4.3 Doel en specificaties 29

4.2.3 Problemen

In deze huidige visualisatie kunnen volgende tekortkomingen geıdentificeerd worden:

– Een cycle stack toont enkel het resultaat na de volledige uitvoering. Er wordt geenverloop in de tijd getoond.

– Wat gebeurt er als we duizenden cores willen visualiseren?– Deze visualisatie is erg statisch, er is geen mogelijkheid om componenten te se-

lecteren, in te zoomen, een meer of minder gedetailleerd niveau te selecteren endergelijke.

4.3 Doel en specificaties

In Sectie 1.3 werden het doel van de visualisaties en de specificaties waaraan ze moetenvoldoen reeds besproken. De visualisaties moeten gebruiksvriendelijk en interactief zijn.Gebruikers moeten de visualisaties kunnen bekijken zonder extra software en onafhankelijkvan welk platform ze gebruiken. Om de visualisaties te kunnen uitbreiden en aanpassenwordt bij voorkeur gewerkt met open-source software en is er een scheiding van data enpresentatie. Ook het combineren van visualisaties is een doelstelling.

Deze specificaties moeten gelden voor alle visualisaties die in dit werk geconstrueerdworden.

4.4 Implementatie

In deze sectie wordt besproken waarom er niet voor een bestaand visualisatiesoftware-pakket gekozen werd. Daarna komen enkele implementatiedetails aan bod, alsook hoe deintegratie met Sniper verliep.

4.4.1 Waarom niet kiezen voor bestaande software?

Zoals uit het overzicht van bestaande visualisatiesoftware blijkt, is er geen bestaandesoftware die aan alle vooropgestelde specificaties voldoet. Elk bestaand softwarepakketheeft zijn beperkingen, zoals vermeld in Sectie 2.6. Om het geheel zo flexibel mogelijkte houden en de integratie met Sniper te vereenvoudigen, werd gekozen voor een eigenimplementatie.

4.4.2 Webgebaseerde visualisatie

Om te voldoen aan het doel en de specificaties werd gekozen voor een webgebaseerdevisualisatie. In moderne browsers, onder meer door de komst van HTML5, is er meer enmeer ondersteuning voor Vector Drawing. Tegenwoordig zijn browsers krachtig genoeg omvloeiend visualisaties te genereren. Een voordeel van deze aanpak is de mogelijkheid om devisualisaties te bekijken zonder extra software, een browser is voldoende. Het combinerenvan visualisaties wordt zeer eenvoudig, op een webpagina verschillende visualisaties samenzetten volstaat. Het gebruik van een webgebaseerde visualisatie zorgt er zelfs voor dat dezeniet beperkt zijn tot traditionele computers, maar ook getoond kunnen worden op tabletsen smartphones, iets wat al helemaal onmogelijk lijkt met bestaande visualisatiesoftware.

30 4.5 Visualisatie genereren

4.4.3 JavaScript en JSON

JavaScript

Om de webgebaseerde visualisaties te genereren, wordt gekozen voor JavaScript. Er zijnheel wat open-source JavaScriptbibliotheken beschikbaar. De JavaScriptbibliotheek diehier gebruikt wordt, is Rickshaw [18]. Deze toolkit wordt omschreven als “Rickshaw is aJavaScript toolkit for creating interactive time series graphs”. Dit bleek een zeer nuttigebibliotheek te zijn voor een visualisatie van cycle stacks in de tijd. Rickshaw is vrije enopen-source software, uitgegeven onder de MIT-licentie, wat het eenvoudig maakte om denodige aanpassingen te verwezenlijken.

JSON

De data wordt opgeslagen in JSON-bestanden (JavaScript Object Notation). Het JSON-formaat is ideaal voor dit doeleind. Het werd oorspronkelijk ontwikkeld voor JavaScript,maar het is taalonafhankelijk, zodat we dezelfde JSON-bestanden ook kunnen gebruikenvoor andere implementaties. Deze bestanden worden via AJAX (Asynchronous JavaScriptand XML) ingeladen in JavaScript. Op die manier bekomen we ook een effectieve scheidingtussen visualisatie en data. Het wordt zeer eenvoudig om verschillende visualisaties tegenereren met dezelfde data.

4.4.4 Integratie met Sniper

Uit de data die standaard gegenereerd wordt door de simulator was het onmogelijk omperiodieke data, met het oog op het toevoegen van een tijdsdimensie, af te leiden. Daaromwordt een script gebruikt dat resultaten wegschrijft per vastgelegde tijdseenheid. De keuzevan de grootte van de intervallen zal uiteindelijk de maximale granulariteit bepalen diete zien kan zijn op de visualisaties. Een groter interval zal een hoger niveau van detailtoelaten, maar kan er ook voor zorgen dat de visualisatie trager zal worden omwille vaneen grotere dataset. Deze problematiek zal verder nog besproken worden in Sectie 4.7,waar getest wordt op de schaalbaarheid van deze visualisatie.

Om Sniper JSON-bestanden met data over de simulatie te laten genereren werdenenkele Python-scripts gemaakt. De workflow gaat als volgt: een applicatie wordt op Sniperuitgevoerd, waarbij een hulpscript periodic-stats.py ervoor zorgt dat er op periodieketijdstippen data wordt weggeschreven over de simulatie. Om uit deze grote hoeveelheiddata de juiste data te selecteren en te verwerken naar JSON-bestanden worden nadiende Python-scripts uitgevoerd. In de bekomen JSON-bestanden staat in dit geval pertijdstip de huidige CPI per component. Sinds Sniper versie 4.1 [19] is deze visualisatiegeıntegreerd in de software en kan ze gegenereerd worden. Een overzicht van de workflowwordt getoond in Figuur 4.2.

4.5 Visualisatie genereren

Het genereren van de visualisatie kan zeer eenvoudig dankzij de integratie met Sniper.Het eenvoudigweg toevoegen van de --viz optie aan het run-sniper commando volstaat.Ook is het mogelijk om bij een bestaand simulatieresultaat achteraf nog een visualisatiete genereren door viz.py uit te voeren met de geschikte parameters. Daarna kan de

4.6 Resultaat 31Implementatie

15

Applicatie Visualisatiescripts

JSON-bestanden

Webpagina’s

Resultaten van simulatie

Figuur 4.2: Workflow van de implementatie. Een programma wordt uitgevoerd door Sniper. Desimulatieresultaten worden verwerkt tot JSON-bestanden, die gebruikt worden door de webpa-gina’s om de visualisaties te genereren.

interactieve visualisatie bekeken worden op een HTML-pagina. De resultaten wordengetoond in figuren 4.3, 4.4 en 4.5. De verschillende elementen waaruit deze visualisatiebestaat en de mogelijke opties worden besproken in volgende sectie.

Commando 4.2: Visualisatie samen met simulatieresultaten genereren

. / run−sniper −−v i z

Commando 4.3: Visualisatie genereren vanuit bestaande simulatieresultaten

. / s n i p e r / t o o l s / v i z . py

4.6 Resultaat

In deze sectie worden de verschillende onderdelen van deze visualisatie besproken. Zowelde esthetische keuzes als het praktisch nut worden uitgelegd.

4.6.1 Assen

Om deze visualisatie te begrijpen is het belangrijk om stil te staan bij wat de twee di-mensies zijn die gebruikt worden. Horizontaal, op de x-as, wordt de tijdsdimensie (inmicroseconden) gemodelleerd. De y-as representeert, bij de standaard genormaliseerdeoptie, het percentage cycli dat verloren gaat aan een bepaalde component. Zo zien wein het voorbeeld van Figuur 4.3 dat in het eerste tijdsslot maar liefst 80% van de cycligebruikt wordt door de geheugencomponent (groen). Dus we kunnen deze voorstelling inprincipe verticaal opdelen in verschillende cycle stacks per tijdsslot.

32 4.6 Resultaat

Figuur 4.3: Cyclestacks in functie van de tijd. De componenten worden vereenvoudigd weerge-geven en de optie ‘normaliseren’ staat aan.

Figuur 4.4: Cyclestacks in functie van de tijd. De componenten worden gedetailleerd weergege-ven en de optie ‘normaliseren’ staat aan.

4.6 Resultaat 33

Figuur 4.5: Cyclestacks in functie van de tijd. De componenten worden gedetailleerd weergege-ven en de optie ‘absolute’ staat aan.

4.6.2 Legende, componenten en kleuren

In de legende, rechts op Figuur 4.3 staan de verschillende componenten. De vier com-ponenten: berekeningen, controleverloop, synchronisatie en geheugen, krijgen elk eenbasiskleur.

Wanneer de optie ‘gedetailleerd’ gebruikt wordt, zoals in Figuur 4.4 in plaats van deoptie ‘eenvoudig’ krijgen we veel meer componenten te zien. Dezelfde basiskleuren blijven,maar elke component krijgt nu een bepaalde tint van de basiskleur. Op die manier ziet degebruiker meteen welke subcomponent behoort tot welke hoofdcomponent. Zo behoortdepend-fp met als kleur donkerrood tot de categorie berekeningen met basiskleur rood.

Een belangrijke opmerking hierbij is dat dezelfde kleuren gebruikt worden zoals bijhet genereren van de eenvoudige CPI-stacks. Dit wordt duidelijk wanneer we Figuur 4.1vergelijken met Figuur 4.4.

Naast het verklaren van de verschillende kleuren heeft de legende ook een belangrijkefunctie binnen deze voorstelling dankzij de mogelijkheden tot interactie. Zweven over eencomponent in de legende zorgt ervoor dat deze component in de visualisatie geaccentueerdwordt. Klikken op een component zorgt ervoor dat alleen deze component te zien is in devisualisatie. Als hierna andere componenten aangevinkt worden is het mogelijk om tweeof meer componenten te vergelijken. Dit wordt geıllustreerd in Figuur 4.6.

4.6.3 IPC-visualisatie

Links van de grafiek staat een optie die de gebruiker toelaat om de IPC-visualisatie tetonen. Deze verschijnt dan onder de andere visualisatie, zoals geıllustreerd in Figuur4.4. IPC staat voor instructies per cyclus en laat toe te tonen hoeveel instructies eruitgevoerd worden in een bepaalde tijdsspanne. Het is dus als het ware een maat voor de

34 4.6 Resultaat

Figuur 4.6: Verschillende componenten kunnen met elkaar vergeleken worden dankzij de inter-actieve legende. Hier werden enkele componenten van het geheugen geselecteerd.

vooruitgang die gemaakt wordt binnen een tijdsslot. Deze visualisatie kan in combinatiemet bovenstaande visualisatie gebruikt worden om te identificeren op welk moment inde tijd het programma weinig vooruitgang maakt, dus een lage IPC heeft. Wanneereen dergelijk moment geıdentificeerd is, kan worden gekeken in de bovenste grafiek welkecomponent mogelijks het verloop van het programma vertraagt.

Deze IPC-visualisatie is vooral nuttig wanneer de optie ‘genormaliseerd’ gebruiktwordt. Bij de optie ‘absoluut’ is de IPC grafiek exact de inverse van de andere visua-lisatie, die de absolute CPI (de inverse van IPC) toont. Dit is duidelijk te zien in Figuur4.5. Er wordt verder ingegaan op het verschil tussen deze opties in Sectie 4.6.5.

4.6.4 Inzoomfunctie

Bij dergelijke visualisaties is een inzoomfunctie onontbeerlijk. Het laat de gebruiker toeom zich te focussen op een bepaalde iteratie of zelfs een bepaald tijdstip. De zoomfunctiekan gebruikt worden door de schuivers op de as onder de visualisatie te verplaatsen. Alsook de IPC-visualisatie getoond wordt, dan zal deze synchroon met de andere visualisatieingezoomd worden.

4.6.5 Opties

De opties ‘eenvoudig’ en ‘gedetailleerd’ werden reeds besproken in Sectie 4.6.2. Zij zor-gen ervoor dat de gebruiker kan switchen tussen een eenvoudige versie waarbij enkel dehoofdcomponenten getoond worden, en een gedetailleerdere versie, waarbij de hoofdcom-ponenten nog eens onderverdeeld worden. Een andere keuze die de gebruiker kan maken isdeze tussen de genormaliseerde en de absolute CPI. Standaard wordt de genormaliseerdeversie getoond waarbij de CPI-waarden genormaliseerd worden. De versie waarbij eenabsolute CPI-waarde getoond wordt, werpt echter een ander licht op de visualisatie. Hieris het meteen duidelijk op welke momenten het programma minder vooruitgang maakt,want de absolute CPI-waarde zal hier hoog zijn. Merk ook op dat CPI de inverse is vanIPC, en wanneer dus de IPC-visualisatie ook getoond wordt zien we dus dat in de tijds-spannes waar de IPC hoog is, de CPI laag zal zijn, en vice versa. Bij de optie ‘absoluut’worden de synchronisatiecomponenten niet weergegeven omdat er tijdens het wachten op

4.6 Resultaat 35

synchronisatie in principe geen instructies worden uitgevoerd, dus zou het niet logischzijn om ze mee te tellen bij de absolute CPI-stack.

4.6.6 Markeringen

Onder de x-as staat een as met markeringen. Wanneer over de markeringen gezweefdwordt, kan de gebruiker zien hoe ver de uitvoering van het programma al staat. Dezemarkeringen kan de gebruiker zelf aan zijn programma toevoegen, bijvoorbeeld bij be-paalde functies. Als er een bepaald tijdsslot geıdentificeerd wordt waarin er erg weinigvooruitgang gemaakt wordt, kan de gebruiker zien in welke iteratie of welke functie ditvoorvalt. In Figuur 4.7 wordt er gezweefd over een van de markeringen.

Figuur 4.7: De markeringen die aangebracht kunnen worden onder de visualisatie.

4.6.7 Afvlakking

Aan de linkerkant van de visualisatie staat een schuifbar waarmee afgevlakt kan worden.Dit kan nuttig zijn wanneer de gebruiker het niet nodig vindt om de grafiek in de standaardgranulariteit te tonen. Als we de visualisatie volledig afvlakken dan verkrijgen we, zoalste verwachten is, bijna de kopie van de standaard cycle stack. Vergelijk de afgevlakteversie in Figuur 4.8 met zijn origineel in Figuur 4.4 en met de statische cycle stack inFiguur 4.1.

Figuur 4.8: Illustratie van het gebruik van de afvlakker.

4.6.8 ‘Negatieve stack’

De ‘negatieve stack’ is een experimentele optie die later aan deze visualisatie is toegevoegd.Wanneer deze optie gebruikt wordt, worden de ‘negatieve’ componenten (componentendie het programma vertragen) letterlijk negatief weergegeven, onder de x-as. De negatievecomponenten in dit geval zijn de synchronisatiecomponenten. Het is voor de gebruiker nuveel gemakkelijker om, in vergelijking met de conventionele visualisatie, de momenten in

36 4.7 Schaalbaarheid

de tijd (of de plaatsen in de code als er ook markers aanwezig zijn) te identificeren waarde negatieve component het sterkst aanwezig is. Deze optie is uiteraard uitbreidbaar inde toekomst waarbij andere componenten ‘negatief’ zijn. Een illustratie van deze optiewordt getoond in Figuur 4.9. Vergelijk deze figuur met Figuur 4.4 waar geen negatieveoptie gebruikt wordt.

Figuur 4.9: Optie ‘negatieve stack’. De negatieve componenten (hier synchronisatiecomponen-ten) worden onder de x-as weergegeven.

4.7 Schaalbaarheid

Om de schaalbaarheid van de scripts te evalueren wordt een experiment opgezet. Eenaantal benchmarks worden uitgevoerd op de simulator waarbij de tijd gemeten wordt diede simulator nodig had om het programma uit te voeren. Daarna worden de visualisatie-scripts uitgevoerd en wordt gemeten hoeveel tijd die in beslag nemen. Met deze resultatenkunnen we dan enkele zaken vergelijken.

Voor de duidelijkheid worden de gebruikte benchmarks in deze en volgende sectiesover schaalbaarheid als volgt genoemd:{benchmarksuite}-{benchmark}-{input}-{cores}.

4.7.1 Schaalbaarheid in de tijd

Deze sectie handelt over twee vormen van schaalbaarheid in de tijd. In de eerste sectiewordt onderzocht wat de overhead is voor de simulatietijd wanneer periodieke statistiekenweggeschreven worden. In de tweede sectie wordt nagegaan wat de verhouding is tussende simulatietijd en het genereren van de JSON-bestanden.

Overhead voor simulatietijd

Wanneer door Sniper de optie voor periodieke statistieken wordt gebruikt, zal de totaleuitvoeringstijd uiteraard ook stijgen. Om deze stijging te onderzoeken werd een experi-ment opgezet waarvan het resultaat te zien is in Figuur 4.10.

De volgende conclusies kunnen hieruit worden getrokken:– De duur van de simulatietijd hangt vooral af van de grootte van de inputset.

4.7 Schaalbaarheid 37

– Er is zeker een overhead, maar deze wordt relatief kleiner als de duur van de ori-ginele simulatietijd groter wordt. Als we een projectie maken naar nog langeresimulatietijden zal de overhead miniem zijn, dus in die zin is dit zeker schaalbaar.

10

100

1000

10000

spla

sh2

-fm

m-t

est

-8

spla

sh2

-fm

m-t

est

-16

spla

sh2

-barn

es-

test

-16

spla

sh2

-fm

m-t

est

-4

spla

sh2

-barn

es-

test

-8

spla

sh2

-fm

m-t

est

-2

spla

sh2

-barn

es-

test

-4

spla

sh2

-barn

es-

test

-2

spla

sh2

-fm

m-s

mall-

16

spla

sh2

-barn

es-

small-

16

spla

sh2

-fm

m-s

mall-

8

spla

sh2

-barn

es-

small-

8

spla

sh2

-fm

m-s

mall-

4

spla

sh2

-barn

es-

small-

4

spla

sh2

-fm

m-s

mall-

2

spla

sh2

-barn

es-

small-

2

oorspronkelijke simulatietijd (s)simulatietijd met optie voor periodieke statistieken (s)

Figuur 4.10: Schaalbaarheid in de tijd: vergelijking van de oorspronkelijke simulatietijd met desimulatietijd wanneer de periodieke statistieken opgeslaan worden.

Genereren van databestanden

De tijd die nodig is voor het genereren van de databestanden is verwaarloosbaar in ver-gelijking met de tijd die nodig is voor de simulatie zelf. Dit wordt aangetoond in eenexperiment waarvan het resultaat te zien is in Figuur 4.11. Alleen wanneer de input-set zeer klein is (bijvoorbeeld bij de ‘test’-inputset) kan het zijn dat het script voor hetgenereren van de bestanden langer duurt dan de simulatie zelf.

4.7.2 Schaalbaarheid in de ruimte

In deze sectie worden twee vormen van schaalbaarheid in de ruimte besproken. De eerstesectie handelt over de grootte van de gegenereerde databestanden die als input zullendienen voor de webpagina’s. De tweede sectie handelt over de toename van de groottevan de databank waarin Sniper zijn statistieken in wegschrijft.

Grootte van de gegenereerde databestanden

De grootte van de bestanden die gegenereerd worden, is zeer beperkt. De HTML-bestanden en JavaScriptbibliotheken bezetten samen slechts 350 kilobytes. De meesteruimte gaat naar de JSON-bestanden, die lineair schalen volgens het aantal gebruikte in-tervallen. Per interval wordt in totaal 1,4 kB aan data gebruikt. Voor een visualisatie van1000 intervallen (dit is de grootteorde van het aantal intervallen gebruikt in de figuren)gaat dit dus slechts om 1,4 MB. Het tienvoud aan intervallen zou nog steeds een zeeraanvaardbare kost aan ruimte betekenen, maar dan zal de browser de bottleneck worden.


10

100

1000

10000sp

lash

2-b

arn

es-

small-

2

spla

sh2

-fm

m-s

mall-

2

spla

sh2

-barn

es-

test

-2

spla

sh2

-fm

m-t

est

-2

spla

sh2

-barn

es-

test

-4

spla

sh2

-fm

m-s

mall-

4

spla

sh2

-barn

es-

small-

4

spla

sh2

-fm

m-t

est

-4

spla

sh2

-barn

es-

test

-8

spla

sh2

-fm

m-s

mall-

8

spla

sh2

-fm

m-t

est

-8

spla

sh2

-barn

es-

small-

8

spla

sh2

-barn

es-

test

-16

spla

sh2

-fm

m-t

est

-16

spla

sh2

-fm

m-s

mall-

16

spla

sh2

-barn

es-

small-

16

simulatietijd (s)genereren van bestanden voor cycle stacks (s)

Figuur 4.11: Schaalbaarheid in de tijd: Vergelijking van de tijd nodig om de databestanden tegenereren en de simulatietijd.

Het aantal intervallen waarmee de browser de visualisatie nog vloeiend kan tonen issterk afhankelijk van het gebruikte device. De weergave op zich zal niet snel een probleemworden, maar het inzoomen kan schokkerig worden wanneer het aantal intervallen sterkoploopt. Op de PC (Intel Core 2 Duo 2GHz met 3 GB RAM-geheugen) waarmee de testenuitgevoerd zijn, ligt die grens op ongeveer 1000 intervallen. 5000 intervallen worden ooknog weergegeven, maar zoomen verloopt met schokken.

De afweging moet dus gemaakt worden tussen granulariteit enerzijds en gebruiksgemakanderzijds.

Toename van de databankgrootte

Wat wel een sterke toename in ruimte kent is de grootte van de databank waarin Sniperzijn resultaten wegschrijft. Aangezien er nu resultaten zijn voor verschillende intervallen(door het gebruik van de periodic-stats optie), zal de databank een aantal grootteordengroter zijn dan de originele databank.

De resultaten van het experiment dat in dit kader opgezet werd, worden getoond inFiguur 4.12. Er kunnen hieruit verschillende conclusies getrokken worden:

– De originele databank verandert van grootte bij toename van het aantal cores, nietdoor de duur van de simulatie.

– De opslag van de periodieke statistieken leidt tot een toename van de databank meteen factor 5.

– De grootte van de nieuwe databank is ook vooral afhankelijk van het aantal cores.

Bij het laatste punt hoort nog een verklaring. Dat de databank niet veel groter wordtwanneer de uitvoeringstijd van de simulatie stijgt, is te danken aan een implementatiebe-slissing die ervoor zorgt dat het totaal aantal intervallen ongeveer constant (1000) blijft.Van zodra er meer intervallen zijn wordt de helft verwijderd, om zo een te grote toename

4.8 Portabiliteit 39

aan ruimte te voorkomen. Dit is een beslissing in het voordeel van de opslagruimte ensnelheid van de visualisatie, maar in het nadeel van de granulariteit.

10000

100000

1e+06

1e+07

1e+08

1e+09

spla

sh2

-barn

es-

small-

2

spla

sh2

-barn

es-

test

-2

spla

sh2

-fm

m-s

mall-

2

spla

sh2

-fm

m-t

est

-2

spla

sh2

-barn

es-

small-

4

spla

sh2

-barn

es-

test

-4

spla

sh2

-fm

m-s

mall-

4

spla

sh2

-fm

m-t

est

-4

spla

sh2

-barn

es-

small-

8

spla

sh2

-barn

es-

test

-8

spla

sh2

-fm

m-t

est

-8

spla

sh2

-fm

m-s

mall-

8

spla

sh2

-barn

es-

small-

16

spla

sh2

-fm

m-t

est

-16

spla

sh2

-barn

es-

test

-16

spla

sh2

-fm

m-s

mall-

16

oorspronkelijke databankgrootte (bytes)databankgrootte met periodieke statistieken (bytes)

Figuur 4.12: Schaalbaarheid in de ruimte: vergelijking van de grootte van de originele databankmet de databank die Sniper genereert als de periodieke statistieken ook bijgehouden worden.

4.8 Portabiliteit

Deze visualisaties zijn webgebaseerd. Dit heeft als groot voordeel dat de resultaten kunnenbekeken worden zonder dat er een extern programma aan te pas komt. Het principe vanscheiding van data en presentatie zorgt ervoor dat het al voldoende is om enkel JSON-bestanden te vervangen om zo een nieuwe visualisatie te bekomen.

Een ander voordeel is dat de visualisaties gegenereerd kunnen worden op gelijk welkdevice dat ondersteuning biedt voor moderne webbrowsers, zoals tablets en smartphones.De visualisaties werden met succes getest op de volgende smartphone en tablet:

– HTC Wildfire S met Opera Mobile– Samsung Galaxy Tab 2 met Google Chrome

4.9 Mogelijke verbeteringen

Het zou uiteraard fout zijn om te pretenderen dat deze visualisatie volledig ‘af’, of per-fect is. Tijdens en na het maken van deze visualisatie werd veel feedback gegeven en devisualisaties werden zo goed mogelijk geoptimaliseerd. Volgende lijst bevat extra featuresdie kunnen toegevoegd worden om de visualisatie nog gebruiksvriendelijker te maken.

– Bij het inzoomen kan het gebeuren dat de gebruiker het overzicht verliest van hettijdstip waar hij zich juist bevindt. Daarom zou het handig kunnen zijn om naastde grafiek een extra visualisatie te hebben die het tijdsverloop minimalistisch kan

40 4.10 Besluit

voorstellen, maar wel een idee geeft van de tijdsspanne waarin de gebruiker heeftingezoomd.

– Een lijst van de markeringen, eventueel in een boomstructuur, zou handig kunnenzijn.

– Nu moeten de markeringen nog handmatig toegevoegd worden aan de software. Au-tomatisch genereren van markeringen, bijvoorbeeld een per functie is een volgendestap.

– Omdat het bij de absolute weergave van de cycle stacks niet logisch is dat de syn-chronisatiecomponent aanwezig is, zoals uitgelegd in Sectie 4.6.5, kan er misschienanaloog aan de IPC-grafiek een synchronisatiegrafiek getoond worden. Zo wordt deinformatie over synchronisatie toch getoond.

– Met deze architectuur is het in principe mogelijk om een ‘live-view’ te genereren.Tijdens de simulatie (die doorgaans enkele grootteorden langer duren dan het gene-reren van een visualisatie) kunnen de tussentijdse resultaten weggeschreven worden.Deze resultaten kunnen dan al gevisualiseerd worden terwijl de simulatie nog be-zig is. Zo kan de gebruiker de voortgang van zijn simulatie bekijken en eventueelvroegtijdig afbreken als de resultaten niet zoals gewenst zijn, bijvoorbeeld door hetvoorkomen van een bug.

– Bij de ‘negatieve stack’-optie kan er een mogelijkheid toegevoegd worden waarbijde gebruiker zelf kiest welke componenten negatief worden weergegeven. Als de ge-bruiker zich bijvoorbeeld wil concentreren op de plaatsen waar de DRAM-toegangenveel cycli vragen, dan zou hij deze component kunnen selecteren om onder de x-asgetoond te worden.

4.10 Besluit

Cycle stacks in functie van de tijd voegen een extra dimensie toe aan de traditioneleCPI-stacks. Dankzij deze tijdsdimensie kan het verloop van de uitvoering van een pro-gramma in de tijd getoond worden. Op deze manier kunnen problemen en optimalisatiesgeıdentificeerd worden om het programma sneller te maken. De geconstrueerde visuali-satie biedt verschillende opties om het de gebruiker gemakkelijk te maken. Verschillendegebruikers zullen een verschillend level van detail wensen en om hieraan te voldoen is eenzoomfunctie beschikbaar en de mogelijkheid om te switchen tussen een eenvoudige en eengedetailleerde view.

Verder is het zeer eenvoudig om de visualisatie te genereren, het eenvoudigweg toe-voegen van de --viz optie aan het run-sniper commando volstaat.

De visualisatie bekijken kan zonder additionele software, een moderne browser ge-bruiken is voldoende. Deze visualisaties kunnen bijgevolg getoond worden op gelijk welkdevice met een moderne browserondersteuning.

Ook de schaalbaarheid van deze visualisatie werd onderzocht. De overhead in de tijd isminiem. De databank waarin Sniper zijn resultaten opslaat, wordt wel aanzienlijk groteraangezien er nu ook periodieke informatie weggeschreven wordt. Maar deze stijging isniet problematisch groot doordat er een limiet staat op het aantal intervallen waaroverinformatie opgeslagen wordt.

MCPAT-OUTPUT IN FUNCTIE VAN DE TIJD 41

Hoofdstuk 5

McPAT-output in functie van de tijd

5.1 McPAT

McPAT (Multicore Power, Area and Timing), voorgesteld in [15], is een raamwerk datvermogen kan modelleren. Op die manier kan een schatting gemaakt worden van hetvermogenverbruik van een programma, uitgevoerd op een bepaalde architectuur.

De integratie van McPAT in de Sniper simulator wordt besproken in [14]. De com-binatie van Sniper en McPAT zorgt ervoor dat hardware/software co-optimalisatie kanplaatsvinden, waarbij ook rekening wordt gehouden met het vermogenverbruik, een steedsbelangrijker wordende factor tijdens de ontwikkeling van nieuwe architecturen.

5.2 Power stacks

Power stacks worden opgebouwd volgens hetzelfde principe als cycle stacks, uitgelegd inSectie 4.2. Hier worden echter geen gebruikte cycli per component getoond, maar hetgebruikt vermogen of energie. Zo kan naast het totale vermogen- of energieverbruik ookgetoond worden welke component het meest vermogen verbruikt heeft. Power stacks kun-nen in Sniper gegenereerd worden door het mcpat.py script uit te voeren, zie Commando5.1. Als voorbeeld genereren we de powerstack van de simulatieresultaten die eerder algebruikt werden. Het resultaat wordt getoond in Figuur 5.1.

Commando 5.1: Standaard power stack genereren

. / s n i p e r / t o o l s /mcpat . py

5.3 Problemen

De visualisatie zoals in Figuur 5.1 is niet interactief en toont enkel het resultaat over hethele verloop van de werklast. Veel interessanter wordt het wanneer het energieverbruik vande architectuur gevisualiseerd wordt over de tijd in een interactieve en gebruiksvriendelijkeomgeving.

42 5.4 Doel en specificaties

Figuur 5.1: Power stack gegenereerd door Sniper. Per component wordt de hoeveelheid energie(in Joule) weergegeven.


Het doel en de specificaties voor deze visualisatie zijn sterk analoog aan wat in Sectie 4.3besproken werd over cycle stacks in functie van de tijd. De beperking van de originelepower stacks is dat er enkel een beeld wordt gegeven na de volledige uitvoering. Het doelis nu om ook hier een tijdsdimensie aan toe te voegen, om het verbruik van vermogen enenergie in de tijd weer te geven.

5.5 Implementatie

Om de data te genereren wordt het mcpat.py script uitgevoerd op alle periodieke data. Omde data te visualiseren werd ook hier gebruik gemaakt van Rickshaw, de JavaScriptbiblio-theek die reeds aangehaald werd in Sectie 4.4.3. De gebruikte workflow wordt omschrevenin Figuur 4.2.


Sinds Sniper versie 4.1 is deze visualisatie ook beschikbaar. Om deze te genereren, moet,naast de --viz optie, ook de --power optie gebruikt worden, zoals weergegeven in Com-mando 5.2. Net zoals bij de andere visualisaties zal deze ook verschijnen op de webpaginadie gecreeerd wordt.

Commando 5.2: Visualisatie samen met simulatieresultaten genereren

. / run−sniper −−v i z −−power

5.7 Resultaat 43

5.7 Resultaat

Het resultaat wordt getoond in 5.2.

Figuur 5.2: Het vermogen, uitgezet in de tijd, dat geschat wordt door McPAT.

5.7.1 Assen

De x-as stelt opnieuw de tijd voor in microseconden, om op die manier de resultaten uitte zetten in de tijd. De y-as staat, naargelang de gekozen optie, voor het vermogen, deenergie of het energiepercentage.

5.7.2 Componenten en legende

In deze visualisatie zijn er minder componenten dan in de gedetailleerde cycle stacks omdatMcPAT eenvoudigweg minder gedetailleerd het energieverbruik over de componenten kanschatten. De legende bevat dezelfde functies als besproken in Sectie 4.6.2.

5.7.3 Opties

De drie verschillende opties zijn het tonen van ‘vermogen’, ‘energie’ en ‘energiepercentage’.Verder is er ook zoals bij de cycle stacks in functie van de tijd een mogelijkheid om inte zoomen, markers te zetten, de afvlakkingsbar te gebruiken en de IPC-grafiek te tonen.De bijkomende IPC-grafiek kan de relatie tussen het aantal instructies uitgevoerd in eentijdsspanne en het vermogen- en energieverbruik weergeven.

5.8 Schaalbaarheid

Voor de resultaten in verband met de schaalbaarheid wordt verwezen naar Sectie 4.7aangezien dit volledig analoog is. Het enige verschil is hier het script om de data voor

44 5.9 Mogelijke verbeteringen

de visualisaties te genereren. Er wordt intern gebruik gemaakt van het mcpat.py script(te vinden in sniper/tools/mcpat.py) dat uitgevoerd wordt op elk periodiek resultaat datdoor Sniper opgeslagen werd. Om de totale uitvoeringstijd van het visualisatiescriptte vergelijken met de simulatietijd werd een experiment opgezet. Het resultaat wordtgetoond in Figuur 5.3.

10

100

1000

10000

spla

sh2

-barn

es-

small-

2

spla

sh2

-barn

es-

test

-2

spla

sh2

-fm

m-s

mall-

2

spla

sh2

-fm

m-t

est

-2

spla

sh2

-fm

m-t

est

-4

spla

sh2

-fm

m-s

mall-

4

spla

sh2

-barn

es-

test

-4

spla

sh2

-barn

es-

small-

4

spla

sh2

-barn

es-

test

-8

spla

sh2

-fm

m-s

mall-

8

spla

sh2

-fm

m-t

est

-8

spla

sh2

-barn

es-

small-

8

spla

sh2

-barn

es-

test

-16

spla

sh2

-fm

m-t

est

-16

spla

sh2

-barn

es-

small-

16

spla

sh2

-fm

m-s

mall-

16

simulatietijd (s)genereren van bestanden voor mcpat output (s)

Figuur 5.3: Schaalbaarheid in de tijd: vergelijking van de oorspronkelijke simulatietijd met detijd nodig om het script uit te voeren dat de data voor de visualisaties genereert.

Het is duidelijk dat de uitvoeringstijd volledig afhangt van het aantal cores dat gebruiktwordt. Het mcpat.py script is relatief traag in vergelijking met bijvoorbeeld het cpistack.pyscript dat gebruikt werd voor de cycle stacks in de tijd. Voor kleine inputs zoals ‘test’zal dit visualisatiescript langer duren dan de simulatietijd zelf. Dit is dan ook de redenwaarom beslist werd om deze visualisatie standaard uit te schakelen. Alleen met de--power optie wordt deze data ook gegenereerd.


Informatie zou ook weergegeven kunnen worden per processorkern. Zo kan het nuttig zijnom te zien hoeveel minder energie een core gebruikt wanneer bijvoorbeeld een techniekals DVFS (Dynamic Voltage and Frequency Scaling) gebruikt wordt. Er zijn ook nogandere toepassingen te bedenken waar een per-core-opsplitsing nuttig kan zijn, zoals bijheterogene processoren waarbij kleine zuinige cores gecombineerd worden met grote co-res die veel meer energie verbruiken. Het kan interessant zijn om te observeren wat deverhouding is tussen het energieverbruik van de twee soorten kernen.

Een andere optimalisatie is uiteraard het versnellen van het script dat de data gene-reert. Als dit sneller kan dan zou de optie voor het genereren van deze visualisatie ookstandaard aan kunnen staan.

Ook hier kan een live-weergave een nuttig instrument zijn. Wanneer de hardware-ontwikkelaar tijdens de uitvoering van de simulatie op de visualisaties al merkt dat het

5.10 Besluit 45

energieverbruik veel te hoog is, kan hij eventueel de simulatie afbreken om een andereconfiguratie te proberen.

5.10 Besluit

Deze visualisatie is nuttig omdat het geen statische representatie van het energieverbruikna afloop van de gehele uitvoering van de applicatie toont, maar een dynamische, inter-actieve voorstelling van het energieverbruik gedurende de loop van het programma. Ditkan inzicht verschaffen in de redenen voor plotse vermogenspieken of -dalen. Het toontaan hoeveel energie per component verbruikt wordt.

Een nadeel aan deze visualisatie is dat de scripts die de data genereren een relatieflange uitvoeringstijd hebben.

3D-VISUALISATIE VAN TIJD-CORES-IPC 47

Hoofdstuk 6

3D-Visualisatie van tijd-cores-IPC

6.1 IPC

IPC staat voor instructies per cyclus. Het is dus een maat voor de vooruitgang die eenprogramma maakt gedurende een bepaalde tijdsspanne.

Een IPC-grafiek plotten over de tijd werd reeds getoond als optie bij de visualisatievan cycle stacks over de tijd, zie bijvoorbeeld onderaan Figuur 4.4. In dit hoofdstukwordt echter verder gegaan. Waar bij de cycle stacks over de tijd de informatie over deverschillende cores geaggregeerd werd, wordt er nu een core-dimensie toegevoegd. Ditresulteert in drie dimensies: tijd, cores en IPC.


Het doel van deze visualisatie is de gebruiker een overzicht te tonen van de vooruitgangdie het programma maakt op een bepaald moment, waarbij informatie over verschillendecores bekeken kan worden. Het resultaat is een driedimensionale visualisatie.

6.3 Implementatie

Ook hier wordt gewerkt met een JavaScriptbibliotheek, ‘JavaScript Surface Plot’ [20]. Ditis een open-source project, uitgegeven onder de BSD-3 licentie. Deze bibliotheek laat toeom driedimensionale oppervlakken te plotten.

6.4 Integratie in Sniper

Deze visualisatie is geıntegreerd in Sniper sinds versie 4.1. Als bij het gebruik van desimulator de optie --viz meegegeven wordt, zoals in Commando 4.2, dan zal ook dezedriedimensionale visualisatie gegenereerd worden.

6.5 Resultaat

Het resultaat is te zien in Figuur 6.1. Op de drie assen kan men de drie dimensiesherkennen: tijd (in microseconden), IPC en cores. De pieken in het vlak tonen wanneer

48 6.6 Praktisch nut

een core op een bepaald ogenblik veel nuttig werk verricht, met andere woorden er wordenop dat moment in die core veel instructies verwerkt. Een dal in het vlak toont eentegengesteld geval aan.

Er werd gekozen voor een vlak, in plaats van een driedimensionale staafgrafiek, omdatdeze voorstelling voor de gebruiker veel duidelijker en leesbaarder is. Verder wordt gewerktmet kleurschakeringen. Een blauwe kleur duidt op een lage IPC, een rode kleur duidt opeen hoge IPC.

Dit vlak kan naar wens gedraaid worden. De visualisatie kan op zo’n manier gedraaidworden dat ze volledig overeenkomt met de reeds besproken IPC-grafiek. Dit wordt ge-toond in Figuur 6.2. Dit is duidelijk hetzelfde IPC-patroon als in Figuur 4.4. Verderbestaat er ook een mogelijkheid tot inzoomen.

Figuur 6.1: 3D-Visualisatie van tijd-cores-IPC.Op de x- en z-as staan de tijd (in microseconden) en de cores. Op de y-as staat de IPC uitgezet.

6.6 Praktisch nut

Op het eerste zicht lijken de praktische mogelijkheden voor deze visualisatie eerder be-perkt. Het vormt echter een duidelijk beeld voor de gebruiker van de manier waarop zijnapplicatie in de tijd verloopt. In tegenstelling tot voorgaande visualisaties wordt hier hetonderscheid gemaakt tussen verschillende cores, dus met deze voorstelling kan het snelduidelijk zijn of de werklast voldoende verdeeld wordt over de verschillende rekencapaci-teiten. Het kan als startpunt dienen voor verder onderzoek. Als er in een bepaalde periodeeen erg lage IPC waarneembaar is, dan kan het zijn dat er niet veel vooruitgang gemaaktwordt door bepaalde architecturale keuzes, die eventueel aangepast kunnen worden omde IPC te verhogen en hiermee de uitvoeringstijd te verkorten.

Een praktisch voorbeeld dat zich gesteld heeft gedurende het verloop van deze mas-terproef is het volgende. Stel er zijn twee simulatieresultaten van hetzelfde programma,maar waarbij in de architectuur een van de 108 cores iets verschillend doet in vergelijking

6.6 Praktisch nut 49

Figuur 6.2: Als deze 3D-visualisatie van Helsim in een juiste hoek wordt gedraaid dan wordtopnieuw de IPC-grafiek getoond zoals in Figuur 4.4.

met het andere simulatieresultaat. De reden hiervoor kan bijvoorbeeld een foute configu-ratie zijn. Deze core identificeren, kan nu zeer eenvoudig gebeuren met deze visualisatie.Het volstaat om de voorstellingen in de juiste hoek te draaien en te vergelijken. Zoals opFiguur 6.3 te zien is, is het duidelijk dat core 42 de bewuste core is.

Figuur 6.3: Vergelijking tussen twee simulatieresultaten. Het is duidelijk dat core 42 op hetlinkse resultaat een ander gedrag vertoont dan op het rechtse resultaat.


6.7 Schaalbaarheid

6.7.1 Schaalbaarheid in de ruimte


De statische JavaScript- en HTML-bestanden zijn slechts 220 kB groot. De grootste kostgaat naar de opslag van JSON-bestanden, die 93 Bytes per interval per core gebruiken.In het voorbeeld gaat het om 93 Bytes * 1349 intervallen * 8 cores = 1 MB. Maar deschaalbaarheid in de ruimte gebeurt lineair, dus dit zou geen probleem mogen vormen.


De toename van de databankgrootte is analoog zoals besproken in Sectie 4.7.2 want deresulterende databank is dezelfde.

6.7.2 Schaalbaarheid in de tijd

Overhead voor simulatietijd

Dit is dezelfde overhead als besproken in Sectie 4.7.1 want Sniper krijgt dezelfde opties.


Het genereren van de visualisatie gebeurt ook hier in een grootteorde van tijd die velemalen kleiner is dan de tijd die nodig is voor de simulatie zelf. De uitvoeringstijd isvermoedelijk vooral afhankelijk van het aantal cores. Om dit te verifieren werd een expe-riment opgezet, waarvan het resultaat te zien is in Figuur 6.4.

Hierbij kunnen de volgende conclusies worden getrokken:– De tijd die nodig is om de databestanden te genereren is veel kleiner dan de simu-

latietijd (behalve in extreme gevallen met een zeer kleine inputset).– Deze tijd stijgt volgens het aantal processorkernen.

6.7.3 Schaalbaarheid van de visualisatie

De grootste beperking ligt niet in de schaalbaarheid van tijd en ruimte, maar in de schaal-baarheid van de visualisatie zelf. Afhankelijk van het gebruikte device zal de browser ergtraag worden tijdens het renderen van simulaties met zeer veel cores en zeer veel interval-len. Op de PC (Intel Core 2 Duo 2GHz met 3 GB RAM-geheugen) waar de testen meeuitgevoerd zijn, blijkt die grens te liggen rond 1500 intervallen en 100 cores.


In deze visualisatie kan de interactiviteit nog verbeterd worden. De visualisatie kan algedraaid en ingezoomd worden, maar meer dan dat is nog niet mogelijk. Het zou zeernuttig kunnen zijn moest de gebruiker op een bepaald punt kunnen klikken om dan meerinformatie over dat bepaalde tijdstip of die bepaalde processorkern te verkrijgen. De linkkan worden gelegd met de visualisaties van Hoofdstuk 4.

6.9 Besluit 51

1

10

100

1000

10000

spla

sh2

-barn

es-

small-

2

spla

sh2

-barn

es-

test

-2

spla

sh2

-fm

m-s

mall-

2

spla

sh2

-barn

es-

small-

4

spla

sh2

-fm

m-t

est

-2

spla

sh2

-barn

es-

test

-4

spla

sh2

-fm

m-s

mall-

4

spla

sh2

-fm

m-t

est

-4

spla

sh2

-barn

es-

small-

8

spla

sh2

-barn

es-

test

-8

spla

sh2

-fm

m-t

est

-8

spla

sh2

-fm

m-s

mall-

8

spla

sh2

-barn

es-

small-

16

spla

sh2

-fm

m-t

est

-16

spla

sh2

-barn

es-

test

-16

spla

sh2

-fm

m-s

mall-

16

simulatietijd (s)genereren van bestanden voor tijd-cores-IPC (s)

Figuur 6.4: Schaalbaarheid in de ruimte: vergelijking tussen de simulatietijd en het genererenvan de databestanden.

6.9 Besluit

De driedimensionale visualisatie van IPC over de tijd en het aantal cores kan voor deonderzoeker een hulpmiddel vormen om snel een overzicht te krijgen van het verloop vande software over de tijd. In tegenstelling tot de visualisaties in Hoofdstuk 4 en Hoofdstuk 5worden hier ook de verschillende cores afzonderlijk getoond. Dit zorgt ervoor dat, wanneereen core geen of al de instructies uitvoert, dit duidelijk zichtbaar zal zijn. Voor eenmeer gedetailleerde weergave zal echter de visualisatie uit Hoofdstuk 4 gebruikt moetenworden. De 3D-visualisatie blijkt schaalbaar te zijn in tijd en ruimte. De beperking inschaalbaarheid ligt bij het renderen in de browser zelf.

53

Deel III

Functiegebaseerde visualisaties

55

Deel III van dit werk handelt over functiegebaseerde visualisaties. De grootste drijfveeris dat informatie gewenst is over de functies zelf. Welke eigenschappen hebben de functies?Welke functies hebben veel ruimte voor optimalisatie? Welke optimalisaties zijn mogelijken behalen de grootste versnelling? Dit zijn vragen die beantwoord kunnen worden doorfunctiegebaseerde visualisaties.

Recent is aan Sniper de mogelijkheid toegevoegd om statistieken te laten uitschrijvendie informatie per functie bevatten. Die informatie bevat bijvoorbeeld het aantal instruc-ties, de gebruikte tijd, het aantal vlottende-komma-instructies, de tijd die verloren gegaanis aan geheugentoegangen enzovoort. Dit leidt ertoe dat een nieuwe reeks van visualisatiesmogelijk is. Deze worden besproken in volgende hoofdstukken:

– Hoofdstuk 7: Functies: instructies versus tijd– Hoofdstuk 8: Roofline model– Hoofdstuk 9: Automatische suggesties voor optimalisatie

Terwijl de twee eerste visualisaties een weergave zijn van de bestaande situatie, gaatde derde visualisatie een stap verder. In de automatische suggesties voor optimalisatieworden voorstellen gedaan om de functies te optimaliseren. Dit is mogelijk doordat weover de nodige informatie beschikken.

Omdat de drie visualisaties telkens dezelfde functies op een andere manier beschrijvenis ervoor gekozen om ze op een webpagina te plaatsen. Dit zorgt ervoor dat ze, hoewelook volledig apart te gebruiken, nauw aan elkaar gelinkt zijn. Een functie selecteren ineen visualisatie, zal ertoe leiden dat deze functie ook geselecteerd wordt in de anderevisualisaties bijvoorbeeld.

Waar de visualisaties uit Deel II vooral door de hardware-onderzoeker kunnen wordengebruikt, zal dit deel eerder voer voor de software-ontwikkelaar zijn omdat er nu meer eendirecte link is tussen de visualisaties en de functies die de ontwikkelaar geschreven heeft.

FUNCTIES: INSTRUCTIES VERSUS TIJD 57

Hoofdstuk 7

Functies: instructies versus tijd

7.1 Inleiding

Vanuit de behoefte om vragen met betrekking tot optimalisatie van functies te beant-woorden en met de beschikbaarheid van functie-informatie worden nieuwe visualisatiesgemaakt. Een eerste, relatief triviale maar daarom niet minder nuttige, visualisatie is eenspreidingsdiagram waarbij de functies uitgezet zijn over de tijd en het aantal gebruikteinstructies.

De verwachting is uiteraard dat de uitvoeringstijd stijgt volgens het aantal instruc-ties dat uitgevoerd wordt. Als de uitvoeringstijd abnormaal groot is volgens het aantaluitgevoerde instructies, dan is er misschien een probleem.

7.2 Implementatie

Opnieuw wordt, zoals de visualisaties in Deel II, gewerkt met webgebaseerde visualisaties.In het vorige deel werden de voordelen en mogelijkheden daarvan besproken. Ook wordtopnieuw gebruik gemaakt van JSON-bestanden voor de data-opslag en een JavaScript-bibliotheek voor de generatie van visualisaties. De visualisatiebibliotheek die hier wordtgebruikt is Flot [21], een open-source JavaScriptbibliotheek die gebruik maakt van jQuery.Flot bevat standaard al voldoende features om deze (en volgende, zie Hoofdstuk 8) visu-alisatie te genereren.

De workflow van deze implementatie wordt geıllustreerd in Figuur 7.1. De simulatie-resultaten die door Sniper gegenereerd werden, worden verwerkt door een functieparserdie alle informatie over de functies verwerkt. Die informatie wordt dan gebruikt doorhet Python-script functionbased.py dat alles zal verwerken tot JSON-bestanden die danuiteindelijk worden ingelezen door de webpagina’s.


Deze visualisatie genereren, gebeurt samen met de visualisaties uit Hoofdstuk 8 en Hoofd-stuk 9. Omdat ze met elkaar interageren, worden ze samengebracht op een webpagina,zoals te zien is op Figuur 7.2.

Eerst moet de applicatie uitgevoerd worden door Sniper met bepaalde opties om func-tiegebaseerde statistieken te bekomen. Een voorbeeld wordt getoond in Commando 7.1.

58 7.4 Resultaat

FunctionParser

1

Applicatie

JSON-bestanden

Webpagina’s


FunctionBased

Figuur 7.1: Workflow van de ’Functies: instructies versus tijd’ visualisatie.

Daarna kan het Python-script uitgevoerd worden die de JSON-bestanden uitschrijft en dewebpagina’s naar de juiste plaats kopieert. Dit wordt geıllustreerd in Commando 7.2. De-s en -x opties zijn niet verplicht, maar wel noodzakelijk als Doxygeninformatie gewenstis. Voor Doxygen wordt verwezen naar Sectie 7.4.2

Commando 7.1: Applicatie uitvoeren met Sniper om functiegebaseerde statistieken te bekomen

. / run−sniper −n 2 −p splash2−fmm −−r o i−g −−i n s t r u c t i o n t r a c e r / type=f p s t a t s−g −−r o u t i n e t r a c e r / type=f u n c s t a t s

Commando 7.2: Python script uitvoeren dat de JSON-bestanden uitschrijft

. / s n i p e r / t o o l s / funct ionbased . py −o / outputd i r −d / r e s u l t s d i r−s / sou r c e coded i r −x / doxygendir

De resulterende webpagina wordt getoond in Figuur 7.2. Wanneer geklikt wordt opeen titel schuift de corresponderende sectie naar beneden. Rechts is er ook nog eendrijvende navigatie voorzien die verschijnt wanneer er over de icoontjes wordt gezweefd.De instructies-versus-tijd-plot kan nu dus worden getoond door te klikken op ‘Functions:instructions versus time’. Dan zal een sectie zoals in Figuur 7.3 getoond worden.

7.4 Resultaat

Een voorbeeld van de ‘Functies: instructies versus tijd’-visualisatie wordt getoond inFiguur 7.3.

7.4.1 Mogelijkheden

Opnieuw was het doel om een interactieve omgeving te creeren. Mogelijkheden zijn onderandere:

7.4 Resultaat 59


Functions: instructions versus time

Roofline model

Function info

Suggestions for OptimizationFunctions: instructions versus timeRoofline ModelFunction Info

Figuur 7.2: Resulterende webpagina na het uitvoeren van het functionbased.py script. De ver-schillende visualisaties kunnen opengeklikt worden door op hun titel te klikken.

functions

Logscale

Suggestions for OptimizationFunctions: instructions versus time

1

10

100

1,000

10,000

100,000

1,000,000

10,000,000

100,000,000

1 10 100 1,000 10,000 100,000 1,000,000 10,000,000

0

100,000,000

Roofline ModelFunction Info

EvaluateLocalExp

Figuur 7.3: Functies: instructies versus de tijd. De verwachting is dat de uitvoeringstijd stijgtvolgens het aantal instructies dat een functie uitvoert. Als de uitvoeringstijd abnormaal grootis volgens het aantal instructies dan zal dit duidelijk te zien zijn op dit spreidingsdiagram.

60 7.5 Praktisch nut

– Zweven over een functie om de naam te zien.– Dubbellogaritmische schaal (logaritme basis 10) aan- of afvinken.– Inzoomen, zie Figuur 7.4– Overzichtsgrafiek rechtsboven. Deze laat toe om het overzicht te bewaren wanneer

ingezoomd wordt.– Klikken op een functie om informatie te tonen, zie Sectie 7.4.2.

7.4.2 Functie-info

Als er op een functie wordt geklikt, komt er ook een sectie ‘Function info’ tevoorschijndie informatie over deze functie weergeeft. Deze visualisatie biedt verschillende mogelijk-heden:

– BasisinformatieFunctienaam, referentie naar broncode, aantal oproepen, aantal vlottende-komma-instructies enzovoort.

– Navigeren door functiesBijvoorbeeld per aantal oproepen. Als je klikt op het pijltje naar rechts dan wordtde volgende functie per aantal oproepen getoond. Er kan ook naar het minimum ofhet maximum van een bepaalde eigenschap genavigeerd worden.

– Terugkoppeling naar de andere visualisatiesAls een andere functie geselecteerd wordt, bijvoorbeeld door de pijltjes, dan wordtdeze functie ook geselecteerd in de andere grafieken.

– CPI-barDe drie CPI-componenten die beschikbaar worden gesteld door de simulator zijn debasis-, sprongen geheugencomponent. Hover over een van de componenten om denaam te zien.

– Suggesties voor optimalisatieHier wordt verder op ingegaan in Hoofdstuk 9.

Als de opties nodig voor het genereren van Doxygeninformatie zijn meegegeven, zie Com-mando 7.2, dan kan de link ook gemaakt worden met Doxygen. Doxygen [22] is eenopen-source (GNU General Public License) tool die automatisch documentatie kan ge-nereren vanuit broncode. Het is nu dus mogelijk om vanuit de visualisatie te navigerennaar de Doxygeninformatie, die onder andere de broncode van een functie kan tonen.Als Doxygeninformatie beschikbaar is zal er een documenticoontje verschijnen naast het‘source’-veld.

Een voorbeeld van de functie-infosectie wordt getoond in Figuur 7.5.

7.5 Praktisch nut

Deze visualisatie kan enerzijds worden gebruikt om snel een overzicht te krijgen van debelangrijkste functies (belangrijk in tijd of aantal instructies) en anderzijds om inefficientefuncties te identificeren. Als een functie zeer weinig instructies uitvoert in een zeer langetijd dan is er misschien wel een optimalisatie mogelijk. De functie-info sectie kan inzichtverschaffen wanneer een functie zeer traag uitgevoerd wordt.


functions

Logscale

Suggestions for OptimizationFunctions: instructions versus time

10

100

1,000

100 1,000

0

100,000,000

Roofline ModelFunction Info

Figuur 7.4: Functies: instructies versus de tijd. Er werd ingezoomd. De overzichtsgrafiek rechts-boven zorgt ervoor dat het toch nog duidelijk is waar we ons in het volledige spreidingsdiagrambevinden. Er is ook een uitzoomknop verschenen die ervoor zorgt dat we terug naar de originelegrafiek gaan.

Function name VListInteraction

EIP 0x408420

Source interactions.c:362

Calls 1,340

Instruction count 20,433,930

Core elapsed time 3,872,130 ns

Nonidle elapsed time 3,872,130 ns

Add/Sub FP ops 3,111,480

Mul/Div FP ops 3,324,540

L3 cache misses 16

CPI 0.504

Optimizations Optimization Speedup

NonFP x1.255

TLP x1.164

ILP x1.111

Vectorization x1.062

Branch x1.050

Memory x1.001

PercentOfDataUtilized x1.001

Function Info

2%

41%

30%

31%

34%

31%

2%

Figuur 7.5: Functie-info-overzicht. Deze sectie toont informatie over de functies. Er kan wordengenavigeerd door de functies door gebruik te maken van de pijltjes. Naast de eigenschappenstaat een bar die weergeeft hoeveel procent van het totaal deze functie van deze eigenschapgebruikt. Er is ook een CPI-bar voorzien en onderaan worden suggesties voor optimalisatiegegeven.


7.6 Schaalbaarheid

7.6.1 Schaalbaarheid in ruimte


Omdat er nu weer extra opties werden toegevoegd aan Sniper om de functiegebaseerdestatistieken te bekomen, is het nuttig om te testen of de databank in grootte is toegeno-men. Er werd een experiment opgezet en de resultaten hiervan worden getoond in Figuur7.6. Het is duidelijk dat deze opties geen grote invloed hebben op de grootte van dedatabank.


De grootste ruimte wordt ingenomen door Doxygeninformatie (dit kan oplopen tot enkeletientallen MB). De JSON-bestanden die gegenereerd worden blijven echter zeer klein.Gemiddeld blijkt dit 7 kB per functie. De grootte van de statische HTML-bestandenblijft uiteraard constant. In de ruimte is er dus zeker plaats voor schaling. Het aantalpunten dat Flot kan renderen is verder ongelimiteerd, dus daar is ook geen bovengrens. Degebruiksvriendelijkheid zal uiteraard wel verminderen naarmate er meer en meer puntenop het spreidingsdiagram worden getoond.

7.6.2 Schaalbaarheid in tijd

Overhead voor de simulatietijd

De extra opties die aan Sniper worden meegegeven zorgen ervoor dat de simulatietijdgroter wordt. Om een zicht te krijgen op de overhead die hiermee gepaard gaat, werd eenexperiment opgezet en de resultaten hiervan worden getoond in Figuur 7.7.

Deze resultaten tonen aan dat er wel degelijk een overhead is. Deze overhead hangtaf van de gebruikte benchmark. Splash2-fmm bevat minder functies dan Splash2-barnesen kent dus een kleinere overhead. De verwachting is ook hier dat de overhead relatiefgezien zal dalen wanneer de simulatietijd stijgt.


Het genereren van de databestanden gebeurt in enkele seconden. Dit stelt dus niets voorin vergelijking met de simulatietijd.

7.7 Besluit

De visualisatie die functies voorstelt naargelang het aantal uitgevoerde instructies en degebruikte tijd kan nuttig zijn om de belangrijkste functies en de minst optimale functieste identificeren. Verder is deze visualisatie deel van een groter geheel van visualisatiesdie met elkaar verbonden zijn. Ook hier wordt een interactieve webgebaseerde interfaceaangeboden.

Hoewel er een overhead is bij het genereren van functiegebaseerde statistieken zal ditbij grote simulaties geen probleem vormen. De toename van de databankgrootte is miniem

7.7 Besluit 63

en het genereren van de databestanden kan in enkele seconden gebeuren. Schaalbaarheidis hier dus geen probleem.

10000

100000

1e+06

spla

sh2

-barn

es-

small-

2

spla

sh2

-barn

es-

test

-2

spla

sh2

-fm

m-s

mall-

2

spla

sh2

-fm

m-t

est

-2

spla

sh2

-barn

es-

small-

4

spla

sh2

-barn

es-

test

-4

spla

sh2

-fm

m-s

mall-

4

spla

sh2

-fm

m-t

est

-4

spla

sh2

-barn

es-

small-

8

spla

sh2

-barn

es-

test

-8

spla

sh2

-fm

m-t

est

-8

spla

sh2

-fm

m-s

mall-

8

spla

sh2

-barn

es-

small-

16

spla

sh2

-fm

m-t

est

-16

spla

sh2

-barn

es-

test

-16

spla

sh2

-fm

m-s

mall-

16

oorspronkelijke databankgrootte (bytes)databankgrootte met functiegebaseerde statistieken (bytes)

Figuur 7.6: Schaalbaarheid in de ruimte: vergelijking tussen de originele databank en de data-bank wanneer aan Sniper de instructietracer-opties worden meegegeven.

10

100

1000

10000

spla

sh2

-fm

m-t

est

-8

spla

sh2

-fm

m-t

est

-16

spla

sh2

-barn

es-

test

-16

spla

sh2

-fm

m-t

est

-4

spla

sh2

-barn

es-

test

-8

spla

sh2

-fm

m-t

est

-2

spla

sh2

-barn

es-

test

-4

spla

sh2

-barn

es-

test

-2

spla

sh2

-fm

m-s

mall-

16

spla

sh2

-barn

es-

small-

16

spla

sh2

-fm

m-s

mall-

8

spla

sh2

-barn

es-

small-

8

spla

sh2

-fm

m-s

mall-

4

spla

sh2

-barn

es-

small-

4

spla

sh2

-fm

m-s

mall-

2

spla

sh2

-barn

es-

small-

2

oorspronkelijke simulatietijd (s)simulatietijd met optie voor functiegebaseerde statistieken (s)

Figuur 7.7: Schaalbaarheid in de tijd: vergelijking tussen de originele simulatietijd en de simu-latietijd met de opties voor de functiegebaseerde statistieken.

ROOFLINE MODEL 65

Hoofdstuk 8

Roofline model

8.1 Inleiding

Het roofline model wordt geıntroduceerd in [23]. Het biedt inzichten in de manier waaropsoftware en hardware geoptimaliseerd kunnen worden. In het roofline model wordt deprestatie uitgedrukt in functie van de aritmetische intensiteit. Het principe is dat deprestatie ofwel begrensd wordt door het maximum aantal vlottende-kommabewerkingenofwel door de maximale geheugenbandbreedte. Deze twee grenzen kunnen gevisualiseerdworden als een ‘roofline’. Elke architectuur heeft zijn specifieke roofline. In [23] testmen de prestatie van bepaalde kernels. In dit hoofdstuk wordt de prestatie van functiesgevisualiseerd. Het roofline model verbindt de vlottende-kommaprestatie, de operationeleintensiteit en de geheugenprestatie en toont deze in een tweedimensionale grafiek.

Het roofline model zal verder nog gelinkt worden aan de automatische suggesties vooroptimalisatie, die aan bod komen in Hoofdstuk 9. Daar worden optimalisaties getoonddie het mogelijk zullen maken om hoger in het roofline model te geraken, om minderbandbreedtegelimiteerd te zijn of om het maximum aantal vlottende-kommabewerkingennaar boven te verplaatsen.

8.2 Implementatie

In deze visualisatie wordt ook gebruik gemaakt van de Flot JavaScriptbibliotheek, diereeds geıntroduceerd werd in Sectie 7.2. Het grootste verschil is dat er nu ook lijnenworden geplot. Verder is de dubbellogaritmische schaal nu met een logaritme basis 2 (inplaats van basis 10) , net zoals dit in [23] gebruikt wordt. De data die de Sniper simulatorteruggeeft, kan niet rechtstreeks gebruikt worden in het roofline model. Gegeven zijnhet aantal uitgevoerde vlottende-kommabewerkingen, de gebruikte tijd, het aantal geheu-gentoegangen en de configuratie van de architectuur. Voor de roofline zijn de maximalevlottende-kommaprestatie en de geheugenbandbreedtepiek gevraagd. Voor het plottenvan de functies zijn de operationele intensiteit en de vlottende-kommaprestatie nodig.

De workflow die deze implementatie hanteert is volkomen analoog aan de werkwijzedie geıllustreerd wordt in Figuur 7.1.

66 8.2 Implementatie

8.2.1 Berekenen van de maximale vlottende-kommaprestatie vande architectuur

De maximale vlottende-kommaprestatie wordt uitgedrukt in GFlops/s (109 Floating pointoperations per second). Het aantal vlottende-kommabewerkingen dat in een cyclus in eencore kan worden verwerkt, is het aantal poorten voor vlottende-kommabewerkingen diein de core aanwezig zijn. Dit kunnen er bijvoorbeeld twee zijn, een voor optelling enaftrekking en een voor vermenigvuldiging en deling.

maximale prestatie(GFlops/s) =#cores×#poorten× frequentie(GHz/s)

8.2.2 Berekenen van de geheugenbandbreedtepiek van de archi-tectuur

De geheugenbandbreedtepiek wordt uitgedrukt in GB/s en zal dus lineair stijgen vol-gens de operationele intensiteit (Flops/byte). Deze piek wordt berekend uit het aantalDRAM-controllers (Dynamic Random-Access Memory controllers) maal de bandbreedteper controller.

maximale bandbreedte(GB/s) =#controllers× bandbreedte per controller(GB/s)

8.2.3 Berekenen van de operationele intensiteit van een functie

De operationele intensiteit (Flops/byte) van een functie is het aantal vlottende komma-bewerkingen dat uitgevoerd wordt per byte die uit het DRAM-geheugen gehaald moetworden. Om het aantal bytes dat uit het DRAM-geheugen gehaald wordt te berekenen,wordt het aantal level 3 cachemissers gebruikt, aangezien die zullen leiden tot een DRAM-toegang. Er wordt dan een nieuwe cachelijn ingeladen. De operationele intensiteit van defunctie wordt dus als volgt berekend:

operationele intensiteit(Flops/byte) = #fpinstrcachelijngrootte(bytes)×#L3 cachemissers

De operationele intensiteit zal de x-waarde zijn van het punt in het roofline model datde functie voorstelt.

8.2.4 Berekenen van de vlottende-kommaprestatie van een func-tie

De vlottende-kommaprestatie (GFlops/s) is het aantal vlottende-kommabewerkingen datde functie heeft uitgevoerd in het tijdsinterval dat de functie nodig gehad heeft om uitte voeren. Deze waarde zal de y-waarde zijn van het punt in het roofline model dat dezefunctie voorstelt.

vlottende-kommaprestatie(GFlops/s) = #fpinstr/1e9tijd(s)

8.3 Visualisatie genereren 67


Deze visualisatie wordt samen met de andere visualisaties uit dit deel gegenereerd. Ditwordt uitgelegd in Sectie 7.3.

8.4 Resultaat

Het resultaat wordt getoond in Figuur 8.1. De functies worden geplot op een dubbel-logaritmische (basis 2) grafiek met als x-as de operationele intensiteit in Flops per byteen als y-as de behaalde vlottende-kommaprestatie in GFlops/s. Verder worden de tweelijnen getoond die de roofline zullen vormen: de maximale geheugenbandbreedte en demaximale vlottende-kommaprestatie. Een functie kan dus begrensd worden door een vandeze twee lijnen. Hoe kleiner de y-waarde, hoe meer ruimte voor optimalisatie er mogelijkis.

Naast de mogelijkheden van deze visualisatie die al beschreven werden in de analogevisualisatie in Secties 7.4.1 en 7.4.2 is het ook mogelijk om de roofline aan of af te vinken.Ook hier is weer alles gesynchroniseerd met de andere visualisaties.

functionspeak floating point performancepeak memory bandwidth

Logscale

Roofline

Roofline Model

0

1

2

4

8

16

0.01

0.02

0.03

0.06

0.13

0.25

0.5

0 1 2 4 8 16 32 64 128 256 5120.01 0.02 0.03 0.06 0.13 0.25 0.5 1,024 2,048 4,096 8,19216,384

16

16,384

Function InfoFiguur 8.1: Het roofline model. De functies worden geplot volgens hun operationele intensiteiten hun gebruikte geheugenbandbreedte. De functies worden ofwel begrensd door de maximalegeheugenbandbreedte of door de maximale vlottende-kommaprestatie. Het doel is om de functieszo hoog mogelijk in het roofline model te krijgen.

8.5 Praktisch nut

Het praktisch nut van het roofline model wordt uitvoerig beschreven in [23]. Wanneer mende prestatie van een functie wil analyseren kan men het roofline model gebruiken. Eeneerste vraag kan zijn of de functie begrensd is door de prestatie van het geheugen of doorde maximale vlottende-kommaprestatie. Verder kan worden vastgesteld hoe ver de functienog van dat maximum zit. Hoe verder, hoe meer optimalisatiemogelijkheid er nog is. Deze


optimalisaties kunnen bijvoorbeeld het reduceren van niet-vlottende-kommabewerkingen,het introduceren van TLP (Thread-Level Parallelism) of het introduceren van vectorisatiezijn.

Het doel is dat de functies zo weinig mogelijk gelimiteerd zijn door de geheugenband-breedte en dat ze zo dicht mogelijk bij de maximale vlottende-kommaprestatie geraken.Op die manier zal hun uitvoeringstijd, en de uitvoeringstijd van de volledige applicatie ge-reduceerd worden. Om de software-ontwikkelaar te helpen om dit doel te bereiken wordenin Hoofdstuk 9 optimalisaties voorgesteld.

8.6 Schaalbaarheid

De schaalbaarheid in tijd en ruimte werden reeds besproken in Sectie 7.6. Dezelfde scriptsen bestanden worden gebruikt, dus de schaalbaarheid is hier volledig analoog. De visuali-satie zelf blijft ook relatief schaalbaar. Er is uiteraard wel een grens voor de leesbaarheidvan het model wanneer er bijvoorbeeld duizend functies getoond moeten worden. Voorprogramma’s met dergelijk groot aantal functies kan het script aangepast worden omenkel functies te tonen met een ondergrens voor het aantal uitgevoerde instructies.


Een mogelijke verbetering aan dit model is het toevoegen van plafonds (‘ceilings’ uit [23]).Dergelijke plafonds zijn lijnen die onder (en parallel met) de maximale geheugenband-breedte en de maximale vlottende-kommaprestatie worden getoond. Ze stellen niveausvan optimalisaties voor. Om naar een bepaald niveau te gaan moeten de voorgaandeniveaus al geımplementeerd zijn. De top van de roofline kan enkel behaald worden wan-neer aan alle optimalisatieniveaus voldaan is. Een voorbeeld van een extra plafond is hetgebruik van vectorisatie, waardoor meer instructies per cyclus uitgevoerd kunnen worden.Dit model kan ook gelinkt worden aan de automatische suggesties voor optimalisatie diein Hoofdstuk 9 besproken worden.

Een andere verbetering kan zijn dat het model automatisch detecteert met welke soortinstructies het te maken heeft, en dan op gepaste wijze het roofline model aanpast aandie gegevens.

Een idee voor de visualisatie is dat de punten die de functies voorstellen een aange-paste grootte krijgen, naargelang hun belangrijkheid. De belangrijkheid van een functiekan bijvoorbeeld gemeten worden aan de hand van het aantal instructies dat de functieuitvoert.

8.8 Besluit

Het roofline model is een hulpmiddel om te detecteren of een functie begrensd is door debandbreedte van het geheugen of door de maximale rekencapaciteit. Het toont ook aanhoe ver een functie nog van dit maximum verwijderd is en bijgevolg hoeveel ruimte ernog is voor optimalisatie. De implementatie zorgt opnieuw voor interactie met de anderevisualisaties van dit deel. Vooral de link met de automatische suggesties voor optimalisatievan volgend hoofdstuk blijkt zeer nuttig omdat deze hints kunnen geven om betere scoresin het roofline model te behalen.

AUTOMATISCHE SUGGESTIES VOOR OPTIMALISATIE 69

Hoofdstuk 9

Automatische suggesties vooroptimalisatie

9.1 Inleiding

Als afsluitend hoofdstuk van dit derde deel worden de automatische suggesties voor opti-malisatie besproken. Sniper laat toe om voldoende statistieken over de functies te gene-reren dat het mogelijk wordt om optimalisaties voor deze functies voor te stellen.

Voor elke functie kunnen de naam, de plaats in de broncode, het aantal bits datuit het geheugen werd gehaald, het aantal instructies dat werd uitgevoerd, de uitvoe-ringstijd, het aantal cachemissers, CPI-componenten en uitgebreide statistieken over hetaantal vlottende-kommabewerkingen opgeslaan worden. Aan de hand van deze data kanberekend worden welke versnellingen nog nodig zijn en kunnen bijgevolg suggesties vooroptimalisaties voorgesteld worden.

Deze optimalisaties zullen het de software-ontwikkelaar mogelijk maken om de functieshoger in het roofline model (zie Hoofdstuk 8) te brengen. Het ‘unique selling point’ ishier opnieuw dat sommige statistieken enkel gegenereerd kunnen worden in een simulatorzoals Sniper, terwijl dit onmogelijk zou zijn op echte hardware.

Op het eerste zicht heeft dit weinig met visualisatie te maken, maar we kunnen ditmodel linken aan de vorige twee visualisaties en zo handig gebruik maken van de inter-activiteit tussen de drie modellen. Deze suggesties voor optimalisatie kunnen hints gevenaan de software-ontwikkelaar om de functies beter te laten scoren in het roofline modelen zo een efficientere implementatie te bekomen.

De automatische suggesties kunnen in drie groepen onderverdeeld worden:

– Suggesties die ervoor zorgen dat de functie minder bandbreedtegelimiteerd is (defunctie verschuift naar rechts in het roofline model).

– Suggesties die ervoor zorgen dat de functie dichter bij de maximale prestatie ligt(de functie verschuift naar boven in het roofline model).

– Suggesties die de maximale prestatie wijzigen (de maximale vlottende-komma-prestatie verschuift verticaal in het roofline model).

In Sectie 9.4 wordt gedetailleerd ingegaan op elke optimalisatiemodule en wordt de modulegelinkt aan een van bovenstaande groepen.

70 9.2 Aanverwant werk

9.2 Aanverwant werk

Hieronder worden enkele tools en methodologieen besproken die aanverwant zijn aan deautomatische suggesties voor optimalisatie die in dit hoofdstuk voorgesteld worden. Tel-kens probeert men om via gerichte tips de software-ontwikkelaar te helpen om parallellismete introduceren in zijn programma.

Kremlin Veel parallellisatietools verlagen de drempel om code te parallelliseren. Erwordt echter vaak over het hoofd gezien dat de belangrijkste vraag is welk deel van decode het meest baat zal hebben bij het parallelliseren. Kremlin [24] is een tool die tipsgeeft over de delen van de code waar het eerst aan gewerkt moet worden. Kremlin gebruikthiervoor een nieuwe vorm van hierarchische analyse van kritieke paden.

Algoritmische karakterisering Gewoonlijk zullen profilers identificeren waar een pro-gramma het meest tijd aan besteedt. Het is echter ook interessant om uit te zoekenwaarom het programma tijd verliest in sommige delen van de code of hoe de uitvoe-ringstijd varieert bij verschillende inputs van het programma. In [25] wordt algoritmischekarakterisering voorgesteld, waarbij gebruik gemaakt wordt van kostenfuncties die gecon-strueerd worden op basis van empirische kostenfuncties en het meten van de kost van hetprogramma bij een gegeven input.

Inputgevoelige karakterisering Meestal is het moeilijk bij klassieke profilers om be-paalde delen van de code te analyseren. Belangrijke algoritmische code moet geanalyseerdworden binnen de context van de applicatie waarin het gebruikt wordt.

Daarom wordt in [26] een nieuwe methodologie, inputgevoelige karakterisering, voorge-steld om ontwikkelaars te helpen om inefficienties in de code te identificeren. Inputgevoe-lige karakterisering gebeurt per functie en in functie van de input zodat de schaalbaarheidkan bepaald worden.

Kismet Kismet [27] is een tool die schattingen kan maken over de versnelling diemogelijk is door parallellisatie van seriele code. Ook hier wordt gebruik gemaakt vanhierarchische analyse van kritieke paden. Er wordt een model voor de uitvoeringstijdvan parallelle code gebruikt om een bovengrens voor de prestatie te berekenen, waarbijbeperkingen van zowel hardwareparameters als de structuur van de software in rekeninggebracht worden.

De doelstellingen en mogelijkheden van deze tool gelijken op deze van het rooflinemodel uit Hoofdstuk 8. Ook daar wordt aangetoond hoever (de functies uitgevoerd door)het programma van de maximale prestatie zit(ten).

9.3 Implementatie

De workflow van de implementatie wordt geıllustreerd in Figuur 9.1. De ingelezen infor-matie over de functies wordt doorgestuurd naar het ASO (Automatische Suggesties voorOptimalisaties) script. Deze roept de verschillende modules uit ASOmodules.py aan omzo de optimalisaties op te lijsten en in volgorde van belangrijkheid te zetten. Het is altijdde intentie geweest om alles zo modulair mogelijk te houden. De modulariteit zorgt ervoor

9.4 ASO-modules 71

dat er eenvoudig nieuwe modules kunnen toegepast worden. Het wordt zelfs mogelijk ommodules te combineren. Een optimalisatiemodule neemt telkens een functie als parameteren geeft diezelfde functie terug waarbij de optimalisatie werd toegepast. De optimalisatiewordt toegepast door bepaalde eigenschappen van die functie te wijzigen. Dit komt meergedetailleerd terug in de volgende secties. Na het ophalen en sorteren van de optimali-saties worden deze weggeschreven in JSON-bestanden die zoals in de andere visualisatiesvan dit werk worden gebruikt als inputdata voor de JavaScript- en HTML-bestanden.

FunctionParser

Applicatie

JSON-bestanden

Webpagina’s


FunctionBased

ASO

ASO-Modules

ILP

TLP

Branch

Mem

DataUtilized

Non-FP

Vectorization

Figuur 9.1: Automatische suggesties voor optimalisatie: workflow

9.4 ASO-modules

De ASO-modules vormen de kern van dit model. Ze nemen telkens een functie als ar-gument en geven diezelfde functie terug waarbij ze eigenschappen veranderen naargelangde optimalisatie die ze doorvoeren. Ze geven een idee van de tijdswinst die theoretischmogelijk is met een bepaalde optimalisatie. Er moet wel benadrukt worden dat dit slechtsbenaderingen zijn. Evenwel zorgen ze er voor dat de gebruiker een idee krijgt van de opti-malisaties die hem het meest tijdswinst kunnen opleveren. Het unieke aan deze modulesis dat ze deze schattingen enkel kunnen maken omdat we met een gesimuleerde omgevingwerken.

9.4.1 ILP-module

Instruction-Level Parallelism (ILP) is een maat voor het aantal instructies dat tegelijk uit-gevoerd kan worden. Operaties van een enkele draad kunnen hierdoor parallel uitgevoerdworden. Op architecturaal niveau kan ILP bereikt worden door pijplijnen en superscalari-teit. Er wordt dus meer dan een instructie per klokcyclus uitgevoerd. De ILP-module gaatervan uit dat, wanneer ILP ten volle benut wordt, de basis CPI-component op 1

pijplijnbreedte

gezet kan worden. Als de pijplijn vier instructies breed is dan kunnen er in een cyclusmaximaal vier instructies uitgevoerd worden. Een instructie duurt dus 0.25 cycli. DeILP-module geeft de functie terug waarbij de tijd die in de basis CPI-component zit,

72 9.4 ASO-modules

wordt teruggebracht tot een equivalent van een CPI van 0.25.

nieuwe cpiBase = #instructies×klokperiode4

De ILP-module brengt een functie dichter bij de maximale vlottende-kommaprestatiein het roofline model.

9.4.2 TLP-module

Bij Thread-Level Parallelism (TLP) worden instructies van verschillende draden paralleluitgevoerd. De TLP-module gebruikt de wet van Amdahl voor parallelle berekeningenom te bepalen wat de maximale versnelling is die behaald kan worden door TLP. Dezewet toont aan dat de versnelling door parallellisatie begrensd is door het sequentiele deelvan een programma. In deze module worden enkele vereenvoudigde veronderstellingengebruikt. Een eerste aanname is dat gedurende 5% van de uitvoeringstijd, de code nietparallelliseerbaar is. Een tweede vereenvoudiging in dit model is dat het aantal cores hetaantal draden voorstelt. De functie die gegeven wordt aan de TLP-module zal bijgevolgals volgt aangepast worden:

nieuwe tijd = 0.95×huidige tijd#cores

+ 0.05× huidige tijd

Een verbetering aan deze module zou een automatische detectie van het sequentieledeel van de code kunnen zijn om zo nog een preciezere schatting te kunnen maken. Eenandere verbetering is het toepassen van een optimalisatie van de wet van Amdahl dievoorgesteld wordt in [28]. De optimalisatie die voorgesteld wordt, is het toevoegen vande notie kritieke secties aan de originele wet van Amdahl omdat parallelle prestatie nietalleen gelimiteerd is door sequentiele code, maar ook door synchronisatie vanwege kritiekesecties.

De TLP-module verhoogt de maximale vlottende-kommaprestatie in het roofline mo-del.

9.4.3 Sprongvoorspellermodule

In deze module wordt de kost van de spronginstructies verwijderd. Sprongen zijn duurals ze leiden tot een misser in de sprongvoorspeller. In de statistieken die de simulatorteruggeeft kunnen we voor elke functie zien hoeveel tijd er verloren gegaan is aan despronginstructies. De CPI-component ten gevolge van foutief voorspelde sprongen wordtin deze component dus eenvoudigweg op nul gezet.

nieuwe cpiSprongV oorspeller = 0

Tot de technieken die het aantal spronginstructies kan reduceren behoort bijvoorbeeldhet concept van lusontvouwing. De sprongvoorspellermodule brengt de functie dichter bijde maximale vlottende-kommaprestatie in het roofline model.

9.4 ASO-modules 73

9.4.4 Percentage van gebruikt geheugen module

Toegangen tot het DRAM-geheugen zijn zeer duur, dus moeten ze zo zuinig mogelijkgebruikt worden. In de functiestatistieken die de simulator teruggeeft zijn er twee veldendie enerzijds tonen hoeveel data er uit het geheugen gehaald is, en anderzijds hoeveel dataer effectief gebruikt is. Bij een efficiente implementatie zouden deze twee aantallen uiter-aard gelijk moeten zijn. Een voorbeeld van een techniek die de efficientie kan bevorderenis de ‘AOS to SOA’- (Array of Structures to Structures of Arrays) techniek. Stel datwe een C-programma hebben met structuren die naast enkele eigenschappen ook telkenseen x-coordinaat bevatten. Als bewerkingen op alle x-coordinaten van de verschillendestructuren uitgevoerd worden, zal dit ertoe leiden dat er veel geheugenblokken ingeladenmoeten worden (bijvoorbeeld een per structuur). Als de structuren nu op een dergelijkemanier opslagen worden zodat elke eigenschap (bijvoorbeeld alle x-coordinaten van allestructuren) in een geheugenblok past, door ze bijvoorbeeld in een array te plaatsen, dankan voorgaande bewerking uitgevoerd worden door enkel dit geheugenblok in te laden.

Deze module toont aan hoeveel tijdswinst er gemaakt kan worden indien de data ef-ficient gebruikt wordt. Dit zal zich vertalen in volgende aanpassing aan de gegeven functie:

nieuwe cpiMem =bits gebruikt

bits totaal× oude cpiMem

nieuwe tijd = oude tijd− (oude cpiMem− nieuwe cpiMem)

Deze module zorgt ervoor dat de functie minder bandbreedtegelimiteerd is in hetroofline model.

9.4.5 Vectorisatiemodule

De vectorisatiemodule is de meest complexe module. Bij vectorisatie wordt een instructieop meerdere data-elementen uitgevoerd in een cyclus (SIMD, Single Instruction MultipleData). SIMD werd toegevoegd aan de Intel-architectuur in de vorm van SSE2-instructies(streaming SIMD extensions). De instructieset werd hierbij uitgebreid met een aantal 128-bit registers (XMM registers). Als illustratie wordt het voorbeeld van vermenigvuldiginggegeven:

– Terwijl een vermenigvuldiging in enkelvoudige precisie (32 bit, MULSS) een klok-cyclus nodig heeft, kunnen er vier 32-bit data-elementen verwerkt worden door de‘packed’ (gevectoriseerde) vermenigvuldiging (MULPS) in een cyclus.

– Terwijl een vermenigvuldiging in dubbele precisie (64 bit, MULSD) een klokcyclusnodig heeft, kunnen er twee 64-bit data-elementen verwerkt worden door de ‘packed’(gevectoriseerde) vermenigvuldiging (MULPD) in een cyclus.

– De vermenigvuldigingen die al gevectoriseerd zijn (MULPS en MULPD) kunnenniet verder worden gevectoriseerd.

– De niet-vlottende-kommabewerkingen kunnen evenmin worden gevectoriseerd.

De ADD-, SUB- en DIV-instructies zijn analoog. Verder moet er ook nog rekening gehou-den worden met de poorten. Als er bijvoorbeeld een poort is voor ADD/SUB-instructies,en een poort voor MUL/DIV-instructies, dan kunnen een ADD/SUB-instructie en eenMUL/DIV-instructie tegelijk worden uitgevoerd. Er moet dus een onderscheid gemaaktworden tussen het geval waar alleen instructies van het ene type voorkomen, en het gevalwaar ze allebei voorkomen.

74 9.4 ASO-modules

Deze module is mogelijk omdat de statistieken van de gegeven functie data bevat overde aantallen van de verschillende soorten instructies.

De aanpassingen die door deze module aan de functie worden gemaakt gaan dus alsvolgt:

nieuwe tijd = 0

#Reeds gevectoriseerd en dubbele precisie

nieuwe tijd +=cpiBasePD

beschikbare poorten

#Vectorisatie: SD → PD

nieuwe tijd +=cpiBaseSD

2× beschikbare poorten

#Reeds gevectoriseerd en enkelvoudige precisie

nieuwe tijd +=cpiBasePS

beschikbare poorten

#Vectorisatie: SS → PS

nieuwe tijd +=cpiBaseSS

4× beschikbare poorten

#Niet-floating point operaties

nieuwe tijd += cpiBaseNonFP

nieuwe cpiBase = nieuwe tijd

#De andere cpi-componenten toevoegen

nieuwe tijd += cpiMem + cpiSprong + cpiOther

De vectorisatiemodule verhoogt de maximale vlottende-kommaprestatie in het rooflinemodel.

9.4.6 Verwijderen van niet-vlottende-komma-instructies

Als je aan de top van het roofline model wil geraken, dan mogen geen niet-vlottende-komma-instructies meer aanwezig zijn. Hoewel dit uiteraard in de praktijk quasi onmo-gelijk zal zijn, kan deze module toch aantonen welke versnelling er mogelijk is wanneerdeze niet-vlottende-komma-instructies niet meer uitgevoerd zouden worden. Het kan desoftware-ontwikkelaar aanmoedigen om op dat vlak na te denken hoe hij zijn code kanoptimaliseren.

#instructies −= #niet fp instructies

tijd −= niet fp tijd

cpiBase −= niet fp fractie× cpiBase

cpiMem −= niet fp fractie× cpiMem

cpiSprongV oorspeller −= niet fp fractie× cpiSprongV oorspeller

Deze module brengt een functie hoger in het roofline model.

9.5 Visualisatie genereren 75

9.4.7 Geheugenmodule

De geheugenmodule is analoog aan de sprongvoorspellermodule uit Sectie 9.4.3 in diezin dat ze ook een CPI-waarde op nul zal zetten. Hier gaat het om de geheugencpi-component. In de praktijk kunnen toegangen naar de LLC (Last-Level Caches) en hetDRAM-geheugen vermeden worden door bijvoorbeeld een techniek zoals cache blockingte hanteren. Het idee hierbij is dat data verschillende malen kan gebruikt worden terwijlhet aanwezig blijft in de caches. Dit kan bijvoorbeeld door het doordacht opsplitsen vanlussen in de bron.

nieuwe cpiMem = 0

Deze module zorgt ervoor dat de functie minder bandbreedtegelimiteerd is in hetroofline model.


De visualisatie genereren gebeurt samen met de andere visualisaties uit dit deel. De uitleghiervan wordt vermeld in Sectie 7.3.

9.6 Resultaat

De resultaten worden getoond in Figuren 9.2, 9.3 en 9.4. De verschillende rankings wordenin verschillende tabbladen getoond. Het principe is telkens hetzelfde. De optimalisatie diede grootste tijdswinst geeft over het gehele programma zal bovenaan staan. Per optimali-satie wordt de applicatieversnelling die de optimalisatie kan teweegbrengen gevisualiseerdin een staafgrafiek. De lengte van de staaf hangt af van de grootte van de versnelling.Op die manier is het snel duidelijk voor de gebruiker wat de verhoudingen in versnellingtussen de verschillende optimalisaties zijn.

Er wordt opnieuw met kleuren gewerkt. Elke optimalisatie krijgt een bepaalde kleur.Deze kleur zal ook in de andere tabbladen gebruikt worden.

Wanneer de gebruiker meer details wenst, kan hij zweven over de staaf die naast eenbepaalde optimalisatie staat. Er werd gekozen voor een tooltip-oplossing om zo niet teveeltekst te moeten tonen, maar ook geen informatie te verliezen.

Ook hier wordt weer gezorgd voor een interactie met de andere visualisaties van ditdeel. Wanneer er op de naam van een functie geklikt wordt, dan wordt deze functiegeselecteerd in de andere visualisaties. Aan de rechterkant bij de eigenschappen staanook enkele icoontjes die verwijzen naar de andere visualisaties. Van links naar rechts zijndit links naar het instructies-versus-tijd model, het roofline model, de functie-info-sectieen eventueel Doxygeninformatie.

Er zijn drie soorten tabbladen:

– Een algemeen optimalisatietabbladDit toont hoe elke optimalisatie afzonderlijk de meeste tijdswinst kan opleveren.

– Een gecombineerd optimalisatietabbladDit toont wanneer de optimalisaties gecombineerd worden, welke functie er dan debeste optimalisatie kent.

76 9.6 Resultaat

– Tabbladen voor de verschillende optimalisaties apartPer optimalisatie wordt een ranking getoond met de functies die het meest baathebben bij deze optimalisatie.

Doordat er vaak afkortingen gebruikt moeten worden wegens de beperkte plaats, krijgtde gebruiker de volledige naam te zien telkens wanneer hij met zijn muis zweeft over deelementen zoals de naam van een optimalisatie of een icoontje. Dit is een principe datvoor alle visualisaties van dit deel toegepast werd om het gebruiksgemak te verhogen.

9.6.1 Optimalisaties: algemeen

Dit tabblad wordt getoond in Figuur 9.2. Een top-10 lijst wordt getoond met de verschil-lende functies. Daarnaast staat de optimalisatie vermeld. Het is mogelijk, zoals in defiguur, dat functies meerdere malen voorkomen. Wanneer de visualisatie net geladen is,zal standaard de eerste functie uit deze lijst gebruikt worden om de functie-infosectie teladen.


Top 10 overall optimizations


speedup

#1 VListInteraction NonFP x1.255

#2 VListInteraction TLP x1.164

#3 VListInteraction ILP x1.111

#4 UListInteraction ILP x1.095

#5 UListInteraction TLP x1.087

#6 XListInteraction ILP x1.082

#7 UListInteraction NonFP x1.081

#8 XListInteraction NonFP x1.070

#9 XListInteraction TLP x1.069

#10 WListInteraction NonFP x1.067



Figuur 9.2: Automatische suggesties voor optimalisaties: een top tien van mogelijke optimali-saties. Naast de naam van de functie staat de voorgestelde optimalisatie met daarbij een staafdie de grootte van de versnelling voorstelt.

9.6.2 Optimalisaties: gecombineerd

Zoals vermeld in Sectie 9.3 is het door de sterk modulaire opbouw van dit model mogelijkom eenvoudig de modules te combineren. Hoewel dit syntactisch wel eenvoudig is, is hetsemantisch minder triviaal. Hoeveel zin heeft het om deze optimalisaties gecombineerdweer te geven? Zoals te zien valt in Secties 9.4.4 en 9.4.7 kunnen modules elkaar over-lappen. Net daarom is er ook voor gekozen om de modules apart weer te geven zoals inSectie 9.6.1. Maar is het combineren van deze modules dan helemaal zinloos? Nee. Als


software-ontwikkelaar kan het handig zijn om bijvoorbeeld twee optimalisaties in een doorte voeren, bijvoorbeeld de twee optimalisaties die samen de grootste tijdswinst opleveren.

Voor de visualisatie hiervan wordt in de kolom ‘Optimalisatie’ een horizontale gesta-pelde staafgrafiek getoond. Deze toont hoeveel procent elke optimalisatie heeft bijgedra-gen tot het totaal. Omdat de plaats beperkt is, werd ervoor gekozen om de gebruikerte laten zweven over een bepaalde kleur om de naam van de optimalisatie te zien. Desoftware-ontwikkelaar kan dus bijvoorbeeld kijken welke twee optimalisaties samen hetgrootste aandeel opleveren en ernaar streven om op dat gebied efficientere code te produ-ceren. Een voorbeeld wordt getoond in Figuur 9.3.

9.6.3 Optimalisaties: per module

Uiteraard is het ook nuttig om een lijst te hebben per optimalisatiemodule. Dit wordtweergegeven in Figuur 9.4 voor de ILP-module. Merk op dat de kleuren voor de opti-malisatiemodules consistent blijven over de verschillende tabbladen in het kader van hetgebruiksgemak.

9.7 Praktisch nut

Het praktisch nut van dit ASO-model is al bewezen in voorgaande secties. Hoewel ditschattingen blijven doordat er bepaalde veronderstellingen worden gedaan, kunnen ze ze-ker aantonen in welke richting er gezocht moet worden naar optimalisaties. Aan sommigeoptimalisaties had de gebruiker in eerste instantie misschien zelfs niet gedacht, dus in diezin is dit model zeker een nuttig hulpmiddel.

Het praktisch nut werd ook bewezen door de link te leggen naar het roofline modelvan vorig hoofdstuk. Sommige optimalisaties zorgen ervoor dat de functies hoger in hetroofline model geraken. Anderen zorgen ervoor dat de functies minder gelimiteerd zijndoor de maximale bandbreedte. Een derde groep zal ervoor zorgen dat de maximalevlottende-kommaprestatie verhoogd wordt.

9.8 Schaalbaarheid

De schaalbaarheid van dit model verschilt niet met de schaalbaarheid die reeds besprokenwerd in de vorige twee hoofdstukken, in Secties 7.6 en 8.6. De tijd en ruimte die nodigzijn, schalen lineair in functie van het aantal nuttige functies (alleen functies die meerdan een instructie hebben uitgevoerd worden in beschouwing genomen). Verder is hetaantal ASO-modules uiteraard ook een factor die meespeelt, al zullen die nooit zeer sterkoplopen. Ook hier geldt dus het principe dat in voorgaande hoofdstukken al naar voorkwam: de simulatietijd is vele grootte-orden groter dan de tijd die nodig is om de scriptsuit te voeren. Verder is de visualisatie op zich ook schaalbaar, want het aantal functiesdat in de ranking getoond wordt, blijft constant.



Top 10 combined optimizations


speedup










#10 ldexp x1.011



Figuur 9.3: Automatische suggesties voor optimalisaties: een top tien van mogelijke gecombi-neerde optimalisaties.


Top 10 ILP optimizations

Use InstructionLevel Parallellism to speed up the application.

Function Application

speedup










#10 AdjacentBoxes x1.002



Figuur 9.4: Automatische suggesties voor optimalisaties: een top tien van mogelijke ILP-optimalisaties.

9.9 Mogelijke verbeteringen 79


9.9.1 Nieuwe modules en verfijnen van huidige modules

Dit model is zeker niet volledig afgewerkt. De strategie is altijd geweest om eenvoudigte beginnen, maar steeds een modulaire opbouw te hanteren. Dit heeft geleid tot enkelemodules, waarvan de een al nauwkeuriger werkt dan de ander. Maar een belangrijkaspect is dat het zeer eenvoudig is om de modules nog verder te verfijnen en modulestoe te voegen. Gedurende de loop van dit project werd de simulator aangepast waardoorsommige modules mogelijk werden. In de toekomst zal dit ook nog het geval zijn en ditzal leiden tot nieuwe modules of aanpassingen aan huidige modules.

Een mogelijke nieuwe module kan bijvoorbeeld een MLP- (Memory-Level Parallelism)module zijn.

9.9.2 Combineren van modules

Verder is er zeker nog ruimte voor verbetering aan het combineren van modules. Nuworden alle modules gecombineerd, maar zoals al vermeld in 9.6.2 zal dit niet altijd zinvolzijn. Het zou mogelijk moeten zijn dat de gebruiker zelf twee modules kan kiezen en dater vervolgens on-the-fly berekend wordt wat de prestatiewinst zou zijn.

9.9.3 Visualisatie

Enkele ideeen voor nieuwe mogelijkheden zijn:

– De gebruiker laten kiezen hoe lang de optimalisatielijst is. Dit is voorlopig beperkttot 10 items.

– Zoeken naar functies op bijvoorbeeld hun naam.– De gebruiker zelf laten kiezen welke optimalisaties er getoond worden en welke niet.

9.10 Besluit

Dit afsluitende hoofdstuk van Deel III is nogal verschillend van de voorgaande hoofd-stukken in de zin dat de focus hier minder lag op de visualisatie. De nadruk lag op deoptimalisatiemodules die de eigenschappen van een functie wijzigen om zo een mogelijkeapplicatieversnelling te kunnen berekenen. De gebruiker krijgt bijgevolg verschillende lijs-ten te zien waardoor hij een idee krijgt van de functies waarin de grootste optimalisatieste behalen zijn. Enerzijds wordt het duidelijk welke functie de grootste applicatiever-snelling kan teweegbrengen, anderzijds wordt ook gesuggereerd met welke vormen vanoptimalisatie dit het best kan behaald worden.

Door de sterk modulaire opbouw werd in dit model de focus gelegd op uitbreidbaarheiden mogelijkheid tot combineren van modules. Er is ook weer een sterke interactie voorzienmet de andere visualisaties, wat ervoor zorgt dat alle modellen in dit deel een interagerendgeheel vormen.

Het werk in dit hoofdstuk is uniek omdat het data gebruikt uit de simulator die enkelbeschikbaar zijn net omdat we in een gesimuleerde omgeving werken. Sommige metriekendie hier gebruikt worden zijn onmogelijk te meten op echte hardware.

81

Deel IV

Besluit

BESLUIT 83

Hoofdstuk 10

Besluit

Software- en hardware-ontwikkelaars willen applicaties kunnen draaien op gesimuleerdehardware om de software en hardware hiervoor te optimaliseren. Hiervoor kan men demulti-coresimulator Sniper gebruiken. De stap tussen het genereren van statistieken enhet kunnen interpreteren van deze informatie is echter groot. Dit werk levert een bijdrageaan het invullen van deze stap. Dankzij de diverse visualisaties kunnen zowel hardware-en software-ontwikkelaars meer halen uit de informatie die door Sniper beschikbaar wordtgesteld.

De hardware-ontwikkelaar kan met behulp van de tijdsgebaseerde visualisaties zienhoe een gegeven applicatie uitgevoerd wordt op de hardware die door hem geconfigureerdwerd. Daarbij wordt in detail getoond welke hardwarecomponenten voor een vertragingzorgen.

De software-ontwikkelaar zal eerder geneigd zijn om te werken met de functiegeba-seerde visualisaties. In eerste instantie wordt de gegeven informatie gepresenteerd. Erwerd echter verder gegaan door automatische suggesties voor optimalisaties te genereren.Deze kunnen hem hints geven over welke functies er het best geoptimaliseerd kunnenworden en welke optimalisaties het meest tijdswinst zullen opleveren.

Naast de eigenschappen van de verschillende visualisaties werd ook telkens een schaal-baarheidstest uitgevoerd. Hoewel de opslagruimte voor de data die Sniper genereert aan-zienlijk toeneemt, zal dit in de praktijk geen probleem vormen. In de implementatie werdervoor gezorgd dat de database niet oneindig groot wordt. De tijd die nodig is om de dataen de visualisaties te genereren is verwaarloosbaar in vergelijking met de simulatietijd,zeker als die zeer groot wordt.

In dit werk werd telkens gekozen voor een webgebaseerde en open-source oplossing.De vele voordelen hiervan zoals portabiliteit, scheiding van data en presentatie, eenvoudenzovoort zijn uitgebreid aan bod gekomen.

Figuur 10.1 toont een synthese van waar dit werk toe bijgedragen heeft.

84 BESLUITBesluit

27

Verloop van programma

tijdens uitvoering? Vermogenverbruik?

Invloed van

architectuur op

prestatie?

Bottlenecks? Suggesties voor

optimalisatie?

Applicatie Hardware-

ontwikkelaars

Software-

ontwikkelaars

Cycle stacks

in functie

van de tijd

McPAT in

functie

van de tijd

3D-visualisatie

van tijd-cores-

IPC

Functies:

instructies

versus tijd

Roofline model

Automatische

suggesties voor

optimalisatie

Figuur 10.1: Synthese van dit werk. Hardware- en software-ontwikkelaars willen bepaalde vragenkunnen beantwoorden die handelen over software die ze uitvoeren op gesimuleerde hardware. Zekunnen hun simulatie uitvoeren op Sniper. De gegenereerde resultaten zullen de input vormenvoor verschillende visualisaties die op hun beurt de opgestelde vragen kunnen beantwoorden.

TOEKOMSTIG WERK 85

Hoofdstuk 11

Toekomstig werk

In de loop van dit werk is gebleken dat er nog verschillende verbeteringen aan de huidige encompleet nieuwe visualisaties mogelijk zijn. De verbeteringen aan de huidige visualisatieswerden reeds besproken in de respectievelijke hoofdstukken. In dit hoofdstuk wordenenkele nieuwe ideeen besproken die kunnen dienen als vervolg van deze thesis.

11.1 Visualisatie van communicatie

Er kan communicatie tussen processorkernen bestaan. Een idee voor een visualisatiehiervan is het gebruik van een topologie waarin de verbindingen naar de caches dikkerworden, of een andere kleur krijgen, naarmate er een grotere bandbreedte gebruikt wordt.Op die manier kunnen bottlenecks geıdentificeerd worden en kan er eventueel een anderehardware-configuratie gebruikt worden.

Communicatie kan ook gevisualiseerd worden zoals voorgesteld in Deel I, Figuur 2.4.

11.2 Visualisatie van meerdere nodes

De visualisaties in dit werk handelden telkens over een enkele node, waarin verschillendeprocessorkernen zitten. Een logische uitbreiding hierop is dat ook de verschillende no-des van bijvoorbeeld een supercomputer gevisualiseerd worden. Een voorbeeld van eentop-down aanpak zou kunnen zijn dat de gebruiker in eerste instantie een globaal beeldkrijgt van de hele supercomputer. Daarna kan hij doorklikken of inzoomen naar een be-paalde node, waarin dan de visualisaties gebruikt kunnen worden die in dit werk werdenvoorgesteld.

Verschillende technieken die aangehaald werden, kunnen ook op dit hoger niveau (opniveau van verschillende nodes) gebruikt worden. Een model dat voor elke node hetenergieverbruik toont of het gedrag van de verschillende nodes doorheen de loop vaneen werklastprogramma weergeeft, behoort zeker tot de mogelijkheden. Visualisatie vancommunicatie, aangehaald in de vorige Sectie 11.1, is ook op node-niveau denkbaar.

Een idee voor het visualiseren van meerdere nodes is het volgende. Er kan een 3D-model gemaakt worden waarin de verschillende nodes gevisualiseerd zijn. Elke node wordtweergegeven door een kubus in de driedimensionale ruimte. Elke kubus heeft een bepaaldekleur die bijvoorbeeld de belasting op die node weergeeft. Hoe meer communicatie ertussen twee nodes is, hoe dikker (of we kunnen werken met een kleurschaal) de verbinding.

86 11.3 Visualisatie van meerdere draden

Ook de tijdsdimensie kan aan dit model toegevoegd worden, zodat er als het ware eenfilm ontstaat over het verloop van een werklastprogramma in de supercomputer. Als ergeklikt wordt op een bepaalde node kunnen de visualisaties per node tevoorschijn komen.

11.3 Visualisatie van meerdere draden

Er kan niet alleen op een hoger niveau gewerkt worden, ook op een lager niveau zijnuitbreidingen mogelijk. De verschillende draden die parallel kunnen lopen op een pro-cessorkern kunnen ook apart gevisualiseerd worden. De visualisatie van communicatie,besproken in Sectie 11.1, kan ook toegepast worden op dit niveau. Zo kan het interessantzijn om te visualiseren hoe de verschillende draden op elkaar wachten.

Voorbeelden van visualisaties waarbij draden met elkaar interageren werden reedsgetoond in Deel I in Figuren 2.9 en 2.12.

11.4 Visualisatie van functie-oproepen

In het deel over de functiegebaseerde visualisaties is er geen visualisatie van een functie-oproepgrafiek. Een dergelijke grafiek, doorgaans voorgesteld als een graaf, start vanuitde hoofdfunctie waaruit pijlen vertrekken naar de opgeroepen functies waaruit dan weerpijlen getrokken worden tot we op het bladniveau zitten. Dergelijke voorstelling kan zekernuttig zijn als toevoeging aan de bestaande visualisaties omdat het opnieuw een anderzicht geeft op de uitvoering van de applicatie.

Gprof2Dot Een interessante visualisatie in dit kader is Gprof2Dot [29]. Deze toolgenereert een visualisatie van functie-oproepen waarbij elke functie een bepaalde kleurkrijgt toegewezen, volgens het percentage van de tijd van uitvoering. Logischerwijs zullenalle functies als (on)rechtstreekse ouder de hoofdfunctie hebben. Deze wordt in het roodweergegeven omdat 100% van de tijd functies worden uitgevoerd die afstammen van dezefunctie. Functies die minder tijd in beslag nemen, krijgen een kleur van groen tot blauw.Een voorbeeld wordt getoond in Figuur 11.1.

De data die deze tool als input neemt, was oorspronkelijk de output van de Gprofprofiler [30]. Tegenwoordig kan Gprof2Dot de output van meerdere profilers visualiseren.Alle data die nodig is voor deze tool is reeds beschikbaar in de output van de simulator,dus deze visualisatie kan zeker gemaakt worden aan de hand van de gegenereerde data.Aangezien er zelfs veel meer informatie beschikbaar is, kan deze visualisatie ook uitgebreidworden. De kleuren kunnen bijvoorbeeld CPI-waarden aangeven. Klikken op een bepaaldefunctie kan dan resulteren in de interactie met de andere visualisaties die voorgesteldwerden in Deel III.

11.4 Visualisatie van functie-oproepen 87

Figuur 11.1: Voorbeeld van een visualisatie van functie-oproepen, gegenereerd door GProf2dot[30]. Bron: [31]

Figuur 11.2: 2D-prefixboom gegenereerd door STAT (Stack Trace Analysis Tool) [32]. Deknopen stellen functies voor en de gerichte bogen tonen de oproepsequenties en worden gelabelddoor de set van taken die dit oproeppad volgt. Bron: [33]

88 11.5 Clusteren van cores

STAT Een andere tool waar functie-oproepen gevisualiseerd worden is STAT (StackTrace Analysis Tool) [32, 33]. Zelfs de meest geavanceerde debuggers kunnen niet omgaanmet de schaal van de snelste supercomputers van vandaag. Om een oplossing hiervoor tebieden, werd STAT ontwikkeld. STAT kan groepen van processen in een parallelle appli-catie die een gelijkaardig gedrag vertonen, identificeren. Elk van deze types processen kandan onderzocht worden door een uitgebreide debugger die een meer diepgaande analysekan bieden.

De tool kan onder andere spatiale en spatiaal-temporele grafen maken. De grafenstellen het oproepgedrag van de processen voor in een prefixboom. In Figuur 11.2 wordteen 2D-prefixboom getoond die een momentopname van de volledige applicatie voorstelt.De knopen stellen functies voor en de gerichte bogen tonen de oproepsequenties en wordengelabeld door de set van taken die dit oproeppad volgt. Nodes die dezelfde set van takenverwerken krijgen dezelfde kleur. Op die manier wordt het snel visueel duidelijk wat deverschillende equivalentieklassen zijn.

De ideeen van Gprof2Dot en STAT, samen met de statistieken die Sniper kan genere-ren, kunnen als startpunt dienen voor verder onderzoek naar functiegebaseerde visualisa-ties van uitvoeringen van parallelle programma’s op gesimuleerde many-coresystemen.

11.5 Clusteren van cores

Het is denkbaar dat, als er een groot aantal cores in een node zitten, de cores verdeeldkunnen worden in een aantal groepen volgens hun gedrag of energieverbruik. Om dit terealiseren kunnen verschillende clusteringstechnieken gebruikt worden. Een mogelijkheidis om hierarchisch te gaan clusteren en deze hierarchie rechtstreeks over te nemen in devisualisatie.

Het opdelen in equivalentieklassen van processen die hetzelfde gedrag vertonen, werdook al aangehaald in Sectie 11.4 bij de bespreking van STAT.

11.6 Gebruik van machinaal leren en data mining

technieken

In Hoofdstuk 9 werden met behulp van de gegeven data automatische suggesties voor opti-malisatie gegenereerd. Maar er kan nog verder gegaan worden. Aan de hand van technie-ken uit het domein van machinaal leren en data mining kan de data die Sniper genereertnog verder geanalyseerd worden. Abnormaal of ongewenst gedrag kan zo geıdentificeerden aangeduid worden in de visualisaties.

11.7 Visualisatie van meerdere uitvoeringen

Wanneer de gebruiker van Sniper verschillende versies heeft van de hardware-opstelling ofvan de software, dan zou het handig zijn om een visualisatie te hebben die de verschillendeuitvoeringen met elkaar vergelijkt. Momenteel is het uiteraard mogelijk om verschillendeuitvoeringen in verschillende browservensters weer te geven, maar een geıntegreerde op-lossing zou zeker beter zijn.

REFERENTIES 89

Referenties

[1] TOP500.Org, “Top500 Supercomputers.” http://www.top500.org/, may 2013.

[2] W. Heirman, T. Carlson, S. Sarkar, P. Ghysels, W. Vanroose, and L. Eeckhout,“Using fast and accurate simulation to explore hardware/software trade-offs in themulti-core era,” in Parco 2011, Proceedings, p. 8, 2011.

[3] T. E. Carlson, W. Heirman, and L. Eeckhout, “Sniper: Exploring the level of abstrac-tion for scalable and accurate parallel multi-core simulations,” in International Con-ference for High Performance Computing, Networking, Storage and Analysis (SC),nov 2011.

[4] T. E. Carlson, W. Heirman, K. V. Craeynest, L. Eeckhout, and I. Hur, “The SniperMulti-Core Simulator.” http://snipersim.org/, apr 2013.

[5] GWT-TUD GmbH - Organisation for Transfer of Knowledge and Technology of theTU Dresden, “VAMPIR, performance optimization.” http://vampir.eu, oct 2012.

[6] W. E. Nagel, A. Arnold, M. Weber, H.-C. Hoppe, and K. Solchenbach, “VAMPIR:Visualization and analysis of MPI resources,” Supercomputer, vol. 12, pp. 69–80,1996.

[7] V. Pillet, V. Pillet, J. Labarta, T. Cortes, T. Cortes, S. Girona, S. Girona, andD. D. D. Computadors, “Paraver: A tool to visualize and analyze parallel code,”tech. rep., In WoTUG-18, 1995.

[8] B. S. Center, “Paraver: a flexible performance analysis tool.” http://www.bsc.es/

computer-sciences/performance-tools/paraver, okt 2012.

[9] J. E. Gottschlich, M. P. Herlihy, G. A. Pokam, and J. G. Siek, “Visualizing transac-tional memory,” in Proceedings of the 21st international conference on Parallel archi-tectures and compilation techniques, PACT ’12, (New York, NY, USA), pp. 159–170,ACM, 2012.

[10] L. Adhianto, S. Banerjee, M. Fagan, M. Krentel, G. Marin, J. Mellor-Crummey, andN. R. Tallent, “HPCToolkit: tools for performance analysis of optimized parallelprograms,” Concurr. Comput. : Pract. Exper., vol. 22, pp. 685–701, apr 2010.

[11] J. Mellor-Crummey, L. Adhianto, M. Fagan, M. Krentel, and N. Tal-lent, “HPCToolkit user’s manual.” http://hpctoolkit.org/manual/

HPCToolkit-users-manual.pdf, okt 2012.

90 REFERENTIES

[12] Intel R©, “Intel R© VTuneTM.” http://software.intel.com/en-us/

intel-vtune-amplifier-xe, apr 2013.

[13] J. Miller, H. Kasture, G. Kurian, C. Gruenwald, N. Beckmann, C. Celio, J. Eastep,and A. Agarwal, “Graphite: A distributed parallel simulator for multicores,” inHigh Performance Computer Architecture (HPCA), 2010 IEEE 16th InternationalSymposium on, pp. 1–12, 2010.

[14] W. Heirman, S. Sarkar, T. E. Carlson, I. Hur, and L. Eeckhout, “Power-aware multi-core simulation for early design stage hardware/software co-optimization,” in PACT,pp. 3–12, 2012.

[15] S. Li, J. H. Ahn, R. Strong, J. Brockman, D. Tullsen, and N. Jouppi, “McPAT: Anintegrated power, area, and timing modeling framework for multicore and manycorearchitectures,” in Microarchitecture, 2009. MICRO-42. 42nd Annual IEEE/ACM In-ternational Symposium on, pp. 469 –480, dec. 2009.

[16] W. Heirman and T. Carlson, “The Sniper User Manual.” http://snipersim.org/

w/Manual, dec 2012.

[17] W. Heirman, T. E. Carlson, S. Che, K. Skadron, and L. Eeckhout, “Using cyclestacks to understand scaling bottlenecks in multi-threaded workloads,” in WorkloadCharacterization (IISWC), 2011 IEEE International Symposium on, pp. 38 –49, nov.2011.

[18] “Rickshaw is a JavaScript toolkit for creating interactive time series graphs.” http:

//code.shutterstock.com/rickshaw, jan 2013.

[19] T. E. Carlson, W. Heirman, K. V. Craeynest, L. Eeckhout, and I. Hur, “Sniper ver-sion 4.1.” http://snipersim.org/w/Releases#Version_4.1_.28December_11th.

2C_2012.29, dec 2012.

[20] G. Ross, “JavaScript Surface Plot, 3D surface plotting in JavaScript.” http://code.

google.com/p/javascript-surface-plot, oct 2012.

[21] IOLA and O. Laursen, “Flot, attractive JavaScript plotting for jQuery.” http://

www.flotcharts.org, mar 2013.

[22] D. van Heesch, “Doxygen, generate documentation from source code.” http://

doxygen.org, mar 2013.

[23] S. Williams, A. Waterman, and D. Patterson, “Roofline: an insightful visual perfor-mance model for multicore architectures,” Commun. ACM, vol. 52, pp. 65–76, apr2009.

[24] S. Garcia, D. Jeon, C. M. Louie, and M. B. Taylor, “Kremlin: rethinking and re-booting gprof for the multicore age,” SIGPLAN Not., vol. 46, pp. 458–469, June2011.

[25] D. Zaparanuks and M. Hauswirth, “Algorithmic profiling,” SIGPLAN Not., vol. 47,pp. 67–76, June 2012.

REFERENTIES 91

[26] E. Coppa, C. Demetrescu, and I. Finocchi, “Input-sensitive profiling,” in Proceed-ings of the 33rd ACM SIGPLAN conference on Programming Language Design andImplementation, PLDI ’12, (New York, NY, USA), pp. 89–98, ACM, 2012.

[27] D. Jeon, S. Garcia, C. Louie, and M. B. Taylor, “Kismet: parallel speedup estimatesfor serial programs,” in Proceedings of the 2011 ACM international conference onObject oriented programming systems languages and applications, OOPSLA ’11, (NewYork, NY, USA), pp. 519–536, ACM, 2011.

[28] S. Eyerman and L. Eeckhout, “Modeling critical sections in Amdahl’s law and its im-plications for multicore design,” SIGARCH Comput. Archit. News, vol. 38, pp. 362–370, jun 2010.

[29] J. Fonseca, “Gprof2dot, convert profiling output to a dot graph.” https://code.

google.com/p/jrfonseca/wiki/Gprof2Dot, apr 2013.

[30] S. L. Graham, P. B. Kessler, and M. K. Mckusick, “Gprof: A call graph executionprofiler,” SIGPLAN Not., vol. 17, pp. 120–126, jun 1982.

[31] A. Miller, “Example of Gprof2Dot output.” http://blog.soc1024.com/

bvh-implementation, apr 2013.

[32] D. Arnold, D. Ahn, B. De Supinski, G. Lee, B. Miller, and M. Schulz, “Stack traceanalysis for large scale debugging,” in Parallel and Distributed Processing Symposium,2007. IPDPS 2007. IEEE International, pp. 1–10, 2007.

[33] L. L. N. L. (LLNL), “STAT: The Stack Trace Analysis Tool.” https://computing.

llnl.gov/code/STAT/, may 2013.

LIJST VAN FIGUREN 93

Lijst van figuren

2.1 Globale tijdslijnweergave. Deze visualisatie toont gedetailleerde informatievan de processen op een tijdsas. Bron: [5] . . . . . . . . . . . . . . . . . . 11

2.2 Processpecifieke tijdslijnweergave. De procestijdslijnen tonen de verschil-lende niveaus van functie-oproepen in een gestapelde staafgrafiek. Bron:[5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Tellerdatatijdslijnweergave. Data van een enkele teller wordt gevisualiseerdvoor de verschillende processen. Bron: [5] . . . . . . . . . . . . . . . . . . . 12

2.4 Communicatiestatistieken tonen de communicatie tussen de processen ineen matrix. De verzendende processen worden getoond in de rijen, deontvangende processen in de kolommen. Bron: [5] . . . . . . . . . . . . . . 12

2.5 Overzicht van het tijdsverbruik door de verschillende functies. Bron: [5] . . 13

2.6 Tijdslijnvisualisatie van Paraver. Elke lijn stelt een CPU voor. De com-municatie tussen de processoren wordt weergegeven. Bron: [8] . . . . . . . 15

2.7 Statistiekvisualisatie van Paraver om cachemissers voor te stellen. Dit iseen voorbeeld van hoe Paraver zowel zeer eenvoudig maar ook flexibel kanzijn. Bron [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.8 TMProf: visualisatie van een enkele uitvoering. Het laat zien hoe transac-ties tussen verschillende draden met elkaar interageren. Bron: [9] . . . . . 16

2.9 TMProf: visualisatie van meerdere uitvoeringen. Dit kan aantonen hoe eenverandering in het programma de prestatie beınvloedt. Bron: [9] . . . . . . 16

2.10 HPCToolkit: geannoteerde screenshot van HPCTraceview. Verschillendevisualisaties die de informatie vanuit een ander niveau tonen worden sa-mengebracht. Bron: [11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.11 Visualisatie van CPU-tijd in Intel VTune. Bron: [12] . . . . . . . . . . . . 19

2.12 Visualisatie van het gedrag van draden in Intel VTune. Bron: [12] . . . . . 19

2.13 Gebruik van tijdslijnen in Intel VTune. Bron: [12] . . . . . . . . . . . . . . 19

3.1 Het intervalmodel dat door Sniper gebruikt wordt. Intervalsimulatie zorgtvoor een hogere abstractie in de architecturale simulatie. In deze vorm vansimulatie wordt gesprongen tussen misserevents. Bron: [4] . . . . . . . . . 21

4.1 Genormaliseerde cycle stack van Helsim, een programma ontwikkeld aanhet Intel Exascience Lab. De informatie over de verschillende cores werdgeaggregeerd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2 Workflow van de implementatie. Een programma wordt uitgevoerd doorSniper. De simulatieresultaten worden verwerkt tot JSON-bestanden, diegebruikt worden door de webpagina’s om de visualisaties te genereren. . . . 31

94 LIJST VAN FIGUREN

4.3 Cyclestacks in functie van de tijd. De componenten worden vereenvoudigdweergegeven en de optie ‘normaliseren’ staat aan. . . . . . . . . . . . . . . 32

4.4 Cyclestacks in functie van de tijd. De componenten worden gedetailleerdweergegeven en de optie ‘normaliseren’ staat aan. . . . . . . . . . . . . . . 32

4.5 Cyclestacks in functie van de tijd. De componenten worden gedetailleerdweergegeven en de optie ‘absolute’ staat aan. . . . . . . . . . . . . . . . . . 33

4.6 Verschillende componenten kunnen met elkaar vergeleken worden dankzijde interactieve legende. Hier werden enkele componenten van het geheugengeselecteerd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.7 De markeringen die aangebracht kunnen worden onder de visualisatie. . . . 35

4.8 Illustratie van het gebruik van de afvlakker. . . . . . . . . . . . . . . . . . 35

4.9 Optie ‘negatieve stack’. De negatieve componenten (hier synchronisatie-componenten) worden onder de x-as weergegeven. . . . . . . . . . . . . . . 36

4.10 Schaalbaarheid in de tijd: vergelijking van de oorspronkelijke simulatietijdmet de simulatietijd wanneer de periodieke statistieken opgeslaan worden. . 37

4.11 Schaalbaarheid in de tijd: Vergelijking van de tijd nodig om de databe-standen te genereren en de simulatietijd. . . . . . . . . . . . . . . . . . . . 38

4.12 Schaalbaarheid in de ruimte: vergelijking van de grootte van de origineledatabank met de databank die Sniper genereert als de periodieke statistie-ken ook bijgehouden worden. . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.1 Power stack gegenereerd door Sniper. Per component wordt de hoeveelheidenergie (in Joule) weergegeven. . . . . . . . . . . . . . . . . . . . . . . . . 42

5.2 Het vermogen, uitgezet in de tijd, dat geschat wordt door McPAT. . . . . . 43

5.3 Schaalbaarheid in de tijd: vergelijking van de oorspronkelijke simulatie-tijd met de tijd nodig om het script uit te voeren dat de data voor devisualisaties genereert. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.1 3D-Visualisatie van tijd-cores-IPC. Op de x- en z-as staan de tijd (in mi-croseconden) en de cores. Op de y-as staat de IPC uitgezet. . . . . . . . . 48

6.2 Als deze 3D-visualisatie van Helsim in een juiste hoek wordt gedraaid danwordt opnieuw de IPC-grafiek getoond zoals in Figuur 4.4. . . . . . . . . . 49

6.3 Vergelijking tussen twee simulatieresultaten. Het is duidelijk dat core 42 ophet linkse resultaat een ander gedrag vertoont dan op het rechtse resultaat. 49

6.4 Schaalbaarheid in de ruimte: vergelijking tussen de simulatietijd en hetgenereren van de databestanden. . . . . . . . . . . . . . . . . . . . . . . . 51

7.1 Workflow van de ’Functies: instructies versus tijd’ visualisatie. . . . . . . . 58

7.2 Resulterende webpagina na het uitvoeren van het functionbased.py script.De verschillende visualisaties kunnen opengeklikt worden door op hun titelte klikken. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

7.3 Functies: instructies versus de tijd. De verwachting is dat de uitvoerings-tijd stijgt volgens het aantal instructies dat een functie uitvoert. Als deuitvoeringstijd abnormaal groot is volgens het aantal instructies dan zaldit duidelijk te zien zijn op dit spreidingsdiagram. . . . . . . . . . . . . . . 59

LIJST VAN FIGUREN 95

7.4 Functies: instructies versus de tijd. Er werd ingezoomd. De overzichts-grafiek rechtsboven zorgt ervoor dat het toch nog duidelijk is waar we onsin het volledige spreidingsdiagram bevinden. Er is ook een uitzoomknopverschenen die ervoor zorgt dat we terug naar de originele grafiek gaan. . . 61

7.5 Functie-info-overzicht. Deze sectie toont informatie over de functies. Erkan worden genavigeerd door de functies door gebruik te maken van depijltjes. Naast de eigenschappen staat een bar die weergeeft hoeveel procentvan het totaal deze functie van deze eigenschap gebruikt. Er is ook eenCPI-bar voorzien en onderaan worden suggesties voor optimalisatie gegeven. 61

7.6 Schaalbaarheid in de ruimte: vergelijking tussen de originele databank ende databank wanneer aan Sniper de instructietracer-opties worden meege-geven. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

7.7 Schaalbaarheid in de tijd: vergelijking tussen de originele simulatietijd ende simulatietijd met de opties voor de functiegebaseerde statistieken. . . . 63

8.1 Het roofline model. De functies worden geplot volgens hun operationeleintensiteit en hun gebruikte geheugenbandbreedte. De functies worden of-wel begrensd door de maximale geheugenbandbreedte of door de maximalevlottende-kommaprestatie. Het doel is om de functies zo hoog mogelijk inhet roofline model te krijgen. . . . . . . . . . . . . . . . . . . . . . . . . . . 67

9.1 Automatische suggesties voor optimalisatie: workflow . . . . . . . . . . . . 719.2 Automatische suggesties voor optimalisaties: een top tien van mogelijke

optimalisaties. Naast de naam van de functie staat de voorgestelde opti-malisatie met daarbij een staaf die de grootte van de versnelling voorstelt. 76

9.3 Automatische suggesties voor optimalisaties: een top tien van mogelijkegecombineerde optimalisaties. . . . . . . . . . . . . . . . . . . . . . . . . . 78

9.4 Automatische suggesties voor optimalisaties: een top tien van mogelijkeILP-optimalisaties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

10.1 Synthese van dit werk. Hardware- en software-ontwikkelaars willen be-paalde vragen kunnen beantwoorden die handelen over software die ze uit-voeren op gesimuleerde hardware. Ze kunnen hun simulatie uitvoeren opSniper. De gegenereerde resultaten zullen de input vormen voor verschil-lende visualisaties die op hun beurt de opgestelde vragen kunnen beant-woorden. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

11.1 Voorbeeld van een visualisatie van functie-oproepen, gegenereerd door GProf2dot[30]. Bron: [31] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

11.2 2D-prefixboom gegenereerd door STAT (Stack Trace Analysis Tool) [32].De knopen stellen functies voor en de gerichte bogen tonen de oproepse-quenties en worden gelabeld door de set van taken die dit oproeppad volgt.Bron: [33] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Visualisatie van many-coresimulaties Mathijs...

Documents

Transcript of Visualisatie van many-coresimulaties Mathijs...