Нужно убрать цикл из цикла, а затем уже параллелить

C++ (Qt)
std::vector<Vec3> CPolySDS::CalcVerNormals( const std::vector<Vec3> & pos ) const
{
	std::vector<Vec3> dst(pos.size());
	std::vector<Vec3> faces( mNorIndex.size() / mNumVerPerFace );
 
        // эффективно распараллеливаем здесь
	for (size_t i = 0; i < mNorIndex.size(); i += mNumVerPerFace) {
		faces[ i / mNumVerPerFace ] = GetFaceNormal(&mNorIndex[i], mNumVerPerFace, pos);
	}
 
        // не очень эффективно распараллеливаем здесь
	for (size_t i = 0; i < mNorIndex.size(); i += mNumVerPerFace) {
		for (size_t j = 0; j < mNumVerPerFace; ++j)
			dst[mNorIndex[i + j]] += faces[ i / mNumVerPerFace ];
	}
 
// ну и далее вектор посылается на видеокарту
 

Как вариант не очень эффективное распараллеливание попробовать реализовать без блокировок диапазонами таким способом

Номера индексов mNorIndex поделить на диапазоны. Первым потоком выполнять операции только для [0...N1), вторым - [N1...N2) и т.д. [Nx...mNorIndex.size()).
Диапазоны нужно выбирать так, чтобы кеши CPU заведомо не пересеклись.

Пожалуйста, прочтите стартовый пост.

Если имеется ввиду "сделать 2 цикла и параллелить каждый" - то так теряем время на запись/чтение (вектор faces) + (еще хуже) ждем на барьере после первого цикла.

Такое "деление на диапазоны" (иногда называют "stencil") совсем не бесплатно/безобидно. И предрассчитать его получается далеко не всегда.

Я бы делал просто "мешком локеров", напр для Qt

C++ (Qt)
std::vector<int> lock(pos.size());

И перед каждым += с наглой мордой привести к QAtomicInt и лочить testAndSetAcquire

Но до этого дело даже не доходит - оно не масштабит и без всякого лока. Мне кажется очевидным надо прорываться к GPU, это его тема

Из первого поста не сильно понятно как было сделано распараллеливание.
Хотя бы псевдокод посмотреть, с теми локами и конкурентным доступом к общим объектам.
PS: OMP параллелит далеко не всегда адекватно.

Для "приличных", нормальных задач - да. А вот для таких мелких - нет. Что вполне естественно. Напр для каждого вертекса нужно собрать индексы фейсов куда он входит. Конечно вычислений никаких, но читаются/пишутся немалые вектора, а это уже соразмеримо с временем вычисления нормалей.

Разумеется гуглил (правда без особого фанатизма) но ничего не нашел. Очевидно нужно задействовать какой-то "инструментарий", но вот какой? Требования к видео: OpenGL 3.3, т.е. рассчитывать на большее я не могу. Какие варианты?

CUDA - ну это вроде NVidia SDК, вика показывает перечень поддерживаемых карт. Т.е. выходит нужно поддерживать текущий (медленный) "software вариант" ? Это заботы/груз

OpenCL - какой-то непонятный зверь. "Собирал" неск приложений где он задействован. Одно вообще висит, хотя device инициализиpуется успешно, пришлось OpenCL отключать. В др приложении вроде работает (радостно сообщает что "откомпилило" какой-то местный шейдер) но каков эффект - хз.

Просто перед циклом вставляем
Также проверялся QtConcurrent - ну там вообще мрачно. Также проверялось "ручное" разбиение (типа того что Вы предлагали). Локер не реализован вообще (пока не до него). Во всех случаях на 4 нитках тот же самый 1 fps. Профайлер показывает что да, все нитки задействованы, но в основном стоят на барьере.

Интересно, можно больше подробностей?

Хотя в данном случае CPU не вызывает энтузиазма. Ну "вдвое" - это же очень мало, будет сцена/объект/итераций побольше, опять встанет тот же вопрос.

Ну это фишка известная, здесь наоборот, кластер слишком велик, в рез-те все "ждут отстающего".  Бороться так

C++ (Qt)
#pragma omp parallel for schedule(dynamic, 1)  // возможно др значение вместо 1

И задач "нарезать" не по числу ниток, а хотя бы вдвое больше

Разумно, примерно таким способом я часто выкручиваюсь (делать/скармливать задачи уровнем выше). К сожалению, это не всегда применимо. Напр в данном случае есть мужик (аттач) который машет руками и.т.п. Я могу его просчитать только для данного кадра (текущего времени), для следующего - все с нуля. Др словами "слишком велико чтобы выделить в задачу"

Что функция рассчетов то делает?
Может она весь кэш процессора вышибает? Есть тулзы (по памяти не скажу) которые профилируют промахи кэша.
Может размер итерации не подогнан под размер кэшей?
Ещё подумать в сторону векторных операций, раза в 4 могут ускорить

А можно поподробнее в сторону векторных операций? (сам просто сейчас занимаюсь вычислениями собственных значений и собственных векторов)