<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div>> OK, I actually meant CachedTable lookups. Hash table
lookups are an order of magnitude slower than array lookups.</div>
<div>> I assume the API is meant to be used like this:</div>
<div>> if (DFA.canReserveResources(MI))</div>
<div>> DFA.reserveResources(MI);<br>
><br>
<br>
</div>
Ah I see what you mean. On Hexagon, the canReserveResources() and
reserveResources() are never used together. We conduct a bunch of
dependency pruning/checking in between the two calls. Since the
dependency checking is relatively intricate we do not want to do
that unless there are enough resources to accommodate the
instruction in a packet.<br>
<br>
<br>
> As for renumbering the states, since the state numbers aren't
used for anything but indexing DFAStateEntryTable, <br>
> you can simply replace all state numbers
with DFAStateEntryTable[s], and you don't have to waste memory on
the table.<br>
<br>
That's a good idea; thanks! I'll need to remove CachedTable for this
and I can implement it along with the "splitting up the transition
table" work.<br>
<br>
-Anshu<br>
<br>
<tt>--<br>
Qualcomm Innovation Center, Inc is a member of Code Aurora Forum<br>
</tt><br>
<br>
<br>
On 11/29/2011 12:22 PM, Jakob Stoklund Olesen wrote:
<blockquote cite="mid:6F0200FC-AFFA-40EE-A66F-A6149E6862F7@2pi.dk"
type="cite"><br>
<div>
<div>On Nov 29, 2011, at 7:34 AM, Anshuman Dasgupta wrote:</div>
<div><br>
</div>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"><tt>> You are
building CachedTable on demand. Is that really necessary?
How much of the table is built in<br>
> a typical run? Would it be better/faster to just
build the whole thing up front?<br>
<br>
That was an interesting decision. So the reason why I
implemented CachedTable is that currently the DFA
generator constructs one common transition table for all
versions (subtargets) of Hexagon. As a result, when we
compile for a particular Hexagon subtarget, I noticed that
only part of the transition table is typically used. I
have plans to augment the DFA generator to create separate
tables for each Hexagon subtarget and once I do, I will
change this to load up the entire transition table. But
for now CachedTable is useful.<br>
</tt></div>
</blockquote>
<div><br>
</div>
<div>That makes perfect sense.</div>
<div><br>
</div>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">
<p class="MsoNormal"><span class="Apple-style-span"
style="font-family: monospace; font-size: 14px; ">>
You have 4 table lookups per DFA transition by my count.
It seems that 1 is enough. Can the API be improved to
allow that?</span></p>
<tt> </tt>
<p class="MsoPlainText"><tt>> Could you get rid of the
DFAStateEntryTable by renumbering your states?</tt></p>
<tt> </tt>
<p class="MsoPlainText"><tt>> s ->
DFAStateEntryTable[s]</tt></p>
<tt> </tt>
<p class="MsoPlainText"><tt>> This would preclude the
sparse transition matrix representation, of course.</tt></p>
<tt> </tt>
<p class="MsoPlainText"><tt> </tt></p>
<tt> </tt>
<p class="MsoPlainText"><tt>If I understand correctly, these
two questions are related. Let me answer them together.
I can change the code so that there is one lookup per
transition. That was my original design. However, most
of the table entries were invalid transitions. So, while
running TableGen, the I/O required to emit the table
became a bottleneck. It significantly slowed down the
Hexagon backend build time. Therefore I moved to a
sparse matrix representation.</tt></p>
</div>
</blockquote>
<div><br>
</div>
<div>OK, I actually meant CachedTable lookups. Hash table
lookups are an order of magnitude slower than array lookups.</div>
<div><br>
</div>
<div>I assume the API is meant to be used like this:</div>
<div><br>
</div>
<div> if (DFA.canReserveResources(MI))</div>
<div> DFA.reserveResources(MI);</div>
<div><br>
</div>
<div>That's 4 hash table lookups for a valid transition. 1
should be enough. For invalid transitions, you need two
lookups because CachedTable is lazily built.</div>
<div><br>
</div>
<div><br>
</div>
<div>As for renumbering the states, since the state numbers
aren't used for anything but indexing DFAStateEntryTable, you
can simply replace all state numbers
with DFAStateEntryTable[s], and you don't have to waste memory
on the table.</div>
<div><br>
</div>
<div>/jakob</div>
<div><br>
</div>
</div>
</blockquote>
<br>
</body>
</html>