日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時(shí)間：8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
如何更快地將String轉(zhuǎn)換成Int/Long

你好鴨，Kirito 今天又來分享性能優(yōu)化的騷操作了。

在很多追求性能的程序挑戰(zhàn)賽中，經(jīng)常會(huì)遇到一個(gè)操作：將 String 轉(zhuǎn)換成 Integer/Long。如果你沒有開發(fā)過高并發(fā)的系統(tǒng)，或者沒有參加過任何性能挑戰(zhàn)賽，可能會(huì)有這樣的疑問：這有啥好講究的，Integer.valueOf/Long.valueOf 又不是不能用。實(shí)際上，很多內(nèi)置的轉(zhuǎn)換工具類只滿足了功能性的需求，在高并發(fā)場景下，可能會(huì)是熱點(diǎn)方法，成為系統(tǒng)性能的瓶頸。

文章開頭，我先做一下說明，本文的測試結(jié)論出自：https://kholdstare.github.io/technical/2020/05/26/faster-integer-parsing.html 。測試代碼基于 C++，我會(huì)在翻譯原文的同時(shí)，添加了部分自己的理解，以協(xié)助讀者更好地理解其中的細(xì)節(jié)。

問題提出

假設(shè)現(xiàn)在有一些文本信息，固定長度為 16 位，例如下文給出的時(shí)間戳，需要盡可能快地解析這些時(shí)間戳

 
 
 
 
    
  
  
  
  
  1. timestamp
    2. 
  
  
  
  
  2. 1585201087123567
    3. 
  
  
  
  
  3. 1585201087123585
    4. 
  
  
  
  
  4. 1585201087123621
    5.

方法體如下所示：

 
 
 
 
    
  
  
  
  
  1. std::uint64_t parse_timestamp(std::string_view s)
    2. 
  
  
  
  
  2. {
    3. 
  
  
  
  
  3.   // ???
    4. 
  
  
  
  
  4. }
    5.

問題提出后，大家不妨先思考下，如果是你，你會(huì)采取什么方案呢?帶著這樣的思考，我們進(jìn)入下面的一個(gè)個(gè)方案。

Native 方案

我們有哪些現(xiàn)成的轉(zhuǎn)換方案呢?

  • 繼承自 C 的 std::atoll
  • std::stringstream
  • C++17 提供的 charconv
  • boost::spirit::qi

評(píng)測程序采用 Google Benchmark 進(jìn)行對(duì)比評(píng)測。同時(shí)，我們以不做任何轉(zhuǎn)換的方案來充當(dāng) baseline，以供對(duì)比。(baseline 方案在底層，相當(dāng)于將數(shù)值放進(jìn)來了寄存器中，所以命名成了 BM_mov)

