Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.145.130.31] |
|
Страницы: (2) 1 [2] все ( Перейти к последнему сообщению ) |
Сообщ.
#16
,
|
|
|
#include <iostream> int numberOfObjects = 10000000; int arraySize = numberOfObjects + 1; int *object = new int[numberOfObjects]; int *shiftArray = new int[arraySize]; #ifdef _MSC_VER #define NOMINMAX #include <windows.h> __forceinline double time() { LARGE_INTEGER counter, frequency; QueryPerformanceCounter(&counter); QueryPerformanceFrequency(&frequency); return double(counter.QuadPart) / double(frequency.QuadPart); } #else #include <sys/time.h> inline __attribute__((always_inline)) double time() { timeval t1; gettimeofday(&t1, NULL); return t1.tv_sec + t1.tv_usec * 0.000001; } #endif void genarr() { for (int i = 0; i < numberOfObjects; i++) { object[i] = 1 + (i % 10); } } int main() { int shiftValue = 0; double t1, t2, t3; t1 = time(); genarr(); t2 = time(); for (int i = 0; i < numberOfObjects; i++) { shiftArray[i] = shiftValue; shiftValue += object[i]; } shiftArray[numberOfObjects] = shiftValue; t3 = time(); delete[] shiftArray; delete[] object; std::cout << "t2=" << (t2 - t1) << "\nt3=" << (t3 - t2); } У меня на рабочем компе время плавает от 0.015, до 0.07. Это медлено? Так же замечу, при таких малых значениях, внедрение OpenMP может увеличить итоговое время расчета (особенно, если это где-то еще в выше стоящих циклах используется), так как накладные расходы высокие. Добавлено + void genarr() { #pragma omp parallel for for (int i = 0; i < numberOfObjects; i++) { object[i] = 1 + (i % 10); } } Время этого кода в тех же пределах. |
Сообщ.
#17
,
|
|
|
Сделал еще один тест
Добавил два нолика к количеству тип заменил на char, перевел код на 64-бита. Первая часть результатов без OpenMP, вторая с ним для генерации исходных данных. Скрытый текст D:\Project\VS\Test2\x64\Release>Test2.exe t2=1.08864 t3=0.842568 D:\Project\VS\Test2\x64\Release>Test2.exe t2=1.11564 t3=0.837306 D:\Project\VS\Test2\x64\Release>Test2.exe t2=1.08041 t3=0.853024 D:\Project\VS\Test2\x64\Release>Test2.exe t2=1.08604 t3=0.819968 D:\Project\VS\Test2\x64\Release>Test2.exe t2=0.474971 t3=0.844585 D:\Project\VS\Test2\x64\Release>Test2.exe t2=0.485372 t3=0.928686 D:\Project\VS\Test2\x64\Release>Test2.exe t2=0.441639 t3=0.789672 D:\Project\VS\Test2\x64\Release>Test2.exe t2=0.508216 t3=0.788921 Вообщем, когда время расчета уже становиться большим, появляется эффект. |
Сообщ.
#18
,
|
|
|
Black_Dragon, для замеров времени лучше пользовать стандартную либу, вместо привязки к оси:
#include <chrono> auto start = std::chrono::high_resolution_clock::now(); // ... тут помещаем замеряемый код auto stop = std::chrono::high_resolution_clock::now(); std::cout << "Прошло:" << std::chrono::duration_cast<std::chrono::milliseconds>(stop - start).count() << "ms" << std::endl; |
Сообщ.
#19
,
|
|
|
JoeUser
Те же цифры. Просто какая цель задачи, просто попробовать сделать параллельный код или реально повысить быстродействие. Во втором случае, надо все целиком рассматривать. Например, есть точка, и куча отрезков. Надо найти ближайший к точке. Вообщем вычислялось расстояние. А так как нам надо было найти отрезок, а не знать расстояние, то я из формулы расстояние убрал корень. Т.е. в начале делаешь как положено и понятно, отлаживаешь все. А потом начинает оптимизировать, упрощать, придумывать новые идеи. Добавлено + Вот время работы программы, где велись геометрические расчеты и использовались разные уловки Начальное время расчета (4 минуты) 00:04:36.0053614 Использование хеш-сетки для исключения не нужных отрезков (4 сек) 00:00:04.8520328 Использование OpenMP на 12 потоков 00:00:34.4000643 Использование хеша + 12 потоков 00:00:03.4497785 |
Сообщ.
#20
,
|
|
|
Цитата Black_Dragon @ JoeUser Те же цифры. Просто код поскромнее |