Performance Analysis Tools

If you have HP-UX 9.07 or 10.10, and have installed HP-PEX 5.1, Version 3.0 or later, a profiled archive library containing the highest level of PEXlib calls is shipped in 〈profile〉^[11]. To get additional information about time spent in PEXlib calls, add libPEX5_prof.a to your link line, as shown in the example below.

cc -DHPPEX_PROCEDURES program.c -I/usr/include/X11R6 \
  -L/usr/lib/X11R6 \
  -W, -L /usr/contrib/PEX5/lib \
  -lPEX5_prof -l PEX5 -lXext -lX11 -lm

This profiled library is only useful for performance tuning. It should not be used to build an actual product, since it is not a supported part of the HP-PEXlib product.

All HP-UX graphics products are tuned for maximum performance based on typical application usage. In other words, there are some combinations of primitives and attributes that HP graphics libraries will execute faster than other combinations of primitives and attributes. In order to determine what those paths are, you need to study the available documentation for each release. If this documentation does not help you understand the performance problems you are experiencing, then you will need to perform some simple experiments.

In most cases, the combinations of primitives and attributes that are optimized do not vary from one API to another, since optimizations are focused on typical application usage. However, there may be some performance issues specific to the graphics products that you are using. HP tunes its graphics libraries for each release. For most graphics APIs, some documentation is shipped with the product about performance tuning. In order to be aware of all performance improvements in the graphics library, read the Release Notes and PERF_NOTES whenever you plan to support a new release of any of HP's graphics APIs.

Most vendors ship similar documentation. When designing your application, it is good practice to read the documentation from multiple vendors, in order to determine which primitives and attributes work best across all of the platforms you plan to support.

Tips for improving application performance on PEXlib are published in the Release Notes document. These files are found in the /etc/newconfig directory on HP-UX 9.01, 9.03, 9.05 and 9.07 releases, or, on HP-UX 10.0 and later releases, in /opt/graphics/PEX5.

Starbase tips are available in /usr/lib/starbase/PERF_NOTES on HP-UX 9.07 or earlier releases, and in /opt/graphics/PERF_NOTES for systems running HP-UX 10.0 or later releases.

In general, PLB benchmarks are most useful for comparing systems before purchase. However, there is one piece of information in the GPC Quarterly that is helpful to application developers for performance tuning. Published with a summary of the GPC results is a description of the optimizations made by the vendor to achieve maximum performance for the benchmark. By applying the optimizations used in the benchmarks to your program, you should be able to improve performance in your application.

The settings of attributes, the number of times attributes are called, and the types of attributes used in your program can all affect graphics performance. Some attribute settings simply involve more work than others. For example, for each light turned on in a PEXSetLightSourceState call, a set of mathematical computations must be done to light the primitives in the scene. The more light sources turned on, the more expensive the call.

