国产精品电影_久久视频免费_欧美日韩国产激情_成年人视频免费在线播放_日本久久亚洲电影_久久都是精品_66av99_九色精品美女在线_蜜臀a∨国产成人精品_冲田杏梨av在线_欧美精品在线一区二区三区_麻豆mv在线看

Go Metrics SDK Tag 校驗性能優化實踐

數據庫
本文主要以 Go Metrics SDK 為例,講述對打點 API 的 hot-path 優化的實踐。

背景

Metrics SDK 是與字節內場時序數據庫 ByteTSD 配套的用戶指標打點 SDK,在字節內數十萬服務中集成,應用廣泛,因此 SDK 的性能優化是個重要和持續性的話題。

用戶在使用 SDK API 進行打點時,需要傳入指標對應的 Tag:

tags := []m.T{{Name: "foo", Value: "a"}, {Name: "bar", Value: "b"}}
metric.WithTags(tags...).Emit(m.Incr(1))

SDK 內部需要對用戶傳入的 Tag Value 的合法性進行校驗,IsValidTagValue,是 SDK 中對 Tag Value 進行字符合法性校驗的 util 函數,在對內部一些用戶的業務使用 pprof 拉取 profile 時,發現這兩個函數的 CPU 消耗占整個打點 API 過程的10%~20%,由于該函數發生在打點 API 的 hot-path 上,因此有必要對其進行進一步優化。

圖片圖片

分析

當前實現

我們先看一下 IsValidTagValue 函數內部的實現方式,是否有可優化的點。當前的實現,對于通過 API 傳入的每一個Tag Value,會進行以下操作來判斷其合法性:

  • 先判斷是否是在 Letter、Number 的范圍內,是則直接通過;
  • 存儲所有允許的特殊字符白名單,遍歷 Tag Value 對比其每個字符是否在白名單內。
var (
   // these runes are valid in tag values
   whiteListRunes = []rune{'_', '-', '.', '%', ':', ' ', '[', ']', ',', '%',
      '/', ':', ';', '<', '=', '>', '@', '~'}
)
func IsValidTagValue(s string) bool {
   if len(s) == 0 || len(s) > maxTagLen {
      return false
   }
   for i, r := range s {
      if r < minValidChar || r > maxValidChar {
         return false
      }
      if unicode.IsLetter(r) || unicode.IsNumber(r) || isRuneInWhiteList(r) {
         continue
      }
      return false
   }
   return true
}

該實現的時間復雜度簡單分析如下:

O(n.)n : stringlength

對于全由特殊字符構成的字符串,其時間復雜度是:

O(m * n)n : stringlength, m : whitelistlength

整個字符串的時間復雜度將介于O(n)到O(m * n)之間

問題點

可以看到,從當前實現看,一個主要影響性能的點是白名單列表的循環遍歷對比操作,我們需要考慮可能的優化方式來降低這個操作的時間復雜度。

優化

優化一:使用 Lookup Table,空間換時間

Metrics SDK 所有允許的合法的字符,實際上是 ASCII 的一個子集,也就是說其所有可能的字符最多只有128個,因此,我們可以通過空間換時間的方式,將對白名單的 O(n) 遍歷操作轉換為 O(1) 的查表操作:

  1. 提前對這128個字符建立一個包含128個成員的數組,在每一個 offset 上標記對應字符是否合法(合法則標記為1),這樣就建立了一個快速的 lookup table
  2. 對于要校驗的每一個字符,只要將其轉化為數組 offset,直接取數組成員值判斷是否為1即可

image.pngimage.png

table := [128]uint8{...}
// fill flags
for i := 0; i < 128; i++ {
   if unicode.IsNumber(rune(i)) || unicode.IsLetter(rune(i)) || isRuneInWhiteList(rune(i)) {
      table[i] = 1
   }
}
str := "hello"
for _, char := range []byte(str) {
    if r > maxValidChar {
       return false
    }
    if table[char] != 1 {
        return false
    }
}
return true

Benchmark

