1. 13 May, 2022 1 commit
  2. 03 May, 2022 1 commit
  3. 31 Jan, 2022 1 commit
  4. 10 Jan, 2022 1 commit
  5. 18 Nov, 2021 1 commit
  6. 16 Nov, 2021 1 commit
  7. 28 Jul, 2021 2 commits
  8. 30 Jun, 2021 1 commit
  9. 28 Jun, 2021 2 commits
  10. 24 Jun, 2021 2 commits
  11. 18 Jun, 2021 2 commits
  12. 17 Jun, 2021 1 commit
  13. 16 Jun, 2021 1 commit
  14. 01 Jun, 2021 1 commit
  15. 27 Apr, 2021 2 commits
  16. 21 Apr, 2021 1 commit
  17. 12 Apr, 2021 1 commit
  18. 17 Feb, 2021 2 commits
    • Chris Mumford's avatar
      IWYU: Added missing include: include/cppgc/persistent.h · 84d2527b
      Chris Mumford authored
      This missing include was undetected because trace_perf.cc is only
      built if the checkout_google_benchmark custom gclient variable is
      defined.
      
      Bug: none
      Change-Id: If2016edad4df382f14903593ea18066f7759c4d5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698387Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Commit-Queue: Chris Mumford <cmumford@google.com>
      Cr-Commit-Position: refs/heads/master@{#72825}
      84d2527b
    • Paolo Severini's avatar
      [Test] Make CSuite benchmark runner work better on Windows · a974dd7e
      Paolo Severini authored
      The csuite.py script does not work correctly on Windows. It runs
      correctly in baseline mode, but there are two problems when running in
      compare mode:
      
      1. In compare mode the output of benchmark.py is piped to the
         compare-baseline.py script, but Windows only execute python files if
         python.exe is the default program to open '.py' files, and this is
         not the case, by default, when python is installed as part of the
         depot_tools.
      
         Fix: explicitly add the 'python' command before compare-baseline.py.
      
      2. By default CSuite prints the results to stdout using escapes codes
         that add color highlights. But this does not work on Windows when
         compare-baseline.py is launched with a pipe:
      
         python test/benchmarks/csuite/benchmark.py <...> |
             python test/benchmarks/csuite/compare-baseline.py <baseline_results>
      
         Fix: Do not use a pipe. Write the benchmark numbers for the
         compare-run into a separate file, and pass the path to this file to
         compare-baseline.py
      
      Change-Id: Ic22d5bd4b47901f0ba0f35bc2496441346d21c6a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2656855Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#72807}
      a974dd7e
  19. 27 Jan, 2021 1 commit
  20. 03 Dec, 2020 3 commits
  21. 24 Nov, 2020 1 commit
  22. 14 Sep, 2020 1 commit
  23. 24 Jul, 2020 1 commit
  24. 10 Jul, 2020 1 commit
  25. 03 Jul, 2020 2 commits
    • Michael Lippautz's avatar
      cppgc: Add micro benchmark for tracing objects · 5ab27690
      Michael Lippautz authored
      The benchmarks cover static vs dynamic tracing of an object where the
      header is computed statically vs using the object start bitmap,
      respectively.
      
      $ out/x64.release/cppgc_basic_benchmarks --benchmark_filter=Trace/*
      
      Running out/x64.release/cppgc_basic_benchmarks
      Run on (56 X 3500 MHz CPU s)
      CPU Caches:
        L1 Data 32 KiB (x28)
        L1 Instruction 32 KiB (x28)
        L2 Unified 256 KiB (x28)
        L3 Unified 35840 KiB (x2)
      Load Average: 0.24, 0.26, 0.26
      --------------------------------------------------------
      Benchmark              Time             CPU   Iterations
      --------------------------------------------------------
      Trace/Static        1.78 ns         1.78 ns    393324147
      Trace/Dynamic       3.27 ns         3.27 ns    215078276
      
      2020-07-03T15: 21:25+02:00
      Change-Id: I8bf5a8ed71a8991873160353e26f96214c038730
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2280099
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarAnton Bikineev <bikineev@chromium.org>
      Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68675}
      5ab27690
    • Michael Lippautz's avatar
      cppgc: Add allocation benchmark · 66fc9431
      Michael Lippautz authored
      Output:
      
      $ out/x64.release/cppgc_allocation_benchmark --benchmark_repetitions=3
      
      Running out/x64.release/cppgc_allocation_benchmark
      Run on (56 X 3500 MHz CPU s)
      CPU Caches:
        L1 Data 32 KiB (x28)
        L1 Instruction 32 KiB (x28)
        L2 Unified 256 KiB (x28)
        L3 Unified 35840 KiB (x2)
      Load Average: 0.23, 0.27, 0.27
      --------------------------------------------------------------------------------
      Benchmark                      Time             CPU   Iterations UserCounters...
      --------------------------------------------------------------------------------
      Allocate/Tiny               17.0 ns         17.0 ns     40348381 bytes_per_second=55.9692M/s
      Allocate/Tiny               17.1 ns         17.1 ns     40348381 bytes_per_second=55.8961M/s
      Allocate/Tiny               17.2 ns         17.2 ns     40348381 bytes_per_second=55.3108M/s
      Allocate/Tiny_mean          17.1 ns         17.1 ns            3 bytes_per_second=55.7254M/s
      Allocate/Tiny_median        17.1 ns         17.1 ns            3 bytes_per_second=55.8961M/s
      Allocate/Tiny_stddev       0.112 ns        0.111 ns            3 bytes_per_second=369.571k/s
      Allocate/Large             40339 ns        40334 ns        17707 bytes_per_second=1.51326G/s
      Allocate/Large             40350 ns        40343 ns        17707 bytes_per_second=1.51292G/s
      Allocate/Large             40205 ns        40192 ns        17707 bytes_per_second=1.51861G/s
      Allocate/Large_mean        40298 ns        40290 ns            3 bytes_per_second=1.51493G/s
      Allocate/Large_median      40339 ns        40334 ns            3 bytes_per_second=1.51326G/s
      Allocate/Large_stddev       81.2 ns         84.7 ns            3 bytes_per_second=3.26614M/s
      
      2020-07-03T09: 14:23+02:00
      Change-Id: I25a55beb5ea1718af76e638b752bf7d67cfe373e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2280086Reviewed-by: 's avatarAnton Bikineev <bikineev@chromium.org>
      Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68672}
      66fc9431
  26. 02 Jul, 2020 1 commit
  27. 06 May, 2020 1 commit
    • Jakob Gruber's avatar
      [snapshot] Clear reconstructable data prior to d8 stress_snapshot run · 3c422d1c
      Jakob Gruber authored
      The serializer currently cannot handle a heap state containing
      arbitrary compiled Code objects. As a quick fix for the
      --stress-snapshot d8 flag, we clear compiled data from the isolate
      prior to the serialize-deserialize-verify pass.
      
      With this change, mjsunit tests pass on x64.
      
      The %SerializeDeserializeNow() runtime function would require more
      work, since it is not possible to mutate the heap to this extent while
      still preserving a runnable host context and isolate. We will need
      another solution there.
      
      Drive-by: Skip the stress_snapshot variant except for the mjsunit
      suite.
      
      Tbr: machenbach@chromium.org
      Bug: v8:10493,v8:10416
      Change-Id: Ie110da8b51613fcd69c7f391d3cf8589d6b04dd8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2182429Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67585}
      3c422d1c
  28. 26 Feb, 2020 1 commit
  29. 22 Oct, 2019 1 commit
  30. 14 Oct, 2019 1 commit
  31. 02 Oct, 2019 1 commit
    • Mythri A's avatar
      Reland "Mark functions for optimization only on bytecode budget interrupts" · 483a5e94
      Mythri A authored
      This is a reland of 9efe315e after marking
      box2d slow.
      
      Original change's description:
      > Mark functions for optimization only on bytecode budget interrupts
      >
      > We used to mark functions for optimization on any interrupt. This sometimes
      > causes functions to OSR when not needed. The implementation was such because
      > we didn't have a different runtime function to distinguish bytecode budget
      > interrupts from other interrupts. For lazy feedback allocation we added a
      > new runtime function for bytecode budget interrupts so it makes it easier
      > to actually mark functions only when needed.
      >
      > This also includes a fix to reduce the stack limits for interrupts when
      > entering a scope that allows interrupts from a postponed interrupt scope.
      >
      > Bug: chromium:993061
      > Change-Id: Iaf7b4dccb7a503e5b6bfcbb993bc7482aa593955
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1829218
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Commit-Queue: Mythri Alle <mythria@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#64048}
      
      Bug: chromium:993061
      Change-Id: I24dae03357d6c368e4173db3f071e8ab09e9d6dc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1832173Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64082}
      483a5e94