Параллельное выполнение цикла расчета

[Daniel]

А после отправки сигнала и исполнения слота, возобновить тред thread->start()? И она продолжит с того же места или начнет run() сначала?

[ssoft]

Скорость выполнения одна и та же, но [] намного легче для восприятия. Использование ** (двух звездочек в объявлении) нежелательно, трех - тем более.  

Написал грубый тест производительности.

Код:

		QVector< float > data( 1024, 0.0f );
		float * values = data.data();
		int int_count = data.count();

		for ( int i = 0; i < 40; ++i )
		{

			quint64 count = quint64( 1 ) << i;
			qDebug()
				<< "Start tests:" << i
				<< "-" << count << "iterations";

			QTime timing;
			timing.start();

			for ( quint64 iter = 0; iter < count; ++iter )
			{
				for ( int i = 0; i < int_count; ++i )
				{
					values[ i ] = static_cast< float >( iter + i );
				}
			}
			qDebug()
				<< timing.elapsed()
				<< "for container[ i ]";

			timing.restart();

			for ( quint64 iter = 0; iter < count; ++iter )
			{
				for ( int i = 0; i < int_count; ++i )
				{
					*( values + i ) = static_cast< float >( iter + i );
				}
			}
			qDebug()
				<< timing.elapsed()
				<< "for *( array + i )";
		}
	}

	return 0;

Для компилятора gcc (mingw) разницы нет, а вот для MSVC2010 разница почти в 10%!
Впервые столкнулся с этим при реализации численных методов лет 8 назад.
10% при длительности расчетов дни или недели - это очень существенно.
Поправьте, если я не прав.

[xokc]

Замеряли, надеюсь, в release с включёнными оптимизациями? Компиляторы сейчас достаточно умны, чтобы слажать на таком примитивном случае.

[Igors]

А после отправки сигнала и исполнения слота, возобновить тред thread->start()? И она продолжит с того же места или начнет run() сначала?

Продолжит (см описание BlockingQueuedConnection). Вообще распараллеливание - довольно серьезная штука, часто требуется переделать задачу в корне. Конечно получится сходу - слава богу, но рассчитывать на это не стоит. Возможно есть смысл сначала попробовать на небольшом тестовом проекте.

Для компилятора gcc (mingw) разницы нет, а вот для MSVC2010 разница почти в 10%!
Впервые столкнулся с этим при реализации численных методов лет 8 назад.
10% при длительности расчетов дни или недели - это очень существенно.
Поправьте, если я не прав.

В MSVC есть много такого что совершенно недоступно моему пониманию А вообще это классический пример из библии Страутструпа где говорится типа "современный компилятор должен сделать примерно одинаковый код".

Длительность расчетов дни/недели часто свидетельствует просто о том что никаких попыток оптимизировать вычисления не предпринималось У меня нет оснований не верить Вашим тестам, но это проверка "холостого хода". То есть изменив все [] на * в рабочем проекте мы получим совсем не -10%, а возможно -2%. а может даже и +5% (бывает и так). В другом кусочке кода компилятор может разбираться с [] уже совсем по-другому.

[ssoft]

MSVC2010
Release
Проверил всё, что предлагает студия
  Disabled (/Od) здесь всегда все одинаково.

А вот для

  Minimize Size /01
  Maximize Speed /02
  Full Optimization /0x

получился просто "волшебный" результат.
Последовательный запуск одной и тоже программы может привести как к одинаковому результату

Код:

Start tests: 16 - 65536 iterations 
612 for container[ i ] 
610 for *( array + i ) 
Start tests: 17 - 131072 iterations 
1235 for container[ i ] 
1230 for *( array + i ) 
Start tests: 18 - 262144 iterations 
2473 for container[ i ] 
2452 for *( array + i ) 
Start tests: 19 - 524288 iterations 
4920 for container[ i ] 
4903 for *( array + i ) 
Start tests: 20 - 1048576 iterations 
9810 for container[ i ] 
9820 for *( array + i ) 

так и к разному

Код:

Start tests: 16 - 65536 iterations 
613 for container[ i ] 
690 for *( array + i ) 
Start tests: 17 - 131072 iterations 
1232 for container[ i ] 
1390 for *( array + i ) 
Start tests: 18 - 262144 iterations 
2455 for container[ i ] 
2775 for *( array + i ) 
Start tests: 19 - 524288 iterations 
4908 for container[ i ] 
5612 for *( array + i ) 
Start tests: 20 - 1048576 iterations 
9818 for container[ i ] 
11183 for *( array + i ) 

не удивлюсь, если у кого-нибудь будет наоборот.

Склоняюсь к мнению, что предложенный мной тест не корректен, и разницы между записями нет.
Вообще нужно сравнить ассемблерный код, он должен быть идентичен.
В gcc все стабильно - результат одинаковый.

Длительность расчетов дни/недели часто свидетельствует просто о том что никаких попыток оптимизировать вычисления не предпринималось

часто да, но здесь нет  . Ряд задач, например, нестационарные задачи газовой динамики с подвижной геометрией считают неделями, а иногда и месяцами.

[Igors]

Склоняюсь к мнению, что предложенный мной тест не корректен, и разницы между записями нет.
Вообще нужно сравнить ассемблерный код, он должен быть идентичен.
В gcc все стабильно - результат одинаковый.

Я бы подытожил так: ковыряться в этом нет никакого смысла, здесь ничего не извлечь 

часто да, но здесь нет  . Ряд задач, например, нестационарные задачи газовой динамики с подвижной геометрией считают неделями, а иногда и месяцами.

Ну спорить о незнакомой мне предметной области я не могу, поэтому др пример. Вы давеча спрашивали "что ето за рендер" - там тоже если увеличить разрешение, то счет быстро пойдет на часы и дни. Однако никаким "волшебным кодом" (т.е. чисто технически) это не решить - нужно менять/усиливать алгоритм.

[Fregloin]

 может немного не в тему, но если такие вычисления длятся сутками, то может посмотреть в сторону OpenCL? и перенсти нагрузку на видеокарту?

[ssoft]

может немного не в тему, но если такие вычисления длятся сутками, то может посмотреть в сторону OpenCL? и перенсти нагрузку на видеокарту?

Так и делают уже достаточно давно (несколько лет), но пока на уровне научно-исследовательских работ.

[xokc]

Так и делают уже достаточно давно (несколько лет), но пока на уровне научно-исследовательских работ.

Очень плотно уже несколько лет работаем с вычислениями на видеокартах NVidia, но не через OpenCL, а через CUDA Toolkit. Очень нравится. И инструментарий разработчика, и комъюнити, и результаты. Раньше эти же задачи решали на ПЛИС - сроки вывода решений на рынок стали в разы короче.

[Daniel]

Спасибо всем, особенно Igors.
Попробую как-нибудь на простом проекте, а вчера вечером меня осенило и я смог ускорить расчет в разы с математической точки зрения.
Но распараллеливанием все равно надо будет заняться.