boost::thread VS openMP!!! Кто кого???

> 1. кому верить time или clock???

clock отдает количество тиков которые поток проводит в активном состоянии. если мерять сколько CPU% пожрал поток - clock. если «реальное время» - time.

про остальные вопросы не знаю

>clock отдает количество тиков которые поток проводит в активном состоянии

Тогда почему так сильно разняца его значения при разных запусках программы? колеблется от 8300000 до 9500000!!!

> Тогда почему так сильно разняца его значения при разных запусках программы? колеблется от 8300000 до 9500000!!!

потому что многозадачность.

for (int i = ind; i < Nmas; i += Npar)

Попробуйте делить вектор не как сейчас, а цельными кусками. Тогда locality лучше.

Если я ни чего не путаю boost::thread порождает каждый создаваемый поток. OpenMP же создаст один раз потоки (по числу ядер) и потом их будет в нужный момент активировать. Создатели TBB(действующий аналогично) заявляют стократное приемущество по сравнению с системными нитями во времени инициализации.

В твоем случае imho быстрее OpenMP (сравнивай real время из time), но тест imho просто рвет многопоточность на куски. Т.к. действий каждому потоку достается очень мало и плюс imho суровый false-sharing. Дели данные непрерывными кусками и не допускай параллельной записи в близкие участки памяти. Из-за false-sharing прога у тебя работает в разы медленее и непредсказуемо по времени.

P.S. можешь еще протестить Intel TBB, но imho должно быть примерно то же самое.

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

Ну на сколько я понял он создает столько потоков сколько укажешь, потому что когда я с ним экспериментировал, то создавалось и 20 потоков на 4-х ядрах без проблем. И все FAQи по нему утверждают что потоки создаются непосредственно в момент

#pragma omp parallel...

именно поэтому они не советуют распараллеливание помещать в цикл. Поскольку процесс создания потоков занимает много времени.

А вот про boost почемуто писали наоборот мол быстрое создание потоков малые затраты процессорных ресурсов.... А оказывается что АБСОЛЮТНО такие же, а иногда даже похуже.

действий каждому потоку достается очень мало

сравнивал результат работы на 1 цикле но с 200000000 итераций который параллелил этими 2 средствами, результат тот-же (времена конечно в разы меньше) openMP рвет!!!

Мне просто интересно, может я их неправильно сравниваю...

Но скажите мне кто-нибудь какое преимущество у boost-а? когда лучше будет использовать его вместо openMP? или это на вкус и цвет, как говориться, одна херня???

Нити не всегда используются для подобных вычислений. Бустовыми нитями вы можете управлять. openMP сами решают, что и когда им делать. В случаях числодроблений это, как правило, сильно упрощает жизнь.

> Ну на сколько я понял он создает столько потоков сколько укажешь, потому что когда я с ним экспериментировал, то создавалось и 20 потоков на 4-х ядрах без проблем. И все FAQи по нему утверждают что потоки создаются непосредственно в момент >#pragma omp parallel...

Отпрофилировал одно свое приложение valgrind-ом(--tool=callgrind), ясно видны 3(Core Quad) вызова pthread_create. Попробуйте тоже отпрофилировать и понять сколько их там создается в вашем случае.

именно поэтому они не советуют распараллеливание помещать в цикл. Поскольку процесс создания потоков занимает много времени.

Даже активировать уже созданную нить - весьма дорого, именно поэтому этого не стоит делать часто, да и вычислений на одну нить должно приходиться много. Imho с 100000 тактов уже имеет смысл активировать нити.

когда лучше будет использовать его вместо openMP?

OpenMP - упрощенные(с точки зрения колва кода) нити для простых вычислительных задач, если тебе нужна сложная логика взаимодействия нитей может быть удобнее использовать или boost::threads или tbb.

Кстати вот как имеет смысл переписать твой цикл:

#pragma omp parallel shared(a, b, c) num_threads(Npar)

{ int myid = omp_get_thread_num(); for (int i = myid; i < Nmas; i += Npar) { a[i] = (float) i; b[i] = a[i] * a[i]; c[i] = 0.3 * a[i] - b[i] / a[i]; } }

#pragma omp parallel for for (int i = 0; i < Nmas; i++) { a[i] = (float) i; b[i] = a[i] * a[i]; c[i] = 0.3 * a[i] - b[i] / a[i]; }

Дело в том, что shared подразумевается по умолчанию а число нитей лучше или не задавать вообще(определяется по кол-ву ядер) или задать один раз при старте программы. Кстати в случае этого цикла итерации разобьются непрерывными блоками и не будет суровых проблем с кэшем(false sharing).

отпрофилировать попробовал... Действительно openMP создает столько ветвей сколько укажешь в num_threads либо (если не указывать) количество ядер - 1 (поскольку один поток это основная программа), причем создает их с самого начала, даже если функция (или метод) содержащая распараллеливание не вызывается вовсе. А вот boost на каждую инициализацию своего класса создает поток, т.е. столько раз сколько его запускал...

с boost::thread должно быть както так (потоки создаются при старте, а не на каждую итерацию):

#include <boost/thread/thread.hpp>
#include <iostream>
#include <time.h>
#define Nmas 1000
#define Npar 4
using namespace std;

void proga(int pos0, int pos1, float* a, float* b, float* c)
{
	for(int it = 0; it < 100000; ++it)
	{
		for (int i = pos0; i < pos1; ++i)
		{
			a[i] = (float) i;
			b[i] = a[i] * a[i];
			c[i] = 0.3 * a[i] - b[i] / a[i];
		}
	}
}

int main(int argc, char* argv[])
{
	float* a = new float[Nmas];
	float* b = new float[Nmas];
	float* c = new float[Nmas];
	size_t num_threads = boost::thread::hardware_concurrency();
	boost::thread_group threads;
	for (int i=0; i<num_threads; ++i)
		threads.create_thread(boost::bind(&proga, i*Nmas/num_threads, (i+1)*Nmas/num_threads, a, b, c));
	threads.join_all();
	delete[] a;
	delete[] b;
	delete[] c;
	std::cout << clock() << endl;
	return 0;
}

OpenMP удобен тем, что ты не руками управляешь временем создания потоков(в данном примере это не сложно). Т.е. если у тебя есть несколько OpenMP-циклов в разных местах программы тебе не потребуется руками писать переход нитей между ними, с OpenMP они сами заснут после окончания одного цикла и возобновятся в начале следующего.