Sweet, thanks! On Thu, Aug 6, 2015 at 9:18 AM Jaroslav Sevcik <[email protected]> wrote:
> Tomorrow, I will send you the change list that enables stack checks in > loops. (I am told it should be as easy as commenting out one line that > disables stack checks for asm.js in AstGraphBuilder::VisitIterationBody and > then benchmarking with Embenchen.) > > On Thu, Aug 6, 2015 at 6:10 PM, Mircea Trofin <[email protected]> > wrote: > >> On the perf topic, it'd be good to feed in the mix some benchmarks that >> validate that, indeed, spilling in deferred blocks brings value to the >> product. I understand these do not exist just yet, is that correct? Is >> there an ETA? >> >> On Thu, Aug 6, 2015 at 8:45 AM Mircea Trofin <[email protected]> >> wrote: >> >>> I'm investigating. >>> >>> On Thu, Aug 6, 2015 at 8:43 AM Jaroslav Sevcik <[email protected]> wrote: >>> >>>> Ouch, the numbers do not look too good. Any idea what is going on in >>>> Lua binary trees and towers.c? Is it compilation time that suffers or is >>>> the code quality worse? >>>> >>>> On Thu, Aug 6, 2015 at 5:36 PM, Mircea Trofin <[email protected]> >>>> wrote: >>>> >>>>> I though I sent perf earlier: >>>>> >>>>> >>>>> https://docs.google.com/spreadsheets/d/1x_W2r5DxIj8dySqMBgZw9zrodaOcjvh8XGuK-vhCBso/edit#gid=1835643316 >>>>> >>>>> see the "Deferred Blocks - do not split spill operands" tab. >>>>> >>>>> >>>>> On Thu, Aug 6, 2015 at 5:28 AM <[email protected]> wrote: >>>>> >>>>>> I think I understand now how the spilling works, but it is very >>>>>> subtle. >>>>>> Once you >>>>>> add explanatory comments, it will be good to go. >>>>>> >>>>>> What are the performance numbers? >>>>>> >>>>>> >>>>>> >>>>>> https://codereview.chromium.org/1271703002/diff/80001/src/compiler/register-allocator.cc >>>>>> File src/compiler/register-allocator.cc (right): >>>>>> >>>>>> >>>>>> https://codereview.chromium.org/1271703002/diff/80001/src/compiler/register-allocator.cc#newcode408 >>>>>> src/compiler/register-allocator.cc:408 >>>>>> <https://codereview.chromium.org/1271703002/diff/80001/src/compiler/register-allocator.cc#newcode408src/compiler/register-allocator.cc:408>: >>>>>> // the range and control flow >>>>>> connection mechanism instead. >>>>>> Please elaborate on how this uses the control flow connection >>>>>> mechanism. >>>>>> >>>>>> This incremental build-up of various moves is in my opinion the worst >>>>>> part of the register allocator (in terms of understandability and >>>>>> maintainability), and this CL makes it worse. It should be explained >>>>>> in >>>>>> the comments. >>>>>> >>>>>> >>>>>> https://codereview.chromium.org/1271703002/diff/80001/src/compiler/register-allocator.h >>>>>> File src/compiler/register-allocator.h (right): >>>>>> >>>>>> >>>>>> https://codereview.chromium.org/1271703002/diff/80001/src/compiler/register-allocator.h#newcode417 >>>>>> src/compiler/register-allocator.h:417 >>>>>> <https://codereview.chromium.org/1271703002/diff/80001/src/compiler/register-allocator.h#newcode417src/compiler/register-allocator.h:417>: >>>>>> // in which it may be worse to >>>>>> spill in it. >>>>>> The comment seems to be out of date (it refers to the ranges with just >>>>>> one spilled child). >>>>>> >>>>>> https://codereview.chromium.org/1271703002/ >>>>>> >>>>> >>>> >>>> >>>> -- >>>> ---------------------------------------------- >>>> >>>> >>>> >>>> *Jaroslav SevcikSoftware EngineerGoogle Germany GmbH* >>>> *Dienerstr. 12* >>>> >>>> *80331 München* >>>> ---------------------------------------------- >>>> Geschäftsführer: Graham Law, Christine Elizabeth Flores >>>> >>>> Sitz der Gesellschaft: Hamburg >>>> >>>> Registergericht und -nummer: Hamburg, HRB 86891 >>>> >>>> >>>> Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat >>>> sind, leiten Sie diese bitte nicht weiter, informieren Sie den Absender und >>>> löschen Sie die E-Mail und alle Anhänge. Vielen Dank. >>>> >>>> >>>> >>>> This e-mail is confidential. If you are not the right addressee please >>>> do not forward it, please inform the sender, and please erase this e-mail >>>> including any attachments. Thanks. >>>> >>>> Der Inhalt dieser E-Mail spiegelt den derzeitigen Stand der >>>> Verhandlungen wider und dient als Basis für weitere Gespräche. Er soll >>>> keine rechtlich verbindliche Verpflichtung begründen. Eine solche >>>> Verpflichtung wird allein durch einen zwischen allen beteiligten Parteien >>>> abgeschlossenen, schriftlichen Vertrag geschaffen. >>>> >>>> The above terms reflect a potential business arrangement, are provided >>>> solely as a basis for further discussion, and are not intended to be and do >>>> not constitute a legally binding obligation. No legally binding obligations >>>> will be created, implied, or inferred until an agreement in final form is >>>> executed in writing by all parties involved. >>>> >>>> > > > -- > ---------------------------------------------- > > > > *Jaroslav SevcikSoftware EngineerGoogle Germany GmbH* > *Dienerstr. 12* > > *80331 München* > ---------------------------------------------- > Geschäftsführer: Graham Law, Christine Elizabeth Flores > > Sitz der Gesellschaft: Hamburg > > Registergericht und -nummer: Hamburg, HRB 86891 > > > Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind, > leiten Sie diese bitte nicht weiter, informieren Sie den Absender und > löschen Sie die E-Mail und alle Anhänge. Vielen Dank. > > > > This e-mail is confidential. If you are not the right addressee please do > not forward it, please inform the sender, and please erase this e-mail > including any attachments. Thanks. > > Der Inhalt dieser E-Mail spiegelt den derzeitigen Stand der Verhandlungen > wider und dient als Basis für weitere Gespräche. Er soll keine rechtlich > verbindliche Verpflichtung begründen. Eine solche Verpflichtung wird allein > durch einen zwischen allen beteiligten Parteien abgeschlossenen, > schriftlichen Vertrag geschaffen. > > The above terms reflect a potential business arrangement, are provided > solely as a basis for further discussion, and are not intended to be and do > not constitute a legally binding obligation. No legally binding obligations > will be created, implied, or inferred until an agreement in final form is > executed in writing by all parties involved. > > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" 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.
