Guys, tnx a lot to every one! Let me try to resubmit it and see how it turns out this time.
yours, anton. On Tue, Jun 9, 2009 at 5:53 PM, Erik Corry<[email protected]> wrote: > I think Anton should just reapply. It seems like it's a spurious > nonreproducable perf regression. > > 2009/6/9 Tobias Käs <[email protected]>: >> Thanks, this works, I don't get the results described though. I've tried it >> on several windows and linux machines but so far I wasn't able to reproduce >> the performance regression, the reported times are almost equal on idle >> machines. On machines with other users/processes working on it there is some >> noise but the average looks to be about equal across 20 runs. (I've >> recompiled r2110 and r2111 individually on each machine, except for two >> machines where the build segfaulted and I had to reapply r2110 to current >> edge, where the segfault seems to be fixed.) >> >> >> 2009/6/9 Erik Corry <[email protected]> >>> >>> 2009/6/9 Tobias Käs <[email protected]>: >>> > Sounds like we are talking about different scripts. The only one I could >>> >>> The correct string-add.js isn't in the repo: >>> >>> // Completely artificial String addition benchmark. >>> >>> function benchmark() { >>> var x = ""; >>> for (var i = 0; i < 1000000; i++) { >>> x = x + "x"; >>> } >>> x.indexOf('x'); // Flatten string. >>> } >>> >>> >>> var elapsed = 0; >>> var start = new Date(); >>> for (var n = 0; elapsed < 2000; n++) { >>> benchmark(); >>> elapsed = new Date() - start; >>> } >>> print('Time (string-add): ' + Math.floor(1000 * elapsed/n) + ' us.'); >>> >>> >>> > find was test/mjsunit/string-add.js ... which doesn't seem to do any >>> > timing >>> > by itself, just doing assertion checks - and the assert functions are >>> > defined in mjsunit.js which is why I'm getting an exception if I don't >>> > execute it before string-add.js >>> > >>> > Since I couldn't get any timing I added some myself in the main entry >>> > point, >>> > but that obviously includes startup/shutdown. That's also why I noticed >>> > shell calls V8::Dispose but d8 doesn't (at least not anywhere near the >>> > main >>> > entrypoint). >>> > >>> > I was trying to reproduce it on windows but I couldn't get any sensible >>> > values, everything drowned in the noise of startup/shutdown and was >>> > pretty >>> > much random. I could also test on several debian linux boxes, but it >>> > probably only makes sense if I find the correct script to run. Sorry I >>> > couldn't be of more help, I'm still trying to find my way around in the >>> > project and sometimes make stupid mistakes. >>> > >>> > 2009/6/8 Anton Muhin <[email protected]> >>> >> >>> >> Good day, Tobias! >>> >> >>> >> On Sat, Jun 6, 2009 at 11:34 AM, Tobias Käs<[email protected]> >>> >> wrote: >>> >> > I noticed that shell does a V8::Dispose and d8 doesn't do this ... is >>> >> > that included in your timing? Also, unless you are averaging multiple >>> >> > runs, the total time is so small that it may be just some startup/ >>> >> > shutdown noise? >>> >> >>> >> I did more runs and the pattern is really stable: d8 shows almost >>> >> identical times every time and shell shows this 1.5 slowdown most of >>> >> time, but not always. >>> >> >>> >> May you elaborate a bit on V8::Dispose? Timing is just as in >>> >> string-add.js, so that doesn't include startup/shutdown stuff. >>> >> >>> >> > >>> >> > PS: Are you using modified code or is this platform-specific >>> >> > behaviour? I had to add mjsunit.js to the command line, otherwise I'm >>> >> > getting an exception. Plus I don't get any timings out of d8/shell. >>> >> >>> >> Hmm, that was on Linux and ran just fine. What's the platform you >>> >> experienced problems on? >>> >> >>> >> Thanks a lot and yours, >>> >> anton. >>> >> >>> >> > >>> >> > On 5 Jun., 17:09, Anton Muhin <[email protected]> wrote: >>> >> >> Dear v8ers, >>> >> >> >>> >> >> Erik pointed out that my r2110 dramatically reduced performance of >>> >> >> several benchmarks, including string-add. I compiled two versions, >>> >> >> with and without 2110 and they ran fine on my box. Erik suggested >>> >> >> to >>> >> >> run them on newt.aar and here began the mistery: unless I misbuilt >>> >> >> the >>> >> >> stuff results look: >>> >> >> >>> >> >> ant...@newt:/home/erikcorry/b$ ~/d8-2110 string-add.js && ~/d8-2111 >>> >> >> string-add.js >>> >> >> Time (string-add): 301000 us. >>> >> >> Time (string-add): 301428 us. >>> >> >> ant...@newt:/home/erikcorry/b$ ~/d8-2110 string-add.js && ~/d8-2111 >>> >> >> string-add.js >>> >> >> Time (string-add): 301857 us. >>> >> >> Time (string-add): 302857 us. >>> >> >> ant...@newt:/home/erikcorry/b$ ~/d8-2110 string-add.js && ~/d8-2111 >>> >> >> string-add.js >>> >> >> Time (string-add): 309714 us. >>> >> >> Time (string-add): 306142 us. >>> >> >> ant...@newt:/home/erikcorry/b$ ~/d8-2110 string-add.js && ~/d8-2111 >>> >> >> string-add.js >>> >> >> Time (string-add): 300714 us. >>> >> >> Time (string-add): 301857 us. >>> >> >> ant...@newt:/home/erikcorry/b$ ~/d8-2110 string-add.js && ~/d8-2111 >>> >> >> string-add.js >>> >> >> Time (string-add): 301571 us. >>> >> >> Time (string-add): 300714 us. >>> >> >> ant...@newt:/home/erikcorry/b$ ~/d8-2110 string-add.js && ~/d8-2111 >>> >> >> string-add.js >>> >> >> Time (string-add): 302571 us. >>> >> >> Time (string-add): 301428 us. >>> >> >> ant...@newt:/home/erikcorry/b$ ~/shell-2110 string-add.js && >>> >> >> ~/shell-2111 string-add.js >>> >> >> Time (string-add): 446800 us. >>> >> >> Time (string-add): 302142 us. >>> >> >> ant...@newt:/home/erikcorry/b$ ~/shell-2110 string-add.js && >>> >> >> ~/shell-2111 string-add.js >>> >> >> Time (string-add): 306857 us. >>> >> >> Time (string-add): 309857 us. >>> >> >> ant...@newt:/home/erikcorry/b$ ~/shell-2110 string-add.js && >>> >> >> ~/shell-2111 string-add.js >>> >> >> Time (string-add): 449400 us. >>> >> >> Time (string-add): 303285 us. >>> >> >> ant...@newt:/home/erikcorry/b$ ~/shell-2110 string-add.js && >>> >> >> ~/shell-2111 string-add.js >>> >> >> Time (string-add): 436800 us. >>> >> >> Time (string-add): 306428 us. >>> >> >> ant...@newt:/home/erikcorry/b$ ~/shell-2110 string-add.js && >>> >> >> ~/shell-2111 string-add.js >>> >> >> Time (string-add): 432200 us. >>> >> >> Time (string-add): 304000 us. >>> >> >> >>> >> >> (r2111 rolls 2110 back, d8 and shell are corresponding binaries, >>> >> >> built >>> >> >> as scons -j4 sample=shell and scons -j4 d8 correspondingly). >>> >> >> >>> >> >> Fun facts: d8 for both 2110 and 2111 runs in same time, shell for >>> >> >> 2110 >>> >> >> usually runs 1.5 (!) longer, but sometimes (~10-20% of the cases) >>> >> >> identically to 2111. >>> >> >> >>> >> >> Does anyone have any idea what might have happened? Erik suggested >>> >> >> that things are linked somewhat differently. >>> >> >> >>> >> >> Change itself looks quite plain and it's not obvious how that can >>> >> >> introduce any regression: >>> >> >> >>> >> >> The only thing I can immediately see is expensive IsJSGlobalProxy, >>> >> >> but >>> >> >> why this is that instable, that'd be odd if more invocations to >>> >> >> IsJSGlobalProxy would lead to more GCing. >>> >> >> >>> >> >> Any ideas are most appreciated. >>> >> >> >>> >> >> tia and yours, >>> >> >> anton. >>> >> > >>> > >>> > >>> >>> >>> >>> -- >>> Erik Corry, Software Engineer >>> Google Denmark ApS. CVR nr. 28 86 69 84 >>> c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 >>> Copenhagen K, Denmark. >> >> > > > > -- > Erik Corry, Software Engineer > Google Denmark ApS. CVR nr. 28 86 69 84 > c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 > Copenhagen K, Denmark. > --~--~---------~--~----~------------~-------~--~----~ v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev -~----------~----~----~----~------~----~------~--~---
