Олег Цилюрик - QNX/UNIX: Анатомия параллелизма

# p2-1

fork time: 3.4333 msec. [1835593 cycles]

# p2-1 1

Fork time: 17.0706 msec [9126696 cycles]

# p2-1 2

Fork time: 31.5257 msec. [16855024 cycles]

# p2-1 5

Fork time: 70.7234 msec. [37811848 cycles]

# p2-1 20

Fork time: 264.042 msec. [141168680 cycles]

# p2-1 50

Fork time: 661.312 msec. [353566688 cycles]

# p2-1 100

Fork time: 1169.45 msec. [625241336 cycles]

Наблюдаются, во-первых, достаточно большие временные затраты на создание процесса (к этому мы еще вернемся), а во-вторых, близкая к линейной зависимость времени создания процесса от размера его образа в памяти и вариации этого времени на несколько порядков. Об этом уже говорилось при рассмотрении функции fork(): это следствие необходимости полного копирования образа адресного пространства родительского процесса во вновь создаваемое для дочернего процесса адресное пространство. При этом линейный рост времени копирования от размера образа процесса становится естественным (вот почему для образов таких задач при их построении посредством программы makeв высшей степени целесообразно выполнить завершающую команду stripдля уменьшения размера итогового образа задачи). Более того, это «высоко затратная» операция копирования, не в пример привычной функции memcpy(). Копирование производится между различными адресными пространствами обращением к средствам системы по принципу: скопировать N байт, начиная с адреса А адресного пространства Р, по адресу, начиная с А (тот же адрес!) адресного пространства С. В большинстве других ОС некоторое смягчение вносит использование техники COW (copy on write), но и этот эффект кажущийся (см. выше подробное обсуждение при описании функции fork()).

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

T = 3000000 + Р * 6000

где Р— размер (в килобайтах) файла образа программы, в которой выполняется fork().

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

void* threadfunc(void* data) { pthread_exit(NULL); }

int main(int argc, char *argv[]) {

uint64_t t = ClockCycles();

pthread_t tid;

pthread_create(&tid, NULL, threadfunc, NULL);

pthread_join(tid, NULL);

t = ClockCycles() - t;

cout << "Thread time, " << cycle2milisec(t) << " msec. [" << t <<

" cycles]" << endl;

exit(EXIT_SUCCESS);

}

На результаты этого теста (в отличие от предыдущего) уже достаточно существенно влияет приоритет, под которым выполняется задача, поэтому проделаем его с достаточно высоким приоритетом (29):

# nice -n-19 p2-2

Thread time: 0.147139 msec. [78667 cycles]

# nice -n-19 p2-1

Fork time: 2.5366 msec. [1356179 cycles]

Вот так… время порождения нового «пустого» процесса, даже минимального размера (размер исполняемого файла этого процесса чуть больше 4 Кбайт), почти в 20 раз больше затрат на создание потока! А для процессов большого объема эта разница может доходить до 3–4 порядков (см. результаты первого теста).

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

void workproc(int how = 1) {

const int nsingl = 1000, msingl = 30;

for (int j = 0; j < how; j++) // ... имитация вычислений

for (uint64_t i = 0; i < msingl; i++)

for (uint64_t k = 0; k < nsingl; k++)

k = (k + 1) - 1;

}

int main(int argc, char *argv[]) {

int numpar = 1;

if (argc > 1 && atoi(argv[1]) > 0)

numpar = atoi(argv[1]);

_clockperiod clcold;

ClockPeriod(CLOCK_REALTIME, NULL, &clcold, 0);

if (argc > 2 && atoi(argv[2]) > 0) {

_clockperiod clcnew = { atoi(argv[2]) * 1000, 0 };

ClockPeriod(CLOCK_REALTIME, &clcnew, &clcold, 0);

}

timespec interval;

sched_rr_get_interval(0, &interval);

cout << "Rescheduling interval = "

<< (double)interval.tv_nsec / 1000000 << " msec." << endl;

uint64_t t = ClockCycles();

for (int i = 0, i < numpar; i++) {

pid_t pid = fork();

if (pid == -1) perror("fork"), exit(EXIT_FAILURE);

if (pid == 0) {

workproc(1000);

exit(EXIT_SUCCESS);

}

}

for (int i = 0; i < numpar; i++) wait3(NULL, WEXITE0, NULL);

t = ClockCycles() - t;

cout << "Forks scheduling time" << cycle2milisec(t)

<< " msec [" << t << " cycles]" << endl;

ClockPeriod(CLOCK_REALTIME, &clcold, NULL, 0);

exit(EXIT_SUCCESS);

}

Имитатором активной вычислительной нагрузки программы является функция workproc(), отличительной особенностью которой является то, что она при активной (хоть и бессмысленной) загрузке процессора не делает на всем интервале своего выполнения никаких системных вызовов, которые могли бы привести к вытеснению выполняющего ее потока.

Первым параметром программы является количество процессов, на которые распределяется общий объем вычислений. Но самое главное: начнем управлять размером периода временного системного тика.

По умолчанию системный тик (для QNX 6.2.1) равен 1 мсек., но в принципе его значение можно уменьшать функцией ClockPeriod()вплоть до 10 мксек. Кстати, в описании именно этой функции присутствует замечание о том, что « …период решедулирования равен 4 тикам, и это соотношение в системе нельзя изменить ».

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

При распараллеливании вычислительного объема между потоками эквивалентный код ( файл p4-2.cc ) будет иметь вид (используется та же функция workproc()), которую мы повторно не показываем):

void* threadfunc(void* data) {

workproc(100);

pthread_exit(NULL);

}

int main(int argc, char *argv[]) {

int numpar = 1;

if (argc > 1 && atoi(argv[1]) > 0)

numpar = atoi(argv[1]);

pthread_t *tids = new pthread_t [numpar];

_clockperiod clcold;

ClockPeriod(CLOCK_REALTIME, NULL, &clcold, 0);

if (argc > 2 && atoi(argv[2]) > 0) {

_clockperiod clcnew = { atoi(argv[2]) * 1000, 0 };