goos: linux
goarch: amd64
pkg: code.byted.org/gopkg/metrics_core/utils
cpu: Intel(R) Xeon(R) Platinum 8260 CPU @ 2.40GHz
BenchmarkLookupAlgoValid
BenchmarkLookupAlgoValid/baseline
BenchmarkLookupAlgoValid/baseline-8                   2839345               478.9 ns/op
BenchmarkLookupAlgoValid/lookup-arraytable
BenchmarkLookupAlgoValid/lookup-arraytable-8          6673456               167.8 ns/op

可以看到,速度提升60%

優化二:使用 SIMD,提升并行度

基于 Lookup Table 的校驗方式,將字符串校驗的時間復雜度穩定在了O(n)n : stringlength, 但有沒有可能進一步減少對字符串每一個字符的遍歷次數,比如一次校驗16個字符?

我們知道,SIMD 指令是循環展開優化的常用思路,那么這里是否可以引入 SIMD 來進一步提升運算并行度和效率?

答案是肯定的,以 intel x86 架構為例,參考其 Intrinsics Guide,在不同的 SIMD 指令集上提供了多個可以實現在不同大小的 lookup table 中查找數據的指令,這些指令可以作為我們加速方案的基礎:

圖片圖片

注:可以通過 cat /proc/cpuinfo 命令來查看機器支持的simd指令集

鑒于 vpermi2b 指令的支持目前不是很普遍的原因,我們考慮使用 pshufb 來實現一個 SIMD 版本,但我們的Lookup Table 需要調整下,因為:

  • 雖然我們基于 bitmap 實現的 Lookup Table 是 128 bits,剛好可以填充 128 bits 的寄存器
  • 但 pshufb 是按字節進行 lookup 的,128 bits 的寄存器支持16字節的 lookup

因此,我們需要將 bitmap lookup table 做一次升維,變成一個16*8 bits 的二維 lookup table,做兩次遞進的行、列 lookup 完成查找,基于該思路,可以實現一次校驗16個字符,大大提升并行度。

整體方案