Redundant attribute settings (for example, attribute calls that are made more than once but don't change values of the current settings) can be very expensive in some implementations. Although the HP graphics libraries do a lot of redundancy checking, certain redundant attribute calls will cause primitives to be drawn using non-optimized paths in the graphics libraries. This can slow graphics performance considerably. Always avoid making duplicate calls to attribute setting routines. If you must set attributes frequently to different values, consider grouping primitives that share similar attributes. For example, sort the primitives according to reflection characteristics, and render all primitives with the same reflection characteristics at once.

Finally, some attribute settings are not optimized by the implementation.

All three of these factors can affect your application performance. The next section describes an experimentation process that will help you determine which attribute calls are having the most impact on graphics performance.

If your application does not set attributes redundantly, then it might be that your application is setting attributes in a way that is not optimized in the libraries. You need to look at the attribute calls and determine if an optimized path might work for your application instead. While it is not always possible to reduce the number of attribute calls, you may want to make some appropriate tradeoffs between appearance and performance. For example, in a preview operation, it may not be necessary to turn depth cueing on or use wide lines.

If you are confused about which paths are optimized, use the published documentation that is shipped with your libraries, or study the optimizations described in the GPC Quarterly.

Just as redundant attribute changes can impact performance, frequent changes in the data formats can also affect application performance. In this case, data format refers to whether or not normals and colors are passed to PEXlib with the vertices. In primitive calls like PEXFillAreaWithData, this information is passed to PEXlib in the vertex_attributes mask. If you are using the OCC interface, vertex attributes are described in the PEXOCC structure.

Determining how changes in data formats are affecting your overall application performance is more difficult than the attribute experiments described above. You will need either to sort the data passed to PEXlib or to perform multipass rendering using your data. To sort data, you would need to group all of the geometry with identical vertex attributes and render it all at once. In a multipass rendering, you would need to traverse the data several times. The first pass might only render primitives without vertex normals. The second pass might render only primitives with vertex normals, etc., until you have rendered all of the primitives in the model. Timing results can be a little confusing, though, because the traversal time needs to be accounted for in a multipass rendering.

Translation between the application's native data format and a packed data format can also have an impact on performance. See the section called Data Formats below for PEX-specific information on data formats.

Window size may be a factor in rendering performance. Larger windows can be slower, especially when rasterization is not done in hardware. On HP systems, this is usually not a problem. In HP-PEXlib, window size might be a factor in texture mapping performance, since hardware acceleration is not available for texture mapping on all devices.

Window system interactions can affect performance if the user interactions cause the graphics to be redrawn frequently. This can happen when the application generates a lot of exposure events, and when menus and other user interface items are drawn in the image planes.

Often the amount of detail in the geometric model is greater than the amount of detail needed to render an object realistically. By experimenting with geometry suppression you may also be able to improve application performance. In this case, your application does not render all of the geometry available.

Two general techniques can be applied to many graphics applications. In the first, multiple variations of the geometry are used. Depending on the level of resolution required for the user's task, different geometry is rendered. In some cases, a very coarse resolution is acceptable. Multiple primitives can be combined into a single primitive. Objects that are too small to be seen can be removed altogether, and replaced with an alternate representation.

Another technique uses bounding boxes to trivially reject all offscreen geometry. This technique is useful when you have a "world" scene, and the viewer can only look in one direction.

On HP systems, there are three fundamental ways to communicate with the graphics libraries and render 3D graphics in PEXlib. Direct Hardware Access (DHA) is the fastest method available when both client and server are on the same workstation. In DHA mode, graphics commands are sent directly to the graphics rendering libraries by PEXlib. In contrast, in protocol mode, graphics requests are sent over the network to the graphics server, where they are decoded and translated into graphics commands that are then sent to the graphics libraries on the server. In the X protocol method, PEXlib commands are translated into X protocol requests, which in turn travel over the network to be decoded by the X server and rendered.

Whenever both the client and server are available on the same system and performance is important, you should run in DHA mode. This is the default, but you can explicitly control the mode by setting the environment variable HPPEX_CLIENT_PROTOCOL to DHA.

In PEXlib, there are two ways to draw a scene. If you are using immediate mode, you can pass all of the primitives and attributes in the scene to PEXlib one at a time, each time you want to draw the picture. In structure mode, you store all of the primitives and attributes in a graphics database, then tell PEX to render the contents of that database. Immediate mode rendering is best suited for applications that need to modify model data frequently, or need to reduce memory usage. Structure mode can be used when the data is somewhat static throughout the application.

When running locally, structure mode reduces procedure call overhead and parameter processing times. Most of the cost is incurred at the time the model is built, not when it is rendered. For example, error checking of parameters can be done when the data is stored in the structure, and does not have to be repeated each time the model is rendered.

Structure mode is even more useful in a distributed environment. Since the network is frequently the bottleneck in distributed application performance, it is important to try to minimize network traffic. Storing the data in structures is one way to do that.

Many applications combine the two modes. Non-changing data is stored in structures, but other data that changes frequently is sent to the graphics server in immediate mode. For example, the geometry of a model might be stored in a structure, but viewing calls are made each time the scene is redrawn.

Structure permissions control the access to structures by applications. By calling PEXSetStructurePermission, an application can set the permission of a structure to either PEXStructureWriteOnly or PEXStructureLocked. Write-only structures cannot be read by PEXFetchElements, and locked structures cannot be edited.

By setting structure permissions appropriately, you permit PEXlib to use its internal knowledge about the best performance paths, and pack primitives in the most efficient way for the hardware on which it is running. For example, if a locked structure contains multiple PEXPolyline primitives, PEXlib can pack those primitives into a single PEXPolylineSetWithData call, reducing procedure call overhead and resulting in faster execution of those polylines. This example is only possible when the structure is locked.

Other optimizations are even possible in write-only structures. For example, decomposition of polygons can be done only once per write-only structure, instead of every time the contents of the structure are rendered.

Whenever an application needs to continually rerender unchanging models, storing data in structures with write-only or locked permissions should be considered. If you need to edit your structure, set the structure permissions to PEXStructureWriteOnly. If you don't need to edit, best performance can be achieved by setting permissions to PEXStructureLocked.

The ExecuteStructure output command that is used to create a structure network can be expensive, because attributes' values are saved when a child structure is executed, and are restored when the traversal returns to the parent structure. Consequently, it is good practice to avoid excessively deep structure networks and avoid creating structures that have very few elements.

PEXlib offers two major argument interfaces for output commands (primitives and attributes): an explicit interface and an output command context interface (OCC). The explicit interface requires that you specify the display, resource ID (renderer or structure), and request type for every output command function call that you make. The explicit interface is the only interface available on PEXlib 5.1 (including HP-PEXlib, Versions 1.0 and 2.0).

The OCC interface is currently available in HP-PEXlib5.1, Version 3, and will be available in the PEXlib 5.2 implementation. The OCC interface generates the same protocol as it generated using the explicit interface, so that PEXlib programs using the OCC interface can communicate with earlier 5.1 servers.

Output commands using the OCC interface replace the first three arguments, and other frequently used primitive descriptions, like vertex_attributes, with a single OC context. The OC context is an opaque structure that contains many of the arguments that are commonly found in the explicit interface output commands.

In addition to providing a reduced argument count for output commands, the OCC interface supports different data formats. The packed form is the same form that was used in earlier releases of PEXlib. It requires you to format data into packed data structures defined by PEXlib. The stride form allows you to supply data formatted in application-defined structured arrays without the need to copy the data into the PEXlib-defined structures before invoking the PEXlib functions. The unpacked form allows you to supply the data in separate lists for each data type. Vertex coordinates, normals, and colors are stored in separate lists in the unpacked form.

In general, the OCC interface uses far fewer arguments than the explicit interface, making coding easier and improving performance. The OCC interface is recommended for applications that are supported on HP-PEXlib, Version 3.0 or later. Best performance is achieved by minimizing the number of calls that modify the OCC context, and not intermixing calls that use different OCC contexts.

If your application is running in DHA mode on HP, the selection of data interface may have a significant impact on performance of your application performance. The OCC interface is implemented at the PEXlib level; the protocol generated by the OCC interface is identical to the protocol generated using the 5.1 PEXlib interface. Consequently, performance is only affected when running in DHA mode.

HP-PEXlib is optimized to use the packed and stride data interfaces most efficiently. The unpacked data interface is executed significantly slower. However, whether or not to use the packed interface depends on the size and nature of your data. Using the unpacked form may be more efficient than converting large amounts of data to the packed form, if the packed form is different from the application's native data format, and if conversion routines are more time-consuming than the difference in performance you will get by calling HP-PEXlib using the packed data interface. In order to determine which interface to use for your application, write some simple benchmarks and experiment with the data formats and conversion routines.

One advantage of the stride interface is that it is possible to change vertex and facet attributes without copying data. If your application is going to rerender the same geometric data with different attributes, the stride interface is an appropriate choice.

All PEXlib FillArea calls accept a shape_hint parameter. By providing a value other than PEXShapeUnknown, you can bypass some unnecessary processing in some cases. For example, on HP hardware, convex shapes can be passed to the graphics hardware immediately. Non-convex shapes may require some preprocessing by PEXlib.

In early releases of HP-PEXlib, shape hints were ignored. In PEXlib 5.1, Version 3.0, shape hints make significant performance differences in many cases. The use of shape hints for potentially non-convex polygons (that is, polygons with more than four sides) is strongly recommended.

Remember that the shape hints must be accurate. Incorrect shape hints can result in the wrong picture being drawn, or in slower performance.

Best performance on the newer graphics products can be achieved by reducing the CPU "non-graphics" overhead, such as procedure call overhead. Applications can reduce overhead by packing more primitives into library calls. In HP-PEXlib 5.1, Version 3, a number of complex primitives are supported. However, just using those primitives is not enough. Applications must send enough primitives per call to amortize the overhead. Best performance is achieved when at least eight primitives are packed per call, with performance levelling out at some point above fifty primitives per call. However, some applications have achieved significant performance improvements simply by changing the number of triangles per strip from two or three to five or six.

Compound primitives optimized for PEXlib include:

Compilers are continually tuned by Hewlett-Packard. Simply updating to newer revisions of compilers and rebuilding your application may improve performance significantly.

If your application is CPU bound, you may be able to substantially improve performance just by compiling and linking with some optimization options. For example, compiler options can automatically remove dead code, make better use of registers, optimize loops, generate in-line code, optimize for a particular architecture (for example, PA RISC, Version 1.0; or PA RISC, Version 1.1), and optimize your application based on a run-time profile. For C programs, this process is described in Optimizing HP C Programs. Linker optimization options are described in Programming on HP-UX.

If graphics applications are spending significant time in the math libraries, linking with the archive version instead of the shared version might help. This is because the symbol resolution overhead is reduced with archive libraries.

Cache and Translation Lookaside Buffer (TLB) misses can cause a CPU bottleneck. A cache holds frequently accessed data and instructions in "local" memory that is faster for the process to access than main memory. A cache miss occurs when the processor needs to reference memory, and a copy of the memory is not stored in cache. Because it is very expensive for the processor to access main memory, frequent cache misses will slow down application performance considerably.

The Translation Lookaside Buffer is used to map physical memory to virtual memory. It contains translations for recently addressed virtual pages. A TLB miss occurs if your application tries to access a page of virtual memory that has not been mapped to physical memory.

Both cache misses and TLB misses can be avoided by improving locality in your application. For example, loops can be written to sequentially access contiguous memory addresses, as opposed to accessing data that is scattered throughout memory. Code routines that frequently call each other should be included in the same source files, or the files containing those routines should be listed next to each other in the ld command. You can also use the ld(1) options for profile-based optimization to reposition code so that better locality is achieved. Note that profile-based optimization will not improve the locality of data references. Profile-based optimization is described in Optimizing HP C Programs.

If memory is the bottleneck and your program is thrashing (that is, pages of virtual memory are excessively swapped into physical memory), you may be able to improve application performance just by increasing the amount of physical memory in your system. You can also tune your application's memory usage. To do this, consider the following, all of which will require some code changes in your application:

If the problem is disk access, you might consider modifying your program to access the disk more efficiently. For example, make some tradeoffs between memory usage and disk usage. Blocks of frequently used data could be read in all at once and stored in memory, instead of accessing the disk each time an item is accessed.