青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

SGI STL中默認Allocator為何變為new_allocator?

peakflys原創作品,轉載請保留原作者和源鏈接
   項目中和自己代碼中大量使用了STL的容器,平時也沒怎么關注alloc的具體實現細節,主觀認識上還停留在侯捷大師的《STL源碼剖析》中的講解。
   以下為書中摘錄截圖:詳見書中2.2.4節內容

前段時間項目中出了一個內存問題,在追查問題的過程中查看了對應的源碼(版本為libstdc++-devel-4.1.2)
源碼文件c++allocator.h中定義了默認的Alloc:#ifndef _CXX_ALLOCATOR_H
#define _CXX_ALLOCATOR_H 1

// Define new_allocator as the base class to std::allocator.
#include <ext/new_allocator.h>
#define __glibcxx_base_allocator  __gnu_cxx::new_allocator

#endif
查看new_allocator.h文件,發現new_allocator僅僅是對operator new和operator delete的簡單封裝(感興趣的朋友可自行查看)。
眾所周知libstdc++中STL的大部分實現是取自SGI的STL,而《STL源碼剖析》的源碼是Cygnus C++ 2.91則是SGI STL的早期版本,下載源碼看了一下allocator的實現確實如書中所言。
不知道從哪個版本起,SGI的STL把默認的Alloc替換成了new_allocator,有興趣的同學可以查一下。
知道結果后,可能很多人和我一樣都不禁要問:Why?
以下是兩個版本的源碼實現:
1、new_allocator
      // NB: __n is permitted to be 0.  The C++ standard says nothing
      
// about what the return value is when __n == 0.
      pointer
      allocate(size_type __n, const void* = 0)
      {
    if (__builtin_expect(__n > this->max_size(), false))
      std::__throw_bad_alloc();

    return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));
      }

      // __p is not permitted to be a null pointer.
      void
      deallocate(pointer __p, size_type)
      { ::operator delete(__p); }
2、__pool_alloc
  template<typename _Tp>
    _Tp*
    __pool_alloc<_Tp>::allocate(size_type __n, const void*)
    {
      pointer __ret = 0;
      if (__builtin_expect(__n != 0, true))
    {
      if (__builtin_expect(__n > this->max_size(), false))
        std::__throw_bad_alloc();

      // If there is a race through here, assume answer from getenv
      
// will resolve in same direction.  Inspired by techniques
      
// to efficiently support threading found in basic_string.h.
      if (_S_force_new == 0)
        {
          if (getenv("GLIBCXX_FORCE_NEW"))
        __atomic_add(&_S_force_new, 1);
          else
        __atomic_add(&_S_force_new, -1);
        }

      const size_t __bytes = __n * sizeof(_Tp);
      if (__bytes > size_t(_S_max_bytes) || _S_force_new == 1)
        __ret = static_cast<_Tp*>(::operator new(__bytes));
      else
        {
          _Obj* volatile* __free_list = _M_get_free_list(__bytes);

          lock sentry(_M_get_mutex());
          _Obj* __restrict__ __result = *__free_list;
          if (__builtin_expect(__result == 0, 0))
        __ret = static_cast<_Tp*>(_M_refill(_M_round_up(__bytes)));
          else
        {
          *__free_list = __result->_M_free_list_link;
          __ret = reinterpret_cast<_Tp*>(__result);
        }
          if (__builtin_expect(__ret == 0, 0))
        std::__throw_bad_alloc();
        }
    }
      return __ret;
    }
  template<typename _Tp>
    void
    __pool_alloc<_Tp>::deallocate(pointer __p, size_type __n)
    {
      if (__builtin_expect(__n != 0 && __p != 0, true))
    {
      const size_t __bytes = __n * sizeof(_Tp);
      if (__bytes > static_cast<size_t>(_S_max_bytes) || _S_force_new == 1)
        ::operator delete(__p);
      else
        {
          _Obj* volatile* __free_list = _M_get_free_list(__bytes);
          _Obj* __q = reinterpret_cast<_Obj*>(__p);

          lock sentry(_M_get_mutex());
          __q ->_M_free_list_link = *__free_list;
          *__free_list = __q;
        }
    }
    }
