（是的，我知道question标题几乎相同，但答案并不理想，见下文）
编辑抱歉，原来的问题没有使用编译器优化。现在已经修复了，但为了避免琐碎的优化并接近我的实际用例，测试已分成两个编译单元。
std::vector<>的构造函数具有线性复杂性，这对于性能关键型应用程序来说是一件麻烦事。考虑这个简单的代码
// compilation unit 1:
void set_v0(type*x, size_t n)
{
for(size_t i=0; i<n; ++i)
x[i] = simple_function(i);
}
// compilation unit 2:
std::vector<type> x(n); // default initialisation is wasteful
set_v0(x.data(),n); // over-writes initial values
通过构建x浪费了大量时间。正如this question所探讨的那样，传统方法似乎只是保留存储空间并使用push_back()来填充数据：
// compilation unit 1:
void set_v1(std::vector<type>&x, size_t n)
{
x.reserve(n);
for(size_t i=0; i<n; ++i)
x.push_back(simple_function(i));
}
// compilation unit 2:
std::vector<type> x(); x.reserve(n); // no initialisation
set_v1(x,n); // using push_back()
然而，正如我的评论所指出的那样，push_back()本来就很慢，这使得第二种方法实际上慢比第一种方法足够简单的可构造对象，例如{{1} } s，何时为
size_t我得到以下时间（使用gcc 4.8和-O3; clang 3.2产生约10％的代码）
simple_function = [](size_t i) { return i; };
如果可以通过以下作弊版本来估算元素的默认构造，实际可能的加速
timing vector::vector(n) + set_v0();
n=10000 time: 3.9e-05 sec
n=100000 time: 0.00037 sec
n=1000000 time: 0.003678 sec
n=10000000 time: 0.03565 sec
n=100000000 time: 0.373275 sec
timing vector::vector() + vector::reserve(n) + set_v1();
n=10000 time: 1.9e-05 sec
n=100000 time: 0.00018 sec
n=1000000 time: 0.00177 sec
n=10000000 time: 0.020829 sec
n=100000000 time: 0.435393 sec
当我们得到
// compilation unit 2
std::vector<type> x; x.reserve(n); // no initialisation
set_v0(x,n); // error: write beyond end of vector
// note: vector::size() == 0
所以，我的第一个问题：有没有合法的方法来使用标准的库容器来提供后面这些时间？或者我是否必须自己管理记忆？
现在，我真正想要的是使用多线程来填充容器。天真的代码（在这个例子中使用openMP来简化，暂时不包括clang）
timing vector::vector + vector::reserve(n) + set_v0(); (CHEATING)
n=10000 time: 8e-06 sec
n=100000 time: 7.2e-05 sec
n=1000000 time: 0.000776 sec
n=10000000 time: 0.01119 sec
n=100000000 time: 0.298024 sec
现在受到以下事实的影响：所有元素的默认初始化都不是多线程的，导致潜在的严重性能下降。以下是// compilation unit 1
void set_v0(type*x, size_t n)
{
#pragma omp for // only difference to set_v0() from above
for(size_t i=0; i<n; ++i)
x[i] = simple_function(i);
}
// compilation unit 2:
std::vector<type> x(n); // default initialisation not mutli-threaded
#pragma omp parallel
set_v0(x,n); // over-writes initial values in parallel
的时间安排和等效的作弊方法（使用我的macbook的intel i7芯片，包含4个内核，8个超线程）：
set_omp_v0()请注意，作弊版本比串行作弊版本快约3.3倍，大致与预期相同，但标准版本不是。
所以，我的第二个问题：是否有任何合法的方法可以使用标准库容器，这样可以在多线程情况下提供后面的时序？
PS。我找到了this question，其中timing std::vector::vector(n) + omp parallel set_v0()
n=10000 time: 0.000389 sec
n=100000 time: 0.000226 sec
n=1000000 time: 0.001406 sec
n=10000000 time: 0.019833 sec
n=100000000 time: 0.35531 sec
timing vector::vector + vector::reserve(n) + omp parallel set_v0(); (CHEATING)
n=10000 time: 0.000222 sec
n=100000 time: 0.000243 sec
n=1000000 time: 0.000793 sec
n=10000000 time: 0.008952 sec
n=100000000 time: 0.089619 sec
通过提供std::vector来避免默认初始化。
这不再符合标准，但对我的测试用例非常有效（详见下面我自己的答案和this question）。
答案 0 :(得分：12)
使用g ++ 4.5，通过使用生成器直接构建，我能够实现从v0（1.0s到0.8s）减少大约20％的运行时间，并且v1从0.95s减少到0.8s：
struct Generator : public std::iterator<std::forward_iterator_tag, int>
{
explicit Generator(int start) : value_(start) { }
void operator++() { ++value_; }
int operator*() const { return value_; }
bool operator!=(Generator other) const { return value_ != other.value_; }
int value_;
};
int main()
{
const int n = 100000000;
std::vector<int> v(Generator(0), Generator(n));
return 0;
}
答案 1 :(得分：11)
好的，这是我在问这个问题后所学到的。
Q1 （有没有合法的方法可以使用标准库容器来提供后面这些时间？）是在某种程度上，如Mark和Evgeny的回答所示。向std::vector的构造函数提供生成器的方法省略了默认构造。
Q2 （有没有合法的方法可以使用标准库容器，这会在多线程情况下提供后面这些时间？）否，我不这么认为。原因是在构造 任何符合标准的容器必须初始化其元素 ，已经确保对元素析构函数的调用（在破坏或调整容器大小时）是良好的。由于std库容器不支持在构造元素时使用多线程，因此无法在此复制 Q1 的技巧，因此我们不能忽略默认构造。
因此，如果我们想要使用C ++进行高性能计算，那么在管理大量数据时，我们的选项会受到限制。我们可以
1 声明一个容器对象，并且在同一个编译单元中，当编译器希望优化构造时的初始化时，立即填充它（并发）;
2 诉诸new[]和delete[]甚至malloc()和free()，当所有内存管理时，在后一种情况下，构建元素是我们的责任，我们对C ++标准库的潜在用法非常有限。
3 欺骗std::vector不使用默认构造的自定义 unitialised_allocator 初始化其元素。在ideas Jared Hoberock之后，这样的分配器看起来像这样（另见here）：
// based on a design by Jared Hoberock
// edited (Walter) 10-May-2013, 23-Apr-2014
template<typename T, typename base_allocator = std::allocator<T> >
struct uninitialised_allocator
: base_allocator
{
static_assert(std::is_same<T,typename base_allocator::value_type>::value,
"allocator::value_type mismatch");
template<typename U>
using base_t =
typename std::allocator_traits<base_allocator>::template rebind_alloc<U>;
// rebind to base_t<U> for all U!=T: we won't leave other types uninitialised!
template<typename U>
struct rebind
{
typedef typename
std::conditional<std::is_same<T,U>::value,
uninitialised_allocator, base_t<U> >::type other;
}
// elide trivial default construction of objects of type T only
template<typename U>
typename std::enable_if<std::is_same<T,U>::value &&
std::is_trivially_default_constructible<U>::value>::type
construct(U*) {}
// elide trivial default destruction of objects of type T only
template<typename U>
typename std::enable_if<std::is_same<T,U>::value &&
std::is_trivially_destructible<U>::value>::type
destroy(U*) {}
// forward everything else to the base
using base_allocator::construct;
using base_allocator::destroy;
};
然后可以像这样定义unitialised_vector<>模板：
template<typename T, typename base_allocator = std::allocator<T>>
using uninitialised_vector = std::vector<T,uninitialised_allocator<T,base_allocator>>;
我们仍然可以使用几乎所有标准库的功能。虽然必须说uninitialised_allocator，因此暗示unitialised_vector不符合标准，因为它的元素不是默认构造的（例如vector<int>不会全部{{1}施工后）。
使用此工具处理我的小测试问题时，我得到了很好的结果：
0当作弊和“合法”版本之间没有任何区别时。
答案 2 :(得分：6)
boost::transformed 对于单线程版本，您可以使用boost::transformed。它有：
返回范围类别：范围的类别
这意味着，如果您将Random Access Range提供给boost::transformed，则会返回Random Access Range，这将允许vector的构造函数预先分配所需的数量存储器中。
您可以按如下方式使用它：
const auto &gen = irange(0,1<<10) | transformed([](int x)
{
return exp(Value{x});
});
vector<Value> v(begin(gen),end(gen));
#define BOOST_RESULT_OF_USE_DECLTYPE
#include <boost/range/adaptor/transformed.hpp>
#include <boost/container/vector.hpp>
#include <boost/range/irange.hpp>
#include <boost/progress.hpp>
#include <boost/range.hpp>
#include <iterator>
#include <iostream>
#include <ostream>
#include <string>
#include <vector>
#include <array>
using namespace std;
using namespace boost;
using namespace adaptors;
#define let const auto&
template<typename T>
void dazzle_optimizer(T &t)
{
auto volatile dummy = &t; (void)dummy;
}
// _______________________________________ //
using Value = array<int,1 << 16>;
using Vector = container::vector<Value>;
let transformer = [](int x)
{
return Value{{x}};
};
let indicies = irange(0,1<<10);
// _______________________________________ //
void random_access()
{
let gen = indicies | transformed(transformer);
Vector v(boost::begin(gen), boost::end(gen));
dazzle_optimizer(v);
}
template<bool reserve>
void single_pass()
{
Vector v;
if(reserve)
v.reserve(size(indicies));
for(let i : indicies)
v.push_back(transformer(i));
dazzle_optimizer(v);
}
void cheating()
{
Vector v;
v.reserve(size(indicies));
for(let i : indicies)
v[i]=transformer(i);
dazzle_optimizer(v);
}
// _______________________________________ //
int main()
{
struct
{
const char *name;
void (*fun)();
} const tests [] =
{
{"single_pass, no reserve",&single_pass<false>},
{"single_pass, reserve",&single_pass<true>},
{"cheating reserve",&cheating},
{"random_access",&random_access}
};
for(let i : irange(0,3))
for(let test : tests)
progress_timer(), // LWS does not support auto_cpu_timer
(void)i,
test.fun(),
cout << test.name << endl;
}
答案 3 :(得分：1)
我实际上建议在这种情况下推出自己的容器或寻找替代品，因为我看到它的方式，你的固有问题不是标准容器的默认构造元素。尝试使用可变容量的容器，可以在施工时确定其容量。
没有标准库不必要地默认构造元素的实例。 vector仅对其填充构造函数和resize执行此操作，这两者在概念上都是通用容器所必需的，因为它们的目的是调整容器大小以包含有效元素。同时，这很简单：
T* mem = static_cast<T*>(malloc(num * sizeof(T)));
for (int j=0; j < num; ++j)
new (mem + j) T(...); // meaningfully construct T
...
for (int j=0; j < num; ++j)
mem[j].~T(); // destroy T
free(mem);
...然后在上面的代码中构建一个异常安全的符合RAII的容器。这就是我在你的案例中所建议的，因为如果默认构造在填充构造函数上下文中足够浪费到不可忽略的地方，那么替代reserve和push_back或{{1同样不足，那么即使是将容量和大小视为变量的容器也是一个不可忽视的开销，在这一点上，你有理由去寻找别的东西，包括从概念中推销你自己的东西上方。
标准库非常有效，因为它在苹果与苹果的比较中难以匹配，但在这种情况下，你的需求需要橙子而不是苹果。在这种情况下，直接接触橙子往往变得更容易，而不是试图将苹果变成橙色。