Есть некоторая структура Measure_Simulation, которая включает в себя достаточно много полей типа int, long, long double, char*, bool.
И есть вектор (std::vector) measuresvector, каждый элемент которого относится к типу Measure_Simulation. Этот вектор имеет 40 тысяч таких элементов.
Я копирую содержимое вектора measuresvector в другой вектор measuresvector2, используя следующий код:
Здравствуйте, RussianFellow, Вы писали:
RF>Можно ли как-то сделать это копирование быстрее? Какой код для этого следует использовать?
зарезервировать 40 тыс. элементов — при помощи метода my_vector.reserve(40000);
UPD:
measuresvector2.reserve(measuresvector.size()); // Резервируем под вектор необходимый размер
std::back_insert_iterator<std::vector <Measure_Simulation> > toV(measuresvector2);
std::copy(measuresvector.begin(),measuresvector.end(),toV);
RF>Этот процесс копирования занимает 20 секунд.
RF>Можно ли как-то сделать это копирование быстрее? Какой код для этого следует использовать?
Можно. Для этого нужно использовать такой код:
measurevector2 = measurevector;
Следующим шагом можно подумать, а действительно ли здесь необходимо копирование. Если окажется, что вместо копирования подходит перемещение, то время сведется вообще к нулю.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, RussianFellow, Вы писали:
RF>А зачем нужно резервирование элементов?
Чтобы во время копирования не резервировалась память и не выполнялось копирование "под капотом"
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, RussianFellow, Вы писали:
RF>А зачем нужно резервирование элементов?
Все реализации вектора должны хранить свои элементы последовательно в памяти.
Условно говоря, изначально вектор в конструкторе выделяет память на N элементов, где N — небольшое число (обычно 8-16 элементов).
После заполнения этой памяти, вектор выделяет память в два раза больше (или всего лишь на 10% больше) и копирует туда элементы из старого массива в новый.
Старый массив удаляет. Когда у тебя 40 тыс. элементов добавятся таких реаллокаций будет множество — из-за них и тормозит.
Это такой std::vector. Из-за требования хранить все элементы рядом друг с другом. std::list от такого недостатка свободен, но у него есть накладные расходы по памяти.
Здравствуйте, RussianFellow, Вы писали:
RF>И ещё вопрос: как лучше всего добавить содержимое вектора measuresvector в конец вектора measuresvector2 ? RF>Есть код:
RF>
RF>Можно ли изменить этот код, чтобы он работал быстрее? Что для этого нужно сделать?
Зачем понадобилось два вектора? Напиши логику работы с ними.
Может быть вместо этого хранить всё в одном векторе и сделать обёртку, которая будет обращаться к нужному участку вектора? Или сделать список векторов.
Здравствуйте, Nuzhny, Вы писали:
N>#pragma omp parallel for
Тут особо выигрыша не будет. Так как здесь не CPU узкое место, а пропускная способность памяти (RAM).
В память может и упрется.
Здравствуйте, GhostCoders, Вы писали:
GC>Здравствуйте, Nuzhny, Вы писали:
N>>#pragma omp parallel for GC>Тут особо выигрыша не будет. Так как здесь не CPU узкое место, а пропускная способность памяти (RAM). GC>В память может и упрется.
Ещё взглянуть бы на конструктор копии Measure_Simulation, может быть он тоже медленный. По описанию "много полей типа int, long, long double, char*, bool") сильно тормозить не должен, но вдруг там гигабайты этих полей.
Здравствуйте, AleksandrN, Вы писали:
R>>Копирование std::vector глазами разработчика _обычного_ языка программирования: R>>Img.
AN>Чем обычный язык программирования отличается от необычного?
Таки нашелся тот, кто заставил объяснять шутку. Ну, допустим, НЕ обычный — это C++. Соответственно, любой язык, отличный от С++ — обычный. Как тебе такая версия?
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, GhostCoders, Вы писали:
N>>#pragma omp parallel for GC>Тут особо выигрыша не будет. Так как здесь не CPU узкое место, а пропускная способность памяти (RAM). GC>В память может и упрется.
Набросал тест с POD структурой на своём 6-ядерном ноуте и параллельная версия получилась процентов на 10 быстрее. Согласен, что на маленьких данных выигрыша особого не будет. Но на больших объёмах он вполне возможен, почему нет? Особенно если много памяти занимает и она многоканальная.
Здравствуйте, Nuzhny, Вы писали:
N>Набросал тест с POD структурой на своём 6-ядерном ноуте и параллельная версия получилась процентов на 10 быстрее. Согласен, что на маленьких данных выигрыша особого не будет. Но на больших объёмах он вполне возможен, почему нет? Особенно если много памяти занимает и она многоканальная.
10 процентов єто как раз "особого віигріша не будет"
Здравствуйте, rg45, Вы писали:
R>Таки нашелся тот, кто заставил объяснять шутку. Ну, допустим, НЕ обычный — это C++. Соответственно, любой язык, отличный от С++ — обычный. Как тебе такая версия?
В єтой ветке ожидается 200+ сообщений.
Здравствуйте, rg45, Вы писали:
R>Здравствуйте, AleksandrN, Вы писали:
R>>>Копирование std::vector глазами разработчика _обычного_ языка программирования: R>>>Img.
AN>>Чем обычный язык программирования отличается от необычного?
R>Таки нашелся тот, кто заставил объяснять шутку. Ну, допустим, НЕ обычный — это C++. Соответственно, любой язык, отличный от С++ — обычный. Как тебе такая версия?
Тогда прыгун должен прыгать в чёрном полупрозрачном ящике. Степень прозрачности зависит от необычности языка. Чем необычней тем прозрачней.
Здравствуйте, AleksandrN, Вы писали:
AN>Тогда прыгун должен прыгать в чёрном полупрозрачном ящике. Степень прозрачности зависит от необычности языка. Чем необычней тем прозрачней.
Слишком сложная шутка. Для меня это некст левел.
--
Не можешь достичь желаемого — пожелай достигнутого.