Подскажите, пожалуйста, ответ на следующий вопрос. Выполняю определеные расчеты. Для этого общий диапазон обрабатываемых данных разбил на 4 поддиапазона и каждый из этих поддиапазонов обрабатываю в отдельном потоке. Все поддиапазоны обрабатываются независимо, по одиннаковому алгоритму. Всего создаю 4 потока и запускаю на 4-х ядерном процессоре. Так вот не совсем понятно, почему, когда каждый поток выполняется по отдельности (загружено только одно ядро), время обработки фиксированного объема данных составляет 10 секунд, когда 2 потока одновременно — то уже 18 секунд, а когда все 4 потока — то около 30 секунд. Хотя казалось бы, что должно быть все равно около 10 секунд, т.к. потоки выполняются параллельно и независимо (у каждого потока индивидуальный набор данных в одиннаковом количестве). Конечно все равно быстрее, чем на одном ядре, но все же казалось, что независмые потоки могут выполняться и побыстрее, при параллельной работе. Процессор Core i5 750. ОС Windows XP.

Если потоки совершенно независимы и локами не перевязаны (с учётом того что даже вывод прогресса на консоль, типа "поток 1 сделал 20%" — лишний лок), то тогда скорее всего упираетесь в память и пропускную способность шины.

Здравствуйте, rondonand, Вы писали:

На код можно взглянуть? Желательно именно на тот, о котором говорите, без купюр.

Здравствуйте, Jolly Roger, Вы писали:

Код показать могу — ничего в нем такого нету, это программа для расчетов статистики шифра, нужной мне для исследований, проводимых с дипломным руководителем. В чем проблема была я уже разобрался. Спасибо, hi_octane, я обратил внимание на то, что слишком уж большие объемы памяти задействовал. В каждом потоке использовалось 256 Мб памяти, которая обнулялась десятки тысяч раз. В итоге, при совместной работе 4-х потоков, приходилось модифицировать 1 Гб памяти, что сильно снижало быстродействие. Собственно сама память использовалась для хеш-таблицы. Когда уменьшил объем памяти под таблицу в каждом потоке до 16 Мб, то быстродействие возросло в 5 раз. И при совместной работе 4-х потоков те же объемы данных обрабатываются уже за 6 секунд, в то время как один поток обрабатывает их за 4,5 секунды, что можно уже частично списать и на системные издержки при переключении и работе других потоков вследствие 100%-ой загруженности процессора. Коллизий конечно стало больше, и возросли размеры связанных списков, но скорость все равно значительно выше.

Общая структура кода в каждом потоке такая:

for ( delta = begin_of_range; ;delta++ )
{
    memset ( XOR_l_4, 0, 1048576 * sizeof (XOR_list)); // здесь происходит наибольшая задержка, т.к. delta проходит в общей сумме 65536
                                                           // значений. Изначельно количество 8-байтых элементов XOR_list было 2^24, а не 2^20. 
    memset ( &maximum_4, 0, sizeof (XOR_counter) );
    maximum_4.counter = 1;

    for ( text = 0;  text < total_num_of_deltas / 2; text++ )
    {
        block[0] = text;
        block[1] = 0;

        cryptG ( block, key );

        *((__int64*)xor_out) = *((__int64*)block);

        block[0] = text ^ delta;
        block[1] = 0;

        cryptG ( block, key );

        *((__int64*)xor_out) ^= *((__int64*)block);

        insert_xor_by_hash ( (__int64*)xor_out, XOR_l_4, 1048576, &maximum_4 );
    }
            
    max_num_of_texts [ delta ] = maximum_4.counter;

    if ( delta == (total_num_of_deltas - 1) )
    {
        break;
    }
}

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Jolly Roger, Вы писали:

А>Код показать могу

Ну коль причина локализована, то это уже не требовалось От себя могу добавить, что Вы, видимо, "упёрлись" в L3 кэш, который у i5 общий для всех ядер и составляет 8 MB. Скорость обмкна с ОЗУ вряд-ли успела сказаться, так как она у данного процессора, если не ошибаюсь, порядка 2x10 GB per sec.

Здравствуйте, rondonand, Вы писали:

R>Подскажите, пожалуйста, ответ на следующий вопрос. Выполняю определеные расчеты. Для этого общий диапазон обрабатываемых данных разбил на 4
...
R> Процессор Core i5 750. ОС Windows XP.

Возможно XP недостаточно грамотно раскидывает их на процессоры.
Далее, возможно твои потоки прыгают между процессорами (context switching), что тоже производительности не добавляет.
Ещё неясен объем данных, возможно и правда упор в кэш. Тогда поможет разделение на более мелкие фрагменты и постановку в очередь на обработку в Thread Pool, дабы одновременно выполнялось только 4 потока, а остальные пакеты для обработки висели в очереди.