Re: [v8-users] What are no obvious reject reasons for cached data
On Fri, Apr 21, 2017 at 11:21 AM, Johannes Rieken wrote: > For some background: We are using cached data since a while in VS Code and > are quite happy with it. It's one of the simpler things to improve start up > time. The only downside is the slow down on first start when we generate > and store the cached data and I was thinking about making our build > machines do this. > You could also try the startup snapshot: This is similar to the code cache (in fact, the code cache implementation was derived from the startup snapshot). This is a build-time operation. It caches more code (that is, it compiles everything), and it runs the code generator so that code will be potentially less efficient, but independent of the cpu feature flags (that is, specialised to a CPU family; not to a particular model). The JS source + V8 source mismatch issue is auto-magically solved by being bundled with the binary. This is used by Chrome to speed up browser + tab startup. (This isn't super well document, though. See v8_extra_library_files in BUILD.gn.) An alternative, that would also work with code cache: Chrome Android has a similar problem. We discussed not running with snapshot/code cache, and then compiling (in idle time) the snapshot/code cache in a separate & "clean" process. That way, you can hide the cache generation time. You'd still have the initial unaided & somewhat slower startup. -- -- v8-users mailing list v8-users@googlegroups.com 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 v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] Why does a combination of optimization flags(--always-opt --turbo) and code caching show bad performance?
As Jochen already said on chromium-dev, --always-opt does not make things faster. This is expected. The purpose of the flag is to flush out certain kinds of bugs when running tests, at the cost of a big slowdown. Code caching has limits. It cannot cache everything. The default configuration is what we believe gives the best performance in general cases. There are no "secret" flags to make things faster. On Fri, Apr 21, 2017 at 9:27 AM, Jin Chul Kim wrote: > Hello, > > I am trying to reduce a execution time on general cases. My approach is a > combination of two features: fully optimized code generation + code caching. > In my experiment, I figured out that code caching is very powerful. By the > way, the execution time was significantly increased when I was using the > following flags: --always-opt. I know turboFan was enabled on the recent V8 > code. Here are my question. > > 1. As far as I know, code caching does not need code compilation to > generate machine(native) code. Is that correct? > > I checked trace with --trace-opt. There were many lines for optimizing and > compilation on code caching. why did them happen? > > [compiling method 0xed4b9e340c1 = 0xed4b9e31ea1)> using TurboFan] > [optimizing 0xed4b9e340c1 0xed4b9e31ea1)> - took 0.081, 0.356, 0.039 ms] > [compiling method 0x3d3958a8f609 0xed4b9e41829)> using TurboFan] > [optimizing 0x3d3958a8f609 0xed4b9e41829)> - took 0.109, 0.560, 0.060 ms] > [compiling method 0x3d3958a93a81 0xed4b9e3d401)> using TurboFan] > [optimizing 0x3d3958a93a81 0xed4b9e3d401)> - took 0.028, 0.086, 0.011 ms] > ... > > 2. Do you explain why execution time is significantly increased on w/ opt. > + w/ caching (examples 4) and 5) below)? > > If I was using the flag(--always-opt), the compiler may generates > optimized or unoptimized code. Then, I think the second run should be same > or better performance than the first run because it does not require > compilation and just loads binary. Please see my experiment result as below: > > - baseline: w/o opt. + w/o caching > 1) 24.06 secs > > - w/o opt. + w/ caching > 2) 1st run(save native code): 24.35 secs > 3) 2nd run(load native code): 16.94 secs > > - w/ opt. + w/ caching > 4) 1st run(save native code): 75.12 secs > 5) 2nd run(load native code): 74.02 secs > > 3. How may I generate an optimal code to decrease an execution time on > code caching? > > Many thanks, > Jinchul > > -- > -- > v8-users mailing list > v8-users@googlegroups.com > 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 v8-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- -- v8-users mailing list v8-users@googlegroups.com 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 v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] What are no obvious reject reasons for cached data
For some background: We are using cached data since a while in VS Code and are quite happy with it. It's one of the simpler things to improve start up time. The only downside is the slow down on first start when we generate and store the cached data and I was thinking about making our build machines do this. Thanks again for clarifying the API contract. I won't try some lucky shots with prebuilt data for the relatively monotone mac world ;-) Actually, we ran into this a while back. Our minifier had changed, producing slightly different code which didn't get rejected but causing things to go south [1]. We now use a stronger cache key such that we don't attempt to reuse bad cached data... Thanks and Happy Coding, Joh [1] https://github.com/Microsoft/vscode/issues/23841#issuecomment-291457502 On Friday, April 21, 2017 at 11:00:04 AM UTC+2, Johannes Rieken wrote: > > Thanks for clarifying! > > On Friday, April 21, 2017 at 10:00:03 AM UTC+2, Ben Noordhuis wrote: >> >> On Fri, Apr 21, 2017 at 9:51 AM, Johannes Rieken >> wrote: >> > Does the data depend on things like endian-ness, CPU etc or only >> > on v8-locals like v8-version and v8-flags? >> >> All of the above; it's machine-, version- and invocation-specific. >> > -- -- v8-users mailing list v8-users@googlegroups.com 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 v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] What are no obvious reject reasons for cached data
Thanks for clarifying! On Friday, April 21, 2017 at 10:00:03 AM UTC+2, Ben Noordhuis wrote: > > On Fri, Apr 21, 2017 at 9:51 AM, Johannes Rieken > > wrote: > > Does the data depend on things like endian-ness, CPU etc or only > > on v8-locals like v8-version and v8-flags? > > All of the above; it's machine-, version- and invocation-specific. > -- -- v8-users mailing list v8-users@googlegroups.com 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 v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] What are no obvious reject reasons for cached data
As Ben says: The code cache is specific the exact source string, the CPU (cpu family & cpu flags, e.g. whether certain features are supported), the exact V8 version (since there is no mechanism to guarantee correctness across versions), and the compile options (debug, release, certain features that affect code generation). Additional info: The API contract is meant to be that the embedder checks all these things, and it's the embedders duty to never hand us a cache w/ kConsumeCodeCache if there's a a source/v8 version/cpu mismatch. When trying to launch the feature (& shortly after), we had a bunch of weird crashes apparently related to code caching (likely from disk or RAM failures on cheap-ish machines, which happens at a noticeable rate with ~1e9 users), and so we added a number of checksums and sanity checks to the code caching. These are the primary reason why stuff gets rejected. But those where really meant as a last resort & sanity check, and it really means that the embedder shouldn't have given us that data in the first place. The sanity checks are mostly hash-sums. Hash collisions are possible, and then there'll be false positives. Looking back, I'm not sure that particular API was the best way of doing this. I hope it works well; I'll be happy to hear any feedback if it doesn't. On Fri, Apr 21, 2017 at 9:59 AM, Ben Noordhuis wrote: > On Fri, Apr 21, 2017 at 9:51 AM, Johannes Rieken > wrote: > > Does the data depend on things like endian-ness, CPU etc or only > > on v8-locals like v8-version and v8-flags? > > All of the above; it's machine-, version- and invocation-specific. > > -- > -- > v8-users mailing list > v8-users@googlegroups.com > 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 v8-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- -- v8-users mailing list v8-users@googlegroups.com 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 v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] What are no obvious reject reasons for cached data
On Fri, Apr 21, 2017 at 9:51 AM, Johannes Rieken wrote: > Does the data depend on things like endian-ness, CPU etc or only > on v8-locals like v8-version and v8-flags? All of the above; it's machine-, version- and invocation-specific. -- -- v8-users mailing list v8-users@googlegroups.com 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 v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[v8-users] What are no obvious reject reasons for cached data
We have a large chunk of (minified and bundled) code and I am using ` kProduceCodeCache` and `kConsumeCodeCache` to improve startup performance. I understand that cached data is rejected when the source changes but I wonder what else can cause this? I am especially interested if I can create cached data on build machines and distribute it with an app? Does the data depend on things like endian-ness, CPU etc or only on v8-locals like v8-version and v8-flags? -- -- v8-users mailing list v8-users@googlegroups.com 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 v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[v8-users] Why does a combination of optimization flags(--always-opt --turbo) and code caching show bad performance?
Hello, I am trying to reduce a execution time on general cases. My approach is a combination of two features: fully optimized code generation + code caching. In my experiment, I figured out that code caching is very powerful. By the way, the execution time was significantly increased when I was using the following flags: --always-opt. I know turboFan was enabled on the recent V8 code. Here are my question. 1. As far as I know, code caching does not need code compilation to generate machine(native) code. Is that correct? I checked trace with --trace-opt. There were many lines for optimizing and compilation on code caching. why did them happen? [compiling method 0xed4b9e340c1 using TurboFan] [optimizing 0xed4b9e340c1 - took 0.081, 0.356, 0.039 ms] [compiling method 0x3d3958a8f609 using TurboFan] [optimizing 0x3d3958a8f609 - took 0.109, 0.560, 0.060 ms] [compiling method 0x3d3958a93a81 using TurboFan] [optimizing 0x3d3958a93a81 - took 0.028, 0.086, 0.011 ms] ... 2. Do you explain why execution time is significantly increased on w/ opt. + w/ caching (examples 4) and 5) below)? If I was using the flag(--always-opt), the compiler may generates optimized or unoptimized code. Then, I think the second run should be same or better performance than the first run because it does not require compilation and just loads binary. Please see my experiment result as below: - baseline: w/o opt. + w/o caching 1) 24.06 secs - w/o opt. + w/ caching 2) 1st run(save native code): 24.35 secs 3) 2nd run(load native code): 16.94 secs - w/ opt. + w/ caching 4) 1st run(save native code): 75.12 secs 5) 2nd run(load native code): 74.02 secs 3. How may I generate an optimal code to decrease an execution time on code caching? Many thanks, Jinchul -- -- v8-users mailing list v8-users@googlegroups.com 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 v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.