下面給出的評(píng)測代碼不是那么地關(guān)鍵，只是為了給大家展示評(píng)測是如何運(yùn)行的。

 
 
 
 
    
  
  
  
  
  1. static void BM_mov(benchmark::State& state) {
    2. 
  
  
  
  
  2.   for (auto _ : state) {
    3. 
  
  
  
  
  3.     benchmark::DoNotOptimize(1585201087123789);
    4. 
  
  
  
  
  4.   }
    5. 
  
  
  
  
  5. }
    6. 
  
  
  
  
  6. 
  
  
  
  
  7. static void BM_atoll(benchmark::State& state) {
    8. 
  
  
  
  
  8.   for (auto _ : state) {
    9. 
  
  
  
  
  9.     benchmark::DoNotOptimize(std::atoll(example_timestamp));
    10. 
  
  
  
  
  10.   }
    11. 
  
  
  
  
  11. }
    12. 
  
  
  
  
  12. 
  
  
  
  
  13. static void BM_sstream(benchmark::State& state) {
    14. 
  
  
  
  
  14.   std::stringstream s(example_timestamp);
    15. 
  
  
  
  
  15.   for (auto _ : state) {
    16. 
  
  
  
  
  16.     s.seekg(0);
    17. 
  
  
  
  
  17.     std::uint64_t i = 0;
    18. 
  
  
  
  
  18.     s >> i;
    19. 
  
  
  
  
  19.     benchmark::DoNotOptimize(i);
    20. 
  
  
  
  
  20.   }
    21. 
  
  
  
  
  21. }
    22. 
  
  
  
  
  22. static void BM_charconv(benchmark::State& state) {
    23. 
  
  
  
  
  23.   auto s = example_timestamp;
    24. 
  
  
  
  
  24.   for (auto _ : state) {
    25. 
  
  
  
  
  25.     std::uint64_t result = 0;
    26. 
  
  
  
  
  26.     std::from_chars(s.data(), s.data() + s.size(), result);
    27. 
  
  
  
  
  27.     benchmark::DoNotOptimize(result);
    28. 
  
  
  
  
  28.   }
    29. 
  
  
  
  
  29. }
    30. 
  
  
  
  
  30. 
  
  
  
  
  31. static void BM_boost_spirit(benchmark::State& state) {
    32. 
  
  
  
  
  32.   using boost::spirit::qi::parse;
    33. 
  
  
  
  
  33.   for (auto _ : state) {
    34. 
  
  
  
  
  34.     std::uint64_t result = 0;
    35. 
  
  
  
  
  35.     parse(s.data(), s.data() + s.size(), result);
    36. 
  
  
  
  
  36.     benchmark::DoNotOptimize(result);
    37. 
  
  
  
  
  37.   }
    38. 
  
  
  
  
  38. }
    39.

Native

可以發(fā)現(xiàn) stringstream 表現(xiàn)的非常差。當(dāng)然，這并不是一個(gè)公平的比較，但從測評(píng)結(jié)果來看，使用 stringstream 來實(shí)現(xiàn)數(shù)值轉(zhuǎn)換相比 baseline 慢了 391 倍。相比之下， 和 boost::spirit 表現(xiàn)的更好。

既然我們已經(jīng)知道了目標(biāo)字符串包含了要解析的數(shù)字，而且不需要做任何的數(shù)值校驗(yàn)，基于這些前提，我們可以思考下，還有更快的方案嗎?

Naive 方案

我們可以通過一個(gè)再簡單不過的循環(huán)方案，一個(gè)個(gè)地解析字符。

 
 
 
 
    
  
  
  
  
  1. inline std::uint64_t parse_naive(std::string_view s) noexcept
    2. 
  
  
  
  
  2. {
    3. 
  
  
  
  
  3.   std::uint64_t result = 0;
    4. 
  
  
  
  
  4.   for(char digit : s)
    5. 
  
  
  
  
  5.   {
    6. 
  
  
  
  
  6.     result *= 10;
    7. 
  
  
  
  
  7.     result += digit - '0';
    8. 
  
  
  
  
  8.   }
    9. 
  
  
  
  
  9.   return result;
    10. 
  
  
  
  
  10. }
    11.

Naive

雖然這層 for 循環(huán)看起來呆呆的，但如果這樣一個(gè)呆呆的解決方案能夠擊敗標(biāo)準(zhǔn)庫實(shí)現(xiàn)，何樂而不為呢?前提是，標(biāo)準(zhǔn)庫的實(shí)現(xiàn)考慮了異常場景，做了一些校驗(yàn)，這種 for 循環(huán)寫法的一個(gè)前提是，我們的輸入一定是合理的。

之前我的文章也提到過這個(gè)方案。顯然， naive 的方案之后還會(huì)有更優(yōu)的替代方案。

循環(huán)展開方案

