Результат многопоточности в более медленном

-1

В основном я ранее не выполнял многопоточное программирование. Концептуально я это понимаю.Результат многопоточности в более медленном

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

так что если я tr для генерации 1-1500 номеров случайным образом, используя одну нить и 10 потоков (или 5 потоков). один поток выполняется быстрее. нить переключения или блокировки, кажется, требует времени. так как с этим справиться?

pthread_mutex_t map_lock; 
std::set<int> numSet; 
int randcount=0; 

static void *thread_fun (void *arg) 
{ 
    int randNum= *(int *)arg; 
    int result; 
    std::set<int> findItr; 

     while (randcount != randNum -1) { 
     result = rand()%randNum; 

     if (result == 0) continue; 
      pthread_mutex_lock (&map_lock); 
      const bool is_in = (numSet.find (result) != numSet.end()); 
      if (!is_in) 
      { 
       numSet.insert (result); 
       printf (" %d\t", result); 
       randcount++; 
      } 

      pthread_mutex_unlock (&map_lock); 
     } 

}

источник

2015-05-26 Sach

Как вы это используете? Скомпилирован ли он как некоторый язык программирования? –

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

Выше приведен неполный код, написанный на языке C++. Который получает вызовы для каждого потока, созданного с помощью pthread_create. – Sach

Поскольку большинство ваших блоков кода все параллельные потоки (потому что находится между pthread_mutex_lock (& map_lock); и pthread_mutex_unlock (& map_lock); блок), ваш код работает, как он работает последовательно только с накладными расходами на параллелизацию.

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

источник

2015-05-26 13:13:19 mg30rg

Результат многопоточности в более медленном

ответ

Смежные вопросы