folly/FBVector.h

Simply replacing std::vector with folly::fbvector (after having included the folly/FBVector.h header file) will improve the performance of your C++ code using vectors with common coding patterns. The improvements are always non-negative, almost always measurable, frequently significant, sometimes dramatic, and occasionally spectacular.

Sample

folly::fbvector<int> numbers({, , , });
numbers.reserve();
for (int i = ; i < ; i++) {
numbers.push_back(i * );
}
assert(numbers[] == );

Motivation


std::vector is the stalwart abstraction many use for dynamically-allocated arrays in C++. It is also the best known and most used of all containers. It may therefore seem a surprise that std::vector leaves important - and sometimes vital - efficiency opportunities on the table. This document explains how our own drop-in abstraction fbvector improves key performance aspects of std::vector. Refer to folly/test/FBVectorTest.cpp for a few benchmarks.

Memory Handling


It is well known that std::vector grows exponentially (at a constant factor) in order to avoid quadratic growth performance. The trick is choosing a good factor. Any factor greater than 1 ensures O(1) amortized append complexity towards infinity. But a factor that's too small (say, 1.1) causes frequent vector reallocation, and one that's too large (say, 3 or 4) forces the vector to consume much more memory than needed.

The initial HP implementation by Stepanov used a growth factor of 2; i.e., whenever you'd push_back into a vector without there being room, it would double the current capacity. This was not a good choice: it can be mathematically proven that a growth factor of 2 is rigorously the worst possible because it never allows the vector to reuse any of its previously-allocated memory. Despite other compilers reducing the growth factor to 1.5, gcc has staunchly maintained its factor of 2. This makes std::vector cache- unfriendly and memory manager unfriendly.

To see why that's the case, consider a large vector of capacity C. When there's a request to grow the vector, the vector (assuming no in-place resizing, see the appropriate section in this document) will allocate a chunk of memory next to its current chunk, copy its existing data to the new chunk, and then deallocate the old chunk. So now we have a chunk of size C followed by a chunk of size k * C. Continuing this process we'll then have a chunk of size k * k * C to the right and so on. That leads to a series of the form (using ^^ for power):

C, C*k,  C*k^^, C*k^^, ...

If we choose k = 2 we know that every element in the series will be strictly larger than the sum of all previous ones because of the remarkable equality:

 + ^^ + ^^ + ^^... + ^^n = ^^(n+) - 

This means that any new chunk requested will be larger than all previously used chunks combined, so the vector must crawl forward in memory; it can't move back to its deallocated chunks. But any number smaller than 2 guarantees that you'll at some point be able to reuse the previous chunks. For instance, choosing 1.5 as the factor allows memory reuse after 4 reallocations; 1.45 allows memory reuse after 3 reallocations; and 1.3 allows reuse after only 2 reallocations.

Of course, the above makes a number of simplifying assumptions about how the memory allocator works, but definitely you don't want to choose the theoretically absolute worst growth factor. fbvector uses a growth factor of 1.5. That does not impede good performance at small sizes because of the way fbvector cooperates with jemalloc (below).

The jemalloc Connection


Virtually all modern allocators allocate memory in fixed-size quanta that are chosen to minimize management overhead while at the same time offering good coverage at low slack. For example, an allocator may choose blocks of doubling size (32, 64, 128, <t_co>, ...) up to 4096, and then blocks of size multiples of a page up until 1MB, and then 512KB increments and so on.

As discussed above, std::vector also needs to (re)allocate in quanta. The next quantum is usually defined in terms of the current size times the infamous growth constant. Because of this setup, std::vector has some slack memory at the end much like an allocated block has some slack memory at the end.

It doesn't take a rocket surgeon to figure out that an allocator- aware std::vector would be a marriage made in heaven: the vector could directly request blocks of "perfect" size from the allocator so there would be virtually no slack in the allocator. Also, the entire growth strategy could be adjusted to work perfectly with allocator's own block growth strategy. That's exactly what fbvector does - it automatically detects the use of jemalloc and adjusts its reallocation strategy accordingly.

