Hi Florian,
On Fri, 2011-07-29 at 10:52 +0200, Florian Schneider wrote:
> Den 28. jul. 2011 16.12 skrev Andy Wingo <[email protected]>:
>
> On Thu, 2011-07-28 at 13:52 +0200, Florian Schneider wrote:
> > I didn't expect that, but it seems the additional allocation
> of Range
> > objects hurts performance considerably.
>
> I was under the (evidently mistaken) impression
> that InferRange would not be called for values with None
> representation.
> It is only called from ComputeInitialRange(), and that is only
> called
> from HRangeAnalysis::InferRange within a block to check for
> None
> representation, and in AddNewRange() -- but the details are a
> bit
> unclear to me.
>
>
> I thought the same. Have yet to identify the exact reason for the
> compilation time slowdown. It seems for some reason we allocate much
> more zone-memory during compilation of certain programs (e.g.
> crypto-aes from the Sunspider benchmarks). For now I'll revert and try
> to find a reliable reduce reproduction.
I added an allocation counter to HValue::InferRange (patch attached).
It will print out the total number of range allocations, indexed by the
representation of the HValue.
On bleeding_edge, running the files in sunspider looks like this:
wingo@badger:~/src/v8$ ./d8 ~/src/kraken/tests/sunspider-0.9.1/*.js
HValue::InferRange::RangeAllocCounter[0] = 0
HValue::InferRange::RangeAllocCounter[1] = 2322
HValue::InferRange::RangeAllocCounter[2] = 197
HValue::InferRange::RangeAllocCounter[3] = 213
HValue::InferRange::RangeAllocCounter[4] = 0
wingo@badger:~/src/v8$ ./d8 ~/src/kraken/tests/sunspider-0.9.1/*.js
HValue::InferRange::RangeAllocCounter[0] = 0
HValue::InferRange::RangeAllocCounter[1] = 2647
HValue::InferRange::RangeAllocCounter[2] = 206
HValue::InferRange::RangeAllocCounter[3] = 281
HValue::InferRange::RangeAllocCounter[4] = 0
wingo@badger:~/src/v8$ ./d8 ~/src/kraken/tests/sunspider-0.9.1/*.js
HValue::InferRange::RangeAllocCounter[0] = 0
HValue::InferRange::RangeAllocCounter[1] = 2470
HValue::InferRange::RangeAllocCounter[2] = 191
HValue::InferRange::RangeAllocCounter[3] = 252
HValue::InferRange::RangeAllocCounter[4] = 0
wingo@badger:~/src/v8$ ./d8 ~/src/kraken/tests/sunspider-0.9.1/*.js
HValue::InferRange::RangeAllocCounter[0] = 0
HValue::InferRange::RangeAllocCounter[1] = 2448
HValue::InferRange::RangeAllocCounter[2] = 194
HValue::InferRange::RangeAllocCounter[3] = 203
HValue::InferRange::RangeAllocCounter[4] = 0
wingo@badger:~/src/v8$ ./d8 ~/src/kraken/tests/sunspider-0.9.1/*.js
HValue::InferRange::RangeAllocCounter[0] = 0
HValue::InferRange::RangeAllocCounter[1] = 3022
HValue::InferRange::RangeAllocCounter[2] = 200
HValue::InferRange::RangeAllocCounter[3] = 267
HValue::InferRange::RangeAllocCounter[4] = 0
wingo@badger:~/src/v8$ ./d8 ~/src/kraken/tests/sunspider-0.9.1/*.js
HValue::InferRange::RangeAllocCounter[0] = 0
HValue::InferRange::RangeAllocCounter[1] = 2556
HValue::InferRange::RangeAllocCounter[2] = 197
HValue::InferRange::RangeAllocCounter[3] = 245
HValue::InferRange::RangeAllocCounter[4] = 0
The indexes are None, Tagged, Double, Int32, External, and respectively.
You can see that this function is not called for a None representation.
After applying the patch from r8753, the result is effectively the same:
wingo@badger:~/src/v8$ ./d8 ~/src/kraken/tests/sunspider-0.9.1/*.js
HValue::InferRange::RangeAllocCounter[0] = 0
HValue::InferRange::RangeAllocCounter[1] = 2786
HValue::InferRange::RangeAllocCounter[2] = 212
HValue::InferRange::RangeAllocCounter[3] = 291
HValue::InferRange::RangeAllocCounter[4] = 0
wingo@badger:~/src/v8$ ./d8 ~/src/kraken/tests/sunspider-0.9.1/*.js
HValue::InferRange::RangeAllocCounter[0] = 0
HValue::InferRange::RangeAllocCounter[1] = 2325
HValue::InferRange::RangeAllocCounter[2] = 158
HValue::InferRange::RangeAllocCounter[3] = 231
HValue::InferRange::RangeAllocCounter[4] = 0
wingo@badger:~/src/v8$ ./d8 ~/src/kraken/tests/sunspider-0.9.1/*.js
HValue::InferRange::RangeAllocCounter[0] = 0
HValue::InferRange::RangeAllocCounter[1] = 2724
HValue::InferRange::RangeAllocCounter[2] = 179
HValue::InferRange::RangeAllocCounter[3] = 261
HValue::InferRange::RangeAllocCounter[4] = 0
I am led to believe that range allocation did not cause the slowdown
that you were seeing. Could it be the part of the patch that did mark
unboxed doubles as possibly being -0? That is the only other change in
the patch, and it could cause more -0 checks to be emitted. However I
cannot see how stating that doubles cannot be -0 would be correct.
I will add instrumentation to count -0 checks.
Andy
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
diff --git a/src/hydrogen-instructions.cc b/src/hydrogen-instructions.cc
index 2be2a03..ecddbe0 100644
--- a/src/hydrogen-instructions.cc
+++ b/src/hydrogen-instructions.cc
@@ -861,7 +861,27 @@ void HInstanceOf::PrintDataTo(StringStream* stream) {
}
+class RangeAllocCounter {
+public:
+ RangeAllocCounter(const char *name="") : name_(name) {
+ for (int i = 0; i < Representation::kNumRepresentations; i++)
+ alloc_counts_[i] = 0;
+ }
+ ~RangeAllocCounter() {
+ for (int i = 0; i < Representation::kNumRepresentations; i++)
+ PrintF ("%s::RangeAllocCounter[%d] = %d\n", name_, i, alloc_counts_[i]);
+ }
+
+ void Count(Representation r) { alloc_counts_[static_cast<int>(r.kind())]++; }
+
+ const char *name_;
+ int alloc_counts_[Representation::kNumRepresentations];
+};
+
Range* HValue::InferRange() {
+ static RangeAllocCounter rcount("HValue::InferRange");
+
+ rcount.Count(representation());
if (representation().IsTagged()) {
// Tagged values are always in int32 range when converted to integer,
// but they can contain -0.
