Спонтанные замедления вычислений

фаза луны?

Бонально, какая-нибудь гадина, системная, в фоне делает что-то, расходуюя проц на 0.1%, но вынуждая шедулер делать больше переключений между тасками, а каждое переключение -- это длинный сброс и заполнение с нуля, всего процессорного конвейра, что очень дорого обходится.

hal опрос? сетевая активность? приоритет задачи?

Трудность в том, что тормозит оно "равноверно по ходу вычислений". Т.е. процесс много стадийный, длительность стадий разная, отличается на порядок, стадии выполняются одна за другой. Так вот тормозят все стадии конкретного тормознутого вычисления и очень короткие, и очень длинные. А буквально следующий же запуск не тормозит вообще!

Может где-то ошибка в коде?

#define true rand() ?

а что профилировщик говорит?

Небось КораДуба с толстым кэшем? (3 Мб?)

2x Opteron 246

А ведро какой версии?

2.6.5-7.244-smp Это SLES 9.

> Однако из сотни абсолютно одинаковых запусков решателя несколько раз всё
> решается за время более 60-ти сек.

Одинаковых ли? Что, на машине не запущено никаких других процессов?

> Время меряется вызовами clock(3),

Это цена на пшеницу в Афганистане так меряется. А время меряют с помощью
getrusage.

> Интересно, от чего так?

Какая-то зараза тоже хочет получить доступ к процессору и "сбивает" кеш?

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

Вдобавок кеш похерится может, что еще дороже обойдется.

Получается, что "какая-то зараза" втечение 50 сек. портит кэш, а на следующем же запуске решалки вообще ничего не делает... Странно, ибо кроме простых кронов, ssh-ей и т.п. ничго не запущено, и юзер один залогинен...

>> Время меряется вызовами clock(3), >Это цена на пшеницу в Афганистане так меряется.

И чего плохого clock(3)?

А нельзя ли это упростить до примерчика, который мне (на x86) тоже можно будет как-нибудь простенько погонять? Действительно любопытно, в чём же может быть дело. Гипотез десятки.

Создай два массива значений double длиной по миллиону. и напиши функцию:

void lin_comb( int size, double a1, double *v1, double a2, double *v2 ) { for( int i = 0; i < size; ++i ) v1[i] = a*v1[i] + a2*v2[i]; }

потом вызови её много раз, так чтобы на минуту работы набрлось. Может что-то и поймаешь. Это, конечно, не всё, но для остального надо реализовывать разреженные матрицы и арифметику для них. Можно ещё написать не последовательный цикл, а по случайному индексу...

lin_comb в чистом виде у меня пошёл хорошо. Что не удивительно. А ловить "то не знаю что" на ровном месте я не умею.

Ну, если тебя всё нормально, то и хорошо...

Ты пробовал lin_comb с циклом не по всему вектору, а по лучайным индексам? Сделай вектор на 5М значений...

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

т.е.буквально for i in `seq 1 100`; do time test_lin_comb; done

> И чего плохого clock(3)?

В том, что он меряет непонятно что.

> Получается, что "какая-то зараза" втечение 50 сек. портит кэш, а на следующем
> же запуске решалки вообще ничего не делает...

Ничего подобного. Раз в M запусков Вашей "решалки" просыпаются/запускаются N
(N >= 1) других процессов. Переключение контекста может запросто похерить кеш,
(а также TLB, конвейеры). И не важно, что эти "мешающие" процессы сами по себе
могли выполняться в течение очень короткого времени.

> Странно, ибо кроме простых кронов, ssh-ей и т.п. ничго не запущено,
> и юзер один залогинен...

Ничего странного. Предлагаю изучить мат. часть. Для начала сойдет и вот это:

http://en.wikipedia.org/wiki/CPU_cache
http://en.wikipedia.org/wiki/Translation_Lookaside_Buffer
http://en.wikipedia.org/wiki/superscalar