But wait, there's more. Many memory allocators do not support in- place reallocation, although most of them could. This comes from the now notorious design of realloc() to opaquely perform either in-place reallocation or an allocate-memcpy-deallocate cycle. Such lack of control subsequently forced all clib-based allocator designs to avoid in-place reallocation, and that includes C++'s new and std::allocator. This is a major loss of efficiency because an in-place reallocation, being very cheap, may mean a much less aggressive growth strategy. In turn that means less slack memory and faster reallocations.

Object Relocation


One particularly sensitive topic about handling C++ values is that they are all conservatively considered non- relocatable. In contrast, a relocatable value would preserve its invariant even if its bits were moved arbitrarily in memory. For example, an int32 is relocatable because moving its 4 bytes would preserve its actual value, so the address of that value does not "matter" to its integrity.

C++'s assumption of non-relocatable values hurts everybody for the benefit of a few questionable designs. The issue is that moving a C++ object "by the book" entails (a) creating a new copy from the existing value; (b) destroying the old value. This is quite vexing and violates common sense; consider this hypothetical conversation between Captain Picard and an incredulous alien:

Incredulous Alien: "So, this teleporter, how does it work?"
Picard: "It beams people and arbitrary matter from one place to another."
Incredulous Alien: "Hmmm... is it safe?"
Picard: "Yes, but earlier models were a hassle. They'd clone the person to another location. Then the teleporting chief would have to shoot the original. Ask O'Brien, he was an intern during those times. A bloody mess, that's what it was."

Only a tiny minority of objects are genuinely non-relocatable:

  • Objects that use internal pointers, e.g.:

    class Ew { char buffer[1024]; char * pointerInsideBuffer; public: Ew() : pointerInsideBuffer(buffer) {} ... }

  • Objects that need to update "observers" that store pointers to them.

The first class of designs can always be redone at small or no cost in efficiency. The second class of objects should not be values in the first place - they should be allocated with new and manipulated using (smart) pointers. It is highly unusual for a value to have observers that alias pointers to it.

Relocatable objects are of high interest to std::vector because such knowledge makes insertion into the vector and vector reallocation considerably faster: instead of going to Picard's copy-destroy cycle, relocatable objects can be moved around simply by using memcpy or memmove. This optimization can yield arbitrarily high wins in efficiency; for example, it transforms vector< vector<double> > or vector< hash_map<int, string> > from risky liabilities into highly workable compositions.

In order to allow fast relocation without risk, fbvector uses a trait folly::IsRelocatable defined in "folly/Traits.h". By default, folly::IsRelocatable::value conservatively yields false. If you know that your type Widget is in fact relocatable, go right after Widget's definition and write this:

// at global namespace level
namespace folly {
struct IsRelocatable<Widget> : boost::true_type {};
}

If you don't do this, fbvector<Widget> will fail to compile with a static_assert.

Miscellaneous


fbvector uses a careful implementation all around to make sure it doesn't lose efficiency through the cracks. Some future directions may be in improving raw memory copying (memcpy is not an intrinsic in gcc and does not work terribly well for large chunks) and in furthering the collaboration with jemalloc. Have fun!