從源碼中可以看出new_allocator基本就沒有什么實現,僅僅是對operator new和operator delete的封裝,而__pool_alloc的實現基本和《STL源碼剖析》中一樣,所不同的是加入了多線程的支持和強制operator new的判斷。
無論從源碼來看,還是實際的測試(后續會附上我的測試版本),都可以看出__pool_alloc比new_allocator更勝一籌。

同很多人討論都不得其解,網上也很少有關注這個問題的文章和討論,倒是libstdc++的官網文檔有這么一段:
(peakflys注:文檔地址:https://gcc.gnu.org/onlinedocs/libstdc++/manual/memory.html#allocator.default)
從文檔的意思來看,選擇new_allocator是基于大量測試,不幸的是文檔中鏈接的測試例子均無法訪問到……不過既然他們說基于測試得出的結果,我就隨手寫了一個自己的例子:
#include <map>
#include <vector>
#ifdef _POOL
#include <ext/pool_allocator.h>
#endif

static const unsigned int Count = 1000000;

using namespace std;

struct Data
{
    int a;
    double b;
};

int main()
{
#ifdef _POOL
    map<int, Data, less<int>, __gnu_cxx::__pool_alloc<pair<int, Data> > > mi;
    vector<Data, __gnu_cxx::__pool_alloc<Data> > vi;
#else
    map<int, Data> mi;
    vector<Data> vi;
#endif

    for(int i = 0; i < Count; ++i)
    {
        Data d;
        d.a = i;
        d.b = i * i;
        mi[i] = d;
        vi.push_back(d);
    }
    mi.clear();
#ifdef _POOL
    vector<Data, __gnu_cxx::__pool_alloc<Data> >().swap(vi);
#else
    vector<Data>().swap(vi);
#endif
    for(int i = 0; i < Count; ++i)
    {
        Data d;
        d.a = i;
        d.b = i * i;
        mi[i] = d;
        vi.push_back(d);
    }
    return 0;
}
因為當數據大于128K時,__pool_alloc同new_allocator一樣直接調用operator,所以例子中構造出的Data小于128K,來模擬兩個分配器的不同。同時如libstdc++官網中說的,我們同時使用了sequence容器vector和associate容器map。
例子中模擬了兩種類型容器的插入-刪除-插入的過程,同時里面包含了元素的構造、析構以及內存的分配和回收。
以下是在我本地機器上運行的結果:
1、-O0的版本:

2、-O2的版本:

多線程的測試例子我就不貼了,測試結果大致和上面相同,大家可以自行測試。
從多次運行的結果來看__pool_alloc的性能始終是優于new_allocator的。
又回到那個問題,為什么SGI STL的官方把默認的Alloc從__pool_alloc變為new_allocator。
本篇文章不能給大家一個答案,官方網站上也未看到解釋,自己唯一可能的猜測是
1、__pool_alloc不利于使用者自定義operator new和operator delete(其實這條理由又被我自己推翻了,因為通過源碼可以知道置位_S_force_new即可解決)
2、malloc性能的提升以及硬件的更新導致使用默認的operator new即可。

如果大家有更好,更權威的答案請告訴我(peakflys@gmail.com)或者留言,謝謝。
                                                                  by peakflys 16:49:49 Wednesday, January 14, 2015

posted on 2015-01-14 16:50 peakflys 閱讀(4462) 評論(8)  編輯 收藏 引用 所屬分類: C++

評論

# re: SGI STL中默認Allocator為何變為new_allocator? 2015-01-15 00:12 egmkang

跟硬件沒關系,malloc性能提升.因為malloc本身在thread上面就有一個pool.
而且高性能的分配器越來越多,比如tcmalloc/jemalloc,已經沒有任何必要再提供一個pool allocator  回復  更多評論   

# re: SGI STL中默認Allocator為何變為new_allocator? 2015-01-15 09:12 蘋果汁

樓主好學 贊一個  回復  更多評論   

# re: SGI STL中默認Allocator為何變為new_allocator?[未登錄] 2015-01-15 13:01 chipset

pool不拼接內存,一塊大內存被分割成很多相等的小塊,此時調用分配一塊較大內存可能失敗,不是因為內存不夠用,而是因為全是分割成小碎塊不拼接導致的。這是Pool的致命傷。再者Pool的效率也高不到哪里,以不拼接小塊換速度的做法不值得提倡。  回復  更多評論   

# re: SGI STL中默認Allocator為何變為new_allocator? 2015-01-15 17:42 xxoo

樓上的,內存池的作用不就是這個嗎?你申請一塊內存,可以做到物理不連續?  回復  更多評論   

# re: SGI STL中默認Allocator為何變為new_allocator? 2015-01-15 19:23 peakflys

如果我沒記錯的話malloc自始至終都有自己的一套pool策略,所以我所說的malloc性能提升并非指的這個。
不過第三方穩定高效的allocator實現可能是標準庫作者放棄pool的一個原因@egmkang
  回復  更多評論   

# re: SGI STL中默認Allocator為何變為new_allocator? 2015-01-15 19:31 peakflys

說的不錯,pool的方式存在的問題是挺多。不過對于pool的效率高不到哪去的觀點我不敢認同,針對大量小數據的分配,有時候還必須得使用pool的方式,不然ptmalloc、tcmalloc、jemalloc等不會維護復雜的內存分配方式@chipset  回復  更多評論   

# re: SGI STL中默認Allocator為何變為new_allocator? 2015-01-20 15:24 juegoskizi

我很喜歡,很不錯的職位。  回復  更多評論   

# re: SGI STL中默認Allocator為何變為new_allocator?[未登錄] 2016-03-07 14:09 JAKE

樓主,有個問題請教下:
我有個應用場景,即線程A使用obj_pool分配了一個對象obj,線程B用完obj后歸還給pool。 這里肯定會有線程同步隱患。

目前我使用兩個lockfree隊列完美解決這個問題,但很繁瑣。

我想問的是
使用tcmalloc的話,能解決我上邊所說的問題嗎?  回復  更多評論   

<2015年1月>
28293031123
45678910
11121314151617
18192021222324
25262728293031
1234567

導航

統計

公告

人不淡定的時候,就愛表現出來,敲代碼如此,偶爾的靈感亦如此……

常用鏈接

留言簿(4)

隨筆分類

隨筆檔案

文章檔案

搜索

最新評論

閱讀排行榜

評論排行榜

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            国产精品国产馆在线真实露脸 | 久久久亚洲高清| 亚洲卡通欧美制服中文| 欧美精品午夜| 亚洲制服少妇| 欧美一区国产一区| 狠狠色丁香婷综合久久| 欧美粗暴jizz性欧美20| 欧美伦理91i| 午夜在线精品| 久久色中文字幕| 日韩午夜在线| 亚洲欧美在线一区二区| 激情小说另类小说亚洲欧美 | 亚洲欧美大片| 欧美在线视频a| 亚洲欧洲在线观看| 日韩一区二区福利| 国模 一区 二区 三区| 欧美成人激情在线| 欧美三级精品| 蜜臀av性久久久久蜜臀aⅴ四虎| 免费欧美日韩| 亚洲影音一区| 美女黄毛**国产精品啪啪| 在线一区视频| 久久综合色天天久久综合图片| 亚洲精品乱码久久久久久蜜桃麻豆 | 99国产精品国产精品久久| 亚洲视频在线观看视频| 国产主播精品| 一区二区国产日产| 在线播放中文字幕一区| 在线中文字幕一区| 亚洲电影毛片| 亚洲欧美日韩在线不卡| 亚洲美女在线一区| 久久国内精品视频| 亚洲女与黑人做爰| 欧美激情精品久久久久久大尺度| 欧美在线观看一区二区| 欧美精品成人一区二区在线观看 | 99在线热播精品免费| 亚洲欧洲av一区二区| 亚洲视频在线观看一区| 噜噜噜91成人网| 久久国产精品久久国产精品| 欧美日本一区| 欧美国产日本在线| 狠狠色综合网| 久久se精品一区二区| 午夜精品久久久久久久久久久久久| 久久亚洲一区二区| 久久人人爽爽爽人久久久| 国产精品久久福利| 99伊人成综合| 中文在线资源观看视频网站免费不卡| 久久综合九色综合网站| 麻豆精品视频在线观看视频| 国产午夜精品麻豆| 欧美亚洲一级| 久久成人国产精品| 国产欧美欧洲在线观看| 亚洲天堂成人在线观看| 亚洲伊人一本大道中文字幕| 欧美日韩的一区二区| 亚洲精品欧美一区二区三区| 亚洲精品美女免费| 欧美国产日本在线| 91久久综合| 亚洲人成网站精品片在线观看| 久久夜色精品国产欧美乱| 欧美成人情趣视频| 亚洲国产激情| 欧美经典一区二区| 99这里有精品| 亚洲欧美精品伊人久久| 国产精品女人久久久久久| 亚洲欧美资源在线| 久久久夜夜夜| 亚洲国产欧美不卡在线观看| 欧美精品电影在线| 一本久久精品一区二区| 午夜精品区一区二区三| 国产午夜精品理论片a级探花| 欧美一区二区高清| 欧美成人久久| 亚洲一区免费看| 国产日韩欧美综合一区| 另类国产ts人妖高潮视频| 亚洲日本成人女熟在线观看| 中国日韩欧美久久久久久久久| 国产精品呻吟| 久久综合一区二区三区| av72成人在线| 久久噜噜噜精品国产亚洲综合 | 国产精品黄色| 久久精品91久久久久久再现| 欧美国产亚洲另类动漫| 亚洲一区二区三区影院| 一区二区亚洲欧洲国产日韩| 欧美国产一区二区| 午夜亚洲一区| 亚洲国产va精品久久久不卡综合| 亚洲一区二区三区精品视频| 国内精品久久久久影院 日本资源| 久久综合一区二区| 亚洲欧美日韩精品久久亚洲区 | 久久夜精品va视频免费观看| 亚洲精品免费看| 国产自产v一区二区三区c| 欧美精品国产精品| 久久精品人人做人人爽| 一本久道久久综合中文字幕| 免费亚洲网站| 欧美一区午夜精品| 亚洲天堂黄色| 亚洲国产精品免费| 国产一区久久| 国产精品第十页| 欧美日本韩国一区二区三区| 欧美一区二区三区四区夜夜大片 | 亚洲一区视频在线观看视频| 欧美激情亚洲另类| 久久精品国产99国产精品澳门| 一区二区免费在线视频| 亚洲国产精品精华液2区45| 国产欧美综合在线| 欧美性猛交xxxx免费看久久久| 免费日本视频一区| 久久久激情视频| 欧美一区久久| 午夜一级在线看亚洲| 亚洲无人区一区| 亚洲视频日本| 99re国产精品| 野花国产精品入口| 日韩视频永久免费| 亚洲精品一区中文| 91久久久久久久久| 亚洲黄色在线| 亚洲国产视频a| 亚洲黄色视屏| 亚洲人成网站777色婷婷| 亚洲激情影院| 亚洲久久视频| 日韩视频在线一区| 一区二区三区高清不卡| 一本久道综合久久精品| 在线午夜精品自拍| 亚洲一区二区在线免费观看视频| 亚洲最黄网站| 亚洲综合色激情五月| 午夜亚洲伦理| 久久精品水蜜桃av综合天堂| 先锋影音网一区二区| 久久激情一区| 美女视频黄免费的久久| 欧美精品观看| 国产精品福利片| 国产一区深夜福利| 亚洲第一搞黄网站| 亚洲精品一级| 亚洲欧美日韩一区二区| 久久久国产午夜精品| 欧美激情第4页| 日韩亚洲欧美高清| 亚洲视频在线一区| 久久久九九九九| 欧美乱妇高清无乱码| 国产精品亚洲美女av网站| 国产一区在线播放| 91久久精品日日躁夜夜躁国产| 一区二区三区精品视频| 欧美专区在线播放| 欧美韩日一区二区| 中国av一区| 久久久久久久久一区二区| 欧美久久久久久久久| 国产精自产拍久久久久久蜜| 亚洲国产日韩综合一区| 亚洲一区日韩在线| 麻豆精品精品国产自在97香蕉| 最新国产成人在线观看| 香蕉乱码成人久久天堂爱免费| 欧美xxx在线观看| 国产午夜精品视频| 亚洲免费观看高清在线观看 | 一区二区三区欧美| 久热精品视频| 国产九九精品视频| 99精品视频免费观看视频| 久久精品水蜜桃av综合天堂| 亚洲黄色影片| 久久婷婷久久| 国产精品爽黄69| 一区二区三区免费在线观看| 男人的天堂亚洲在线| 亚洲一区二区在线| 欧美日韩八区|