История изменений

Вопрос - а что ж 3x так мало?

Я бы попробовал выяснить источник проблемы по двум вариантам - либо это сам алгоритм consume_line(), либо это немного не правильное использование omp (синтаксис или логика или еще что-то).

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

• Если время будет примерно одинаково - значит либо функция consume_line() слишком быстра (больше времени уходит на синхронизацию при создании/удалении потоков, чем на полезную работу каждого потока), либо экземпляры функции consume_line() дерутся за другой ресурс (например нехватка ОЗУ, нехватка кэша процессора и т.п.). Тут поможет только пересмотр алгоритма в consume_line().

• Если время на обычных потоках будет близко к ожидаемому (ускорению в 7-8 раз на 8 потоках) - значит что-то не так с использованием omp и нужно разбираться с применением omp.

И еще. Одно дело, если у вас без потоков время работы занимало 10 сек., а с omp потоками 3 сек. И совсем другое дело, если у вас без потоков 10 часов, а с omp потоками 3 часа. И там и там ускорение примрерно в 3 раза, но возиться и ускорять условные 3 сек. уже врятли имеет смысл, а вот ускорять 3 часа вполне разумное желание.

Ибо многопоточность работает НЕ бесплатно и вы просто добавляете работы компьютеру, что бы как можно больше использовать именно простаивающие ресурсы - используете несколько простаивающих ядер, несколько свободных кусков ОЗУ и кусков кэшей процессора, но платите за это доп. нагрузкой на эти ядра/ОЗУ/кэш на операции с потоками в дополнение к полезной работе.

Вопрос - а что ж 3x так мало?

Я бы попробовал выяснить источник проблемы по двум вариантам - либо это сам алгоритм consume_line(), либо это немного не правильное использование omp (синтаксис или логика или еще что-то).

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

• Если время будет примерно одинаково - значит либо функция consume_line() слишком быстра (больше времени уходит на синхронизацию при создании/удалении потоков, чем на полезную работу каждого потока), либо экземпляры функции consume_line() дерутся за другой ресурс (например нехватка ОЗУ, нехватка кэша процессора и т.п.). Тут поможет только пересмотр алгоритма в consume_line().

• Если время на обычных потоках будет близко к ожидаемому (ускорению в 7-8 раз на 8 потоках) - значит что-то не так с использованием omp и нужно разбираться с применением omp.

И еще. Одно дело, если у вас без потоков время работы занимало 10 сек., а с omp потоками 3 сек. И совсем другое дело, если у вас без потоков 10 часов, а с omp потоками 3 часа. Потому что возиться и ускорять условные 3 сек. уже врятли имеет смысл, а вот ускорять 3 часа вполне разумное желание.

Ибо многопоточность работает НЕ бесплатно и вы просто добавляете работы компьютеру, что бы как можно больше использовать именно простаивающие ресурсы - используете несколько простаивающих ядер, несколько свободных кусков ОЗУ и кусков кэшей процессора, но платите за это доп. нагрузкой на эти ядра/ОЗУ/кэш на операции с потоками в дополнение к полезной работе.

Вопрос - а что ж 3x так мало?

Я бы попробовал выяснить источник проблемы по двум вариантам - либо это сам алгоритм consume_line(), либо это немного не правильное использование omp (синтаксис или логика или еще что-то).

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

• Если время будет примерно одинаково - значит либо функция consume_line() слишком быстра (больше времени уходит на синхронизацию при создании/удалении потоков, чем на полезную работу каждого потока), либо экземпляры функции consume_line() дерутся за другой ресурс (например нехватка ОЗУ, нехватка кэша процессора и т.п.). Тут поможет только пересмотр алгоритма в consume_line().

• Если время на обычных потоках будет близко к ожидаемому (ускорению в 7-8 раз на 8 потоках) - значит что-то не так с использованием omp и нужно разбираться с применением omp.

И еще. Одно дело, если у вас без потоков время работы занимало 10 сек., а с omp потоками 3 сек. И совсем другое дело, если у вас без потоков 10 часов, а с omp потоками 3 часа. Потому что возиться и ускорять условные 3 сек. уже врятли имеет смысл, а вот ускорять 3 часа вполне разумное желание.

Ибо многопоточность работает НЕ бесплатно и вы просто добавляете работы компьютеру, что бы как можно больше использовать именно простаивающие ресурсы - используете несколько простаивающих ядер, несколько свободных кусков ОЗУ и кусков кэшей процессора, но платите за это доп. нагрузкой на эти ядра/ОЗУ/кэш на операции с потоками.

Вопрос - а что ж 3x так мало?

Я бы попробовал выяснить источник проблемы по двум вариантам - либо это сам алгоритм consume_line(), либо это немного не правильное использование omp (синтаксис или логика или еще что-то).

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

• Если время будет примерно одинаково - значит либо функция consume_line() слишком быстра (больше времени уходит на синхронизацию при создании/удалении потоков, чем на полезную работу каждого потока), либо экземпляры функции consume_line() дерутся за другой ресурс (например нехватка ОЗУ, нехватка кэша процессора и т.п.). Тут поможет только пересмотр алгоритма в consume_line().

• Если время на обычных потоках будет близко к ожидаемому (ускорению в 7-8 раз на 8 потоках) - значит что-то не так с использованием omp и нужно разбираться с применением omp.

И еще. Одно дело, если у вас без потоков время работы занимало 10 сек., а с omp потоками 3 сек. И совсем другое дело, если у вас без потоков 10 часов, а с omp потоками 3 часа. Потому что возиться и ускорять условные 3 сек. уже врятли имеет смысл, а вот ускорять 3 часа вполне разумное желание.

Вопрос - а что ж 3x так мало?

Я бы попробовал выяснить источник проблемы по двум вариантам - либо это сам алгоритм consume_line(), либо это немного не правильное использование omp (синтаксис или логика или еще что-то).

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

• Если время будет примерно одинаково - значит либо функция consume_line() слишком быстра (больше времени уходит на синхронизацию при создании/удалении потоков, чем на полезную работу каждого потока), либо экземпляры функции consume_line() дерутся за другой ресурс (например нехватка ОЗУ, нехватка кэша процессора и т.п.). Тут поможет только пересмотр алгоритма в consume_line().

• Если время на обычных потоках будет близко к ожидаемому (ускорению в 7-8 раз на 8 потоках) - значит что-то не так с использованием omp и нужно разбираться с применением omp.