What you want is not possible. JavaScript is not C. V8 is not a C compiler.

Optimized compilation (not only *when* it triggers, but also *what* it
does) depends on type feedback collected while unoptimized code was
executed. 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
-- so much so that I'd question the usefulness of profiling it.

That said, V8 already has profiling facilities for its compilers: look at
the --hydrogen-stats and --turbo-stats flags. Is that what you want?

Lastly, in V8's world, note that for overall performance (which at the end
of the day is the only thing that matters) 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
Profiling the entire execution of a given workload has the implicit benefit
that it shows where the main bottleneck is. I'm not sure how useful it is
to look at only one aspect in isolation.


On Tue, Dec 8, 2015 at 1:31 AM, Abe Skolnik <a.skol...@samsung.com> wrote:

> First: thanks very much!
>
> > d8 currently doesn't have functionality to parse but not execute source
> code,
> > although that should be trivial to add: just return before the call to
> script->Run() in Shell::ExecuteString() in src/d8.cc.
>
> Hmm...  but under the current/normal setup, that would also prevent
> compilation, since it`s execution-triggered JITC, right?
>
>
> > V8 is a tiered JIT compiler.  Native code is initially generated by the
> baseline (full-codegen) compiler,
> > Crankshaft and TurboFan don't come into play until the run-time profiler
> decides that a function is "hot"
>
> Yes.  I already knew that, but thanks for explaining anyway.
>
> What I want to do is to override that behavior and make it operate
> similarly to "normal" compilers such as GCC`s and Clang`s C compilers: in
> goes C code, out comes either [an] error message[s] or assembly/machine
> code, possibly with warnings either way.  Just substitute ECMAscript for C
> and V8 for Clang/GCC, and you get the picture of what I want.  However, I
> don`t care too much about the assembly/machine code -- all I really need is
> the profiling stats.
>
>
> > You can force the issue to some extent with the --always_opt flag but
> the optimizing compilers aren't very effective
> > when they haven't had time to collect run-time information.  You may end
> up profiling the wrong thing this way.
>
> > Functions are normally compiled lazily.  The baseline compiler doesn't
> emit native code
> > until the first time a function is called but you can force it to with
> the --nolazy flag.
>
> Thanks; I`m pretty sure I understand this topic.
>
>
> > The V8 team considers Crankshaft deprecated(ish), soon to be replaced
> with TurboFan.
> > You would probably do best to focus your efforts on the latter.
>
> Thanks.
>
> Although "--always_opt --nolazy" would probably be a good starting point,
> I`m sure it won`t accomplish all that I want.  In principle, I want to be
> able to profile full-codegen and TurboFan using JS tests that take minutes
> or hours to run, but only take seconds to compile, and to do so with only a
> few seconds spent on each such profiling run.
>
>
> Perhaps the only way to get exactly what I want is to write a new
> top-level program that will use V8 as a library, then invoke the phases
> myself "manually"?  In other words, to write a new compiler _driver_ while
> keeping all the actual compiler guts the same.
>
> Maybe "baking in" the flags "--always_opt" & "--nolazy" combined with your
> suggestion of "just return before the call to script->Run() [...]" would
> give me either exactly what I want or within epsilon of it?
>
>
> > Hope that helps.  Don't hesitate to ask more questions.
>
> Thanks again.
>
> 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.

Reply via email to