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. >> >> -- -- 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.
