2012-08-29 06:44:10 +02:00
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
2013-04-02 02:09:44 +02:00
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> < html xmlns = "http://www.w3.org/1999/xhtml" > < head > < meta http-equiv = "Content-Type" content = "text/html; charset=UTF-8" / > < title > Diagnostics< / title > < meta name = "generator" content = "DocBook XSL-NS Stylesheets V1.78.1" / > < meta name = "keywords" content = "C++, library, profile" / > < meta name = "keywords" content = "ISO C++, library" / > < meta name = "keywords" content = "ISO C++, runtime, library" / > < link rel = "home" href = "../index.html" title = "The GNU C++ Library" / > < link rel = "up" href = "profile_mode.html" title = "Chapter / > < link rel = "prev" href = "profile_mode_devel.html" title = "Developer Information" / > < link rel = "next" href = "mt_allocator.html" title = "Chapter / > < / head > < body > < div class = "navheader" > < table width = "100%" summary = "Navigation header" > < tr > < th colspan = "3" align = "center" > Diagnostics< / th > < / tr > < tr > < td width = "20%" align = "left" > < a accesskey = "p" href = "profile_mode_devel.html" > Prev< / a > < / td > < th width = "60%" align = "center" > Chapter < / th > < td width = "20%" align = "right" > < a accesskey = "n" href = "mt_allocator.html" > Next< / a > < / td > < / tr > < / table > < hr / > < / div > < div class = "section" > < div class = "titlepage" > < div > < div > < h2 class = "title" style = "clear: both" > < a id = "manual.ext.profile_mode.diagnostics" > < / a > Diagnostics< / h2 > < / div > < / div > < / div > < p >
2009-10-05 20:04:44 +02:00
The table below presents all the diagnostics we intend to implement.
Each diagnostic has a corresponding compile time switch
< code class = "code" > -D_GLIBCXX_PROFILE_< diagnostic> < / code > .
Groups of related diagnostics can be turned on with a single switch.
For instance, < code class = "code" > -D_GLIBCXX_PROFILE_LOCALITY< / code > is equivalent to
2010-04-22 01:33:44 +02:00
< code class = "code" > -D_GLIBCXX_PROFILE_SOFTWARE_PREFETCH
2009-10-05 20:04:44 +02:00
-D_GLIBCXX_PROFILE_RBTREE_LOCALITY< / code > .
< / p > < p >
The benefit, cost, expected frequency and accuracy of each diagnostic
was given a grade from 1 to 10, where 10 is highest.
A high benefit means that, if the diagnostic is accurate, the expected
performance improvement is high.
A high cost means that turning this diagnostic on leads to high slowdown.
A high frequency means that we expect this to occur relatively often.
A high accuracy means that the diagnostic is unlikely to be wrong.
These grades are not perfect. They are just meant to guide users with
specific needs or time budgets.
2014-06-09 16:47:17 +02:00
< / p > < div class = "table" > < a id = "table.profile_diagnostics" > < / a > < p class = "title" > < strong > Table < / strong > < / p > < div class = "table-contents" > < table summary = "Profile Diagnostics" border = "1" > < colgroup > < col align = "left" class = "c1" / > < col align = "left" class = "c2" / > < col align = "left" class = "c3" / > < col align = "left" class = "c4" / > < col align = "left" class = "c5" / > < col align = "left" class = "c6" / > < col align = "left" class = "c7" / > < / colgroup > < thead > < tr > < th align = "left" > Group< / th > < th align = "left" > Flag< / th > < th align = "left" > Benefit< / th > < th align = "left" > Cost< / th > < th align = "left" > Freq.< / th > < th align = "left" > Implemented< / th > < td class = "auto-generated" > < / td > < / tr > < / thead > < tbody > < tr > < td align = "left" > < a class = "link" href = "profile_mode_diagnostics.html#manual.ext.profile_mode.analysis.containers" title = "Containers" >
2012-12-18 12:08:33 +01:00
CONTAINERS< / a > < / td > < td align = "left" > < a class = "link" href = "profile_mode_diagnostics.html#manual.ext.profile_mode.analysis.hashtable_too_small" title = "Hashtable Too Small" >
HASHTABLE_TOO_SMALL< / a > < / td > < td align = "left" > 10< / td > < td align = "left" > 1< / td > < td align = "left" > < / td > < td align = "left" > 10< / td > < td align = "left" > yes< / td > < / tr > < tr > < td align = "left" > < / td > < td align = "left" > < a class = "link" href = "profile_mode_diagnostics.html#manual.ext.profile_mode.analysis.hashtable_too_large" title = "Hashtable Too Large" >
HASHTABLE_TOO_LARGE< / a > < / td > < td align = "left" > 5< / td > < td align = "left" > 1< / td > < td align = "left" > < / td > < td align = "left" > 10< / td > < td align = "left" > yes< / td > < / tr > < tr > < td align = "left" > < / td > < td align = "left" > < a class = "link" href = "profile_mode_diagnostics.html#manual.ext.profile_mode.analysis.inefficient_hash" title = "Inefficient Hash" >
INEFFICIENT_HASH< / a > < / td > < td align = "left" > 7< / td > < td align = "left" > 3< / td > < td align = "left" > < / td > < td align = "left" > 10< / td > < td align = "left" > yes< / td > < / tr > < tr > < td align = "left" > < / td > < td align = "left" > < a class = "link" href = "profile_mode_diagnostics.html#manual.ext.profile_mode.analysis.vector_too_small" title = "Vector Too Small" >
VECTOR_TOO_SMALL< / a > < / td > < td align = "left" > 8< / td > < td align = "left" > 1< / td > < td align = "left" > < / td > < td align = "left" > 10< / td > < td align = "left" > yes< / td > < / tr > < tr > < td align = "left" > < / td > < td align = "left" > < a class = "link" href = "profile_mode_diagnostics.html#manual.ext.profile_mode.analysis.vector_too_large" title = "Vector Too Large" >
VECTOR_TOO_LARGE< / a > < / td > < td align = "left" > 5< / td > < td align = "left" > 1< / td > < td align = "left" > < / td > < td align = "left" > 10< / td > < td align = "left" > yes< / td > < / tr > < tr > < td align = "left" > < / td > < td align = "left" > < a class = "link" href = "profile_mode_diagnostics.html#manual.ext.profile_mode.analysis.vector_to_hashtable" title = "Vector to Hashtable" >
VECTOR_TO_HASHTABLE< / a > < / td > < td align = "left" > 7< / td > < td align = "left" > 7< / td > < td align = "left" > < / td > < td align = "left" > 10< / td > < td align = "left" > no< / td > < / tr > < tr > < td align = "left" > < / td > < td align = "left" > < a class = "link" href = "profile_mode_diagnostics.html#manual.ext.profile_mode.analysis.hashtable_to_vector" title = "Hashtable to Vector" >
HASHTABLE_TO_VECTOR< / a > < / td > < td align = "left" > 7< / td > < td align = "left" > 7< / td > < td align = "left" > < / td > < td align = "left" > 10< / td > < td align = "left" > no< / td > < / tr > < tr > < td align = "left" > < / td > < td align = "left" > < a class = "link" href = "profile_mode_diagnostics.html#manual.ext.profile_mode.analysis.vector_to_list" title = "Vector to List" >
VECTOR_TO_LIST< / a > < / td > < td align = "left" > 8< / td > < td align = "left" > 5< / td > < td align = "left" > < / td > < td align = "left" > 10< / td > < td align = "left" > yes< / td > < / tr > < tr > < td align = "left" > < / td > < td align = "left" > < a class = "link" href = "profile_mode_diagnostics.html#manual.ext.profile_mode.analysis.list_to_vector" title = "List to Vector" >
LIST_TO_VECTOR< / a > < / td > < td align = "left" > 10< / td > < td align = "left" > 5< / td > < td align = "left" > < / td > < td align = "left" > 10< / td > < td align = "left" > no< / td > < / tr > < tr > < td align = "left" > < / td > < td align = "left" > < a class = "link" href = "profile_mode_diagnostics.html#manual.ext.profile_mode.analysis.assoc_ord_to_unord" title = "Ordered to Unordered Associative Container" >
ORDERED_TO_UNORDERED< / a > < / td > < td align = "left" > 10< / td > < td align = "left" > 5< / td > < td align = "left" > < / td > < td align = "left" > 10< / td > < td align = "left" > only map/unordered_map< / td > < / tr > < tr > < td align = "left" > < a class = "link" href = "profile_mode_diagnostics.html#manual.ext.profile_mode.analysis.algorithms" title = "Algorithms" >
ALGORITHMS< / a > < / td > < td align = "left" > < a class = "link" href = "profile_mode_diagnostics.html#manual.ext.profile_mode.analysis.algorithms.sort" title = "Sort Algorithm Performance" >
SORT< / a > < / td > < td align = "left" > 7< / td > < td align = "left" > 8< / td > < td align = "left" > < / td > < td align = "left" > 7< / td > < td align = "left" > no< / td > < / tr > < tr > < td align = "left" > < a class = "link" href = "profile_mode_diagnostics.html#manual.ext.profile_mode.analysis.locality" title = "Data Locality" >
LOCALITY< / a > < / td > < td align = "left" > < a class = "link" href = "profile_mode_diagnostics.html#manual.ext.profile_mode.analysis.locality.sw_prefetch" title = "Need Software Prefetch" >
SOFTWARE_PREFETCH< / a > < / td > < td align = "left" > 8< / td > < td align = "left" > 8< / td > < td align = "left" > < / td > < td align = "left" > 5< / td > < td align = "left" > no< / td > < / tr > < tr > < td align = "left" > < / td > < td align = "left" > < a class = "link" href = "profile_mode_diagnostics.html#manual.ext.profile_mode.analysis.locality.linked" title = "Linked Structure Locality" >
RBTREE_LOCALITY< / a > < / td > < td align = "left" > 4< / td > < td align = "left" > 8< / td > < td align = "left" > < / td > < td align = "left" > 5< / td > < td align = "left" > no< / td > < / tr > < tr > < td align = "left" > < / td > < td align = "left" > < a class = "link" href = "profile_mode_diagnostics.html#manual.ext.profile_mode.analysis.mthread.false_share" title = "False Sharing" >
2013-02-12 00:24:26 +01:00
FALSE_SHARING< / a > < / td > < td align = "left" > 8< / td > < td align = "left" > 10< / td > < td align = "left" > < / td > < td align = "left" > 10< / td > < td align = "left" > no< / td > < / tr > < / tbody > < / table > < / div > < / div > < br class = "table-break" / > < div class = "section" > < div class = "titlepage" > < div > < div > < h3 class = "title" > < a id = "manual.ext.profile_mode.analysis.template" > < / a > Diagnostic Template< / h3 > < / div > < / div > < / div > < div class = "itemizedlist" > < ul class = "itemizedlist" style = "list-style-type: disc; " > < li class = "listitem" > < p > < span class = "emphasis" > < em > Switch:< / em > < / span >
2009-10-05 20:04:44 +02:00
< code class = "code" > _GLIBCXX_PROFILE_< diagnostic> < / code > .
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Goal:< / em > < / span > What problem will it diagnose?
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Fundamentals:< / em > < / span > .
What is the fundamental reason why this is a problem< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Sample runtime reduction:< / em > < / span >
2009-10-05 20:04:44 +02:00
Percentage reduction in execution time. When reduction is more than
a constant factor, describe the reduction rate formula.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Recommendation:< / em > < / span >
What would the advise look like?< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > To instrument:< / em > < / span >
What stdlibc++ components need to be instrumented?< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Analysis:< / em > < / span >
How do we decide when to issue the advice?< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Cost model:< / em > < / span >
How do we measure benefits? Math goes here.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Example:< / em > < / span >
2009-10-05 20:04:44 +02:00
< / p > < pre class = "programlisting" >
program code
...
advice sample
< / pre > < p >
2013-02-12 00:24:26 +01:00
< / p > < / li > < / ul > < / div > < / div > < div class = "section" > < div class = "titlepage" > < div > < div > < h3 class = "title" > < a id = "manual.ext.profile_mode.analysis.containers" > < / a > Containers< / h3 > < / div > < / div > < / div > < p >
2009-10-05 20:04:44 +02:00
< span class = "emphasis" > < em > Switch:< / em > < / span >
< code class = "code" > _GLIBCXX_PROFILE_CONTAINERS< / code > .
2013-02-12 00:24:26 +01:00
< / p > < div class = "section" > < div class = "titlepage" > < div > < div > < h4 class = "title" > < a id = "manual.ext.profile_mode.analysis.hashtable_too_small" > < / a > Hashtable Too Small< / h4 > < / div > < / div > < / div > < div class = "itemizedlist" > < ul class = "itemizedlist" style = "list-style-type: disc; " > < li class = "listitem" > < p > < span class = "emphasis" > < em > Switch:< / em > < / span >
2009-10-05 20:04:44 +02:00
< code class = "code" > _GLIBCXX_PROFILE_HASHTABLE_TOO_SMALL< / code > .
2010-04-22 01:33:44 +02:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Goal:< / em > < / span > Detect hashtables with many
2009-10-05 20:04:44 +02:00
rehash operations, small construction size and large destruction size.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Fundamentals:< / em > < / span > Rehash is very expensive.
2009-10-05 20:04:44 +02:00
Read content, follow chains within bucket, evaluate hash function, place at
2010-01-05 21:51:05 +01:00
new location in different order.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Sample runtime reduction:< / em > < / span > 36%.
2009-10-05 20:04:44 +02:00
Code similar to example below.
2010-04-22 01:33:44 +02:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Recommendation:< / em > < / span >
2009-10-05 20:04:44 +02:00
Set initial size to N at construction site S.
2010-04-22 01:33:44 +02:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > To instrument:< / em > < / span >
2009-10-05 20:04:44 +02:00
< code class = "code" > unordered_set, unordered_map< / code > constructor, destructor, rehash.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Analysis:< / em > < / span >
2009-10-05 20:04:44 +02:00
For each dynamic instance of < code class = "code" > unordered_[multi]set|map< / code > ,
record initial size and call context of the constructor.
Record size increase, if any, after each relevant operation such as insert.
2010-01-05 21:51:05 +01:00
Record the estimated rehash cost.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Cost model:< / em > < / span >
2010-04-22 01:33:44 +02:00
Number of individual rehash operations * cost per rehash.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Example:< / em > < / span >
2009-10-05 20:04:44 +02:00
< / p > < pre class = "programlisting" >
1 unordered_set< int> us;
2 for (int k = 0; k < 1000000; ++k) {
3 us.insert(k);
4 }
foo.cc:1: advice: Changing initial unordered_set size from 10 to 1000000 saves 1025530 rehash operations.
< / pre > < p >
2013-02-12 00:24:26 +01:00
< / p > < / li > < / ul > < / div > < / div > < div class = "section" > < div class = "titlepage" > < div > < div > < h4 class = "title" > < a id = "manual.ext.profile_mode.analysis.hashtable_too_large" > < / a > Hashtable Too Large< / h4 > < / div > < / div > < / div > < div class = "itemizedlist" > < ul class = "itemizedlist" style = "list-style-type: disc; " > < li class = "listitem" > < p > < span class = "emphasis" > < em > Switch:< / em > < / span >
2009-10-05 20:04:44 +02:00
< code class = "code" > _GLIBCXX_PROFILE_HASHTABLE_TOO_LARGE< / code > .
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Goal:< / em > < / span > Detect hashtables which are
2009-10-05 20:04:44 +02:00
never filled up because fewer elements than reserved are ever
inserted.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Fundamentals:< / em > < / span > Save memory, which
2009-10-05 20:04:44 +02:00
is good in itself and may also improve memory reference performance through
2010-01-05 21:51:05 +01:00
fewer cache and TLB misses.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Sample runtime reduction:< / em > < / span > unknown.
2010-04-22 01:33:44 +02:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Recommendation:< / em > < / span >
2009-10-05 20:04:44 +02:00
Set initial size to N at construction site S.
2010-04-22 01:33:44 +02:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > To instrument:< / em > < / span >
2009-10-05 20:04:44 +02:00
< code class = "code" > unordered_set, unordered_map< / code > constructor, destructor, rehash.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Analysis:< / em > < / span >
2009-10-05 20:04:44 +02:00
For each dynamic instance of < code class = "code" > unordered_[multi]set|map< / code > ,
record initial size and call context of the constructor, and correlate it
with its size at destruction time.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Cost model:< / em > < / span >
2010-04-22 01:33:44 +02:00
Number of iteration operations + memory saved.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Example:< / em > < / span >
2009-10-05 20:04:44 +02:00
< / p > < pre class = "programlisting" >
1 vector< unordered_set< int> > v(100000, unordered_set< int> (100)) ;
2 for (int k = 0; k < 100000; ++k) {
3 for (int j = 0; j < 10; ++j) {
4 v[k].insert(k + j);
5 }
6 }
foo.cc:1: advice: Changing initial unordered_set size from 100 to 10 saves N
bytes of memory and M iteration steps.
< / pre > < p >
2013-02-12 00:24:26 +01:00
< / p > < / li > < / ul > < / div > < / div > < div class = "section" > < div class = "titlepage" > < div > < div > < h4 class = "title" > < a id = "manual.ext.profile_mode.analysis.inefficient_hash" > < / a > Inefficient Hash< / h4 > < / div > < / div > < / div > < div class = "itemizedlist" > < ul class = "itemizedlist" style = "list-style-type: disc; " > < li class = "listitem" > < p > < span class = "emphasis" > < em > Switch:< / em > < / span >
2009-10-05 20:04:44 +02:00
< code class = "code" > _GLIBCXX_PROFILE_INEFFICIENT_HASH< / code > .
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Goal:< / em > < / span > Detect hashtables with polarized
2009-10-05 20:04:44 +02:00
distribution.
2010-04-22 01:33:44 +02:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Fundamentals:< / em > < / span > A non-uniform
2009-10-05 20:04:44 +02:00
distribution may lead to long chains, thus possibly increasing complexity
by a factor up to the number of elements.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Sample runtime reduction:< / em > < / span > factor up
2009-10-05 20:04:44 +02:00
to container size.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Recommendation:< / em > < / span > Change hash function
2009-10-05 20:04:44 +02:00
for container built at site S. Distribution score = N. Access score = S.
Longest chain = C, in bucket B.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > To instrument:< / em > < / span >
2009-10-05 20:04:44 +02:00
< code class = "code" > unordered_set, unordered_map< / code > constructor, destructor, [],
insert, iterator.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Analysis:< / em > < / span >
2009-10-05 20:04:44 +02:00
Count the exact number of link traversals.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Cost model:< / em > < / span >
2010-04-22 01:33:44 +02:00
Total number of links traversed.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Example:< / em > < / span >
2009-10-05 20:04:44 +02:00
< / p > < pre class = "programlisting" >
class dumb_hash {
public:
size_t operator() (int i) const { return 0; }
};
...
unordered_set< int, dumb_hash> hs;
...
for (int i = 0; i < COUNT; ++i) {
hs.find(i);
}
< / pre > < p >
2013-02-12 00:24:26 +01:00
< / p > < / li > < / ul > < / div > < / div > < div class = "section" > < div class = "titlepage" > < div > < div > < h4 class = "title" > < a id = "manual.ext.profile_mode.analysis.vector_too_small" > < / a > Vector Too Small< / h4 > < / div > < / div > < / div > < div class = "itemizedlist" > < ul class = "itemizedlist" style = "list-style-type: disc; " > < li class = "listitem" > < p > < span class = "emphasis" > < em > Switch:< / em > < / span >
2009-10-05 20:04:44 +02:00
< code class = "code" > _GLIBCXX_PROFILE_VECTOR_TOO_SMALL< / code > .
2010-04-22 01:33:44 +02:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Goal:< / em > < / span > Detect vectors with many
2009-10-05 20:04:44 +02:00
resize operations, small construction size and large destruction size..
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Fundamentals:< / em > < / span > Resizing can be expensive.
2009-10-05 20:04:44 +02:00
Copying large amounts of data takes time. Resizing many small vectors may
2010-01-05 21:51:05 +01:00
have allocation overhead and affect locality.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Sample runtime reduction:< / em > < / span > %.
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Recommendation:< / em > < / span >
Set initial size to N at construction site S.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > To instrument:< / em > < / span > < code class = "code" > vector< / code > .
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Analysis:< / em > < / span >
2009-10-05 20:04:44 +02:00
For each dynamic instance of < code class = "code" > vector< / code > ,
record initial size and call context of the constructor.
2010-04-22 01:33:44 +02:00
Record size increase, if any, after each relevant operation such as
2009-10-05 20:04:44 +02:00
< code class = "code" > push_back< / code > . Record the estimated resize cost.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Cost model:< / em > < / span >
2010-04-22 01:33:44 +02:00
Total number of words copied * time to copy a word.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Example:< / em > < / span >
2009-10-05 20:04:44 +02:00
< / p > < pre class = "programlisting" >
1 vector< int> v;
2 for (int k = 0; k < 1000000; ++k) {
3 v.push_back(k);
4 }
2010-04-22 01:33:44 +02:00
foo.cc:1: advice: Changing initial vector size from 10 to 1000000 saves
2009-10-05 20:04:44 +02:00
copying 4000000 bytes and 20 memory allocations and deallocations.
< / pre > < p >
2013-02-12 00:24:26 +01:00
< / p > < / li > < / ul > < / div > < / div > < div class = "section" > < div class = "titlepage" > < div > < div > < h4 class = "title" > < a id = "manual.ext.profile_mode.analysis.vector_too_large" > < / a > Vector Too Large< / h4 > < / div > < / div > < / div > < div class = "itemizedlist" > < ul class = "itemizedlist" style = "list-style-type: disc; " > < li class = "listitem" > < p > < span class = "emphasis" > < em > Switch:< / em > < / span >
2009-10-05 20:04:44 +02:00
< code class = "code" > _GLIBCXX_PROFILE_VECTOR_TOO_LARGE< / code >
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Goal:< / em > < / span > Detect vectors which are
2009-10-05 20:04:44 +02:00
never filled up because fewer elements than reserved are ever
inserted.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Fundamentals:< / em > < / span > Save memory, which
2009-10-05 20:04:44 +02:00
is good in itself and may also improve memory reference performance through
2010-01-05 21:51:05 +01:00
fewer cache and TLB misses.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Sample runtime reduction:< / em > < / span > %.
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Recommendation:< / em > < / span >
Set initial size to N at construction site S.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > To instrument:< / em > < / span > < code class = "code" > vector< / code > .
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Analysis:< / em > < / span >
2009-10-05 20:04:44 +02:00
For each dynamic instance of < code class = "code" > vector< / code > ,
record initial size and call context of the constructor, and correlate it
2010-01-05 21:51:05 +01:00
with its size at destruction time.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Cost model:< / em > < / span >
2010-04-22 01:33:44 +02:00
Total amount of memory saved.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Example:< / em > < / span >
2009-10-05 20:04:44 +02:00
< / p > < pre class = "programlisting" >
1 vector< vector< int> > v(100000, vector< int> (100)) ;
2 for (int k = 0; k < 100000; ++k) {
3 for (int j = 0; j < 10; ++j) {
4 v[k].insert(k + j);
5 }
6 }
foo.cc:1: advice: Changing initial vector size from 100 to 10 saves N
bytes of memory and may reduce the number of cache and TLB misses.
< / pre > < p >
2013-02-12 00:24:26 +01:00
< / p > < / li > < / ul > < / div > < / div > < div class = "section" > < div class = "titlepage" > < div > < div > < h4 class = "title" > < a id = "manual.ext.profile_mode.analysis.vector_to_hashtable" > < / a > Vector to Hashtable< / h4 > < / div > < / div > < / div > < div class = "itemizedlist" > < ul class = "itemizedlist" style = "list-style-type: disc; " > < li class = "listitem" > < p > < span class = "emphasis" > < em > Switch:< / em > < / span >
2009-10-05 20:04:44 +02:00
< code class = "code" > _GLIBCXX_PROFILE_VECTOR_TO_HASHTABLE< / code > .
2010-04-22 01:33:44 +02:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Goal:< / em > < / span > Detect uses of
2009-10-05 20:04:44 +02:00
< code class = "code" > vector< / code > that can be substituted with < code class = "code" > unordered_set< / code >
to reduce execution time.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Fundamentals:< / em > < / span >
2009-10-05 20:04:44 +02:00
Linear search in a vector is very expensive, whereas searching in a hashtable
2010-01-05 21:51:05 +01:00
is very quick.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Sample runtime reduction:< / em > < / span > factor up
2009-10-05 20:04:44 +02:00
to container size.
2010-04-22 01:33:44 +02:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Recommendation:< / em > < / span > Replace
2009-10-05 20:04:44 +02:00
< code class = "code" > vector< / code > with < code class = "code" > unordered_set< / code > at site S.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > To instrument:< / em > < / span > < code class = "code" > vector< / code >
operations and access methods.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Analysis:< / em > < / span >
2009-10-05 20:04:44 +02:00
For each dynamic instance of < code class = "code" > vector< / code > ,
record call context of the constructor. Issue the advice only if the
2010-04-22 01:33:44 +02:00
only methods called on this < code class = "code" > vector< / code > are < code class = "code" > push_back< / code > ,
2009-10-05 20:04:44 +02:00
< code class = "code" > insert< / code > and < code class = "code" > find< / code > .
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Cost model:< / em > < / span >
2009-10-05 20:04:44 +02:00
Cost(vector::push_back) + cost(vector::insert) + cost(find, vector) -
cost(unordered_set::insert) + cost(unordered_set::find).
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Example:< / em > < / span >
2009-10-05 20:04:44 +02:00
< / p > < pre class = "programlisting" >
1 vector< int> v;
...
2 for (int i = 0; i < 1000; ++i) {
3 find(v.begin(), v.end(), i);
4 }
foo.cc:1: advice: Changing "vector" to "unordered_set" will save about 500,000
comparisons.
< / pre > < p >
2013-02-12 00:24:26 +01:00
< / p > < / li > < / ul > < / div > < / div > < div class = "section" > < div class = "titlepage" > < div > < div > < h4 class = "title" > < a id = "manual.ext.profile_mode.analysis.hashtable_to_vector" > < / a > Hashtable to Vector< / h4 > < / div > < / div > < / div > < div class = "itemizedlist" > < ul class = "itemizedlist" style = "list-style-type: disc; " > < li class = "listitem" > < p > < span class = "emphasis" > < em > Switch:< / em > < / span >
2009-10-05 20:04:44 +02:00
< code class = "code" > _GLIBCXX_PROFILE_HASHTABLE_TO_VECTOR< / code > .
2010-04-22 01:33:44 +02:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Goal:< / em > < / span > Detect uses of
2009-10-05 20:04:44 +02:00
< code class = "code" > unordered_set< / code > that can be substituted with < code class = "code" > vector< / code >
to reduce execution time.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Fundamentals:< / em > < / span >
Hashtable iterator is slower than vector iterator.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Sample runtime reduction:< / em > < / span > 95%.
2010-04-22 01:33:44 +02:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Recommendation:< / em > < / span > Replace
2009-10-05 20:04:44 +02:00
< code class = "code" > unordered_set< / code > with < code class = "code" > vector< / code > at site S.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > To instrument:< / em > < / span > < code class = "code" > unordered_set< / code >
operations and access methods.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Analysis:< / em > < / span >
2009-10-05 20:04:44 +02:00
For each dynamic instance of < code class = "code" > unordered_set< / code > ,
record call context of the constructor. Issue the advice only if the
2010-04-22 01:33:44 +02:00
number of < code class = "code" > find< / code > , < code class = "code" > insert< / code > and < code class = "code" > []< / code >
2009-10-05 20:04:44 +02:00
operations on this < code class = "code" > unordered_set< / code > are small relative to the
number of elements, and methods < code class = "code" > begin< / code > or < code class = "code" > end< / code >
2010-01-05 21:51:05 +01:00
are invoked (suggesting iteration).< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Cost model:< / em > < / span >
Number of .< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Example:< / em > < / span >
2009-10-05 20:04:44 +02:00
< / p > < pre class = "programlisting" >
1 unordered_set< int> us;
...
2 int s = 0;
3 for (unordered_set< int> ::iterator it = us.begin(); it != us.end(); ++it) {
4 s += *it;
5 }
foo.cc:1: advice: Changing "unordered_set" to "vector" will save about N
indirections and may achieve better data locality.
< / pre > < p >
2013-02-12 00:24:26 +01:00
< / p > < / li > < / ul > < / div > < / div > < div class = "section" > < div class = "titlepage" > < div > < div > < h4 class = "title" > < a id = "manual.ext.profile_mode.analysis.vector_to_list" > < / a > Vector to List< / h4 > < / div > < / div > < / div > < div class = "itemizedlist" > < ul class = "itemizedlist" style = "list-style-type: disc; " > < li class = "listitem" > < p > < span class = "emphasis" > < em > Switch:< / em > < / span >
2009-10-05 20:04:44 +02:00
< code class = "code" > _GLIBCXX_PROFILE_VECTOR_TO_LIST< / code > .
2010-04-22 01:33:44 +02:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Goal:< / em > < / span > Detect cases where
2009-10-05 20:04:44 +02:00
< code class = "code" > vector< / code > could be substituted with < code class = "code" > list< / code > for
better performance.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Fundamentals:< / em > < / span >
2010-04-22 01:33:44 +02:00
Inserting in the middle of a vector is expensive compared to inserting in a
2009-10-05 20:04:44 +02:00
list.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Sample runtime reduction:< / em > < / span > factor up to
2009-10-05 20:04:44 +02:00
container size.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Recommendation:< / em > < / span > Replace vector with list
at site S.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > To instrument:< / em > < / span > < code class = "code" > vector< / code >
operations and access methods.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Analysis:< / em > < / span >
2009-10-05 20:04:44 +02:00
For each dynamic instance of < code class = "code" > vector< / code > ,
record the call context of the constructor. Record the overhead of each
< code class = "code" > insert< / code > operation based on current size and insert position.
Report instance with high insertion overhead.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Cost model:< / em > < / span >
2009-10-05 20:04:44 +02:00
(Sum(cost(vector::method)) - Sum(cost(list::method)), for
method in [push_back, insert, erase])
2010-04-22 01:33:44 +02:00
+ (Cost(iterate vector) - Cost(iterate list))< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Example:< / em > < / span >
2009-10-05 20:04:44 +02:00
< / p > < pre class = "programlisting" >
1 vector< int> v;
2 for (int i = 0; i < 10000; ++i) {
3 v.insert(v.begin(), i);
4 }
2010-04-22 01:33:44 +02:00
foo.cc:1: advice: Changing "vector" to "list" will save about 5,000,000
2009-10-05 20:04:44 +02:00
operations.
< / pre > < p >
2013-02-12 00:24:26 +01:00
< / p > < / li > < / ul > < / div > < / div > < div class = "section" > < div class = "titlepage" > < div > < div > < h4 class = "title" > < a id = "manual.ext.profile_mode.analysis.list_to_vector" > < / a > List to Vector< / h4 > < / div > < / div > < / div > < div class = "itemizedlist" > < ul class = "itemizedlist" style = "list-style-type: disc; " > < li class = "listitem" > < p > < span class = "emphasis" > < em > Switch:< / em > < / span >
2009-10-05 20:04:44 +02:00
< code class = "code" > _GLIBCXX_PROFILE_LIST_TO_VECTOR< / code > .
2010-04-22 01:33:44 +02:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Goal:< / em > < / span > Detect cases where
2009-10-05 20:04:44 +02:00
< code class = "code" > list< / code > could be substituted with < code class = "code" > vector< / code > for
better performance.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Fundamentals:< / em > < / span >
2009-10-05 20:04:44 +02:00
Iterating through a vector is faster than through a list.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Sample runtime reduction:< / em > < / span > 64%.
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Recommendation:< / em > < / span > Replace list with vector
at site S.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > To instrument:< / em > < / span > < code class = "code" > vector< / code >
operations and access methods.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Analysis:< / em > < / span >
2009-10-05 20:04:44 +02:00
Issue the advice if there are no < code class = "code" > insert< / code > operations.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Cost model:< / em > < / span >
2009-10-05 20:04:44 +02:00
(Sum(cost(vector::method)) - Sum(cost(list::method)), for
method in [push_back, insert, erase])
2010-04-22 01:33:44 +02:00
+ (Cost(iterate vector) - Cost(iterate list))< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Example:< / em > < / span >
2009-10-05 20:04:44 +02:00
< / p > < pre class = "programlisting" >
1 list< int> l;
...
2 int sum = 0;
3 for (list< int> ::iterator it = l.begin(); it != l.end(); ++it) {
4 sum += *it;
5 }
foo.cc:1: advice: Changing "list" to "vector" will save about 1000000 indirect
memory references.
< / pre > < p >
2013-02-12 00:24:26 +01:00
< / p > < / li > < / ul > < / div > < / div > < div class = "section" > < div class = "titlepage" > < div > < div > < h4 class = "title" > < a id = "manual.ext.profile_mode.analysis.list_to_slist" > < / a > List to Forward List (Slist)< / h4 > < / div > < / div > < / div > < div class = "itemizedlist" > < ul class = "itemizedlist" style = "list-style-type: disc; " > < li class = "listitem" > < p > < span class = "emphasis" > < em > Switch:< / em > < / span >
2010-01-12 02:37:06 +01:00
< code class = "code" > _GLIBCXX_PROFILE_LIST_TO_SLIST< / code > .
2010-04-22 01:33:44 +02:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Goal:< / em > < / span > Detect cases where
2010-01-12 02:37:06 +01:00
< code class = "code" > list< / code > could be substituted with < code class = "code" > forward_list< / code > for
better performance.
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Fundamentals:< / em > < / span >
The memory footprint of a forward_list is smaller than that of a list.
This has beneficial effects on memory subsystem, e.g., fewer cache misses.
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Sample runtime reduction:< / em > < / span > 40%.
Note that the reduction is only noticeable if the size of the forward_list
node is in fact larger than that of the list node. For memory allocators
with size classes, you will only notice an effect when the two node sizes
belong to different allocator size classes.
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Recommendation:< / em > < / span > Replace list with
forward_list at site S.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > To instrument:< / em > < / span > < code class = "code" > list< / code >
operations and iteration methods.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Analysis:< / em > < / span >
Issue the advice if there are no < code class = "code" > backwards< / code > traversals
or insertion before a given node.
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Cost model:< / em > < / span >
2010-04-22 01:33:44 +02:00
Always true.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Example:< / em > < / span >
2010-01-12 02:37:06 +01:00
< / p > < pre class = "programlisting" >
1 list< int> l;
...
2 int sum = 0;
3 for (list< int> ::iterator it = l.begin(); it != l.end(); ++it) {
4 sum += *it;
5 }
foo.cc:1: advice: Change "list" to "forward_list".
< / pre > < p >
2013-02-12 00:24:26 +01:00
< / p > < / li > < / ul > < / div > < / div > < div class = "section" > < div class = "titlepage" > < div > < div > < h4 class = "title" > < a id = "manual.ext.profile_mode.analysis.assoc_ord_to_unord" > < / a > Ordered to Unordered Associative Container< / h4 > < / div > < / div > < / div > < div class = "itemizedlist" > < ul class = "itemizedlist" style = "list-style-type: disc; " > < li class = "listitem" > < p > < span class = "emphasis" > < em > Switch:< / em > < / span >
2009-10-05 20:04:44 +02:00
< code class = "code" > _GLIBCXX_PROFILE_ORDERED_TO_UNORDERED< / code > .
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Goal:< / em > < / span > Detect cases where ordered
2009-10-05 20:04:44 +02:00
associative containers can be replaced with unordered ones.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Fundamentals:< / em > < / span >
2010-04-22 01:33:44 +02:00
Insert and search are quicker in a hashtable than in
2010-01-05 21:51:05 +01:00
a red-black tree.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Sample runtime reduction:< / em > < / span > 52%.
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Recommendation:< / em > < / span >
Replace set with unordered_set at site S.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > To instrument:< / em > < / span >
2009-10-05 20:04:44 +02:00
< code class = "code" > set< / code > , < code class = "code" > multiset< / code > , < code class = "code" > map< / code > ,
2010-01-05 21:51:05 +01:00
< code class = "code" > multimap< / code > methods.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Analysis:< / em > < / span >
2009-10-05 20:04:44 +02:00
Issue the advice only if we are not using operator < code class = "code" > ++< / code > on any
iterator on a particular < code class = "code" > [multi]set|map< / code > .
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Cost model:< / em > < / span >
2009-10-05 20:04:44 +02:00
(Sum(cost(hashtable::method)) - Sum(cost(rbtree::method)), for
method in [insert, erase, find])
2010-01-05 21:51:05 +01:00
+ (Cost(iterate hashtable) - Cost(iterate rbtree))< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Example:< / em > < / span >
2009-10-05 20:04:44 +02:00
< / p > < pre class = "programlisting" >
1 set< int> s;
2 for (int i = 0; i < 100000; ++i) {
3 s.insert(i);
4 }
5 int sum = 0;
6 for (int i = 0; i < 100000; ++i) {
7 sum += *s.find(i);
8 }
< / pre > < p >
2013-02-12 00:24:26 +01:00
< / p > < / li > < / ul > < / div > < / div > < / div > < div class = "section" > < div class = "titlepage" > < div > < div > < h3 class = "title" > < a id = "manual.ext.profile_mode.analysis.algorithms" > < / a > Algorithms< / h3 > < / div > < / div > < / div > < p > < span class = "emphasis" > < em > Switch:< / em > < / span >
2009-10-05 20:04:44 +02:00
< code class = "code" > _GLIBCXX_PROFILE_ALGORITHMS< / code > .
2013-02-12 00:24:26 +01:00
< / p > < div class = "section" > < div class = "titlepage" > < div > < div > < h4 class = "title" > < a id = "manual.ext.profile_mode.analysis.algorithms.sort" > < / a > Sort Algorithm Performance< / h4 > < / div > < / div > < / div > < div class = "itemizedlist" > < ul class = "itemizedlist" style = "list-style-type: disc; " > < li class = "listitem" > < p > < span class = "emphasis" > < em > Switch:< / em > < / span >
2009-10-05 20:04:44 +02:00
< code class = "code" > _GLIBCXX_PROFILE_SORT< / code > .
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Goal:< / em > < / span > Give measure of sort algorithm
2009-10-05 20:04:44 +02:00
performance based on actual input. For instance, advise Radix Sort over
Quick Sort for a particular call context.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Fundamentals:< / em > < / span >
2010-04-22 01:33:44 +02:00
See papers:
2013-04-02 02:09:44 +02:00
< a class = "link" href = "https://dl.acm.org/citation.cfm?doid=1065944.1065981" target = "_top" >
2010-04-22 01:33:44 +02:00
A framework for adaptive algorithm selection in STAPL< / a > and
2012-08-29 04:09:55 +02:00
< a class = "link" href = "http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=4228227" target = "_top" >
2009-10-05 20:04:44 +02:00
Optimizing Sorting with Machine Learning Algorithms< / a > .
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Sample runtime reduction:< / em > < / span > 60%.
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Recommendation:< / em > < / span > Change sort algorithm
at site S from X Sort to Y Sort.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > To instrument:< / em > < / span > < code class = "code" > sort< / code >
algorithm.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Analysis:< / em > < / span >
2009-10-05 20:04:44 +02:00
Issue the advice if the cost model tells us that another sort algorithm
2010-04-22 01:33:44 +02:00
would do better on this input. Requires us to know what algorithm we
2010-01-05 21:51:05 +01:00
are using in our sort implementation in release mode.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Cost model:< / em > < / span >
Runtime(algo) for algo in [radix, quick, merge, ...]< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Example:< / em > < / span >
2009-10-05 20:04:44 +02:00
< / p > < pre class = "programlisting" >
< / pre > < p >
2013-02-12 00:24:26 +01:00
< / p > < / li > < / ul > < / div > < / div > < / div > < div class = "section" > < div class = "titlepage" > < div > < div > < h3 class = "title" > < a id = "manual.ext.profile_mode.analysis.locality" > < / a > Data Locality< / h3 > < / div > < / div > < / div > < p > < span class = "emphasis" > < em > Switch:< / em > < / span >
2009-10-05 20:04:44 +02:00
< code class = "code" > _GLIBCXX_PROFILE_LOCALITY< / code > .
2013-02-12 00:24:26 +01:00
< / p > < div class = "section" > < div class = "titlepage" > < div > < div > < h4 class = "title" > < a id = "manual.ext.profile_mode.analysis.locality.sw_prefetch" > < / a > Need Software Prefetch< / h4 > < / div > < / div > < / div > < div class = "itemizedlist" > < ul class = "itemizedlist" style = "list-style-type: disc; " > < li class = "listitem" > < p > < span class = "emphasis" > < em > Switch:< / em > < / span >
2009-10-05 20:04:44 +02:00
< code class = "code" > _GLIBCXX_PROFILE_SOFTWARE_PREFETCH< / code > .
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Goal:< / em > < / span > Discover sequences of indirect
2009-10-05 20:04:44 +02:00
memory accesses that are not regular, thus cannot be predicted by
hardware prefetchers.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Fundamentals:< / em > < / span >
2009-10-05 20:04:44 +02:00
Indirect references are hard to predict and are very expensive when they
2010-01-05 21:51:05 +01:00
miss in caches.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Sample runtime reduction:< / em > < / span > 25%.
2010-04-22 01:33:44 +02:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Recommendation:< / em > < / span > Insert prefetch
2010-01-05 21:51:05 +01:00
instruction.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > To instrument:< / em > < / span > Vector iterator and
2009-10-05 20:04:44 +02:00
access operator [].
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Analysis:< / em > < / span >
2009-10-05 20:04:44 +02:00
First, get cache line size and page size from system.
Then record iterator dereference sequences for which the value is a pointer.
2010-04-22 01:33:44 +02:00
For each sequence within a container, issue a warning if successive pointer
2009-10-05 20:04:44 +02:00
addresses are not within cache lines and do not form a linear pattern
(otherwise they may be prefetched by hardware).
If they also step across page boundaries, make the warning stronger.
< / p > < p > The same analysis applies to containers other than vector.
However, we cannot give the same advice for linked structures, such as list,
as there is no random access to the n-th element. The user may still be
able to benefit from this information, for instance by employing frays (user
level light weight threads) to hide the latency of chasing pointers.
< / p > < p >
This analysis is a little oversimplified. A better cost model could be
created by understanding the capability of the hardware prefetcher.
2010-04-22 01:33:44 +02:00
This model could be trained automatically by running a set of synthetic
2009-10-05 20:04:44 +02:00
cases.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Cost model:< / em > < / span >
2009-10-05 20:04:44 +02:00
Total distance between pointer values of successive elements in vectors
2010-04-22 01:33:44 +02:00
of pointers.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Example:< / em > < / span >
2009-10-05 20:04:44 +02:00
< / p > < pre class = "programlisting" >
1 int zero = 0;
2 vector< int*> v(10000000, & zero);
3 for (int k = 0; k < 10000000; ++k) {
4 v[random() % 10000000] = new int(k);
5 }
6 for (int j = 0; j < 10000000; ++j) {
7 count += (*v[j] == 0 ? 0 : 1);
8 }
foo.cc:7: advice: Insert prefetch instruction.
< / pre > < p >
2013-02-12 00:24:26 +01:00
< / p > < / li > < / ul > < / div > < / div > < div class = "section" > < div class = "titlepage" > < div > < div > < h4 class = "title" > < a id = "manual.ext.profile_mode.analysis.locality.linked" > < / a > Linked Structure Locality< / h4 > < / div > < / div > < / div > < div class = "itemizedlist" > < ul class = "itemizedlist" style = "list-style-type: disc; " > < li class = "listitem" > < p > < span class = "emphasis" > < em > Switch:< / em > < / span >
2009-10-05 20:04:44 +02:00
< code class = "code" > _GLIBCXX_PROFILE_RBTREE_LOCALITY< / code > .
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Goal:< / em > < / span > Give measure of locality of
2009-10-05 20:04:44 +02:00
objects stored in linked structures (lists, red-black trees and hashtables)
with respect to their actual traversal patterns.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Fundamentals:< / em > < / span > Allocation can be tuned
2009-10-05 20:04:44 +02:00
to a specific traversal pattern, to result in better data locality.
2010-04-22 01:33:44 +02:00
See paper:
2012-08-29 04:09:55 +02:00
< a class = "link" href = "http://www.springerlink.com/content/8085744l00x72662/" target = "_top" >
2009-10-05 20:04:44 +02:00
Custom Memory Allocation for Free< / a > .
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Sample runtime reduction:< / em > < / span > 30%.
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Recommendation:< / em > < / span >
2009-10-05 20:04:44 +02:00
High scatter score N for container built at site S.
Consider changing allocation sequence or choosing a structure conscious
2010-04-22 01:33:44 +02:00
allocator.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > To instrument:< / em > < / span > Methods of all
2010-01-05 21:51:05 +01:00
containers using linked structures.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Analysis:< / em > < / span >
2009-10-05 20:04:44 +02:00
First, get cache line size and page size from system.
Then record the number of successive elements that are on different line
or page, for each traversal method such as < code class = "code" > find< / code > . Give advice
only if the ratio between this number and the number of total node hops
2010-01-05 21:51:05 +01:00
is above a threshold.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Cost model:< / em > < / span >
Sum(same_cache_line(this,previous))< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Example:< / em > < / span >
2009-10-05 20:04:44 +02:00
< / p > < pre class = "programlisting" >
1 set< int> s;
2 for (int i = 0; i < 10000000; ++i) {
3 s.insert(i);
4 }
5 set< int> s1, s2;
6 for (int i = 0; i < 10000000; ++i) {
7 s1.insert(i);
8 s2.insert(i);
9 }
...
// Fast, better locality.
10 for (set< int> ::iterator it = s.begin(); it != s.end(); ++it) {
11 sum += *it;
12 }
// Slow, elements are further apart.
13 for (set< int> ::iterator it = s1.begin(); it != s1.end(); ++it) {
14 sum += *it;
15 }
foo.cc:5: advice: High scatter score NNN for set built here. Consider changing
the allocation sequence or switching to a structure conscious allocator.
< / pre > < p >
2013-02-12 00:24:26 +01:00
< / p > < / li > < / ul > < / div > < / div > < / div > < div class = "section" > < div class = "titlepage" > < div > < div > < h3 class = "title" > < a id = "manual.ext.profile_mode.analysis.mthread" > < / a > Multithreaded Data Access< / h3 > < / div > < / div > < / div > < p >
2009-10-05 20:04:44 +02:00
The diagnostics in this group are not meant to be implemented short term.
They require compiler support to know when container elements are written
to. Instrumentation can only tell us when elements are referenced.
< / p > < p > < span class = "emphasis" > < em > Switch:< / em > < / span >
< code class = "code" > _GLIBCXX_PROFILE_MULTITHREADED< / code > .
2013-02-12 00:24:26 +01:00
< / p > < div class = "section" > < div class = "titlepage" > < div > < div > < h4 class = "title" > < a id = "manual.ext.profile_mode.analysis.mthread.ddtest" > < / a > Data Dependence Violations at Container Level< / h4 > < / div > < / div > < / div > < div class = "itemizedlist" > < ul class = "itemizedlist" style = "list-style-type: disc; " > < li class = "listitem" > < p > < span class = "emphasis" > < em > Switch:< / em > < / span >
2009-10-05 20:04:44 +02:00
< code class = "code" > _GLIBCXX_PROFILE_DDTEST< / code > .
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Goal:< / em > < / span > Detect container elements
2009-10-05 20:04:44 +02:00
that are referenced from multiple threads in the parallel region or
across parallel regions.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Fundamentals:< / em > < / span >
2009-10-05 20:04:44 +02:00
Sharing data between threads requires communication and perhaps locking,
which may be expensive.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Sample runtime reduction:< / em > < / span > ?%.
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Recommendation:< / em > < / span > Change data
distribution or parallel algorithm.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > To instrument:< / em > < / span > Container access methods
2009-10-05 20:04:44 +02:00
and iterators.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Analysis:< / em > < / span >
2009-10-05 20:04:44 +02:00
Keep a shadow for each container. Record iterator dereferences and
container member accesses. Issue advice for elements referenced by
multiple threads.
2013-04-02 02:09:44 +02:00
See paper: < a class = "link" href = "https://dl.acm.org/citation.cfm?id=207110.207148" target = "_top" >
2010-04-22 01:33:44 +02:00
The LRPD test: speculative run-time parallelization of loops with
2009-10-05 20:04:44 +02:00
privatization and reduction parallelization< / a > .
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Cost model:< / em > < / span >
2009-10-05 20:04:44 +02:00
Number of accesses to elements referenced from multiple threads
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Example:< / em > < / span >
2009-10-05 20:04:44 +02:00
< / p > < pre class = "programlisting" >
< / pre > < p >
2013-02-12 00:24:26 +01:00
< / p > < / li > < / ul > < / div > < / div > < div class = "section" > < div class = "titlepage" > < div > < div > < h4 class = "title" > < a id = "manual.ext.profile_mode.analysis.mthread.false_share" > < / a > False Sharing< / h4 > < / div > < / div > < / div > < div class = "itemizedlist" > < ul class = "itemizedlist" style = "list-style-type: disc; " > < li class = "listitem" > < p > < span class = "emphasis" > < em > Switch:< / em > < / span >
2009-10-05 20:04:44 +02:00
< code class = "code" > _GLIBCXX_PROFILE_FALSE_SHARING< / code > .
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Goal:< / em > < / span > Detect elements in the
2010-04-22 01:33:44 +02:00
same container which share a cache line, are written by at least one
2009-10-05 20:04:44 +02:00
thread, and accessed by different threads.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Fundamentals:< / em > < / span > Under these assumptions,
2009-10-05 20:04:44 +02:00
cache protocols require
communication to invalidate lines, which may be expensive.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Sample runtime reduction:< / em > < / span > 68%.
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Recommendation:< / em > < / span > Reorganize container
or use padding to avoid false sharing.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > To instrument:< / em > < / span > Container access methods
2009-10-05 20:04:44 +02:00
and iterators.
2010-01-05 21:51:05 +01:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Analysis:< / em > < / span >
2009-10-05 20:04:44 +02:00
First, get the cache line size.
2010-04-22 01:33:44 +02:00
For each shared container, record all the associated iterator dereferences
2009-10-05 20:04:44 +02:00
and member access methods with the thread id. Compare the address lists
2010-04-22 01:33:44 +02:00
across threads to detect references in two different threads to the same
cache line. Issue a warning only if the ratio to total references is
significant. Do the same for iterator dereference values if they are
2010-01-05 21:51:05 +01:00
pointers.< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Cost model:< / em > < / span >
2009-10-05 20:04:44 +02:00
Number of accesses to same cache line from different threads.
2010-04-22 01:33:44 +02:00
< / p > < / li > < li class = "listitem" > < p > < span class = "emphasis" > < em > Example:< / em > < / span >
2009-10-05 20:04:44 +02:00
< / p > < pre class = "programlisting" >
1 vector< int> v(2, 0);
2 #pragma omp parallel for shared(v, SIZE) schedule(static, 1)
3 for (i = 0; i < SIZE; ++i) {
4 v[i % 2] += i;
5 }
OMP_NUM_THREADS=2 ./a.out
2010-04-22 01:33:44 +02:00
foo.cc:1: advice: Change container structure or padding to avoid false
2009-10-05 20:04:44 +02:00
sharing in multithreaded access at foo.cc:4. Detected N shared cache lines.
< / pre > < p >
2013-02-12 00:24:26 +01:00
< / p > < / li > < / ul > < / div > < / div > < / div > < div class = "section" > < div class = "titlepage" > < div > < div > < h3 class = "title" > < a id = "manual.ext.profile_mode.analysis.statistics" > < / a > Statistics< / h3 > < / div > < / div > < / div > < p >
2009-10-05 20:04:44 +02:00
< span class = "emphasis" > < em > Switch:< / em > < / span >
< code class = "code" > _GLIBCXX_PROFILE_STATISTICS< / code > .
< / p > < p >
In some cases the cost model may not tell us anything because the costs
appear to offset the benefits. Consider the choice between a vector and
a list. When there are both inserts and iteration, an automatic advice
may not be issued. However, the programmer may still be able to make use
of this information in a different way.
< / p > < p >
This diagnostic will not issue any advice, but it will print statistics for
each container construction site. The statistics will contain the cost
of each operation actually performed on the container.
2013-02-12 00:24:26 +01:00
< / p > < / div > < / div > < div class = "navfooter" > < hr / > < table width = "100%" summary = "Navigation footer" > < tr > < td width = "40%" align = "left" > < a accesskey = "p" href = "profile_mode_devel.html" > Prev< / a > < / td > < td width = "20%" align = "center" > < a accesskey = "u" href = "profile_mode.html" > Up< / a > < / td > < td width = "40%" align = "right" > < a accesskey = "n" href = "mt_allocator.html" > Next< / a > < / td > < / tr > < tr > < td width = "40%" align = "left" valign = "top" > Developer Information < / td > < td width = "20%" align = "center" > < a accesskey = "h" href = "../index.html" > Home< / a > < / td > < td width = "40%" align = "right" valign = "top" > < / td > < / tr > < / table > < / div > < / body > < / html >
