From 3d096654b910e52768d7335a0c2c7d7cd32c8bb7 Mon Sep 17 00:00:00 2001 From: mtklein Date: Tue, 29 Sep 2015 10:38:59 -0700 Subject: update memset16/32 inlining heuristics I spent some time looking at perf.skia.org and it looks like we can do better. It is weird, weird, weird that on x86, we see three completely different behaviors: - x86 Android: inlining better for small N, custom better for large N; - Windows: inlining better for large N, custom better for small N; - other x86: inlining generally better BUG=skia:4316,chromium:516426 Committed: https://skia.googlesource.com/skia/+/b68fa409fc00ce2f38e2a0fd6f9dc2379b372481 Summaries: https://perf.skia.org/#4179 All traces, log scale: https://perf.skia.org/#4180 TBR=reed@google.com No public API changes. Review URL: https://codereview.chromium.org/1357193002 --- include/core/SkUtils.h | 38 +++++++++++++++++++++++--------------- 1 file changed, 23 insertions(+), 15 deletions(-) diff --git a/include/core/SkUtils.h b/include/core/SkUtils.h index 4e24bd0883..2b390f04e5 100644 --- a/include/core/SkUtils.h +++ b/include/core/SkUtils.h @@ -17,13 +17,12 @@ namespace SkOpts { /////////////////////////////////////////////////////////////////////////////// -// The inlining heuristics below were determined using bench/MemsetBench.cpp -// on a x86 desktop, a Nexus 7 with and without NEON, and a Nexus 9: -// - on x86, inlining was never faster, -// - on ARMv7, inlining was faster for N<=10. Putting this check inside the NEON -// code was not helpful; it's got to be here outside. -// - NEON code generation for ARMv8 with GCC 4.9 is terrible, -// making the NEON code ~8x slower that just a serial loop. +// Inlining heuristics were determined by using perf.skia.org and bench/MemsetBench.cpp. +// When using MSVC, inline is better >= 1K and worse <= 100. The Nexus Player was the opposite. +// Otherwise, when NEON or SSE is available to GCC or Clang, they can handle it best. +// See https://code.google.com/p/chromium/issues/detail?id=516426#c15 for more details. +// See also skia:4316; it might be a good idea to use rep stosw/stosd here. +#define INLINE_IF(cond) if (cond) { while (count --> 0) { *buffer++ = value; } return; } /** Similar to memset(), but it assigns a 16bit value into the buffer. @param buffer The memory to have value copied into it @@ -31,10 +30,14 @@ namespace SkOpts { @param count The number of times value should be copied into the buffer. */ static inline void sk_memset16(uint16_t buffer[], uint16_t value, int count) { -#if defined(SK_CPU_ARM64) - while (count --> 0) { *buffer++ = value; } return; -#elif defined(SK_CPU_ARM32) - if (count <= 10) { while (count --> 0) { *buffer++ = value; } return; } +#if defined(_MSC_VER) + INLINE_IF(count > 300) +#elif defined(SK_BUILD_FOR_ANDROID) && defined(SK_CPU_X86) + INLINE_IF(count < 300) +#elif defined(SK_ARM_HAS_NEON) || SK_CPU_SSE_LEVEL >= SK_CPU_SSE_LEVEL_SSE2 + INLINE_IF(true) +#else + INLINE_IF(count <= 10) #endif SkOpts::memset16(buffer, value, count); } @@ -45,14 +48,19 @@ static inline void sk_memset16(uint16_t buffer[], uint16_t value, int count) { @param count The number of times value should be copied into the buffer. */ static inline void sk_memset32(uint32_t buffer[], uint32_t value, int count) { -#if defined(SK_CPU_ARM64) - while (count --> 0) { *buffer++ = value; } return; -#elif defined(SK_CPU_ARM32) - if (count <= 10) { while (count --> 0) { *buffer++ = value; } return; } +#if defined(_MSC_VER) + INLINE_IF(count > 300) +#elif defined(SK_BUILD_FOR_ANDROID) && defined(SK_CPU_X86) + INLINE_IF(count < 300) +#elif defined(SK_ARM_HAS_NEON) || SK_CPU_SSE_LEVEL >= SK_CPU_SSE_LEVEL_SSE2 + INLINE_IF(true) +#else + INLINE_IF(count <= 10) #endif SkOpts::memset32(buffer, value, count); } +#undef INLINE_IF /////////////////////////////////////////////////////////////////////////////// -- cgit v1.2.3