Здравствуйте, cures, Вы писали:

C>Здравствуйте, smeeld, Вы писали:

S>>что быстро выполниться при больших N не может.

C>Интересно, что этот construct делает, и можно ли его попросить этого не делать?
C>По крайней мере, new раньше спокойно оставлял примитивные типы неинициализированными, а vector так не умеет?

S>>Да, делайте просто malloc() без этих stl дурковатостей.

C>Можно с придурковатостями, в shared_ptr засунуть, но после malloc
C>Другой вопрос — нужен ли в программе этот здоровый массив? Если его нулями заливает 10 минут, то какое время займёт его обычное использование? Если 10 минут — ничтожная доля в общем времени, то имеем классическую причину всех зол, по Кнуту. Если доля существенная, то массив как таковой практически не исползуется, только небольшие его участки, и его хорошо бы заменить на подходящую структуру меньшего размера.

Там всё плохо с точки зрения оптимизации — массив не разрежен и сразу после запуска инициализируется рандомными числами в многопоточном режиме. Но это делается быстро, ибо 64 ядра отлично параллелятся. А "выделение" памяти делалось одним потоком и долго, что сильно раздражало. Теперь то я понимаю, что это было не само выделение, а дураковатости в конструкторе вектора.

C>А если его таки надо забить изначально нулями, то может быть проще его в .bss завести, система сама инициализирует, если умная — аппаратно. Ну или правда через OpenMP распараллелить, обычно в машине несколько каналов к памяти, может в несколько раз ускориться. Или memset позвать, вдруг он что-то знает

Ээээ. А как компилятору сказать что вектор нужно в .bss завести? Размер в компайл-тайм известен.