記得我們?cè)谖恼碌拈_頭加了一個(gè)限定，限定了字符串長度固定是 16 位，所以循環(huán)是可以被省略的，循環(huán)展開之后，方案可以更快。

 
 
 
 
    
  
  
  
  
  1. inline std::uint64_t parse_unrolled(std::string_view s) noexcept
    2. 
  
  
  
  
  2. {
    3. 
  
  
  
  
  3.   std::uint64_t result = 0;
    4. 
  
  
  
  
  4. 
  
  
  
  
  5.   result += (s[0] - '0') * 1000000000000000ULL;
    6. 
  
  
  
  
  6.   result += (s[1] - '0') * 100000000000000ULL;
    7. 
  
  
  
  
  7.   result += (s[2] - '0') * 10000000000000ULL;
    8. 
  
  
  
  
  8.   result += (s[3] - '0') * 1000000000000ULL;
    9. 
  
  
  
  
  9.   result += (s[4] - '0') * 100000000000ULL;
    10. 
  
  
  
  
  10.   result += (s[5] - '0') * 10000000000ULL;
    11. 
  
  
  
  
  11.   result += (s[6] - '0') * 1000000000ULL;
    12. 
  
  
  
  
  12.   result += (s[7] - '0') * 100000000ULL;
    13. 
  
  
  
  
  13.   result += (s[8] - '0') * 10000000ULL;
    14. 
  
  
  
  
  14.   result += (s[9] - '0') * 1000000ULL;
    15. 
  
  
  
  
  15.   result += (s[10] - '0') * 100000ULL;
    16. 
  
  
  
  
  16.   result += (s[11] - '0') * 10000ULL;
    17. 
  
  
  
  
  17.   result += (s[12] - '0') * 1000ULL;
    18. 
  
  
  
  
  18.   result += (s[13] - '0') * 100ULL;
    19. 
  
  
  
  
  19.   result += (s[14] - '0') * 10ULL;
    20. 
  
  
  
  
  20.   result += (s[15] - '0');
    21. 
  
  
  
  
  21. 
  
  
  
  
  22.   return result;
    23. 
  
  
  
  
  23. }
    24.

unrolled

關(guān)于循環(huán)展開為什么會(huì)更快，可以參考我過去關(guān)于 JMH 的文章。

byteswap 方案

先思考下，如果繼續(xù)圍繞上述的方案進(jìn)行，我們可能只有兩個(gè)方向：

并發(fā)執(zhí)行加法和乘法計(jì)算，但這種 CPU 操作似乎又不能通過多線程之類的手段進(jìn)行加速，該如何優(yōu)化是個(gè)問題

將乘法和加法運(yùn)算轉(zhuǎn)換成位運(yùn)算，獲得更快的 CPU 執(zhí)行速度，但如果轉(zhuǎn)換又是個(gè)問題

相信讀者們都會(huì)有這樣的疑問，那我們繼續(xù)帶著這樣疑問往下看原作者的優(yōu)化思路是什么。

緊接著上述的循環(huán)展開方案，將 “1234” 解析為 32 位整數(shù)對(duì)應(yīng)的循環(huán)展開操作繪制為圖，過程如下：

Unrolled solution graph

我們可以看到，乘法和加法的操作次數(shù)跟字符的數(shù)量是線性相關(guān)的。由于每一次乘法都是由不同的乘數(shù)進(jìn)行，所以我們不能只乘“一次”，在乘法的最后，我們還需要將所有結(jié)果相加。乍一看，好像很難優(yōu)化。

下面的優(yōu)化技巧，需要一些操作系統(tǒng)、編譯原理相關(guān)的知識(shí)作為輔助，你需要了解 byteswap 這個(gè)系統(tǒng)調(diào)用，了解大端序和小端序的字節(jié)序表示方法(后面我也會(huì)分享相關(guān)的文章)，如果你不關(guān)心這些細(xì)節(jié)，也可以直接跳到本段的最后，直接看結(jié)論。

理解清楚下圖的含義，需要理解幾個(gè)概念：

  • 字符 1 對(duì)應(yīng)的 ascii 值是 31，相應(yīng)的 2 對(duì)應(yīng) 32，4 對(duì)應(yīng) 34
  • 在小端序機(jī)器上(例如 x86)，字符串是以大端序存儲(chǔ)的，而 Integer 是以小端序存儲(chǔ)的
  • byteswap 可以實(shí)現(xiàn)字節(jié)序調(diào)換

byteswap

上圖展示了十六進(jìn)制表示下的轉(zhuǎn)換過程，可以在更少的操作下達(dá)到最終的解析狀態(tài)。

