Ah, so you don't actually care about V8's compilers, you just want a stress test for the C++ parts of V8. Could have said so :-)
The optimizing compilers are indeed a large C++ component, but as discussed, turning those into a benchmark will require hackery and will not be representative of production use. There's a bunch more C++ code (GC, IC patching, slow fallback cases of various operations that are unsupported in generated code) that in some scenarios can account for more than half of all profiler ticks, but it'll be intermingled with execution of generated code, so it'll be hard or impossible to create a *pure* C++ benchmark from them. Maybe you don't require purity. The easiest approach would be to run some workload that just so happens to spend a lot of time in C++ code. For example, Octane's "Code-load" test spends 98% of its time in C++ (about 75% in parser and full-codegen, less than 1% in optimizing compilers). On Tue, Dec 8, 2015 at 5:38 PM, Abe Skolnik <a.skol...@samsung.com> wrote: > [Jakob Kummerow <jkumme...@chromium.org> wrote...] > > > What you want is not possible. > > "not possible" is a very strong phrase... perhaps "inadvisable" is more > appropriate to this particular case? > > > > JavaScript is not C. > > I know. > > > > V8 is not a C compiler. > > I know. > > > > Optimized compilation (not only when it triggers, but also what it does) > depends on type feedback > > I know. > > > > If you hack things to start optimized compilation immediately, > > then the generated optimized code > > (and, therefore, the work that the optimizing compiler is doing) > > will be very different from regular operation -- > > I know. > > > > so much so that I'd question the usefulness of profiling it. > > Well, I only want to profile the JS->native compilation itself. > > > > That said, V8 already has profiling facilities for its compilers: > > look at the --hydrogen-stats and --turbo-stats flags. Is that what you > want? > > I played around with some of the flags, esp. those with "prof", but maybe > not with those yet. Thanks for the hint[s]. > > > > in V8's world, note that for overall performance [...] three things need > to be balanced: > > - time spent in the optimizing compiler > > - execution speed of generated optimized code > > - selecting the right functions for optimization at the right time > > I know. > > > > Profiling the entire execution of a given workload has the implicit > benefit that it shows where the main bottleneck is. > > Agreed. > > > > I'm not sure how useful it is to look at only one aspect in isolation. > > I`m trying to judge how good a job the C++ compiler did of compiling V8, > so I don`t really care how good a job V8 did of compiling JS since that > will not [I hope! ;-)] vary as the C++ compiler -- and, potentially, the > flags given to it -- is/are varied and the V8 source code is held constant. > > Thanks for taking the time to write a detailed reply. > > Regards, > > Abe > > -- > -- > 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.