FBVector的更多相关文章

  1. 用#define来实现多份近似代码 - map,set中的应用

    在stl中map,set内部都是使用相同的红黑树实现,map对应模板参数key_type,mapped_type,而set对应模板参数没有mapped_type 两者都支持insert操作 pair& ...

  2. 转: 在创业公司使用C++

    from: http://oicwx.com/detail/827436 在创业公司使用C++ 2016-01-04开发资讯 James Perry和朋友创办了一家公司,主要是做基于云的OLAP多维数 ...

  3. [原创]CentOS6.4编译安装Facebook的folly库(gcc4.8.1boost1.5.3)

      Folly: Facebook Open-souce LibrarY,Facebook开源的一个基础组件库,据说在大规模的场景中性能较高.目前因为自己负责的系统有几个地方性能较差,因此特意找来看看 ...

  4. Traits

    'folly/Traits.h' Implements traits complementary to those provided in <type_traits> Implements ...

  5. small_vector

    folly/small_vector.h folly::small_vector<T,Int=1,...> is a sequence container that implements ...

  6. DynamicConverter

    folly/DynamicConverter.h When dynamic objects contain data of a known type, it is sometimes useful t ...

  7. folly学习心得(转)

    原文地址:  https://www.cnblogs.com/Leo_wl/archive/2012/06/27/2566346.html   阅读目录 学习代码库的一般步骤 folly库的学习心得 ...

  8. Folly: Facebook Open-source Library Readme.md 和 Overview.md(感觉包含的东西并不多,还是Boost更有用)

    folly/ For a high level overview see the README Components Below is a list of (some) Folly component ...

  9. C++ folly库解读(二) small_vector —— 小数据集下的std::vector替代方案

    介绍 使用场景 为什么不是std::array 其他用法 其他类似库 Benchmark 代码关注点 主要类 small_vector small_vector_base 数据结构 InlineSto ...

随机推荐

  1. location.host 与 location.hostname 的区别

    JavaScript 中,大多数情况下,我们不会发现 location.host 与 location.hostname 的区别,因为大多数情况下,我们的网页用的是 80 端口. 他们的区别: loc ...

  2. MPAndroidChart Wiki(译文)~Part 5

    19. ChartData子类 这篇wiki主要关注ChartData子类的具体介绍.至于此部分没有提及到的ChartData的子类,代表他们没有特性功能需要介绍. BarData 方法 使用 set ...

  3. socket创建TCP服务端和客户端

    看情况选择相对应的套接字*面向连接的传输--tcp协议--可靠的--流式套接字(SOCK_STREAM)*面向无连接的传输--udp协议--不可靠的--数据报套接字(SOCK_DGRAM) 在liun ...

  4. org.hibernate.hql.QueryExecutionRequestException:org.hibernate.hql.QueryExecutionRequestException: Not supported for DML operations【异常】

    springData学习资料 [http://blog.csdn.net/lw_power/article/details/51296353] [JPA报错]org.springframework.w ...

  5. 【Codeforces】Round #488 (Div. 2) 总结

    [Codeforces]Round #488 (Div. 2) 总结 比较僵硬的一场,还是手速不够,但是作为正式成为竞赛生的第一场比赛还是比较圆满的,起码没有FST,A掉ABCD,总排82,怒涨rat ...

  6. Hive中日期处理

    1.日期函数UNIX时间戳转日期函数:from_unixtime() 函数 格式 返回值 说明 from_unixtime from_unixtime(bigint unixtime[, string ...

  7. scrapy模拟浏览器爬取验证码页面

    使用selenium模块爬取验证码页面,selenium模块需要另外安装这里不讲环境的配置,我有一篇博客有专门讲ubuntn下安装和配置模拟浏览器的开发 spider的代码 # -*- coding: ...

  8. LG4475 巧克力王国

    题意 巧克力王国里的巧克力都是由牛奶和可可做成的.但是并不是每一块巧克力都受王国人民的欢迎,因为大家都不喜欢过于甜的巧克力. 对于每一块巧克力,我们设 x 和 y 为其牛奶和可可的含量.由于每个人对于 ...

  9. Docker生态不会重蹈Hadoop的覆辙

    本文原作者是晏东(精灵云Ghostcould创始人),在读到<Docker生态会重蹈Hadoop的覆辙吗?>文章后的个人思考,里面的不少观点也是很不错的. 1.形态上的差异 2013年的时 ...

  10. 使用Navicat for Oracle新建表空间、用户及权限赋予 (转)

    Navicat for Oracle是有关Oracle数据库的客户端工具.通过这个客户端,我们可以图形方式对Oracle数据库进行操作. 说明我们此次试验的Oracle数据库版本是Oracle 10G ...