將上圖的流程使用 C++ 來實(shí)現(xiàn)，將 String 重新解釋為 Integer，必須使用 std::memcpy(避免命名沖突)，執(zhí)行相減操作，然后通過編譯器內(nèi)置的 __builtin_bswap64 在一條指令中交換字節(jié)。到目前為止，這是最快的一個(gè)優(yōu)化。

 
 
 
 
    
  
  
  
  
  1. template 
    2. 
  
  
  
  
  2. inline T get_zeros_string() noexcept;
    3. 
  
  
  
  
  3. 
  
  
  
  
  4. template <>
    5. 
  
  
  
  
  5. inline std::uint64_t get_zeros_string() noexcept
    6. 
  
  
  
  
  6. {
    7. 
  
  
  
  
  7.   std::uint64_t result = 0;
    8. 
  
  
  
  
  8.   constexpr char zeros[] = "00000000";
    9. 
  
  
  
  
  9.   std::memcpy(&result, zeros, sizeof(result));
    10. 
  
  
  
  
  10.   return result;
    11. 
  
  
  
  
  11. }
    12. 
  
  
  
  
  12. 
  
  
  
  
  13. inline std::uint64_t parse_8_chars(const char* string) noexcept
    14. 
  
  
  
  
  14. {
    15. 
  
  
  
  
  15.   std::uint64_t chunk = 0;
    16. 
  
  
  
  
  16.   std::memcpy(&chunk, string, sizeof(chunk));
    17. 
  
  
  
  
  17.   chunk = __builtin_bswap64(chunk - get_zeros_string());
    18. 
  
  
  
  
  18. 
  
  
  
  
  19.   // ...
    20. 
  
  
  
  
  20. }
    21.

我們看上去得到了想要的結(jié)果，但是這個(gè)方案從時(shí)間復(fù)雜度來看，仍然是 O(n) 的，是否可以在這個(gè)方案的基礎(chǔ)上，繼續(xù)進(jìn)行優(yōu)化呢?

分治方案

從最初的 Native 方案，到上一節(jié)的 byteswap 方案，我們都只是優(yōu)化了 CPU 操作，并沒有優(yōu)化復(fù)雜度，既然不滿足于 O(n)，那下一個(gè)復(fù)雜度可能性是什么?O(logn)!我們可以將每個(gè)相鄰的數(shù)字組合成一對(duì)，然后將每對(duì)數(shù)字繼續(xù)組合成一組四個(gè)，依此類推，直到我們得到整個(gè)整數(shù)。

如何同時(shí)處理鄰近的數(shù)字，這是讓算法跑進(jìn) O(logn) 的關(guān)鍵

該方案的關(guān)鍵之處在于：將偶數(shù)位的數(shù)字乘以 10 的冪，并且單獨(dú)留下奇數(shù)位的數(shù)字。這可以通過位掩碼(bitmasking)來實(shí)現(xiàn)

分治方案

通過 bitmasking，我們可以一次對(duì)多個(gè)數(shù)字進(jìn)行操作，將它們組合成一個(gè)更大的組合