該方案主要參考這篇文章:SIMDized check which bytes are in a set(http://0x80.pl/articles/simd-byte-lookup.html)

構建 bitmap table

對于一個 ASCII 字符,我們用其低 4bits 作為 lookup table 的 row index,用高 3bits 作為 lookup table 的 column index,這樣對128個 ASCII 字符建立如下的一個二維 bitmap table:

圖片圖片

Lookup 流程

我們先實現一個純 go 語言版本的基于二維 bitmap lookup table 的方案,以便于理解其中的關鍵邏輯:

table := [16]uint8{}
// fill flags
for i := 0; i < 128; i++ {
   if unicode.IsNumber(rune(i)) || unicode.IsLetter(rune(i)) || isRuneInWhiteList(rune(i)) {
      lowerNibble := i & 0x0f
      upperNibble := i >> 4
      table[lowerNibble] |= 1 << upperNibble
   }
}
str := "hello"

for _, char := range []byte(str) {
    if r > maxValidChar {
       return false
    }
    lowerNibble := uint8(r) & 0x0f
    upperNibble := uint8(r) >> 4
    if table[lowerNibble]&(1<<upperNibble) == 0 {
       return false
    }
}
return true

如上代碼示例,可以看到,判斷某個字符合法的關鍵邏輯是:

  • 通過 table[lowerNibble] 獲取table第 lowerNibble 行內容,然后再看其第 upperNibble 個 bit 位是否為0

而 SIMD 版本,即是將上述的每一步操作都使用對應的 SIMD 指令變成對16個字節的并行操作,SIMD 的關鍵操作流程以及和上述 go 代碼的對應關系如下:

圖片圖片

代碼實現

在 go 語言中,想要使用 SIMD,需要寫 plan9 匯編,而編寫 plan9 通常有兩種方式:

  • 手撕,可借助 avo 這樣的工具
  • C code 轉 plan9,可借助 goat、c2goasm 這樣的工具

這里采用 C code 轉 plan9 的方式,先寫一個 C 版本:

注:由于 goat 工具限制,不能很好的支持 C 代碼中的常量定義,因此以下示例通過函數參數定義用到的 sm、hm 常量

#include <tmmintrin.h>
// is_valid_string returns 1 if all chars is in table, returns 0 else.
void is_valid_string(char* table, char* strptr, long strlen, char* sm, char* hm, char* rt) {
    __m128i bitmap = _mm_loadu_si128((__m128i*)table);
    __m128i shift_mask = _mm_loadu_si128((__m128i*)sm);
    __m128i high_mask = _mm_loadu_si128((__m128i*)hm);
    size_t n = strlen/16;
    for (size_t i = 0; i < n; i++)
    {
        __m128i input = _mm_loadu_si128((__m128i*)strptr);
        __m128i rows = _mm_shuffle_epi8(bitmap, input);
        __m128i hi_nibbles = _mm_and_si128(_mm_srli_epi16(input, 4), high_mask);
        __m128i cols = _mm_shuffle_epi8(shift_mask, hi_nibbles);
        __m128i tmp = _mm_and_si128(rows, cols);
        __m128i result = _mm_cmpeq_epi8(tmp, cols);
        size_t mask = _mm_movemask_epi8(result);
        if (mask != 65535) {
            *rt = 0;
            return;
        }
        strptr = strptr + 16;
    }
    size_t left = strlen%16;
    for (size_t i = 0; i < left; i++)
    {
        size_t lower = strptr[i] & 0x0f;
        size_t higher = strptr[i] >> 4;
        if ((table[lower] & (1<<higher)) == 0) {
            *rt = 0;
            return;
        }
    }
    *rt = 1;
    return;
}

通過以下命令轉為 plan9:

goat is_valid_string.c -03 -mssse3

生成的 plan9 代碼如下:

//go:build !noasm && amd64
// AUTO-GENERATED BY GOAT -- DO NOT EDIT
TEXT ·_is_valid_string(SB), $0-48
   MOVQ table+0(FP), DI
   MOVQ strptr+8(FP), SI
   MOVQ strlen+16(FP), DX
   MOVQ sm+24(FP), CX
   MOVQ hm+32(FP), R8
   MOVQ rt+40(FP), R9
   WORD $0x8949; BYTE $0xd2     // movq   %rdx, %r10
   LONG $0x3ffac149             // sarq   $63, %r10
   LONG $0x3ceac149             // shrq   $60, %r10
   WORD $0x0149; BYTE $0xd2     // addq   %rdx, %r10
   LONG $0x0f428d48             // leaq   15(%rdx), %rax
   LONG $0x1ff88348             // cmpq   $31, %rax
   JB   LBB0_4
   LONG $0x076f0ff3             // movdqu (%rdi), %xmm0
   LONG $0x096f0ff3             // movdqu (%rcx), %xmm1
   LONG $0x6f0f41f3; BYTE $0x10 // movdqu (%r8), %xmm2
   WORD $0x894d; BYTE $0xd0     // movq   %r10, %r8
   LONG $0x04f8c149             // sarq   $4, %r8
   WORD $0xc031                 // xorl   %eax, %eax
LBB0_2:
   LONG $0x1e6f0ff3               // movdqu   (%rsi), %xmm3
   LONG $0xe06f0f66               // movdqa   %xmm0, %xmm4
   LONG $0x00380f66; BYTE $0xe3   // pshufb   %xmm3, %xmm4
   LONG $0xd3710f66; BYTE $0x04   // psrlw    $4, %xmm3
   LONG $0xdadb0f66               // pand %xmm2, %xmm3
   LONG $0xe96f0f66               // movdqa   %xmm1, %xmm5
   LONG $0x00380f66; BYTE $0xeb   // pshufb   %xmm3, %xmm5
   LONG $0xe5db0f66               // pand %xmm5, %xmm4
   LONG $0xe5740f66               // pcmpeqb  %xmm5, %xmm4
   LONG $0xccd70f66               // pmovmskb %xmm4, %ecx
   LONG $0xfffff981; WORD $0x0000 // cmpl $65535, %ecx
   JNE  LBB0_8
   LONG $0x10c68348               // addq $16, %rsi
   LONG $0x01c08348               // addq $1, %rax
   WORD $0x394c; BYTE $0xc0       // cmpq %r8, %rax
   JB   LBB0_2
LBB0_4:
   LONG $0xf0e28349         // andq   $-16, %r10
   WORD $0xb041; BYTE $0x01 // movb   $1, %r8b
   WORD $0x294c; BYTE $0xd2 // subq   %r10, %rdx
   JE   LBB0_9
   WORD $0xc031             // xorl   %eax, %eax
LBB0_7:
   LONG $0x1cbe0f4c; BYTE $0x06 // movsbq (%rsi,%rax), %r11
   WORD $0x8945; BYTE $0xda     // movl   %r11d, %r10d
   LONG $0x0fe28341             // andl   $15, %r10d
   LONG $0x04ebc141             // shrl   $4, %r11d
   LONG $0x0cbe0f42; BYTE $0x17 // movsbl (%rdi,%r10), %ecx
   LONG $0xd9a30f44             // btl    %r11d, %ecx
   JAE  LBB0_8
   LONG $0x01c08348             // addq   $1, %rax
   WORD $0x3948; BYTE $0xd0     // cmpq   %rdx, %rax
   JB   LBB0_7
LBB0_9:
   WORD $0x8845; BYTE $0x01 // movb   %r8b, (%r9)
   BYTE $0xc3               // retq
LBB0_8:
   WORD $0x3145; BYTE $0xc0 // xorl   %r8d, %r8d
   WORD $0x8845; BYTE $0x01 // movb   %r8b, (%r9)
   BYTE $0xc3               // retq

對應的 Go Wrapper 代碼如下:

var (
        // these runes are valid in tag values
        whiteListRunes = []rune{'_', '-', '.', '%', ':', ' ', '[', ']', ',', '%',
                '/', ':', ';', '<', '=', '>', '@', '~'}
        rcBitTable [16]uint8
        smTable    [16]int8
        hmTable    [16]uint8
)
//go:noescape
func _is_valid_string(table unsafe.Pointer, str unsafe.Pointer, len int32, sm, hm unsafe.Pointer, rt unsafe.Pointer)
func init() {
        // build tables
        for i := 0; i < 128; i++ {
                if unicode.IsNumber(rune(i)) || unicode.IsLetter(rune(i)) || isRuneInWhiteList(rune(i)) {
                        lowerNibble := i & 0x0f
                        upperNibble := i >> 4
                        rcBitTable[lowerNibble] |= 1 << upperNibble
                }
        }
        smTable = [16]int8{1, 2, 4, 8, 16, 32, 64, -128, 1, 2, 4, 8, 16, 32, 64, -128}
        hmTable = [16]uint8{0x0f, 0x0f, 0x0f, 0x0f, 0x0f, 0x0f, 0x0f, 0x0f, 0x0f, 0x0f, 0x0f, 0x0f, 0x0f, 0x0f, 0x0f, 0x0f}
}
func IsValidTagValueLookup2dBitTableSIMD(s string) bool {
        l := len(s)
        if l == 0 || len(s) > maxTagLen {
                return false
        }
        sptr := unsafe.Pointer((*reflect.StringHeader)(unsafe.Pointer(&s)).Data)
        var rt byte
        _is_valid_string(unsafe.Pointer(&rcBitTable), sptr, int32(len(s)), unsafe.Pointer(&smTable), unsafe.Pointer(&hmTable), unsafe.Pointer(&rt))
        return rt != 0
}

Benchmark

  1. 先做一個通用的 benchmark,待校驗的 string 長度從1 ~ 20不等:
goos: linux
goarch: amd64
pkg: code.byted.org/gopkg/metrics_core/utils
cpu: Intel(R) Xeon(R) Platinum 8260 CPU @ 2.40GHz
BenchmarkLookupAlgoValid
BenchmarkLookupAlgoValid/baseline
BenchmarkLookupAlgoValid/baseline-8                  2574217               510.5 ns/op
BenchmarkLookupAlgoValid/lookup-arraytable
BenchmarkLookupAlgoValid/lookup-arraytable-8         6347204               193.7 ns/op
BenchmarkLookupAlgoValid/lookup-2d-bittable-simd
BenchmarkLookupAlgoValid/lookup-2d-bittable-simd-8   6133671               185.2 ns/op

可以看到,SIMD 版本在平均水平上與 arraytable 相當

  1. 由于 SIMD 優勢主要體現在長字符串時,因此,我們使用一組長度為20左右的 string,再次 benchmark:
goos: linux
goarch: amd64
pkg: code.byted.org/gopkg/metrics_core/utils
cpu: Intel(R) Xeon(R) Platinum 8260 CPU @ 2.40GHz
BenchmarkLookupAlgoValidLong
BenchmarkLookupAlgoValidLong/baseline
BenchmarkLookupAlgoValidLong/baseline-8                  3523198           356.4 ns/op
BenchmarkLookupAlgoValidLong/lookup-arraytable
BenchmarkLookupAlgoValidLong/lookup-arraytable-8         8434142           153.3 ns/op
BenchmarkLookupAlgoValidLong/lookup-2d-bittable-simd
BenchmarkLookupAlgoValidLong/lookup-2d-bittable-simd-8  13621970            87.29 ns/op

可以看到,在長 string 上 SIMD 版本表現出非常大的優勢,相對于 arraytable 版本再次提升50%

結論

  • 通過 lookup table + SIMD 的方式優化,字符校驗的整體性能可以提升2~4倍
  • 但由于在 Go 中 plan9 匯編無法內聯,因此在待校驗的字符串較短時不能體現其優勢
責任編輯:龐桂玉 來源: 字節跳動技術團隊
相關推薦

2022-10-28 13:41:51

字節SDK監控

2024-01-03 16:29:01

Agent性能優化

2020-03-23 15:15:57

MySQL性能優化數據庫

2010-07-06 09:07:09

2020-07-17 19:55:50

Vue前端性能優化

2021-08-13 09:06:52

Go高性能優化

2021-09-24 14:02:53

性能優化實踐

2019-08-02 11:28:45

HadoopYARN調度系統

2022-03-29 13:27:22

Android優化APP

2025-05-15 07:11:51

2014-03-19 14:34:06

JQuery高性能

2017-03-01 20:53:56

HBase實踐

2022-07-08 09:38:27

攜程酒店Flutter技術跨平臺整合

2016-11-17 09:00:46

HBase優化策略

2012-12-24 09:55:15

JavaJava WebJava優化

2022-07-15 09:20:17

性能優化方案

2021-09-11 21:02:24

監控Sentry Web性能

2023-12-30 18:35:37

Go識別應用程序

2021-08-04 09:33:22

Go 性能優化

2025-05-21 08:15:00

GoAPI開發
點贊
收藏

51CTO技術棧公眾號

国产精品久久久久久av| 国产视频二区| 美女看a上一区| 中文字幕日韩精品久久| 国产激情一区二区三区| 97在线播放视频| 一区二区三区高清在线| 国产女主播在线直播| 制服视频三区第一页精品| 欧美办公室脚交xxxx| 日韩亚洲国产中文字幕| 亚洲精品一级二级三级| 官网99热精品| 国产宾馆实践打屁股91| jlzzjlzz欧美大全| 欧美美女黄视频| 久久91导航| 欧洲精品毛片网站| 亚洲久久一区| 日韩精品在线免费| 成人在线超碰| 国产精品成人一区二区三区| 日韩成人一区二区三区在线观看| 久久这里只有精品23| 亚洲综合一区二区精品导航| 久久五月精品| 精品视频9999| 亚洲国产日本| 免费在线激情视频| 欧洲日韩一区二区三区| 欧美三级电影网址| 91九色偷拍| 99久久777色| 国产小视频福利在线| 最近2019中文字幕大全第二页| 成人在线免费观看视频| 午夜啪啪免费视频| 亚洲在线观看免费视频| 中文在线免费视频| 成人免费直播live| 99麻豆久久久国产精品免费| yw在线观看| 欧美国产日本在线| 日韩国产欧美视频| 色佬视频在线观看| 最近2019中文字幕一页二页| 尤物精品在线| 污污网站免费看| 亚洲第一二三四五区| 久久网站免费观看| 北条麻妃av高潮尖叫在线观看| 欧美一级片免费看| 日韩理论电影| 久久久国产欧美| 精品国产a毛片| 亚洲精品国产日韩| 国产米奇在线777精品观看| 亚洲不卡在线观看| 亚洲成人精品综合在线| 国产高清一区二区三区| 国产亚洲欧美日韩在线一区| 美女国产在线| 国产精品普通话| 久久亚洲精华国产精华液 | 日韩精品视频观看| 精品日产免费二区日产免费二区| 96av麻豆蜜桃一区二区| 成人国产综合| 亚洲日日夜夜| 亚洲性视频大全| 黄色在线播放网站| 免费在线精品视频| 日韩精品中文字幕一区二区三区 | 日韩av一二三四区| 久久精品国产欧美亚洲人人爽| 视频一区中文字幕| 日本在线观看大片免费视频| 日韩av免费在线观看| 精品一区免费av| 最新av网站在线观看| 欧美人与性动交a欧美精品| 日韩精品午夜视频| 一级毛片aaaaaa免费看| 91精品国产福利| 日韩护士脚交太爽了| 国产噜噜噜噜噜久久久久久久久 | 奇米成人av国产一区二区三区| 久久久99久久| 欧美日韩爱爱| av亚洲免费| 欧美男男gaygay1069| 一级特黄视频| 精品日本一区二区三区| 亚洲激情国产精品| 欧美性开放视频| 国产精品嫩草影院com| 激情欧美一区二区三区黑长吊| 丰满少妇久久久| 国产美女被下药99| 色综合色综合色综合色综合色综合| 九色视频网站| 免费的av在线| 成人亚洲激情网| 久久久国产精彩视频美女艺术照福利| 久久女同精品一区二区| 激情av综合| 可以在线观看的av| 在线亚洲美日韩| 日韩理论片久久| 综合电影一区二区三区 | 亚洲精品视频在线观看网站| 激情久久久久| 久久久精品动漫| 精品三级在线观看| 亚洲v中文字幕| 日韩二区三区在线观看| 欧美久久综合| 国产香蕉精品| 国产精品xxx在线观看| 日韩美女网站| 五月天亚洲综合| 最近2019好看的中文字幕免费| 一区二区三区成人| 裸体一区二区| 欧美精品日韩| 91国内精品白嫩初高生| 国产在线精品一区二区三区》| 欧美日韩国产首页在线观看| 天堂成人国产精品一区| 精品3atv在线视频| 一级黄色特级片| 91免费版网站入口| 日韩三级视频中文字幕| 亚洲第一视频在线观看| 亚洲第一网站免费视频| 日韩欧美在线不卡| 亚洲欧美综合色| 中文av字幕一区| 成人毛片老司机大片| 日韩加勒比系列| 成人黄色生活片| 国产超碰91| 国产欧美日韩视频| 五月天亚洲婷婷| 天堂成人免费av电影一区| 久久亚洲国产精品尤物| 自由色视频.| 亚洲图片小说在线| 欧美一级大片在线观看| 91精品国产色综合久久ai换脸| 不卡欧美aaaaa| 中文av一区| 成人开心激情| 蜜桃av成人| 欧美久久久久久久久久久久久久| 国产精品1234| 亚洲精品国产精品久久清纯直播 | 韩剧1988免费观看全集| 一本色道久久综合狠狠躁的推荐 | 中文字幕无线精品亚洲乱码一区| 亚洲四区在线观看| 乱一区二区av| 亚洲系列另类av| free性欧美| 三级黄色网址| 无码人妻精品一区二区蜜桃网站| 成人午夜在线影院| 久久综合久中文字幕青草| 欧美喷潮久久久xxxxx| 国产精品私房写真福利视频| 日韩影院精彩在线| 日韩成人免费| www一区二区三区| 午夜av在线播放| 一二三四在线视频观看社区| 婷婷无套内射影院| 国产美女精品免费电影| 国内精品二区| 在线视频尤物| 成人在线观看免费播放| 亚洲国产最新| 久久国产精品无码网站| 亚洲女人小视频在线观看| 欧美日韩一区二区欧美激情| 在线精品一区二区| 在线看片一区| 久久综合九色综合久久久精品综合 | 亚洲国产国产| 成人av观看| jizzjizz在线观看| 激情视频免费| 久久久久久久久久久久久国产精品| 久久精品日产第一区二区三区精品版| 8x拔播拔播x8国产精品| 中文字幕亚洲欧美| 亚洲国产精品yw在线观看| 欧美日韩在线播放三区| 香蕉成人啪国产精品视频综合网 | 日本欧美一区二区三区乱码| 久久青草久久|