skia2/bench/GrMemoryPoolBench.cpp

221 lines
8.4 KiB
C++
Raw Normal View History

/*
* Copyright 2012 Google Inc.
*
* Use of this source code is governed by a BSD-style license that can be
* found in the LICENSE file.
*/
#include "bench/Benchmark.h"
Reland "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit dff4c1d5fd0011f33094fb1e87478fbc849e6b5e. Reason for revert: Fix WIP Original change's description: > Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" > > This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. > > Reason for revert: breaks on iOS > > Original change's description: > > Avoid loop-dependent behavior in GrMemoryPoolBench > > > > This helps stability of benchmark across repeated runs, and across code > > changes. Previously, a change to the tuned loop count could radically > > change the allocation behavior within the loop's iteration and lead to > > unfair comparisons. > > > > In addition, this separates the stack allocation pattern into N allocations > > followed by N LIFO releases, and a push-pop alternating pattern of N > > allocates and releases (so still LIFO, but reuses the memory at the start > > of a block). > > > > In later CLs experimenting on the memory pool, I found that there were > > surprising effects on performance linked to the specific interaction between > > the allocation size, per-allocation metadata, and per-block metadata. To > > help differentiate these coincidences, this adds two modes of allocation > > where one should already be aligned. > > > > It also moves away from a global pool, so that it's possible to benchmark > > on different block sizes and factor in the allocation/release cost of the > > actual blocks (vs. the cursor management of a larger sized pool). As part > > of this, the new/delete reference operator is added as an explicit benchmark. > > > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > > Reviewed-by: Brian Salomon <bsalomon@google.com> > > TBR=bsalomon@google.com,michaelludwig@google.com > > Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 > Reviewed-by: Michael Ludwig <michaelludwig@google.com> > Commit-Queue: Michael Ludwig <michaelludwig@google.com> Change-Id: I51a9db111c26b49572c3fa0928e26ef6e5a7a74c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263196 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Brian Salomon <bsalomon@google.com> Auto-Submit: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-08 18:50:42 +00:00
#include "include/private/GrTypesPriv.h"
#include "include/utils/SkRandom.h"
#include "src/gpu/GrMemoryPool.h"
Reland "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit dff4c1d5fd0011f33094fb1e87478fbc849e6b5e. Reason for revert: Fix WIP Original change's description: > Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" > > This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. > > Reason for revert: breaks on iOS > > Original change's description: > > Avoid loop-dependent behavior in GrMemoryPoolBench > > > > This helps stability of benchmark across repeated runs, and across code > > changes. Previously, a change to the tuned loop count could radically > > change the allocation behavior within the loop's iteration and lead to > > unfair comparisons. > > > > In addition, this separates the stack allocation pattern into N allocations > > followed by N LIFO releases, and a push-pop alternating pattern of N > > allocates and releases (so still LIFO, but reuses the memory at the start > > of a block). > > > > In later CLs experimenting on the memory pool, I found that there were > > surprising effects on performance linked to the specific interaction between > > the allocation size, per-allocation metadata, and per-block metadata. To > > help differentiate these coincidences, this adds two modes of allocation > > where one should already be aligned. > > > > It also moves away from a global pool, so that it's possible to benchmark > > on different block sizes and factor in the allocation/release cost of the > > actual blocks (vs. the cursor management of a larger sized pool). As part > > of this, the new/delete reference operator is added as an explicit benchmark. > > > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > > Reviewed-by: Brian Salomon <bsalomon@google.com> > > TBR=bsalomon@google.com,michaelludwig@google.com > > Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 > Reviewed-by: Michael Ludwig <michaelludwig@google.com> > Commit-Queue: Michael Ludwig <michaelludwig@google.com> Change-Id: I51a9db111c26b49572c3fa0928e26ef6e5a7a74c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263196 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Brian Salomon <bsalomon@google.com> Auto-Submit: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-08 18:50:42 +00:00
#include <type_traits>
Reland "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit dff4c1d5fd0011f33094fb1e87478fbc849e6b5e. Reason for revert: Fix WIP Original change's description: > Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" > > This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. > > Reason for revert: breaks on iOS > > Original change's description: > > Avoid loop-dependent behavior in GrMemoryPoolBench > > > > This helps stability of benchmark across repeated runs, and across code > > changes. Previously, a change to the tuned loop count could radically > > change the allocation behavior within the loop's iteration and lead to > > unfair comparisons. > > > > In addition, this separates the stack allocation pattern into N allocations > > followed by N LIFO releases, and a push-pop alternating pattern of N > > allocates and releases (so still LIFO, but reuses the memory at the start > > of a block). > > > > In later CLs experimenting on the memory pool, I found that there were > > surprising effects on performance linked to the specific interaction between > > the allocation size, per-allocation metadata, and per-block metadata. To > > help differentiate these coincidences, this adds two modes of allocation > > where one should already be aligned. > > > > It also moves away from a global pool, so that it's possible to benchmark > > on different block sizes and factor in the allocation/release cost of the > > actual blocks (vs. the cursor management of a larger sized pool). As part > > of this, the new/delete reference operator is added as an explicit benchmark. > > > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > > Reviewed-by: Brian Salomon <bsalomon@google.com> > > TBR=bsalomon@google.com,michaelludwig@google.com > > Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 > Reviewed-by: Michael Ludwig <michaelludwig@google.com> > Commit-Queue: Michael Ludwig <michaelludwig@google.com> Change-Id: I51a9db111c26b49572c3fa0928e26ef6e5a7a74c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263196 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Brian Salomon <bsalomon@google.com> Auto-Submit: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-08 18:50:42 +00:00
namespace {
Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. Reason for revert: breaks on iOS Original change's description: > Avoid loop-dependent behavior in GrMemoryPoolBench > > This helps stability of benchmark across repeated runs, and across code > changes. Previously, a change to the tuned loop count could radically > change the allocation behavior within the loop's iteration and lead to > unfair comparisons. > > In addition, this separates the stack allocation pattern into N allocations > followed by N LIFO releases, and a push-pop alternating pattern of N > allocates and releases (so still LIFO, but reuses the memory at the start > of a block). > > In later CLs experimenting on the memory pool, I found that there were > surprising effects on performance linked to the specific interaction between > the allocation size, per-allocation metadata, and per-block metadata. To > help differentiate these coincidences, this adds two modes of allocation > where one should already be aligned. > > It also moves away from a global pool, so that it's possible to benchmark > on different block sizes and factor in the allocation/release cost of the > actual blocks (vs. the cursor management of a larger sized pool). As part > of this, the new/delete reference operator is added as an explicit benchmark. > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > Reviewed-by: Brian Salomon <bsalomon@google.com> TBR=bsalomon@google.com,michaelludwig@google.com Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 Reviewed-by: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Michael Ludwig <michaelludwig@google.com>
2020-01-08 15:53:59 +00:00
Reland "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit dff4c1d5fd0011f33094fb1e87478fbc849e6b5e. Reason for revert: Fix WIP Original change's description: > Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" > > This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. > > Reason for revert: breaks on iOS > > Original change's description: > > Avoid loop-dependent behavior in GrMemoryPoolBench > > > > This helps stability of benchmark across repeated runs, and across code > > changes. Previously, a change to the tuned loop count could radically > > change the allocation behavior within the loop's iteration and lead to > > unfair comparisons. > > > > In addition, this separates the stack allocation pattern into N allocations > > followed by N LIFO releases, and a push-pop alternating pattern of N > > allocates and releases (so still LIFO, but reuses the memory at the start > > of a block). > > > > In later CLs experimenting on the memory pool, I found that there were > > surprising effects on performance linked to the specific interaction between > > the allocation size, per-allocation metadata, and per-block metadata. To > > help differentiate these coincidences, this adds two modes of allocation > > where one should already be aligned. > > > > It also moves away from a global pool, so that it's possible to benchmark > > on different block sizes and factor in the allocation/release cost of the > > actual blocks (vs. the cursor management of a larger sized pool). As part > > of this, the new/delete reference operator is added as an explicit benchmark. > > > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > > Reviewed-by: Brian Salomon <bsalomon@google.com> > > TBR=bsalomon@google.com,michaelludwig@google.com > > Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 > Reviewed-by: Michael Ludwig <michaelludwig@google.com> > Commit-Queue: Michael Ludwig <michaelludwig@google.com> Change-Id: I51a9db111c26b49572c3fa0928e26ef6e5a7a74c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263196 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Brian Salomon <bsalomon@google.com> Auto-Submit: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-08 18:50:42 +00:00
// sizeof is a multiple of GrMemoryPool::kAlignment for 4, 8, or 16 byte alignment
struct alignas(GrMemoryPool::kAlignment) Aligned {
char buf[32];
};
Reland "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit dff4c1d5fd0011f33094fb1e87478fbc849e6b5e. Reason for revert: Fix WIP Original change's description: > Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" > > This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. > > Reason for revert: breaks on iOS > > Original change's description: > > Avoid loop-dependent behavior in GrMemoryPoolBench > > > > This helps stability of benchmark across repeated runs, and across code > > changes. Previously, a change to the tuned loop count could radically > > change the allocation behavior within the loop's iteration and lead to > > unfair comparisons. > > > > In addition, this separates the stack allocation pattern into N allocations > > followed by N LIFO releases, and a push-pop alternating pattern of N > > allocates and releases (so still LIFO, but reuses the memory at the start > > of a block). > > > > In later CLs experimenting on the memory pool, I found that there were > > surprising effects on performance linked to the specific interaction between > > the allocation size, per-allocation metadata, and per-block metadata. To > > help differentiate these coincidences, this adds two modes of allocation > > where one should already be aligned. > > > > It also moves away from a global pool, so that it's possible to benchmark > > on different block sizes and factor in the allocation/release cost of the > > actual blocks (vs. the cursor management of a larger sized pool). As part > > of this, the new/delete reference operator is added as an explicit benchmark. > > > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > > Reviewed-by: Brian Salomon <bsalomon@google.com> > > TBR=bsalomon@google.com,michaelludwig@google.com > > Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 > Reviewed-by: Michael Ludwig <michaelludwig@google.com> > Commit-Queue: Michael Ludwig <michaelludwig@google.com> Change-Id: I51a9db111c26b49572c3fa0928e26ef6e5a7a74c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263196 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Brian Salomon <bsalomon@google.com> Auto-Submit: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-08 18:50:42 +00:00
static_assert(sizeof(Aligned) == 32);
static_assert(sizeof(Aligned) % GrMemoryPool::kAlignment == 0);
Reland "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit dff4c1d5fd0011f33094fb1e87478fbc849e6b5e. Reason for revert: Fix WIP Original change's description: > Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" > > This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. > > Reason for revert: breaks on iOS > > Original change's description: > > Avoid loop-dependent behavior in GrMemoryPoolBench > > > > This helps stability of benchmark across repeated runs, and across code > > changes. Previously, a change to the tuned loop count could radically > > change the allocation behavior within the loop's iteration and lead to > > unfair comparisons. > > > > In addition, this separates the stack allocation pattern into N allocations > > followed by N LIFO releases, and a push-pop alternating pattern of N > > allocates and releases (so still LIFO, but reuses the memory at the start > > of a block). > > > > In later CLs experimenting on the memory pool, I found that there were > > surprising effects on performance linked to the specific interaction between > > the allocation size, per-allocation metadata, and per-block metadata. To > > help differentiate these coincidences, this adds two modes of allocation > > where one should already be aligned. > > > > It also moves away from a global pool, so that it's possible to benchmark > > on different block sizes and factor in the allocation/release cost of the > > actual blocks (vs. the cursor management of a larger sized pool). As part > > of this, the new/delete reference operator is added as an explicit benchmark. > > > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > > Reviewed-by: Brian Salomon <bsalomon@google.com> > > TBR=bsalomon@google.com,michaelludwig@google.com > > Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 > Reviewed-by: Michael Ludwig <michaelludwig@google.com> > Commit-Queue: Michael Ludwig <michaelludwig@google.com> Change-Id: I51a9db111c26b49572c3fa0928e26ef6e5a7a74c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263196 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Brian Salomon <bsalomon@google.com> Auto-Submit: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-08 18:50:42 +00:00
// sizeof is not a multiple of GrMemoryPool::kAlignment (will not be a multiple of max_align_t
// if it's 4, 8, or 16, as desired).
struct alignas(2) Unaligned {
char buf[30];
};
Reland "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit dff4c1d5fd0011f33094fb1e87478fbc849e6b5e. Reason for revert: Fix WIP Original change's description: > Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" > > This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. > > Reason for revert: breaks on iOS > > Original change's description: > > Avoid loop-dependent behavior in GrMemoryPoolBench > > > > This helps stability of benchmark across repeated runs, and across code > > changes. Previously, a change to the tuned loop count could radically > > change the allocation behavior within the loop's iteration and lead to > > unfair comparisons. > > > > In addition, this separates the stack allocation pattern into N allocations > > followed by N LIFO releases, and a push-pop alternating pattern of N > > allocates and releases (so still LIFO, but reuses the memory at the start > > of a block). > > > > In later CLs experimenting on the memory pool, I found that there were > > surprising effects on performance linked to the specific interaction between > > the allocation size, per-allocation metadata, and per-block metadata. To > > help differentiate these coincidences, this adds two modes of allocation > > where one should already be aligned. > > > > It also moves away from a global pool, so that it's possible to benchmark > > on different block sizes and factor in the allocation/release cost of the > > actual blocks (vs. the cursor management of a larger sized pool). As part > > of this, the new/delete reference operator is added as an explicit benchmark. > > > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > > Reviewed-by: Brian Salomon <bsalomon@google.com> > > TBR=bsalomon@google.com,michaelludwig@google.com > > Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 > Reviewed-by: Michael Ludwig <michaelludwig@google.com> > Commit-Queue: Michael Ludwig <michaelludwig@google.com> Change-Id: I51a9db111c26b49572c3fa0928e26ef6e5a7a74c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263196 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Brian Salomon <bsalomon@google.com> Auto-Submit: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-08 18:50:42 +00:00
static_assert(sizeof(Unaligned) == 30);
static_assert(sizeof(Unaligned) % GrMemoryPool::kAlignment != 0);
Reland "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit dff4c1d5fd0011f33094fb1e87478fbc849e6b5e. Reason for revert: Fix WIP Original change's description: > Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" > > This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. > > Reason for revert: breaks on iOS > > Original change's description: > > Avoid loop-dependent behavior in GrMemoryPoolBench > > > > This helps stability of benchmark across repeated runs, and across code > > changes. Previously, a change to the tuned loop count could radically > > change the allocation behavior within the loop's iteration and lead to > > unfair comparisons. > > > > In addition, this separates the stack allocation pattern into N allocations > > followed by N LIFO releases, and a push-pop alternating pattern of N > > allocates and releases (so still LIFO, but reuses the memory at the start > > of a block). > > > > In later CLs experimenting on the memory pool, I found that there were > > surprising effects on performance linked to the specific interaction between > > the allocation size, per-allocation metadata, and per-block metadata. To > > help differentiate these coincidences, this adds two modes of allocation > > where one should already be aligned. > > > > It also moves away from a global pool, so that it's possible to benchmark > > on different block sizes and factor in the allocation/release cost of the > > actual blocks (vs. the cursor management of a larger sized pool). As part > > of this, the new/delete reference operator is added as an explicit benchmark. > > > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > > Reviewed-by: Brian Salomon <bsalomon@google.com> > > TBR=bsalomon@google.com,michaelludwig@google.com > > Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 > Reviewed-by: Michael Ludwig <michaelludwig@google.com> > Commit-Queue: Michael Ludwig <michaelludwig@google.com> Change-Id: I51a9db111c26b49572c3fa0928e26ef6e5a7a74c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263196 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Brian Salomon <bsalomon@google.com> Auto-Submit: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-08 18:50:42 +00:00
// When max_align_t == 16, 8, or 4 the padded Unaligned will also be 32
Revert "Move GR_MAKE_BITFIELD_OPS and GrAlignTo to non-GPU files" This reverts commit 65a726bb4948ed662ca06302b57b5a2ddb81d4fb. Reason for revert: You cannot include a src file in an include file. This ends up using c++17 features in our includes. Breaks rolls. Original change's description: > Move GR_MAKE_BITFIELD_OPS and GrAlignTo to non-GPU files > > These have been renamed SK_MAKE_BITFIELD_OPS and SkAlignTo > because nothing seemed particularly GPU/Ganesh specific to them. > > I moved the latter to SkTypes.h because we have other align > code there and former to src/SkUtils.h because I didn't know > where else it should go. > > The primary motivation was removing the GrTypesPriv.h > include from src/core/SkBlockAllocator.h. I had attempted > some amount of #if SK_SUPPORT_GPU, but that's not as clean > here because both our CPU and GPU backends use the > SkBlockAllocator (as far as I could tell). > > This also moves sk_memset* from SkUtils.h to SkOpts.h, because > SkOpts.h requires bringing in RasterPipeline, which seemed > like overkill. > > Change-Id: I5163ef5064ad3840a15b7e873930d60e2620bf9d > Bug: skia:12584 > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/464876 > Reviewed-by: Brian Osman <brianosman@google.com> Bug: skia:12584 Change-Id: I1b772bbbc6f150d737bb53fa4e5f45d1581929fa No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://skia-review.googlesource.com/c/skia/+/465376 Auto-Submit: Greg Daniel <egdaniel@google.com> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
2021-10-29 12:49:36 +00:00
static_assert(GrAlignTo(sizeof(Unaligned), GrMemoryPool::kAlignment) == sizeof(Aligned));
Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. Reason for revert: breaks on iOS Original change's description: > Avoid loop-dependent behavior in GrMemoryPoolBench > > This helps stability of benchmark across repeated runs, and across code > changes. Previously, a change to the tuned loop count could radically > change the allocation behavior within the loop's iteration and lead to > unfair comparisons. > > In addition, this separates the stack allocation pattern into N allocations > followed by N LIFO releases, and a push-pop alternating pattern of N > allocates and releases (so still LIFO, but reuses the memory at the start > of a block). > > In later CLs experimenting on the memory pool, I found that there were > surprising effects on performance linked to the specific interaction between > the allocation size, per-allocation metadata, and per-block metadata. To > help differentiate these coincidences, this adds two modes of allocation > where one should already be aligned. > > It also moves away from a global pool, so that it's possible to benchmark > on different block sizes and factor in the allocation/release cost of the > actual blocks (vs. the cursor management of a larger sized pool). As part > of this, the new/delete reference operator is added as an explicit benchmark. > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > Reviewed-by: Brian Salomon <bsalomon@google.com> TBR=bsalomon@google.com,michaelludwig@google.com Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 Reviewed-by: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Michael Ludwig <michaelludwig@google.com>
2020-01-08 15:53:59 +00:00
Reland "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit dff4c1d5fd0011f33094fb1e87478fbc849e6b5e. Reason for revert: Fix WIP Original change's description: > Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" > > This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. > > Reason for revert: breaks on iOS > > Original change's description: > > Avoid loop-dependent behavior in GrMemoryPoolBench > > > > This helps stability of benchmark across repeated runs, and across code > > changes. Previously, a change to the tuned loop count could radically > > change the allocation behavior within the loop's iteration and lead to > > unfair comparisons. > > > > In addition, this separates the stack allocation pattern into N allocations > > followed by N LIFO releases, and a push-pop alternating pattern of N > > allocates and releases (so still LIFO, but reuses the memory at the start > > of a block). > > > > In later CLs experimenting on the memory pool, I found that there were > > surprising effects on performance linked to the specific interaction between > > the allocation size, per-allocation metadata, and per-block metadata. To > > help differentiate these coincidences, this adds two modes of allocation > > where one should already be aligned. > > > > It also moves away from a global pool, so that it's possible to benchmark > > on different block sizes and factor in the allocation/release cost of the > > actual blocks (vs. the cursor management of a larger sized pool). As part > > of this, the new/delete reference operator is added as an explicit benchmark. > > > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > > Reviewed-by: Brian Salomon <bsalomon@google.com> > > TBR=bsalomon@google.com,michaelludwig@google.com > > Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 > Reviewed-by: Michael Ludwig <michaelludwig@google.com> > Commit-Queue: Michael Ludwig <michaelludwig@google.com> Change-Id: I51a9db111c26b49572c3fa0928e26ef6e5a7a74c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263196 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Brian Salomon <bsalomon@google.com> Auto-Submit: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-08 18:50:42 +00:00
// All benchmarks create and delete the same number of objects. The key difference is the order
// of operations, the size of the objects being allocated, and the size of the pool.
typedef void (*RunBenchProc)(GrMemoryPool*, int);
} // namespace
Reland "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit dff4c1d5fd0011f33094fb1e87478fbc849e6b5e. Reason for revert: Fix WIP Original change's description: > Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" > > This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. > > Reason for revert: breaks on iOS > > Original change's description: > > Avoid loop-dependent behavior in GrMemoryPoolBench > > > > This helps stability of benchmark across repeated runs, and across code > > changes. Previously, a change to the tuned loop count could radically > > change the allocation behavior within the loop's iteration and lead to > > unfair comparisons. > > > > In addition, this separates the stack allocation pattern into N allocations > > followed by N LIFO releases, and a push-pop alternating pattern of N > > allocates and releases (so still LIFO, but reuses the memory at the start > > of a block). > > > > In later CLs experimenting on the memory pool, I found that there were > > surprising effects on performance linked to the specific interaction between > > the allocation size, per-allocation metadata, and per-block metadata. To > > help differentiate these coincidences, this adds two modes of allocation > > where one should already be aligned. > > > > It also moves away from a global pool, so that it's possible to benchmark > > on different block sizes and factor in the allocation/release cost of the > > actual blocks (vs. the cursor management of a larger sized pool). As part > > of this, the new/delete reference operator is added as an explicit benchmark. > > > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > > Reviewed-by: Brian Salomon <bsalomon@google.com> > > TBR=bsalomon@google.com,michaelludwig@google.com > > Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 > Reviewed-by: Michael Ludwig <michaelludwig@google.com> > Commit-Queue: Michael Ludwig <michaelludwig@google.com> Change-Id: I51a9db111c26b49572c3fa0928e26ef6e5a7a74c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263196 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Brian Salomon <bsalomon@google.com> Auto-Submit: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-08 18:50:42 +00:00
// N objects are created, and then destroyed in reverse order (fully unwinding the cursor within
// each block of the memory pool).
template <typename T>
static void run_stack(GrMemoryPool* pool, int loops) {
static const int kMaxObjects = 4 * (1 << 10);
T* objs[kMaxObjects];
for (int i = 0; i < loops; ++i) {
// Push N objects into the pool (or heap if pool is null)
for (int j = 0; j < kMaxObjects; ++j) {
objs[j] = pool ? (T*) pool->allocate(sizeof(T)) : new T;
}
// Pop N objects off in LIFO order
for (int j = kMaxObjects - 1; j >= 0; --j) {
if (pool) {
pool->release(objs[j]);
} else {
Reland "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit dff4c1d5fd0011f33094fb1e87478fbc849e6b5e. Reason for revert: Fix WIP Original change's description: > Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" > > This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. > > Reason for revert: breaks on iOS > > Original change's description: > > Avoid loop-dependent behavior in GrMemoryPoolBench > > > > This helps stability of benchmark across repeated runs, and across code > > changes. Previously, a change to the tuned loop count could radically > > change the allocation behavior within the loop's iteration and lead to > > unfair comparisons. > > > > In addition, this separates the stack allocation pattern into N allocations > > followed by N LIFO releases, and a push-pop alternating pattern of N > > allocates and releases (so still LIFO, but reuses the memory at the start > > of a block). > > > > In later CLs experimenting on the memory pool, I found that there were > > surprising effects on performance linked to the specific interaction between > > the allocation size, per-allocation metadata, and per-block metadata. To > > help differentiate these coincidences, this adds two modes of allocation > > where one should already be aligned. > > > > It also moves away from a global pool, so that it's possible to benchmark > > on different block sizes and factor in the allocation/release cost of the > > actual blocks (vs. the cursor management of a larger sized pool). As part > > of this, the new/delete reference operator is added as an explicit benchmark. > > > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > > Reviewed-by: Brian Salomon <bsalomon@google.com> > > TBR=bsalomon@google.com,michaelludwig@google.com > > Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 > Reviewed-by: Michael Ludwig <michaelludwig@google.com> > Commit-Queue: Michael Ludwig <michaelludwig@google.com> Change-Id: I51a9db111c26b49572c3fa0928e26ef6e5a7a74c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263196 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Brian Salomon <bsalomon@google.com> Auto-Submit: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-08 18:50:42 +00:00
delete objs[j];
}
}
Reland "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit dff4c1d5fd0011f33094fb1e87478fbc849e6b5e. Reason for revert: Fix WIP Original change's description: > Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" > > This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. > > Reason for revert: breaks on iOS > > Original change's description: > > Avoid loop-dependent behavior in GrMemoryPoolBench > > > > This helps stability of benchmark across repeated runs, and across code > > changes. Previously, a change to the tuned loop count could radically > > change the allocation behavior within the loop's iteration and lead to > > unfair comparisons. > > > > In addition, this separates the stack allocation pattern into N allocations > > followed by N LIFO releases, and a push-pop alternating pattern of N > > allocates and releases (so still LIFO, but reuses the memory at the start > > of a block). > > > > In later CLs experimenting on the memory pool, I found that there were > > surprising effects on performance linked to the specific interaction between > > the allocation size, per-allocation metadata, and per-block metadata. To > > help differentiate these coincidences, this adds two modes of allocation > > where one should already be aligned. > > > > It also moves away from a global pool, so that it's possible to benchmark > > on different block sizes and factor in the allocation/release cost of the > > actual blocks (vs. the cursor management of a larger sized pool). As part > > of this, the new/delete reference operator is added as an explicit benchmark. > > > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > > Reviewed-by: Brian Salomon <bsalomon@google.com> > > TBR=bsalomon@google.com,michaelludwig@google.com > > Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 > Reviewed-by: Michael Ludwig <michaelludwig@google.com> > Commit-Queue: Michael Ludwig <michaelludwig@google.com> Change-Id: I51a9db111c26b49572c3fa0928e26ef6e5a7a74c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263196 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Brian Salomon <bsalomon@google.com> Auto-Submit: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-08 18:50:42 +00:00
// Everything has been cleaned up for the next loop
}
Reland "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit dff4c1d5fd0011f33094fb1e87478fbc849e6b5e. Reason for revert: Fix WIP Original change's description: > Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" > > This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. > > Reason for revert: breaks on iOS > > Original change's description: > > Avoid loop-dependent behavior in GrMemoryPoolBench > > > > This helps stability of benchmark across repeated runs, and across code > > changes. Previously, a change to the tuned loop count could radically > > change the allocation behavior within the loop's iteration and lead to > > unfair comparisons. > > > > In addition, this separates the stack allocation pattern into N allocations > > followed by N LIFO releases, and a push-pop alternating pattern of N > > allocates and releases (so still LIFO, but reuses the memory at the start > > of a block). > > > > In later CLs experimenting on the memory pool, I found that there were > > surprising effects on performance linked to the specific interaction between > > the allocation size, per-allocation metadata, and per-block metadata. To > > help differentiate these coincidences, this adds two modes of allocation > > where one should already be aligned. > > > > It also moves away from a global pool, so that it's possible to benchmark > > on different block sizes and factor in the allocation/release cost of the > > actual blocks (vs. the cursor management of a larger sized pool). As part > > of this, the new/delete reference operator is added as an explicit benchmark. > > > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > > Reviewed-by: Brian Salomon <bsalomon@google.com> > > TBR=bsalomon@google.com,michaelludwig@google.com > > Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 > Reviewed-by: Michael Ludwig <michaelludwig@google.com> > Commit-Queue: Michael Ludwig <michaelludwig@google.com> Change-Id: I51a9db111c26b49572c3fa0928e26ef6e5a7a74c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263196 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Brian Salomon <bsalomon@google.com> Auto-Submit: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-08 18:50:42 +00:00
}
// N objects are created, and then destroyed in creation order (is not able to unwind the cursor
// within each block, but can reclaim the block once everything is destroyed).
template <typename T>
static void run_queue(GrMemoryPool* pool, int loops) {
static const int kMaxObjects = 4 * (1 << 10);
T* objs[kMaxObjects];
for (int i = 0; i < loops; ++i) {
// Push N objects into the pool (or heap if pool is null)
for (int j = 0; j < kMaxObjects; ++j) {
objs[j] = pool ? (T*) pool->allocate(sizeof(T)) : new T;
}
// Pop N objects off in FIFO order
for (int j = 0; j < kMaxObjects; ++j) {
if (pool) {
pool->release(objs[j]);
} else {
delete objs[j];
}
}
Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. Reason for revert: breaks on iOS Original change's description: > Avoid loop-dependent behavior in GrMemoryPoolBench > > This helps stability of benchmark across repeated runs, and across code > changes. Previously, a change to the tuned loop count could radically > change the allocation behavior within the loop's iteration and lead to > unfair comparisons. > > In addition, this separates the stack allocation pattern into N allocations > followed by N LIFO releases, and a push-pop alternating pattern of N > allocates and releases (so still LIFO, but reuses the memory at the start > of a block). > > In later CLs experimenting on the memory pool, I found that there were > surprising effects on performance linked to the specific interaction between > the allocation size, per-allocation metadata, and per-block metadata. To > help differentiate these coincidences, this adds two modes of allocation > where one should already be aligned. > > It also moves away from a global pool, so that it's possible to benchmark > on different block sizes and factor in the allocation/release cost of the > actual blocks (vs. the cursor management of a larger sized pool). As part > of this, the new/delete reference operator is added as an explicit benchmark. > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > Reviewed-by: Brian Salomon <bsalomon@google.com> TBR=bsalomon@google.com,michaelludwig@google.com Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 Reviewed-by: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Michael Ludwig <michaelludwig@google.com>
2020-01-08 15:53:59 +00:00
Reland "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit dff4c1d5fd0011f33094fb1e87478fbc849e6b5e. Reason for revert: Fix WIP Original change's description: > Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" > > This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. > > Reason for revert: breaks on iOS > > Original change's description: > > Avoid loop-dependent behavior in GrMemoryPoolBench > > > > This helps stability of benchmark across repeated runs, and across code > > changes. Previously, a change to the tuned loop count could radically > > change the allocation behavior within the loop's iteration and lead to > > unfair comparisons. > > > > In addition, this separates the stack allocation pattern into N allocations > > followed by N LIFO releases, and a push-pop alternating pattern of N > > allocates and releases (so still LIFO, but reuses the memory at the start > > of a block). > > > > In later CLs experimenting on the memory pool, I found that there were > > surprising effects on performance linked to the specific interaction between > > the allocation size, per-allocation metadata, and per-block metadata. To > > help differentiate these coincidences, this adds two modes of allocation > > where one should already be aligned. > > > > It also moves away from a global pool, so that it's possible to benchmark > > on different block sizes and factor in the allocation/release cost of the > > actual blocks (vs. the cursor management of a larger sized pool). As part > > of this, the new/delete reference operator is added as an explicit benchmark. > > > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > > Reviewed-by: Brian Salomon <bsalomon@google.com> > > TBR=bsalomon@google.com,michaelludwig@google.com > > Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 > Reviewed-by: Michael Ludwig <michaelludwig@google.com> > Commit-Queue: Michael Ludwig <michaelludwig@google.com> Change-Id: I51a9db111c26b49572c3fa0928e26ef6e5a7a74c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263196 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Brian Salomon <bsalomon@google.com> Auto-Submit: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-08 18:50:42 +00:00
// Everything has been cleaned up for the next loop
}
Reland "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit dff4c1d5fd0011f33094fb1e87478fbc849e6b5e. Reason for revert: Fix WIP Original change's description: > Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" > > This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. > > Reason for revert: breaks on iOS > > Original change's description: > > Avoid loop-dependent behavior in GrMemoryPoolBench > > > > This helps stability of benchmark across repeated runs, and across code > > changes. Previously, a change to the tuned loop count could radically > > change the allocation behavior within the loop's iteration and lead to > > unfair comparisons. > > > > In addition, this separates the stack allocation pattern into N allocations > > followed by N LIFO releases, and a push-pop alternating pattern of N > > allocates and releases (so still LIFO, but reuses the memory at the start > > of a block). > > > > In later CLs experimenting on the memory pool, I found that there were > > surprising effects on performance linked to the specific interaction between > > the allocation size, per-allocation metadata, and per-block metadata. To > > help differentiate these coincidences, this adds two modes of allocation > > where one should already be aligned. > > > > It also moves away from a global pool, so that it's possible to benchmark > > on different block sizes and factor in the allocation/release cost of the > > actual blocks (vs. the cursor management of a larger sized pool). As part > > of this, the new/delete reference operator is added as an explicit benchmark. > > > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > > Reviewed-by: Brian Salomon <bsalomon@google.com> > > TBR=bsalomon@google.com,michaelludwig@google.com > > Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 > Reviewed-by: Michael Ludwig <michaelludwig@google.com> > Commit-Queue: Michael Ludwig <michaelludwig@google.com> Change-Id: I51a9db111c26b49572c3fa0928e26ef6e5a7a74c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263196 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Brian Salomon <bsalomon@google.com> Auto-Submit: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-08 18:50:42 +00:00
}
// N objects are created and immediately destroyed, so space at the start of the pool should be
// immediately reclaimed.
template <typename T>
static void run_pushpop(GrMemoryPool* pool, int loops) {
static const int kMaxObjects = 4 * (1 << 10);
T* objs[kMaxObjects];
for (int i = 0; i < loops; ++i) {
// Push N objects into the pool (or heap if pool is null)
for (int j = 0; j < kMaxObjects; ++j) {
if (pool) {
objs[j] = (T*) pool->allocate(sizeof(T));
pool->release(objs[j]);
} else {
objs[j] = new T;
delete objs[j];
}
}
Reland "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit dff4c1d5fd0011f33094fb1e87478fbc849e6b5e. Reason for revert: Fix WIP Original change's description: > Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" > > This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. > > Reason for revert: breaks on iOS > > Original change's description: > > Avoid loop-dependent behavior in GrMemoryPoolBench > > > > This helps stability of benchmark across repeated runs, and across code > > changes. Previously, a change to the tuned loop count could radically > > change the allocation behavior within the loop's iteration and lead to > > unfair comparisons. > > > > In addition, this separates the stack allocation pattern into N allocations > > followed by N LIFO releases, and a push-pop alternating pattern of N > > allocates and releases (so still LIFO, but reuses the memory at the start > > of a block). > > > > In later CLs experimenting on the memory pool, I found that there were > > surprising effects on performance linked to the specific interaction between > > the allocation size, per-allocation metadata, and per-block metadata. To > > help differentiate these coincidences, this adds two modes of allocation > > where one should already be aligned. > > > > It also moves away from a global pool, so that it's possible to benchmark > > on different block sizes and factor in the allocation/release cost of the > > actual blocks (vs. the cursor management of a larger sized pool). As part > > of this, the new/delete reference operator is added as an explicit benchmark. > > > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > > Reviewed-by: Brian Salomon <bsalomon@google.com> > > TBR=bsalomon@google.com,michaelludwig@google.com > > Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 > Reviewed-by: Michael Ludwig <michaelludwig@google.com> > Commit-Queue: Michael Ludwig <michaelludwig@google.com> Change-Id: I51a9db111c26b49572c3fa0928e26ef6e5a7a74c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263196 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Brian Salomon <bsalomon@google.com> Auto-Submit: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-08 18:50:42 +00:00
// Everything has been cleaned up for the next loop
}
}
// N object creations and destructions are invoked in random order.
template <typename T>
static void run_random(GrMemoryPool* pool, int loops) {
static const int kMaxObjects = 4 * (1 << 10);
T* objs[kMaxObjects];
for (int i = 0; i < kMaxObjects; ++i) {
objs[i] = nullptr;
Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. Reason for revert: breaks on iOS Original change's description: > Avoid loop-dependent behavior in GrMemoryPoolBench > > This helps stability of benchmark across repeated runs, and across code > changes. Previously, a change to the tuned loop count could radically > change the allocation behavior within the loop's iteration and lead to > unfair comparisons. > > In addition, this separates the stack allocation pattern into N allocations > followed by N LIFO releases, and a push-pop alternating pattern of N > allocates and releases (so still LIFO, but reuses the memory at the start > of a block). > > In later CLs experimenting on the memory pool, I found that there were > surprising effects on performance linked to the specific interaction between > the allocation size, per-allocation metadata, and per-block metadata. To > help differentiate these coincidences, this adds two modes of allocation > where one should already be aligned. > > It also moves away from a global pool, so that it's possible to benchmark > on different block sizes and factor in the allocation/release cost of the > actual blocks (vs. the cursor management of a larger sized pool). As part > of this, the new/delete reference operator is added as an explicit benchmark. > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > Reviewed-by: Brian Salomon <bsalomon@google.com> TBR=bsalomon@google.com,michaelludwig@google.com Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 Reviewed-by: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Michael Ludwig <michaelludwig@google.com>
2020-01-08 15:53:59 +00:00
}
Reland "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit dff4c1d5fd0011f33094fb1e87478fbc849e6b5e. Reason for revert: Fix WIP Original change's description: > Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" > > This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. > > Reason for revert: breaks on iOS > > Original change's description: > > Avoid loop-dependent behavior in GrMemoryPoolBench > > > > This helps stability of benchmark across repeated runs, and across code > > changes. Previously, a change to the tuned loop count could radically > > change the allocation behavior within the loop's iteration and lead to > > unfair comparisons. > > > > In addition, this separates the stack allocation pattern into N allocations > > followed by N LIFO releases, and a push-pop alternating pattern of N > > allocates and releases (so still LIFO, but reuses the memory at the start > > of a block). > > > > In later CLs experimenting on the memory pool, I found that there were > > surprising effects on performance linked to the specific interaction between > > the allocation size, per-allocation metadata, and per-block metadata. To > > help differentiate these coincidences, this adds two modes of allocation > > where one should already be aligned. > > > > It also moves away from a global pool, so that it's possible to benchmark > > on different block sizes and factor in the allocation/release cost of the > > actual blocks (vs. the cursor management of a larger sized pool). As part > > of this, the new/delete reference operator is added as an explicit benchmark. > > > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > > Reviewed-by: Brian Salomon <bsalomon@google.com> > > TBR=bsalomon@google.com,michaelludwig@google.com > > Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 > Reviewed-by: Michael Ludwig <michaelludwig@google.com> > Commit-Queue: Michael Ludwig <michaelludwig@google.com> Change-Id: I51a9db111c26b49572c3fa0928e26ef6e5a7a74c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263196 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Brian Salomon <bsalomon@google.com> Auto-Submit: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-08 18:50:42 +00:00
auto del = [&](int j) {
// Delete
if (pool) {
pool->release(objs[j]);
} else {
delete objs[j];
}
objs[j] = nullptr;
};
SkRandom r;
for (int i = 0; i < loops; ++i) {
// Execute 2*kMaxObjects operations, which should average to N create and N destroy,
// followed by a small number of remaining deletions.
for (int j = 0; j < 2 * kMaxObjects; ++j) {
int k = r.nextRangeU(0, kMaxObjects-1);
if (objs[k]) {
del(k);
} else {
Reland "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit dff4c1d5fd0011f33094fb1e87478fbc849e6b5e. Reason for revert: Fix WIP Original change's description: > Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" > > This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. > > Reason for revert: breaks on iOS > > Original change's description: > > Avoid loop-dependent behavior in GrMemoryPoolBench > > > > This helps stability of benchmark across repeated runs, and across code > > changes. Previously, a change to the tuned loop count could radically > > change the allocation behavior within the loop's iteration and lead to > > unfair comparisons. > > > > In addition, this separates the stack allocation pattern into N allocations > > followed by N LIFO releases, and a push-pop alternating pattern of N > > allocates and releases (so still LIFO, but reuses the memory at the start > > of a block). > > > > In later CLs experimenting on the memory pool, I found that there were > > surprising effects on performance linked to the specific interaction between > > the allocation size, per-allocation metadata, and per-block metadata. To > > help differentiate these coincidences, this adds two modes of allocation > > where one should already be aligned. > > > > It also moves away from a global pool, so that it's possible to benchmark > > on different block sizes and factor in the allocation/release cost of the > > actual blocks (vs. the cursor management of a larger sized pool). As part > > of this, the new/delete reference operator is added as an explicit benchmark. > > > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > > Reviewed-by: Brian Salomon <bsalomon@google.com> > > TBR=bsalomon@google.com,michaelludwig@google.com > > Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 > Reviewed-by: Michael Ludwig <michaelludwig@google.com> > Commit-Queue: Michael Ludwig <michaelludwig@google.com> Change-Id: I51a9db111c26b49572c3fa0928e26ef6e5a7a74c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263196 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Brian Salomon <bsalomon@google.com> Auto-Submit: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-08 18:50:42 +00:00
// Create
objs[k] = pool ? (T*) pool->allocate(sizeof(T)) : new T;
}
}
Reland "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit dff4c1d5fd0011f33094fb1e87478fbc849e6b5e. Reason for revert: Fix WIP Original change's description: > Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" > > This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. > > Reason for revert: breaks on iOS > > Original change's description: > > Avoid loop-dependent behavior in GrMemoryPoolBench > > > > This helps stability of benchmark across repeated runs, and across code > > changes. Previously, a change to the tuned loop count could radically > > change the allocation behavior within the loop's iteration and lead to > > unfair comparisons. > > > > In addition, this separates the stack allocation pattern into N allocations > > followed by N LIFO releases, and a push-pop alternating pattern of N > > allocates and releases (so still LIFO, but reuses the memory at the start > > of a block). > > > > In later CLs experimenting on the memory pool, I found that there were > > surprising effects on performance linked to the specific interaction between > > the allocation size, per-allocation metadata, and per-block metadata. To > > help differentiate these coincidences, this adds two modes of allocation > > where one should already be aligned. > > > > It also moves away from a global pool, so that it's possible to benchmark > > on different block sizes and factor in the allocation/release cost of the > > actual blocks (vs. the cursor management of a larger sized pool). As part > > of this, the new/delete reference operator is added as an explicit benchmark. > > > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > > Reviewed-by: Brian Salomon <bsalomon@google.com> > > TBR=bsalomon@google.com,michaelludwig@google.com > > Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 > Reviewed-by: Michael Ludwig <michaelludwig@google.com> > Commit-Queue: Michael Ludwig <michaelludwig@google.com> Change-Id: I51a9db111c26b49572c3fa0928e26ef6e5a7a74c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263196 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Brian Salomon <bsalomon@google.com> Auto-Submit: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-08 18:50:42 +00:00
// Ensure everything is null for the next loop
for (int j = 0; j < kMaxObjects; ++j) {
if (objs[j]) {
del(j);
}
Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. Reason for revert: breaks on iOS Original change's description: > Avoid loop-dependent behavior in GrMemoryPoolBench > > This helps stability of benchmark across repeated runs, and across code > changes. Previously, a change to the tuned loop count could radically > change the allocation behavior within the loop's iteration and lead to > unfair comparisons. > > In addition, this separates the stack allocation pattern into N allocations > followed by N LIFO releases, and a push-pop alternating pattern of N > allocates and releases (so still LIFO, but reuses the memory at the start > of a block). > > In later CLs experimenting on the memory pool, I found that there were > surprising effects on performance linked to the specific interaction between > the allocation size, per-allocation metadata, and per-block metadata. To > help differentiate these coincidences, this adds two modes of allocation > where one should already be aligned. > > It also moves away from a global pool, so that it's possible to benchmark > on different block sizes and factor in the allocation/release cost of the > actual blocks (vs. the cursor management of a larger sized pool). As part > of this, the new/delete reference operator is added as an explicit benchmark. > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > Reviewed-by: Brian Salomon <bsalomon@google.com> TBR=bsalomon@google.com,michaelludwig@google.com Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 Reviewed-by: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Michael Ludwig <michaelludwig@google.com>
2020-01-08 15:53:59 +00:00
}
}
Reland "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit dff4c1d5fd0011f33094fb1e87478fbc849e6b5e. Reason for revert: Fix WIP Original change's description: > Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" > > This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. > > Reason for revert: breaks on iOS > > Original change's description: > > Avoid loop-dependent behavior in GrMemoryPoolBench > > > > This helps stability of benchmark across repeated runs, and across code > > changes. Previously, a change to the tuned loop count could radically > > change the allocation behavior within the loop's iteration and lead to > > unfair comparisons. > > > > In addition, this separates the stack allocation pattern into N allocations > > followed by N LIFO releases, and a push-pop alternating pattern of N > > allocates and releases (so still LIFO, but reuses the memory at the start > > of a block). > > > > In later CLs experimenting on the memory pool, I found that there were > > surprising effects on performance linked to the specific interaction between > > the allocation size, per-allocation metadata, and per-block metadata. To > > help differentiate these coincidences, this adds two modes of allocation > > where one should already be aligned. > > > > It also moves away from a global pool, so that it's possible to benchmark > > on different block sizes and factor in the allocation/release cost of the > > actual blocks (vs. the cursor management of a larger sized pool). As part > > of this, the new/delete reference operator is added as an explicit benchmark. > > > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > > Reviewed-by: Brian Salomon <bsalomon@google.com> > > TBR=bsalomon@google.com,michaelludwig@google.com > > Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 > Reviewed-by: Michael Ludwig <michaelludwig@google.com> > Commit-Queue: Michael Ludwig <michaelludwig@google.com> Change-Id: I51a9db111c26b49572c3fa0928e26ef6e5a7a74c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263196 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Brian Salomon <bsalomon@google.com> Auto-Submit: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-08 18:50:42 +00:00
}
Reland "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit dff4c1d5fd0011f33094fb1e87478fbc849e6b5e. Reason for revert: Fix WIP Original change's description: > Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" > > This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. > > Reason for revert: breaks on iOS > > Original change's description: > > Avoid loop-dependent behavior in GrMemoryPoolBench > > > > This helps stability of benchmark across repeated runs, and across code > > changes. Previously, a change to the tuned loop count could radically > > change the allocation behavior within the loop's iteration and lead to > > unfair comparisons. > > > > In addition, this separates the stack allocation pattern into N allocations > > followed by N LIFO releases, and a push-pop alternating pattern of N > > allocates and releases (so still LIFO, but reuses the memory at the start > > of a block). > > > > In later CLs experimenting on the memory pool, I found that there were > > surprising effects on performance linked to the specific interaction between > > the allocation size, per-allocation metadata, and per-block metadata. To > > help differentiate these coincidences, this adds two modes of allocation > > where one should already be aligned. > > > > It also moves away from a global pool, so that it's possible to benchmark > > on different block sizes and factor in the allocation/release cost of the > > actual blocks (vs. the cursor management of a larger sized pool). As part > > of this, the new/delete reference operator is added as an explicit benchmark. > > > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > > Reviewed-by: Brian Salomon <bsalomon@google.com> > > TBR=bsalomon@google.com,michaelludwig@google.com > > Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 > Reviewed-by: Michael Ludwig <michaelludwig@google.com> > Commit-Queue: Michael Ludwig <michaelludwig@google.com> Change-Id: I51a9db111c26b49572c3fa0928e26ef6e5a7a74c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263196 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Brian Salomon <bsalomon@google.com> Auto-Submit: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-08 18:50:42 +00:00
///////////////////////////////////////////////////////////////////////////////////////////////////
class GrMemoryPoolBench : public Benchmark {
Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. Reason for revert: breaks on iOS Original change's description: > Avoid loop-dependent behavior in GrMemoryPoolBench > > This helps stability of benchmark across repeated runs, and across code > changes. Previously, a change to the tuned loop count could radically > change the allocation behavior within the loop's iteration and lead to > unfair comparisons. > > In addition, this separates the stack allocation pattern into N allocations > followed by N LIFO releases, and a push-pop alternating pattern of N > allocates and releases (so still LIFO, but reuses the memory at the start > of a block). > > In later CLs experimenting on the memory pool, I found that there were > surprising effects on performance linked to the specific interaction between > the allocation size, per-allocation metadata, and per-block metadata. To > help differentiate these coincidences, this adds two modes of allocation > where one should already be aligned. > > It also moves away from a global pool, so that it's possible to benchmark > on different block sizes and factor in the allocation/release cost of the > actual blocks (vs. the cursor management of a larger sized pool). As part > of this, the new/delete reference operator is added as an explicit benchmark. > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > Reviewed-by: Brian Salomon <bsalomon@google.com> TBR=bsalomon@google.com,michaelludwig@google.com Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 Reviewed-by: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Michael Ludwig <michaelludwig@google.com>
2020-01-08 15:53:59 +00:00
public:
Reland "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit dff4c1d5fd0011f33094fb1e87478fbc849e6b5e. Reason for revert: Fix WIP Original change's description: > Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" > > This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. > > Reason for revert: breaks on iOS > > Original change's description: > > Avoid loop-dependent behavior in GrMemoryPoolBench > > > > This helps stability of benchmark across repeated runs, and across code > > changes. Previously, a change to the tuned loop count could radically > > change the allocation behavior within the loop's iteration and lead to > > unfair comparisons. > > > > In addition, this separates the stack allocation pattern into N allocations > > followed by N LIFO releases, and a push-pop alternating pattern of N > > allocates and releases (so still LIFO, but reuses the memory at the start > > of a block). > > > > In later CLs experimenting on the memory pool, I found that there were > > surprising effects on performance linked to the specific interaction between > > the allocation size, per-allocation metadata, and per-block metadata. To > > help differentiate these coincidences, this adds two modes of allocation > > where one should already be aligned. > > > > It also moves away from a global pool, so that it's possible to benchmark > > on different block sizes and factor in the allocation/release cost of the > > actual blocks (vs. the cursor management of a larger sized pool). As part > > of this, the new/delete reference operator is added as an explicit benchmark. > > > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > > Reviewed-by: Brian Salomon <bsalomon@google.com> > > TBR=bsalomon@google.com,michaelludwig@google.com > > Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 > Reviewed-by: Michael Ludwig <michaelludwig@google.com> > Commit-Queue: Michael Ludwig <michaelludwig@google.com> Change-Id: I51a9db111c26b49572c3fa0928e26ef6e5a7a74c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263196 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Brian Salomon <bsalomon@google.com> Auto-Submit: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-08 18:50:42 +00:00
GrMemoryPoolBench(const char* name, RunBenchProc proc, int poolSize)
: fPoolSize(poolSize)
, fProc(proc) {
fName.printf("grmemorypool_%s", name);
}
bool isSuitableFor(Backend backend) override {
return backend == kNonRendering_Backend;
}
protected:
const char* onGetName() override {
Reland "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit dff4c1d5fd0011f33094fb1e87478fbc849e6b5e. Reason for revert: Fix WIP Original change's description: > Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" > > This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. > > Reason for revert: breaks on iOS > > Original change's description: > > Avoid loop-dependent behavior in GrMemoryPoolBench > > > > This helps stability of benchmark across repeated runs, and across code > > changes. Previously, a change to the tuned loop count could radically > > change the allocation behavior within the loop's iteration and lead to > > unfair comparisons. > > > > In addition, this separates the stack allocation pattern into N allocations > > followed by N LIFO releases, and a push-pop alternating pattern of N > > allocates and releases (so still LIFO, but reuses the memory at the start > > of a block). > > > > In later CLs experimenting on the memory pool, I found that there were > > surprising effects on performance linked to the specific interaction between > > the allocation size, per-allocation metadata, and per-block metadata. To > > help differentiate these coincidences, this adds two modes of allocation > > where one should already be aligned. > > > > It also moves away from a global pool, so that it's possible to benchmark > > on different block sizes and factor in the allocation/release cost of the > > actual blocks (vs. the cursor management of a larger sized pool). As part > > of this, the new/delete reference operator is added as an explicit benchmark. > > > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > > Reviewed-by: Brian Salomon <bsalomon@google.com> > > TBR=bsalomon@google.com,michaelludwig@google.com > > Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 > Reviewed-by: Michael Ludwig <michaelludwig@google.com> > Commit-Queue: Michael Ludwig <michaelludwig@google.com> Change-Id: I51a9db111c26b49572c3fa0928e26ef6e5a7a74c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263196 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Brian Salomon <bsalomon@google.com> Auto-Submit: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-08 18:50:42 +00:00
return fName.c_str();
}
void onDraw(int loops, SkCanvas*) override {
Reland "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit dff4c1d5fd0011f33094fb1e87478fbc849e6b5e. Reason for revert: Fix WIP Original change's description: > Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" > > This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. > > Reason for revert: breaks on iOS > > Original change's description: > > Avoid loop-dependent behavior in GrMemoryPoolBench > > > > This helps stability of benchmark across repeated runs, and across code > > changes. Previously, a change to the tuned loop count could radically > > change the allocation behavior within the loop's iteration and lead to > > unfair comparisons. > > > > In addition, this separates the stack allocation pattern into N allocations > > followed by N LIFO releases, and a push-pop alternating pattern of N > > allocates and releases (so still LIFO, but reuses the memory at the start > > of a block). > > > > In later CLs experimenting on the memory pool, I found that there were > > surprising effects on performance linked to the specific interaction between > > the allocation size, per-allocation metadata, and per-block metadata. To > > help differentiate these coincidences, this adds two modes of allocation > > where one should already be aligned. > > > > It also moves away from a global pool, so that it's possible to benchmark > > on different block sizes and factor in the allocation/release cost of the > > actual blocks (vs. the cursor management of a larger sized pool). As part > > of this, the new/delete reference operator is added as an explicit benchmark. > > > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > > Reviewed-by: Brian Salomon <bsalomon@google.com> > > TBR=bsalomon@google.com,michaelludwig@google.com > > Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 > Reviewed-by: Michael Ludwig <michaelludwig@google.com> > Commit-Queue: Michael Ludwig <michaelludwig@google.com> Change-Id: I51a9db111c26b49572c3fa0928e26ef6e5a7a74c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263196 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Brian Salomon <bsalomon@google.com> Auto-Submit: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-08 18:50:42 +00:00
std::unique_ptr<GrMemoryPool> pool;
if (fPoolSize > 0) {
pool = GrMemoryPool::Make(fPoolSize, fPoolSize);
} // else keep it null to test regular new/delete performance
fProc(pool.get(), loops);
}
Reland "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit dff4c1d5fd0011f33094fb1e87478fbc849e6b5e. Reason for revert: Fix WIP Original change's description: > Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" > > This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. > > Reason for revert: breaks on iOS > > Original change's description: > > Avoid loop-dependent behavior in GrMemoryPoolBench > > > > This helps stability of benchmark across repeated runs, and across code > > changes. Previously, a change to the tuned loop count could radically > > change the allocation behavior within the loop's iteration and lead to > > unfair comparisons. > > > > In addition, this separates the stack allocation pattern into N allocations > > followed by N LIFO releases, and a push-pop alternating pattern of N > > allocates and releases (so still LIFO, but reuses the memory at the start > > of a block). > > > > In later CLs experimenting on the memory pool, I found that there were > > surprising effects on performance linked to the specific interaction between > > the allocation size, per-allocation metadata, and per-block metadata. To > > help differentiate these coincidences, this adds two modes of allocation > > where one should already be aligned. > > > > It also moves away from a global pool, so that it's possible to benchmark > > on different block sizes and factor in the allocation/release cost of the > > actual blocks (vs. the cursor management of a larger sized pool). As part > > of this, the new/delete reference operator is added as an explicit benchmark. > > > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > > Reviewed-by: Brian Salomon <bsalomon@google.com> > > TBR=bsalomon@google.com,michaelludwig@google.com > > Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 > Reviewed-by: Michael Ludwig <michaelludwig@google.com> > Commit-Queue: Michael Ludwig <michaelludwig@google.com> Change-Id: I51a9db111c26b49572c3fa0928e26ef6e5a7a74c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263196 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Brian Salomon <bsalomon@google.com> Auto-Submit: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-08 18:50:42 +00:00
SkString fName;
int fPoolSize;
RunBenchProc fProc;
using INHERITED = Benchmark;
};
Reland "Avoid loop-dependent behavior in GrMemoryPoolBench" This reverts commit dff4c1d5fd0011f33094fb1e87478fbc849e6b5e. Reason for revert: Fix WIP Original change's description: > Revert "Avoid loop-dependent behavior in GrMemoryPoolBench" > > This reverts commit f811fc331a143631f3ba48a266336ccf18d5a459. > > Reason for revert: breaks on iOS > > Original change's description: > > Avoid loop-dependent behavior in GrMemoryPoolBench > > > > This helps stability of benchmark across repeated runs, and across code > > changes. Previously, a change to the tuned loop count could radically > > change the allocation behavior within the loop's iteration and lead to > > unfair comparisons. > > > > In addition, this separates the stack allocation pattern into N allocations > > followed by N LIFO releases, and a push-pop alternating pattern of N > > allocates and releases (so still LIFO, but reuses the memory at the start > > of a block). > > > > In later CLs experimenting on the memory pool, I found that there were > > surprising effects on performance linked to the specific interaction between > > the allocation size, per-allocation metadata, and per-block metadata. To > > help differentiate these coincidences, this adds two modes of allocation > > where one should already be aligned. > > > > It also moves away from a global pool, so that it's possible to benchmark > > on different block sizes and factor in the allocation/release cost of the > > actual blocks (vs. the cursor management of a larger sized pool). As part > > of this, the new/delete reference operator is added as an explicit benchmark. > > > > Change-Id: I12b8c11cb75db0df70460fe2e8cf6c029db7eb22 > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262936 > > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > > Reviewed-by: Brian Salomon <bsalomon@google.com> > > TBR=bsalomon@google.com,michaelludwig@google.com > > Change-Id: I16f2810699a378eb5a516ab9fb1834c10b65f01b > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263029 > Reviewed-by: Michael Ludwig <michaelludwig@google.com> > Commit-Queue: Michael Ludwig <michaelludwig@google.com> Change-Id: I51a9db111c26b49572c3fa0928e26ef6e5a7a74c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/263196 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Brian Salomon <bsalomon@google.com> Auto-Submit: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-08 18:50:42 +00:00
///////////////////////////////////////////////////////////////////////////////////////////////////
static const int kLargePool = 10 * (1 << 10);
static const int kSmallPool = GrMemoryPool::kMinAllocationSize;
DEF_BENCH( return new GrMemoryPoolBench("stack_aligned_lg", run_stack<Aligned>, kLargePool); )
DEF_BENCH( return new GrMemoryPoolBench("stack_aligned_sm", run_stack<Aligned>, kSmallPool); )
DEF_BENCH( return new GrMemoryPoolBench("stack_aligned_ref", run_stack<Aligned>, 0); )
DEF_BENCH( return new GrMemoryPoolBench("stack_unaligned_lg", run_stack<Unaligned>, kLargePool); )
DEF_BENCH( return new GrMemoryPoolBench("stack_unaligned_sm", run_stack<Unaligned>, kSmallPool); )
DEF_BENCH( return new GrMemoryPoolBench("stack_unaligned_ref", run_stack<Unaligned>, 0); )
DEF_BENCH( return new GrMemoryPoolBench("queue_aligned_lg", run_queue<Aligned>, kLargePool); )
DEF_BENCH( return new GrMemoryPoolBench("queue_aligned_sm", run_queue<Aligned>, kSmallPool); )
DEF_BENCH( return new GrMemoryPoolBench("queue_aligned_ref", run_queue<Aligned>, 0); )
DEF_BENCH( return new GrMemoryPoolBench("queue_unaligned_lg", run_queue<Unaligned>, kLargePool); )
DEF_BENCH( return new GrMemoryPoolBench("queue_unaligned_sm", run_queue<Unaligned>, kSmallPool); )
DEF_BENCH( return new GrMemoryPoolBench("queue_unaligned_ref", run_queue<Unaligned>, 0); )
DEF_BENCH( return new GrMemoryPoolBench("pushpop_aligned_lg", run_pushpop<Aligned>, kLargePool); )
DEF_BENCH( return new GrMemoryPoolBench("pushpop_aligned_sm", run_pushpop<Aligned>, kSmallPool); )
// DEF_BENCH( return new GrMemoryPoolBench("pushpop_aligned_ref", run_pushpop<Aligned>, 0); )
DEF_BENCH( return new GrMemoryPoolBench("pushpop_unaligned_lg", run_pushpop<Unaligned>, kLargePool); )
DEF_BENCH( return new GrMemoryPoolBench("pushpop_unaligned_sm", run_pushpop<Unaligned>, kSmallPool); )
// DEF_BENCH( return new GrMemoryPoolBench("pushpop_unaligned_ref", run_pushpop<Unaligned>, 0); )
// pushpop_x_ref are not meaningful because the compiler completely optimizes away new T; delete *.
DEF_BENCH( return new GrMemoryPoolBench("random_aligned_lg", run_random<Aligned>, kLargePool); )
DEF_BENCH( return new GrMemoryPoolBench("random_aligned_sm", run_random<Aligned>, kSmallPool); )
DEF_BENCH( return new GrMemoryPoolBench("random_aligned_ref", run_random<Aligned>, 0); )
DEF_BENCH( return new GrMemoryPoolBench("random_unaligned_lg", run_random<Unaligned>, kLargePool); )
DEF_BENCH( return new GrMemoryPoolBench("random_unaligned_sm", run_random<Unaligned>, kSmallPool); )
DEF_BENCH( return new GrMemoryPoolBench("random_unaligned_ref", run_random<Unaligned>, 0); )