通過使用這個(gè)掩碼技巧來實(shí)現(xiàn)前文提到的 parse_8_chars 函數(shù)。使用 bitmasking 的另一好處在于，我們不用減去 '0' ，因?yàn)槲谎诖a的副作用，使得我們正好可以省略這一步。

 
 
 
 
    
  
  
  
  
  1. inline std::uint64_t parse_8_chars(const char* string) noexcept
    2. 
  
  
  
  
  2. {
    3. 
  
  
  
  
  3.   std::uint64_t chunk = 0;
    4. 
  
  
  
  
  4.   std::memcpy(&chunk, string, sizeof(chunk));
    5. 
  
  
  
  
  5. 
  
  
  
  
  6.   // 1-byte mask trick (works on 4 pairs of single digits)
    7. 
  
  
  
  
  7.   std::uint64_t lower_digits = (chunk & 0x0f000f000f000f00) >> 8;
    8. 
  
  
  
  
  8.   std::uint64_t upper_digits = (chunk & 0x000f000f000f000f) * 10;
    9. 
  
  
  
  
  9.   chunk = lower_digits + upper_digits;
    10. 
  
  
  
  
  10. 
  
  
  
  
  11.   // 2-byte mask trick (works on 2 pairs of two digits)
    12. 
  
  
  
  
  12.   lower_digits = (chunk & 0x00ff000000ff0000) >> 16;
    13. 
  
  
  
  
  13.   upper_digits = (chunk & 0x000000ff000000ff) * 100;
    14. 
  
  
  
  
  14.   chunk = lower_digits + upper_digits;
    15. 
  
  
  
  
  15. 
  
  
  
  
  16.   // 4-byte mask trick (works on pair of four digits)
    17. 
  
  
  
  
  17.   lower_digits = (chunk & 0x0000ffff00000000) >> 32;
    18. 
  
  
  
  
  18.   upper_digits = (chunk & 0x000000000000ffff) * 10000;
    19. 
  
  
  
  
  19.   chunk = lower_digits + upper_digits;
    20. 
  
  
  
  
  20. 
  
  
  
  
  21.   return chunk;
    22. 
  
  
  
  
  22. }
    23.

trick 方案

綜合前面兩節(jié)，解析 16 位的數(shù)字，我們將它分成兩個(gè) 8 字節(jié)的塊，運(yùn)行剛剛編寫的 parse_8_chars，并對(duì)其進(jìn)行基準(zhǔn)測試!

 
 
 
 
    
  
  
  
  
  1. inline std::uint64_t parse_trick(std::string_view s) noexcept
    2. 
  
  
  
  
  2. {
    3. 
  
  
  
  
  3.   std::uint64_t upper_digits = parse_8_chars(s.data());
    4. 
  
  
  
  
  4.   std::uint64_t lower_digits = parse_8_chars(s.data() + 8);
    5. 
  
  
  
  
  5.   return upper_digits * 100000000 + lower_digits;
    6. 
  
  
  
  
  6. }
    7. 
  
  
  
  
  7. 
  
  
  
  
  8. static void BM_trick(benchmark::State& state) {
    9. 
  
  
  
  
  9.   for (auto _ : state) {
    10. 
  
  
  
  
  10.     benchmark::DoNotOptimize(parse_trick(example_stringview));
    11. 
  
  
  
  
  11.   }
    12. 
  
  
  
  
  12. }
    13.

trick

看上去優(yōu)化的不錯(cuò)，我們將循環(huán)展開方案的基準(zhǔn)測試優(yōu)化了近 56% 的性能。能做到這一點(diǎn)，主要得益于我們手動(dòng)進(jìn)行一系列 CPU 優(yōu)化的操作，雖然這些并不是特別通用的技巧。這樣算不算開了個(gè)不好的頭呢?我們看起來對(duì) CPU 操作干預(yù)地太多了，或許我們應(yīng)該放棄這些優(yōu)化，讓 CPU 自由地飛翔。

SIMD trick 方案

你是不是以為上面已經(jīng)是最終方案了呢?不，優(yōu)化還剩最后一步。

我們已經(jīng)得到了一個(gè)結(jié)論

  • 同時(shí)組合多組數(shù)字以實(shí)現(xiàn) O(logn) 復(fù)雜度

如果有 16 個(gè)字符或 128 位的字符串要解析，還可以使用 SIMD。感興趣的讀者可以參考SIMD stands for Single Instruction Multiple Data。Intel 和 AMD CPU 都支持 SSE 和 AVX 指令，并且它們通常使用更寬的寄存器。

SIMA 簡單來說就是一組 CPU 的擴(kuò)展指令，可以通過調(diào)用多組寄存器實(shí)現(xiàn)并行的乘法運(yùn)算，從而提升系統(tǒng)性能。我們一般提到的向量化運(yùn)算就是 SIMA。

