AuroraMiddleware/skia2
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
34db2ddc92
skia2/bench/MemsetBench.cpp

78 lines
2.6 KiB
C++
Raw Normal View History

add bench for sk_memset16/32 BUG= Review URL: https://codereview.chromium.org/16336009 git-svn-id: http://skia.googlecode.com/svn/trunk@9405 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-06-03 16:54:10 +00:00
/*
* Copyright 2013 Google Inc.
*
* Use of this source code is governed by a BSD-style license that can be
* found in the LICENSE file.
*/
rewrite includes to not need so much -Ifoo Current strategy: everything from the top Things to look at first are the manual changes: - added tools/rewrite_includes.py - removed -Idirectives from BUILD.gn - various compile.sh simplifications - tweak tools/embed_resources.py - update gn/find_headers.py to write paths from the top - update gn/gn_to_bp.py SkUserConfig.h layout so that #include "include/config/SkUserConfig.h" always gets the header we want. No-Presubmit: true Change-Id: I73a4b181654e0e38d229bc456c0d0854bae3363e Reviewed-on: https://skia-review.googlesource.com/c/skia/+/209706 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Hal Canary <halcanary@google.com> Reviewed-by: Brian Osman <brianosman@google.com> Reviewed-by: Florin Malita <fmalita@chromium.org>
2019-04-23 17:05:21 +00:00
#include "bench/Benchmark.h"
#include "include/private/SkTemplates.h"
#include "src/core/SkUtils.h"
add bench for sk_memset16/32 BUG= Review URL: https://codereview.chromium.org/16336009 git-svn-id: http://skia.googlecode.com/svn/trunk@9405 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-06-03 16:54:10 +00:00
Reland "add ERMS (enhanced rep mov/sto) SkOpts slice" This is a reland of 26ad8ccdeca1e8a065c7d45d3620d270da45acd6 ... now with MSAN support. Original change's description: > add ERMS (enhanced rep mov/sto) SkOpts slice > > Intel's got two CPUID bits indicating the speed of rep mov/sto > (memcpy/memset), > > - ERMS, Enhanced Rep Mov/Sto, older, large copies are fast? > - FSRM, Fast Short Rep Mov, newer, small copies are fast? > > ERMS has been around a long time on Intel, but is relatively recent on > Ryzen, and FSRM is new across the board. The startup cost for > ERMS-but-not-FSRM copies really is noticeable, so we cut over to the > previous SSE/AVX routines when N is small. > > I've left the memset benchmarks as I found them most useful when > tuning the small/large cutoff in this CL. > > Change-Id: I3ac4e3f34796aba0ea86aabbe9dda7526919456a > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/332580 > Reviewed-by: Herb Derby <herb@google.com> > Commit-Queue: Mike Klein <mtklein@google.com> Cq-Include-Trybots: luci.skia.skia.primary:Test-Debian10-Clang-GCE-CPU-AVX2-x86_64-Release-All-MSAN Change-Id: Ia293bba90022c48c884599331ef35aa67644729b Reviewed-on: https://skia-review.googlesource.com/c/skia/+/334343 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2020-11-05 15:38:53 +00:00
template <typename T>
Remove Sk prefix from some bench classes. This idea came while commenting on https://codereview.chromium.org/343583005/ Since SkBenchmark, SkBenchLogger and SkGMBench are not part of the Skia library, they should not have the Sk prefix. BUG=None TEST=make all R=mtklein@google.com Author: tfarina@chromium.org Review URL: https://codereview.chromium.org/347823004
2014-06-19 19:32:29 +00:00
class MemsetBench : public Benchmark {
add bench for sk_memset16/32 BUG= Review URL: https://codereview.chromium.org/16336009 git-svn-id: http://skia.googlecode.com/svn/trunk@9405 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-06-03 16:54:10 +00:00
public:
Reland "add ERMS (enhanced rep mov/sto) SkOpts slice" This is a reland of 26ad8ccdeca1e8a065c7d45d3620d270da45acd6 ... now with MSAN support. Original change's description: > add ERMS (enhanced rep mov/sto) SkOpts slice > > Intel's got two CPUID bits indicating the speed of rep mov/sto > (memcpy/memset), > > - ERMS, Enhanced Rep Mov/Sto, older, large copies are fast? > - FSRM, Fast Short Rep Mov, newer, small copies are fast? > > ERMS has been around a long time on Intel, but is relatively recent on > Ryzen, and FSRM is new across the board. The startup cost for > ERMS-but-not-FSRM copies really is noticeable, so we cut over to the > previous SSE/AVX routines when N is small. > > I've left the memset benchmarks as I found them most useful when > tuning the small/large cutoff in this CL. > > Change-Id: I3ac4e3f34796aba0ea86aabbe9dda7526919456a > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/332580 > Reviewed-by: Herb Derby <herb@google.com> > Commit-Queue: Mike Klein <mtklein@google.com> Cq-Include-Trybots: luci.skia.skia.primary:Test-Debian10-Clang-GCE-CPU-AVX2-x86_64-Release-All-MSAN Change-Id: Ia293bba90022c48c884599331ef35aa67644729b Reviewed-on: https://skia-review.googlesource.com/c/skia/+/334343 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2020-11-05 15:38:53 +00:00
explicit MemsetBench(size_t bytes)
: fN(bytes / sizeof(T))
, fBuffer(fN)
, fName(SkStringPrintf("memset%zu_%zu", sizeof(T)*8, bytes)) {}
Implement a benchmark for GrResourceCache Adds "grresourcecache_add" and "grresourcecache_find" bench tests to test GrResourceCache::add and GrResourceCache::find. The tests work only with GPU backends, since GrResourceCache needs an GrGpu. Modifies bench tests to override SkBenchmark::isSuitableFor(Backend) function that specifies what kind of backend the test is inteded for. This replaces the previous "fIsRendering" flag that would indicate test that did no rendering. Adds SkCanvas::getGrContext() call to get the GrContext that the canvas ends up drawing to. The member function solves a common use-case that is also used in the benchmark added here. R=mtklein@google.com, bsalomon@google.com Author: kkinnunen@nvidia.com Review URL: https://codereview.chromium.org/73643005 git-svn-id: http://skia.googlecode.com/svn/trunk@12334 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-11-21 06:21:58 +00:00
Rewrite memset benches, then use results to add a small-N optimization. The benches for N <= 10 get around 2x faster on my N7 and N9. I believe this is because of the reduced function-call-then-function-pointer-call overhead on the N7, and additionally because it seems autovectorization beats our NEON code for small N on the N9. My desktop is unchanged, though that's probably because N=10 lies well within a region where memset's performance is essentially constant: N=100 takes only about 2x as long as N=1 and N=10, which perform nearly identically. BUG=skia: Review URL: https://codereview.chromium.org/1073863002
2015-04-09 21:05:17 +00:00
bool isSuitableFor(Backend backend) override { return backend == kNonRendering_Backend; }
const char* onGetName() override { return fName.c_str(); }
add bench for sk_memset16/32 BUG= Review URL: https://codereview.chromium.org/16336009 git-svn-id: http://skia.googlecode.com/svn/trunk@9405 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-06-03 16:54:10 +00:00
Remove const from `const int loops`. This drives me nuts, and prevents `while (loops --> 0)`. BUG=skia: Review URL: https://codereview.chromium.org/1379923005
2015-10-01 16:43:39 +00:00
void onDraw(int loops, SkCanvas*) override;
add bench for sk_memset16/32 BUG= Review URL: https://codereview.chromium.org/16336009 git-svn-id: http://skia.googlecode.com/svn/trunk@9405 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-06-03 16:54:10 +00:00
private:
Rewrite memset benches, then use results to add a small-N optimization. The benches for N <= 10 get around 2x faster on my N7 and N9. I believe this is because of the reduced function-call-then-function-pointer-call overhead on the N7, and additionally because it seems autovectorization beats our NEON code for small N on the N9. My desktop is unchanged, though that's probably because N=10 lies well within a region where memset's performance is essentially constant: N=100 takes only about 2x as long as N=1 and N=10, which perform nearly identically. BUG=skia: Review URL: https://codereview.chromium.org/1073863002
2015-04-09 21:05:17 +00:00
int fN;
SkAutoTMalloc<T> fBuffer;
SkString fName;
add bench for sk_memset16/32 BUG= Review URL: https://codereview.chromium.org/16336009 git-svn-id: http://skia.googlecode.com/svn/trunk@9405 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-06-03 16:54:10 +00:00
};
Reland "add ERMS (enhanced rep mov/sto) SkOpts slice" This is a reland of 26ad8ccdeca1e8a065c7d45d3620d270da45acd6 ... now with MSAN support. Original change's description: > add ERMS (enhanced rep mov/sto) SkOpts slice > > Intel's got two CPUID bits indicating the speed of rep mov/sto > (memcpy/memset), > > - ERMS, Enhanced Rep Mov/Sto, older, large copies are fast? > - FSRM, Fast Short Rep Mov, newer, small copies are fast? > > ERMS has been around a long time on Intel, but is relatively recent on > Ryzen, and FSRM is new across the board. The startup cost for > ERMS-but-not-FSRM copies really is noticeable, so we cut over to the > previous SSE/AVX routines when N is small. > > I've left the memset benchmarks as I found them most useful when > tuning the small/large cutoff in this CL. > > Change-Id: I3ac4e3f34796aba0ea86aabbe9dda7526919456a > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/332580 > Reviewed-by: Herb Derby <herb@google.com> > Commit-Queue: Mike Klein <mtklein@google.com> Cq-Include-Trybots: luci.skia.skia.primary:Test-Debian10-Clang-GCE-CPU-AVX2-x86_64-Release-All-MSAN Change-Id: Ia293bba90022c48c884599331ef35aa67644729b Reviewed-on: https://skia-review.googlesource.com/c/skia/+/334343 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2020-11-05 15:38:53 +00:00
template <> void MemsetBench<uint64_t>::onDraw(int loops, SkCanvas*) {
Rewrite memset benches, then use results to add a small-N optimization. The benches for N <= 10 get around 2x faster on my N7 and N9. I believe this is because of the reduced function-call-then-function-pointer-call overhead on the N7, and additionally because it seems autovectorization beats our NEON code for small N on the N9. My desktop is unchanged, though that's probably because N=10 lies well within a region where memset's performance is essentially constant: N=100 takes only about 2x as long as N=1 and N=10, which perform nearly identically. BUG=skia: Review URL: https://codereview.chromium.org/1073863002
2015-04-09 21:05:17 +00:00
for (int i = 0; i < 1000*loops; i++) {
Reland "add ERMS (enhanced rep mov/sto) SkOpts slice" This is a reland of 26ad8ccdeca1e8a065c7d45d3620d270da45acd6 ... now with MSAN support. Original change's description: > add ERMS (enhanced rep mov/sto) SkOpts slice > > Intel's got two CPUID bits indicating the speed of rep mov/sto > (memcpy/memset), > > - ERMS, Enhanced Rep Mov/Sto, older, large copies are fast? > - FSRM, Fast Short Rep Mov, newer, small copies are fast? > > ERMS has been around a long time on Intel, but is relatively recent on > Ryzen, and FSRM is new across the board. The startup cost for > ERMS-but-not-FSRM copies really is noticeable, so we cut over to the > previous SSE/AVX routines when N is small. > > I've left the memset benchmarks as I found them most useful when > tuning the small/large cutoff in this CL. > > Change-Id: I3ac4e3f34796aba0ea86aabbe9dda7526919456a > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/332580 > Reviewed-by: Herb Derby <herb@google.com> > Commit-Queue: Mike Klein <mtklein@google.com> Cq-Include-Trybots: luci.skia.skia.primary:Test-Debian10-Clang-GCE-CPU-AVX2-x86_64-Release-All-MSAN Change-Id: Ia293bba90022c48c884599331ef35aa67644729b Reviewed-on: https://skia-review.googlesource.com/c/skia/+/334343 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2020-11-05 15:38:53 +00:00
sk_memset64(fBuffer.get(), 0xFACEFACEFACEFACE, fN);
Rewrite memset benches, then use results to add a small-N optimization. The benches for N <= 10 get around 2x faster on my N7 and N9. I believe this is because of the reduced function-call-then-function-pointer-call overhead on the N7, and additionally because it seems autovectorization beats our NEON code for small N on the N9. My desktop is unchanged, though that's probably because N=10 lies well within a region where memset's performance is essentially constant: N=100 takes only about 2x as long as N=1 and N=10, which perform nearly identically. BUG=skia: Review URL: https://codereview.chromium.org/1073863002
2015-04-09 21:05:17 +00:00
}
}
add bench for sk_memset16/32 BUG= Review URL: https://codereview.chromium.org/16336009 git-svn-id: http://skia.googlecode.com/svn/trunk@9405 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-06-03 16:54:10 +00:00
Reland "add ERMS (enhanced rep mov/sto) SkOpts slice" This is a reland of 26ad8ccdeca1e8a065c7d45d3620d270da45acd6 ... now with MSAN support. Original change's description: > add ERMS (enhanced rep mov/sto) SkOpts slice > > Intel's got two CPUID bits indicating the speed of rep mov/sto > (memcpy/memset), > > - ERMS, Enhanced Rep Mov/Sto, older, large copies are fast? > - FSRM, Fast Short Rep Mov, newer, small copies are fast? > > ERMS has been around a long time on Intel, but is relatively recent on > Ryzen, and FSRM is new across the board. The startup cost for > ERMS-but-not-FSRM copies really is noticeable, so we cut over to the > previous SSE/AVX routines when N is small. > > I've left the memset benchmarks as I found them most useful when > tuning the small/large cutoff in this CL. > > Change-Id: I3ac4e3f34796aba0ea86aabbe9dda7526919456a > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/332580 > Reviewed-by: Herb Derby <herb@google.com> > Commit-Queue: Mike Klein <mtklein@google.com> Cq-Include-Trybots: luci.skia.skia.primary:Test-Debian10-Clang-GCE-CPU-AVX2-x86_64-Release-All-MSAN Change-Id: Ia293bba90022c48c884599331ef35aa67644729b Reviewed-on: https://skia-review.googlesource.com/c/skia/+/334343 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2020-11-05 15:38:53 +00:00
template <> void MemsetBench<uint32_t>::onDraw(int loops, SkCanvas*) {
Rewrite memset benches, then use results to add a small-N optimization. The benches for N <= 10 get around 2x faster on my N7 and N9. I believe this is because of the reduced function-call-then-function-pointer-call overhead on the N7, and additionally because it seems autovectorization beats our NEON code for small N on the N9. My desktop is unchanged, though that's probably because N=10 lies well within a region where memset's performance is essentially constant: N=100 takes only about 2x as long as N=1 and N=10, which perform nearly identically. BUG=skia: Review URL: https://codereview.chromium.org/1073863002
2015-04-09 21:05:17 +00:00
for (int i = 0; i < 1000*loops; i++) {
Reland "add ERMS (enhanced rep mov/sto) SkOpts slice" This is a reland of 26ad8ccdeca1e8a065c7d45d3620d270da45acd6 ... now with MSAN support. Original change's description: > add ERMS (enhanced rep mov/sto) SkOpts slice > > Intel's got two CPUID bits indicating the speed of rep mov/sto > (memcpy/memset), > > - ERMS, Enhanced Rep Mov/Sto, older, large copies are fast? > - FSRM, Fast Short Rep Mov, newer, small copies are fast? > > ERMS has been around a long time on Intel, but is relatively recent on > Ryzen, and FSRM is new across the board. The startup cost for > ERMS-but-not-FSRM copies really is noticeable, so we cut over to the > previous SSE/AVX routines when N is small. > > I've left the memset benchmarks as I found them most useful when > tuning the small/large cutoff in this CL. > > Change-Id: I3ac4e3f34796aba0ea86aabbe9dda7526919456a > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/332580 > Reviewed-by: Herb Derby <herb@google.com> > Commit-Queue: Mike Klein <mtklein@google.com> Cq-Include-Trybots: luci.skia.skia.primary:Test-Debian10-Clang-GCE-CPU-AVX2-x86_64-Release-All-MSAN Change-Id: Ia293bba90022c48c884599331ef35aa67644729b Reviewed-on: https://skia-review.googlesource.com/c/skia/+/334343 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2020-11-05 15:38:53 +00:00
sk_memset32(fBuffer.get(), 0xFACEB004, fN);
add bench for sk_memset16/32 BUG= Review URL: https://codereview.chromium.org/16336009 git-svn-id: http://skia.googlecode.com/svn/trunk@9405 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-06-03 16:54:10 +00:00
}
Rewrite memset benches, then use results to add a small-N optimization. The benches for N <= 10 get around 2x faster on my N7 and N9. I believe this is because of the reduced function-call-then-function-pointer-call overhead on the N7, and additionally because it seems autovectorization beats our NEON code for small N on the N9. My desktop is unchanged, though that's probably because N=10 lies well within a region where memset's performance is essentially constant: N=100 takes only about 2x as long as N=1 and N=10, which perform nearly identically. BUG=skia: Review URL: https://codereview.chromium.org/1073863002
2015-04-09 21:05:17 +00:00
}
add bench for sk_memset16/32 BUG= Review URL: https://codereview.chromium.org/16336009 git-svn-id: http://skia.googlecode.com/svn/trunk@9405 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-06-03 16:54:10 +00:00
Reland "add ERMS (enhanced rep mov/sto) SkOpts slice" This is a reland of 26ad8ccdeca1e8a065c7d45d3620d270da45acd6 ... now with MSAN support. Original change's description: > add ERMS (enhanced rep mov/sto) SkOpts slice > > Intel's got two CPUID bits indicating the speed of rep mov/sto > (memcpy/memset), > > - ERMS, Enhanced Rep Mov/Sto, older, large copies are fast? > - FSRM, Fast Short Rep Mov, newer, small copies are fast? > > ERMS has been around a long time on Intel, but is relatively recent on > Ryzen, and FSRM is new across the board. The startup cost for > ERMS-but-not-FSRM copies really is noticeable, so we cut over to the > previous SSE/AVX routines when N is small. > > I've left the memset benchmarks as I found them most useful when > tuning the small/large cutoff in this CL. > > Change-Id: I3ac4e3f34796aba0ea86aabbe9dda7526919456a > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/332580 > Reviewed-by: Herb Derby <herb@google.com> > Commit-Queue: Mike Klein <mtklein@google.com> Cq-Include-Trybots: luci.skia.skia.primary:Test-Debian10-Clang-GCE-CPU-AVX2-x86_64-Release-All-MSAN Change-Id: Ia293bba90022c48c884599331ef35aa67644729b Reviewed-on: https://skia-review.googlesource.com/c/skia/+/334343 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2020-11-05 15:38:53 +00:00
template <> void MemsetBench<uint16_t>::onDraw(int loops, SkCanvas*) {
Rewrite memset benches, then use results to add a small-N optimization. The benches for N <= 10 get around 2x faster on my N7 and N9. I believe this is because of the reduced function-call-then-function-pointer-call overhead on the N7, and additionally because it seems autovectorization beats our NEON code for small N on the N9. My desktop is unchanged, though that's probably because N=10 lies well within a region where memset's performance is essentially constant: N=100 takes only about 2x as long as N=1 and N=10, which perform nearly identically. BUG=skia: Review URL: https://codereview.chromium.org/1073863002
2015-04-09 21:05:17 +00:00
for (int i = 0; i < 1000*loops; i++) {
Reland "add ERMS (enhanced rep mov/sto) SkOpts slice" This is a reland of 26ad8ccdeca1e8a065c7d45d3620d270da45acd6 ... now with MSAN support. Original change's description: > add ERMS (enhanced rep mov/sto) SkOpts slice > > Intel's got two CPUID bits indicating the speed of rep mov/sto > (memcpy/memset), > > - ERMS, Enhanced Rep Mov/Sto, older, large copies are fast? > - FSRM, Fast Short Rep Mov, newer, small copies are fast? > > ERMS has been around a long time on Intel, but is relatively recent on > Ryzen, and FSRM is new across the board. The startup cost for > ERMS-but-not-FSRM copies really is noticeable, so we cut over to the > previous SSE/AVX routines when N is small. > > I've left the memset benchmarks as I found them most useful when > tuning the small/large cutoff in this CL. > > Change-Id: I3ac4e3f34796aba0ea86aabbe9dda7526919456a > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/332580 > Reviewed-by: Herb Derby <herb@google.com> > Commit-Queue: Mike Klein <mtklein@google.com> Cq-Include-Trybots: luci.skia.skia.primary:Test-Debian10-Clang-GCE-CPU-AVX2-x86_64-Release-All-MSAN Change-Id: Ia293bba90022c48c884599331ef35aa67644729b Reviewed-on: https://skia-review.googlesource.com/c/skia/+/334343 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2020-11-05 15:38:53 +00:00
sk_memset16(fBuffer.get(), 0x4973, fN);
add bench for sk_memset16/32 BUG= Review URL: https://codereview.chromium.org/16336009 git-svn-id: http://skia.googlecode.com/svn/trunk@9405 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-06-03 16:54:10 +00:00
}
Rewrite memset benches, then use results to add a small-N optimization. The benches for N <= 10 get around 2x faster on my N7 and N9. I believe this is because of the reduced function-call-then-function-pointer-call overhead on the N7, and additionally because it seems autovectorization beats our NEON code for small N on the N9. My desktop is unchanged, though that's probably because N=10 lies well within a region where memset's performance is essentially constant: N=100 takes only about 2x as long as N=1 and N=10, which perform nearly identically. BUG=skia: Review URL: https://codereview.chromium.org/1073863002
2015-04-09 21:05:17 +00:00
}
add bench for sk_memset16/32 BUG= Review URL: https://codereview.chromium.org/16336009 git-svn-id: http://skia.googlecode.com/svn/trunk@9405 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-06-03 16:54:10 +00:00
Reland "add ERMS (enhanced rep mov/sto) SkOpts slice" This is a reland of 26ad8ccdeca1e8a065c7d45d3620d270da45acd6 ... now with MSAN support. Original change's description: > add ERMS (enhanced rep mov/sto) SkOpts slice > > Intel's got two CPUID bits indicating the speed of rep mov/sto > (memcpy/memset), > > - ERMS, Enhanced Rep Mov/Sto, older, large copies are fast? > - FSRM, Fast Short Rep Mov, newer, small copies are fast? > > ERMS has been around a long time on Intel, but is relatively recent on > Ryzen, and FSRM is new across the board. The startup cost for > ERMS-but-not-FSRM copies really is noticeable, so we cut over to the > previous SSE/AVX routines when N is small. > > I've left the memset benchmarks as I found them most useful when > tuning the small/large cutoff in this CL. > > Change-Id: I3ac4e3f34796aba0ea86aabbe9dda7526919456a > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/332580 > Reviewed-by: Herb Derby <herb@google.com> > Commit-Queue: Mike Klein <mtklein@google.com> Cq-Include-Trybots: luci.skia.skia.primary:Test-Debian10-Clang-GCE-CPU-AVX2-x86_64-Release-All-MSAN Change-Id: Ia293bba90022c48c884599331ef35aa67644729b Reviewed-on: https://skia-review.googlesource.com/c/skia/+/334343 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2020-11-05 15:38:53 +00:00
DEF_BENCH(return (new MemsetBench<uint64_t>(16)));
DEF_BENCH(return (new MemsetBench<uint64_t>(64)));
DEF_BENCH(return (new MemsetBench<uint64_t>(256)));
DEF_BENCH(return (new MemsetBench<uint64_t>(512)));
DEF_BENCH(return (new MemsetBench<uint64_t>(768)));
DEF_BENCH(return (new MemsetBench<uint64_t>(1024)));
DEF_BENCH(return (new MemsetBench<uint64_t>(2048)));
DEF_BENCH(return (new MemsetBench<uint64_t>(4096)));
DEF_BENCH(return (new MemsetBench<uint64_t>(65536)));
Rewrite memset benches, then use results to add a small-N optimization. The benches for N <= 10 get around 2x faster on my N7 and N9. I believe this is because of the reduced function-call-then-function-pointer-call overhead on the N7, and additionally because it seems autovectorization beats our NEON code for small N on the N9. My desktop is unchanged, though that's probably because N=10 lies well within a region where memset's performance is essentially constant: N=100 takes only about 2x as long as N=1 and N=10, which perform nearly identically. BUG=skia: Review URL: https://codereview.chromium.org/1073863002
2015-04-09 21:05:17 +00:00
Reland "add ERMS (enhanced rep mov/sto) SkOpts slice" This is a reland of 26ad8ccdeca1e8a065c7d45d3620d270da45acd6 ... now with MSAN support. Original change's description: > add ERMS (enhanced rep mov/sto) SkOpts slice > > Intel's got two CPUID bits indicating the speed of rep mov/sto > (memcpy/memset), > > - ERMS, Enhanced Rep Mov/Sto, older, large copies are fast? > - FSRM, Fast Short Rep Mov, newer, small copies are fast? > > ERMS has been around a long time on Intel, but is relatively recent on > Ryzen, and FSRM is new across the board. The startup cost for > ERMS-but-not-FSRM copies really is noticeable, so we cut over to the > previous SSE/AVX routines when N is small. > > I've left the memset benchmarks as I found them most useful when > tuning the small/large cutoff in this CL. > > Change-Id: I3ac4e3f34796aba0ea86aabbe9dda7526919456a > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/332580 > Reviewed-by: Herb Derby <herb@google.com> > Commit-Queue: Mike Klein <mtklein@google.com> Cq-Include-Trybots: luci.skia.skia.primary:Test-Debian10-Clang-GCE-CPU-AVX2-x86_64-Release-All-MSAN Change-Id: Ia293bba90022c48c884599331ef35aa67644729b Reviewed-on: https://skia-review.googlesource.com/c/skia/+/334343 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2020-11-05 15:38:53 +00:00
DEF_BENCH(return (new MemsetBench<uint32_t>(16)));
DEF_BENCH(return (new MemsetBench<uint32_t>(64)));
DEF_BENCH(return (new MemsetBench<uint32_t>(256)));
DEF_BENCH(return (new MemsetBench<uint32_t>(512)));
DEF_BENCH(return (new MemsetBench<uint32_t>(768)));
DEF_BENCH(return (new MemsetBench<uint32_t>(1024)));
DEF_BENCH(return (new MemsetBench<uint32_t>(2048)));
DEF_BENCH(return (new MemsetBench<uint32_t>(4096)));
DEF_BENCH(return (new MemsetBench<uint32_t>(65536)));
Rewrite memset benches, then use results to add a small-N optimization. The benches for N <= 10 get around 2x faster on my N7 and N9. I believe this is because of the reduced function-call-then-function-pointer-call overhead on the N7, and additionally because it seems autovectorization beats our NEON code for small N on the N9. My desktop is unchanged, though that's probably because N=10 lies well within a region where memset's performance is essentially constant: N=100 takes only about 2x as long as N=1 and N=10, which perform nearly identically. BUG=skia: Review URL: https://codereview.chromium.org/1073863002
2015-04-09 21:05:17 +00:00
Reland "add ERMS (enhanced rep mov/sto) SkOpts slice" This is a reland of 26ad8ccdeca1e8a065c7d45d3620d270da45acd6 ... now with MSAN support. Original change's description: > add ERMS (enhanced rep mov/sto) SkOpts slice > > Intel's got two CPUID bits indicating the speed of rep mov/sto > (memcpy/memset), > > - ERMS, Enhanced Rep Mov/Sto, older, large copies are fast? > - FSRM, Fast Short Rep Mov, newer, small copies are fast? > > ERMS has been around a long time on Intel, but is relatively recent on > Ryzen, and FSRM is new across the board. The startup cost for > ERMS-but-not-FSRM copies really is noticeable, so we cut over to the > previous SSE/AVX routines when N is small. > > I've left the memset benchmarks as I found them most useful when > tuning the small/large cutoff in this CL. > > Change-Id: I3ac4e3f34796aba0ea86aabbe9dda7526919456a > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/332580 > Reviewed-by: Herb Derby <herb@google.com> > Commit-Queue: Mike Klein <mtklein@google.com> Cq-Include-Trybots: luci.skia.skia.primary:Test-Debian10-Clang-GCE-CPU-AVX2-x86_64-Release-All-MSAN Change-Id: Ia293bba90022c48c884599331ef35aa67644729b Reviewed-on: https://skia-review.googlesource.com/c/skia/+/334343 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2020-11-05 15:38:53 +00:00
DEF_BENCH(return (new MemsetBench<uint16_t>(16)));
DEF_BENCH(return (new MemsetBench<uint16_t>(64)));
DEF_BENCH(return (new MemsetBench<uint16_t>(256)));
DEF_BENCH(return (new MemsetBench<uint16_t>(512)));
DEF_BENCH(return (new MemsetBench<uint16_t>(768)));
DEF_BENCH(return (new MemsetBench<uint16_t>(1024)));
DEF_BENCH(return (new MemsetBench<uint16_t>(2048)));
DEF_BENCH(return (new MemsetBench<uint16_t>(4096)));
DEF_BENCH(return (new MemsetBench<uint16_t>(65536)));
Reference in New Issue Copy Permalink