STL тяги многократного векторного преобразования? - PullRequest
Новая
       13

STL тяги многократного векторного преобразования?

6 голосов
/ 22 сентября 2011

Мне было интересно, есть ли более эффективный способ записи a = a + b + c? 

 thrust::transform(b.begin(), b.end(), c.begin(), b.begin(), thrust::plus<int>());
 thrust::transform(a.begin(), a.end(), b.begin(), a.begin(), thrust::plus<int>());

Это работает, но есть ли способ получить тот же эффект, используя только одну строку кода? Я посмотрел на реализацию saxpy в примерах, однако здесь используются 2 вектора и постоянное значение;

Это более эффективно? 

struct arbitrary_functor
{
    template <typename Tuple>
    __host__ __device__
    void operator()(Tuple t)
    {
        // D[i] = A[i] + B[i] + C[i];
        thrust::get<3>(t) = thrust::get<0>(t) + thrust::get<1>(t) + thrust::get<2>(t);
    }
};


int main(){

     // allocate storage
    thrust::host_vector<int> A;
    thrust::host_vector<int> B;
    thrust::host_vector<int> C;

    // initialize input vectors
    A.push_back(10);
    B.push_back(10);
    C.push_back(10);

    // apply the transformation
    thrust::for_each(thrust::make_zip_iterator(thrust::make_tuple(A.begin(), B.begin(), C.begin(), A.begin())),
                     thrust::make_zip_iterator(thrust::make_tuple(A.end(),   B.end(),   C.end(),   A.end())),
                     arbitrary_functor());

    // print the output
       std::cout << A[0] << std::endl;

    return 0;
}

1 Ответ

7 голосов
/ 25 сентября 2011

a = a + b + c имеет низкую арифметическую интенсивность (только две арифметические операции для каждых 4 операций с памятью), поэтому вычисление будет ограничено пропускной способностью памяти.Чтобы сравнить эффективность предложенных вами решений, нам нужно измерить их требования к пропускной способности.

Каждый вызов transform в первом решении требует двух загрузок и одного хранилища для каждого вызова plus.Таким образом, мы можем смоделировать стоимость каждого transform вызова как 3N, где N - это размер векторов a, b и c.Поскольку существует два вызова transform, стоимость этого решения составляет 6N.

Мы можем смоделировать стоимость второго решения аналогичным образом.Каждый вызов arbitrary_functor требует трех загрузок и одного хранилища.Таким образом, стоимостной моделью для этого решения будет 4N, что означает, что решение for_each должно быть более эффективным, чем двойной вызов transform.Когда N велико, второе решение должно работать на 6N/4N = 1.5x быстрее, чем первое.

Конечно, вы всегда можете объединить zip_iterator с transform аналогичным образом, чтобы избежать двух отдельных вызововtransform.

...