讓我們先設(shè)置 16 個(gè)字節(jié)中的每一個(gè)數(shù)字：

 
 
 
 
    
  
  
  
  
  1. inline std::uint64_t parse_16_chars(const char* string) noexcept
    2. 
  
  
  
  
  2. {
    3. 
  
  
  
  
  3.   auto chunk = _mm_lddqu_si128(
    4. 
  
  
  
  
  4.     reinterpret_cast(string)
    5. 
  
  
  
  
  5.   );
    6. 
  
  
  
  
  6.   auto zeros =  _mm_set1_epi8('0');
    7. 
  
  
  
  
  7.   chunk = chunk - zeros;
    8. 
  
  
  
  
  8.   
    9. 
  
  
  
  
  9.   // ...
    10. 
  
  
  
  
  10. }
    11.

現(xiàn)在，主角變成了 madd 該系統(tǒng)調(diào)用。這些 SIMD 函數(shù)與我們使用位掩碼技巧所做的操作完全一樣——它們采用同一個(gè)寬寄存器，將其解釋為一個(gè)由較小整數(shù)組成的向量，每個(gè)乘以一個(gè)特定的乘數(shù)，然后將相鄰位的結(jié)果相加到一個(gè)更寬的整數(shù)向量中。所有操作一步完成。

 
 
 
 
    
  
  
  
  
  1. // The 1-byte "trick" in one instruction
    2. 
  
  
  
  
  2. const auto mult = _mm_set_epi8(
    3. 
  
  
  
  
  3.   1, 10, 1, 10, 1, 10, 1, 10, 1, 10, 1, 10, 1, 10, 1, 10
    4. 
  
  
  
  
  4. );
    5. 
  
  
  
  
  5. chunk = _mm_maddubs_epi16(chunk, mult);
    6.

2 字節(jié)方案其實(shí)還有另一條指令，但不幸的是我并沒有找到 4 字節(jié)方案的指令，還是需要兩條指令。這是完整的 parse_16_chars 方案：

 
 
 
 
    
  
  
  
  
  1. inline std::uint64_t parse_16_chars(const char* string) noexcept
    2. 
  
  
  
  
  2. {
    3. 
  
  
  
  
  3.   auto chunk = _mm_lddqu_si128(
    4. 
  
  
  
  
  4.     reinterpret_cast(string)
    5. 
  
  
  
  
  5.   );
    6. 
  
  
  
  
  6.   auto zeros =  _mm_set1_epi8('0');
    7. 
  
  
  
  
  7.   chunk = chunk - zeros;
    8. 
  
  
  
  
  8. 
  
  
  
  
  9.   {
    10. 
  
  
  
  
  10.     const auto mult = _mm_set_epi8(
    11. 
  
  
  
  
  11.       1, 10, 1, 10, 1, 10, 1, 10, 1, 10, 1, 10, 1, 10, 1, 10
    12. 
  
  
  
  
  12.     );
    13. 
  
  
  
  
  13.     chunk = _mm_maddubs_epi16(chunk, mult);
    14. 
  
  
  
  
  14.   }
    15. 
  
  
  
  
  15.   {
    16. 
  
  
  
  
  16.     const auto mult = _mm_set_epi16(1, 100, 1, 100, 1, 100, 1, 100);
    17. 
  
  
  
  
  17.     chunk = _mm_madd_epi16(chunk, mult);
    18. 
  
  
  
  
  18.   }
    19. 
  
  
  
  
  19.   {
    20. 
  
  
  
  
  20.     chunk = _mm_packus_epi32(chunk, chunk);
    21. 
  
  
  
  
  21.     const auto mult = _mm_set_epi16(0, 0, 0, 0, 1, 10000, 1, 10000);
    22. 
  
  
  
  
  22.     chunk = _mm_madd_epi16(chunk, mult);
    23. 
  
  
  
  
  23.   }
    24. 
  
  
  
  
  24. 
  
  
  
  
  25.   return ((chunk[0] & 0xffffffff) * 100000000) + (chunk[0] >> 32);
    26. 
  
  
  
  
  26. }
    27.

SIMD trick

0.75 nanoseconds! 是不是大吃一驚呢.

總結(jié)

整體對(duì)比

