Here is the CL that adds stack/interrupt checks to loops: https://codereview.chromium.org/1273353002
Below are the perf numbers fox x64 Embenchen. As you can see, at the moment we would pay >10%, depending on benchmark (mem-ops being especially bad because it is just a tight loop). We hope that the deferred code spilling/splitting will make the checks essentially free. With stack/interrupt check in loops: EmbenchenBox2d(RunTime): 12611 ms. EmbenchenBullet(RunTime): 18108 ms. EmbenchenCopy(RunTime): 5128 ms. EmbenchenCorrections(RunTime): 7821 ms. EmbenchenFannkuch(RunTime): 6108 ms. EmbenchenFasta(RunTime): 13805 ms. EmbenchenLuaBinaryTrees(RunTime): 11213 ms. EmbenchenMemOps(RunTime): 22923 ms. EmbenchenPrimes(RunTime): 8122 ms. EmbenchenSkinning(RunTime): 17250 ms. EmbenchenZLib(RunTime): 13763 ms. Without stack/interrupt checks: EmbenchenBox2d(RunTime): 11221 ms. EmbenchenBullet(RunTime): 16720 ms. EmbenchenCopy(RunTime): 4867 ms. EmbenchenCorrections(RunTime): 6756 ms. EmbenchenFannkuch(RunTime): 4037 ms. EmbenchenFasta(RunTime): 9568 ms. EmbenchenLuaBinaryTrees(RunTime): 10310 ms. EmbenchenMemOps(RunTime): 5885 ms. EmbenchenPrimes(RunTime): 7490 ms. EmbenchenSkinning(RunTime): 15860 ms. EmbenchenZLib(RunTime): 10815 ms. On Thu, Aug 6, 2015 at 6:19 PM, Mircea Trofin <[email protected]> wrote: > 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. >> >> -- ---------------------------------------------- *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.
