On Thu, Jun 23, 2022 at 10:06 AM Jianxiao Lu <[email protected]> wrote:
> Test on an AWS server: > Intel(R) Xeon(R) Platinum 8275CL CPU @ 3.00GHz (16 cores) > > Running webtooling with d8 > > Here is the v8.gc tracing data: > [image: baseline.png] > > [image: 15worker.png] > Raw tracing log files: > https://drive.google.com/drive/folders/1NRQCjNQ5x9RDHA0AVvTOr8neuARyheq-?usp=sharing > > > For the concurrent marking speed, I simply sum up the KB and ms in the > trace log and divide them (KB/ms), > For each worker: > baseline: 640.5, 669.86, 684.72 > 15 workers:508.91, 515.51, 503.51 > So that's 20-25% less efficient in terms of cycles. It's hard to say whether the trade off in terms of absolute time is worth it. Can you relate the time spent more in concurrent marking vs the time saved on the main thread (incremental steps above)? > Maybe it's better to replace the fixed kMaxTasks with core number? Just > like what parallel compaction do. > > https://source.chromium.org/chromium/chromium/src/+/main:v8/src/heap/mark-compact.cc;l=472;bpv=1;bpt=0?q=NumberOfParallelCompactionTasks&ss=chromium%2Fchromium%2Fsrc > > Parallel compaction is more coarse grained and scales a little better I think. I am curious whether you can provide the trade off (see above). What we can always do is exposing a flag though for users that don't care about this tradeoff. > Regards, > Jianxiao > On Wednesday, June 22, 2022 at 2:03:30 AM UTC+8 Michael Lippautz wrote: > >> On Tue, Jun 21, 2022 at 11:36 AM Jianxiao Lu <[email protected]> wrote: >> >>> Thanks for the explanation. The second screenshot is 1520ms~1560ms in >>> fact. The snapshots were taken from the first major gc running webtooling. >>> Because I believe the first major gcs are relatively predictable and >>> consistent. (Maybe I am wrong). >>> >>> I will check with your suggestion later. Does the gc-tracer already have >>> something to record the mark-bytes/ms ? Or I need to try to implement one? >>> >> >> --trace-concurrent-marking will log concurrently marked bytes and >> timespans which can be used to compute the speed. Any custom logging will >> also do though. >> >> -Michael >> >> >>> >>> Thanks, >>> Jianxiao >>> >>> On Tuesday, June 21, 2022 at 3:08:10 PM UTC+8 [email protected] >>> wrote: >>> >>>> On Tue, Jun 21, 2022 at 8:33 AM Jianxiao Lu <[email protected]> wrote: >>>> >>>>> >>>>> https://source.chromium.org/chromium/chromium/src/+/main:v8/src/heap/concurrent-marking.h;l=59?q=kMaxTasks&sq=&ss=chromium >>>>> >>>>> The code comments above seems out of date. So I wonder if this >>>>> limitation is intentional or just no be updated in time. >>>>> >>>>> Here is a snapshot in webtooling (d8). >>>>> >>>>> [image: 7.png] >>>>> >>>>> After I tuned the worker number( >>>>> https://chromium-review.googlesource.com/c/v8/v8/+/3711496): >>>>> [image: 15.png] >>>>> >>>>> Seems that we can benefit from more worker? >>>>> >>>> >>>> This really depends on what the average size of the heap is.The numbers >>>> were chosen as a compromise between small and large heaps and low-end vs >>>> desktop devices. Also, the algorithm doesn't scale linearly but there's >>>> smaller trade offs here and there which add up as the # tasks are >>>> increased. >>>> >>>> Did the absolute time actually improve? I see 1280ms-1340ms in the >>>> first screenshot vs 1520ms-1580ms. You could check marked bytes/s as a >>>> proxy of whether the helper tasks are still efficient or not. >>>> >>>> -Michael >>>> >>>> >>>>> -- >>>>> -- >>>>> 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]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/v8-dev/2944463a-a964-40a9-91f4-fba7a74debe8n%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/v8-dev/2944463a-a964-40a9-91f4-fba7a74debe8n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>> -- >>> 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]. >>> >> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/v8-dev/3e8a9fd6-0a7f-424a-843c-9d3be714ecebn%40googlegroups.com >>> <https://groups.google.com/d/msgid/v8-dev/3e8a9fd6-0a7f-424a-843c-9d3be714ecebn%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > -- > 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]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/v8-dev/50b7b577-3304-4227-ae7c-1b59f8d4690bn%40googlegroups.com > <https://groups.google.com/d/msgid/v8-dev/50b7b577-3304-4227-ae7c-1b59f8d4690bn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAH%2BmL5DG%2BBuKij-E_RwQVDVV9949HqJieMPr8Q__2LLOKTT73Q%40mail.gmail.com.