有人可能會(huì)問，你為啥要用 C++ 來介紹下，不能用 Java 嗎?我再補(bǔ)充下，本文的測試結(jié)論，均來自于老外的文章，文章出處見開頭，其次，本文的后半部分的優(yōu)化，都是基于一些系統(tǒng)調(diào)用，和 CPU 指令的優(yōu)化，這些在 C++ 中實(shí)現(xiàn)起來方便一些，Java 只能走系統(tǒng)調(diào)用。

在最近過去的性能挑戰(zhàn)賽中，由于限定了不能使用 JNI，使得選手們只能將方案止步于循環(huán)展開方案，試想一下，如果允許走系統(tǒng)調(diào)用，加上比賽中字符串也基本是固定的長度，完全可以采用 SIMD 的 trick 方案，String 轉(zhuǎn) Long 的速度會(huì)更快。

polardb優(yōu)化點(diǎn)

實(shí)際上，在之前 polarDB 的比賽中，普哥就給我介紹過 bswap 的向量化方案，這也是為啥 Java 方案就是比 C++ 方案遜色的原因之一，C++ 在執(zhí)行一些 CPU 指令集以及系統(tǒng)調(diào)用上，比 Java 方便很多。

如何看待這一系列的優(yōu)化呢?從 std::stringstream 的 86.23 到 sima trick 方案的 0.75，這個(gè)優(yōu)化的過程是令人興奮的，但我們也發(fā)現(xiàn)，越往后，越是用到一些底層的優(yōu)化技巧，正如方案中的 trick 而言，適用性是有限的。也有一種聲音是在說：花費(fèi)這么大精力去優(yōu)化，為啥不去寫匯編呢?這又回到了“優(yōu)化是萬惡之源”這個(gè)話題。在業(yè)務(wù)項(xiàng)目中，可能你不用過多關(guān)注 String 是如何轉(zhuǎn)換為 Long 和 Integer 的，可能 Integer.valueOf 和 Long.valueOf 就可以滿足你的訴求，但如果你是一個(gè)需要大數(shù)據(jù)解析系統(tǒng)，String 轉(zhuǎn)換是系統(tǒng)的瓶頸之一，相信本文的方案會(huì)給你一定的啟發(fā)。

另外對(duì)于 SIMD 這些方案，我想再多說一句。其實(shí)一些性能挑戰(zhàn)賽進(jìn)行到最后，大家的整體方案其實(shí)都相差無幾，無非是參數(shù)差異，因?yàn)楸荣悎鼍巴ǔ２粫?huì)太復(fù)雜，最后前幾名的差距，就是在一些非常小的細(xì)節(jié)上。正如 SIMA 提供的向量化運(yùn)算等優(yōu)化技巧，它就是可以幫助你比其他人快個(gè)幾百毫秒，甚至 1~2s。這時(shí)候你會(huì)感嘆，原來我跟大神的差距，就是在這些細(xì)節(jié)上。但反觀整個(gè)過程，似乎這些優(yōu)化并不能幫助程序設(shè)計(jì)競賽發(fā)揮更大的能量，一個(gè)比賽如果只能依靠 CPU 優(yōu)化來實(shí)現(xiàn)區(qū)分度，我覺得一定不是成功的。所以，對(duì)于主辦方而言，禁用掉一些類庫，其實(shí)有效的避免了內(nèi)卷，于參賽者而言，算是一種減負(fù)了。希望以后的比賽也都朝著讓選手花更多精力去優(yōu)化方案，而不是優(yōu)化通用的細(xì)節(jié)上。

再回到 String 解析成 Long/Integer 的話題上。在實(shí)際使用時(shí)，大家也不用避諱繼續(xù)使用 Integer.valueOf 或者 Long.valueOf，大多數(shù)情況下，這不是系統(tǒng)的瓶頸。而如果你恰好在某些場景下遇到了 String 轉(zhuǎn)換的瓶頸，希望本文能夠幫到你。


網(wǎng)站名稱：如何更快地將String轉(zhuǎn)換成Int/Long
本文URL：http://www.dlmjj.cn/article/cdpcgpg.html