> > Glad its working now! I'm no expert in the Chromium dev tools, but I > thought connecting the debugger forced v8 to run *all* JS non-optimized. > I'm very surprised that it appears to be different at M31. Did you really > run the tests via debugger there as well?
Experimenting with this, the debugger also makes M31 slower, but to a much lesser degree (about 1/3rd the impact) than on M37. So our benchmarks were always inaccurate, they were just less inaccurate on M31! Now that everything is running without any debugger interference, the numbers are roughly comparable between M31 and M37. The Octane score is slightly higher (M31: 1104, M37: 1217), but the SunSpider results are worse (M31: 2935.2ms +/- 4.0%, M37: 3688.8ms +/- 2.4%). On Tuesday, 4 November 2014 12:30:04 UTC-5, Toon Verwaest wrote: > > Note that --always-opt is an internal debugging flag, not a flag for > higher performance. Most often it will result is way lower performance due > to missing type feedback necessary for good optimized code. > > On Tue Nov 04 2014 at 4:10:52 PM Stephen <[email protected] <javascript:>> > wrote: > >> Success! >> >> I ran the Octane benchmarks with a developer tools session attached, >> hooking some code to tab to the 'Start Octane 2.0' button and press it >> instead, and got the following much more sensible results: >> >> Richards: 2189 >> DeltaBlue: 2936 >> Crypto: 1355 >> RayTrace: 2532 >> EarleyBoyer: 1801 >> RegExp: 209 >> Splay: 318 >> SplayLatency: 2243 >> NavierStokes: 1073 >> PdfJS: 592 >> Mandreel: 763 >> MandreelLatency: 442 >> Gameboy: 1610 >> CodeLoad: 886 >> Box2D: 739 >> zlib: 2863 >> Typescript: 1081 >> Total: 1087 >> >> I then tried settings --js-flags="--always-opt" and using our normal >> developer tools approach, but that didn't seem to work (so 'always' doesnt >> really mean 'always'?). '--nodebugger' also didnt seem to affect things. >> Any ideas on how one could attach remote developer tools but still have V8 >> do its optimizations? >> >> Thanks, >> Stephen >> >> On Tuesday, 4 November 2014 09:25:02 UTC-5, Stephen wrote: >>> >>> Hi Paul, >>> >>> Thanks for the quick and enthusiastic reply! Notes inline: >>> >>> I see _no_ perf degradation. This is on 'mipsel', a mips32r2 device with >>>> floating point. >>> >>> >>> Alas, I am not that surprised. I assumed that such a large performance >>> hit wouldn't have slipped past the v8 folks, so I was reckoning it would >>> turn out to be something platform/environment specific. >>> >>> Such a serious perf drop is very likely due to incorrect >>>> deoptimizations. Or in the browser you could try >>>> --js-flags="--trace-deopt" >>>> in the browser. If you get something, please send logs. >>> >>> >>> I ran with --trace-opt and --trace-deopt this morning, and got some very >>> interesting logs, attached (and truncated, because its just the same thing >>> over and over). It looks like v8 is not incorrectly deoptimizing, instead >>> it is actually failing to optimize because it thinks the debugger is on: >>> >>> "[failed to optimize am3: Debugger is active]" >>> >>> Do you know how v8 decides if its in debug mode? We are building >>> Chromium for Release, so I'm not sure why it would put v8 in debug mode (if >>> that's what is happening here). I do fire the Octane tests via an attached >>> Chrome Developer Tools session, so I wonder if that puts v8 into debug mode? >>> >>> As far as debugging on your side, I suggest you do try v8 standalone >>>> >>> >>> Still working on this, albeit it may be moot. Managed to get it build >>> correctly for our platform but running into SIGILL when running Octane, so >>> either something is horribly corrupted or I failed to describe our platform >>> correctly to the build process :). >>> >>> On Monday, 3 November 2014 19:59:16 UTC-5, paul lind wrote: >>>> >>>> Hi Stephen - >>>> >>>> I've built v8 standalone at today's top-of-tree, the top of 3.27 branch >>>> (3.27.34.21), and your specific version 3.27.34.0) and all are fine. >>>> >>>> I see _no_ perf degradation. This is on 'mipsel', a mips32r2 device >>>> with floating point. >>>> >>>> I've just checked a Chromium ToT Android build from mid-last week, and >>>> it looks fine also. I will pull a M37 release branch, and build that too. >>>> >>>> You are on 37.0.2062.0. I see Android stable is on 37.0.2062.117. Not >>>> that it should make any difference with this terrible perf drop you are >>>> seeing. >>>> >>>> I'll build both Android and Linux at 37.0.2062.0 and see what I find. >>>> I've not looked at your traces in detail yet, I've been just >>>> sanity-checking perf on the devices we usually test on. >>>> >>>> As far as debugging on your side, I suggest you do try v8 standalone. >>>> Also, I'm using gcc 4.8.1 for these tests, using the Mentor/Code-Sourcery >>>> lite toolchain available here: >>>> https://sourcery.mentor.com/GNUToolchain/package12215/ >>>> public/mips-linux-gnu/mips-2013.11-36-mips-linux-gnu- >>>> i686-pc-linux-gnu.tar.bz2 >>>> >>>> paul >>>> >>>> >>>> On Nov 3, 2014, at 3:43 PM, Paul Lind <[email protected]> wrote: >>>> >>>> Very sorry Stephen, that is crazy bad. We'll get on this immediately >>>> and get it understood and fixed asap. >>>> >>>> paul >>>> >>>> >>>> On Nov 3, 2014, at 2:59 PM, Stephen <[email protected]> wrote: >>>> >>>> Dear v8-users, >>>> >>>> We have a port of Chromium to a MIPS(el) embedded system, and are >>>> currently in the process of upgrading it from M31 (31.0.1650.61, v8 >>>> version >>>> 3.21.18.9[1]) to M37 (37.0.2062.0, v8 version 3.27.34.0[1]). In doing so, >>>> we have run into what seems to be a serious regression in V8 performance. >>>> Running the Octane benchmark (http://octane-benchmark. >>>> googlecode.com/svn/latest/index.html), these are the numbers on our >>>> platform for M31 and M37: >>>> >>>> M31: >>>> >>>> Richards: 1578 >>>> DeltaBlue: 951 >>>> Crypto: 1133 >>>> RayTrace: 1830 >>>> EarleyBoyer: 2347 >>>> RegExp: 256 >>>> Splay: 341 >>>> SplayLatency: 1434 >>>> NavierStokes: 1223 >>>> PdfJS: 580 >>>> Mandreel: 654 >>>> MandreelLatency: 649 >>>> Gameboy: 1112 >>>> CodeLoad: 756 >>>> Box2D: 501 >>>> zlib: 1769 >>>> Typescript: 887 >>>> Overall: 905 >>>> >>>> M37: >>>> >>>> Richards: 5.88 >>>> DeltaBlue: 3.66 >>>> Crypto: 21.4 >>>> RayTrace: 15.3 >>>> EarleyBoyer: 67.4 >>>> RegExp: 57.9 >>>> Splay: 55.5 >>>> SplayLatency: 487 >>>> NavierStokes: 36.6 >>>> PdfJS: 50.2 >>>> Mandreel: 4.60 >>>> MandreelLatency: 66.2 >>>> Gameboy: 1589 >>>> CodeLoad: 801 >>>> Box2D: 689 >>>> zlib: 2650 >>>> Typescript: 968 >>>> Overall: 87.0 >>>> >>>> Obviously we are rather concerned by these numbers - a 10x degradation >>>> in overall score, and nearly 300x in some benchmarks! SunSpider shows >>>> similar levels of regression - a 3x overall increase in time taken, and >>>> multiple 100x's in some individual benchmarks. >>>> >>>> I have begun to dig into some of the benchmarks, and am attaching >>>> traces taken against the Octane 'crypto' benchmark on M31 and M37 using >>>> the >>>> --js-flags="--perf" switch. The M37 version seems to spend an enormous >>>> amount of time in the 'am3' function: 16913 ticks (as opposed to 39 ticks >>>> in the M31 case). Might this indicate some sort of regression in MIPS math >>>> code? >>>> >>>> Are there any known performance regressions in v8 on MIPS(el) in M37, >>>> or any suggestions on how we can debug this further? Feel free to ask for >>>> further information/testing/etc, and I will do my best to provide! I have >>>> tried to build standalone ToT V8 for our platform, but ran into issues >>>> with >>>> warnings being converted to errors that I haven't dealt with yet. >>>> >>>> Thanks, >>>> Stephen >>>> >>>> [1]: According to http://omahaproxy.appspot.com/ >>>> >>>> -- >>>> -- >>>> v8-users mailing list >>>> [email protected] >>>> http://groups.google.com/group/v8-users >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "v8-users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> <v8_m37_crypto_trace.log><v8_m31_crypto_trace.log> >>>> >>>> >>>> >>>> -- >>>> -- >>>> v8-users mailing list >>>> [email protected] >>>> http://groups.google.com/group/v8-users >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "v8-users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> >>>> -- >> -- >> v8-users mailing list >> [email protected] <javascript:> >> http://groups.google.com/group/v8-users >> --- >> You received this message because you are subscribed to the Google Groups >> "v8-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > -- -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
