[Bug translator/11695] DWIM promotion of ++ to <<<

[Bug translator/11695] DWIM promotion of ++ to <<<

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=11695

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #4 from Frank Ch. Eigler <fche at redhat dot com> ---
Not that compelling, and the translator may not have the wits to know whether
the write vs read*#cpus tradeoffs are worthwhile.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug translator/11695] DWIM promotion of ++ to <<<

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2010-06-14 09:26 -------
(In reply to comment #2)
> So this transformation is only worthwhile when updating the value is more common
> than reading it.

The example that triggered this was like that:

$ stap -e 'global modules;
  probe timer.profile { if (target() == pid()) modules[umodname(uaddr())]++ }
  probe end { foreach ([m] in modules- limit 5)
              { printf("%4d:%s\n", modules[m], m) } }' -x `pidof firefox`

There are two advantages to using aggregates. It is "cheaper" in this use case.
And you don't necessarily need to write the end probe since systemtap detects
that it is only written to, so will generate the end probe printing it itself.
(That is bug #6954 for global arrays).

The disadvantage is that is it slightly obscure (you don't actually want the
whole aggregate, only the @count). And that the generated printing of the global
is somewhat messy (you get the whole aggregate printed out).

It might always be a win for global arrays that are never read.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11695

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/11695] DWIM promotion of ++ to <<<

[jistone at redhat dot com]

------- Additional Comments From jistone at redhat dot com  2010-06-11 15:52 -------
(In reply to comment #1)
> The aggregate doesn't need a global lock, it uses per-cpu counters.

It does have a lock, but the exclusiveness is inverted: <<< takes a read lock
and @extract takes a write lock.  You can think of it as locking the aggregate
structure, which you write to when @extracting data from the per-cpu structures.

So this transformation is only worthwhile when updating the value is more common
than reading it.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11695

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/11695] DWIM promotion of ++ to <<<

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2010-06-11 14:36 -------
In case it isn't clear why the transformation from scalar to aggregate is better
(as I did before it was explained to me). The aggregate doesn't need a global
lock, it uses per-cpu counters.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11695

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.