Сравнение производительности гиперпоточности

Я написал проект, в котором используются некоторые базовые функции openssl, такие как RAND_bytes и des_ecb_encrypt.

Мой компьютер имеет i7-2600 (4 ядра и 8 логических процессоров). Когда я запускаю свой проект с 4 потоками, это будет стоить 10 секунд. Когда я запускаю его с 8 потоками, он также стоит 10 секунд.

Я имею в виду, что гиперпоточность не дает мне никакого улучшения производительности. В Linux результат эксперимента такой же.

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

Тем не менее, я попытался написать несколько простых тестов и нашел несколько простых примеров, которые покажут, что гиперпоточность не даст мне очевидного улучшения. К сожалению не нахожу.

Итак, мои вопросы заключаются в том, что есть ли какие-то simple тесты, показывающие, что гиперпоточность не даст мне никакого улучшения производительности.


person Yulong Tian    schedule 19.02.2014    source источник
comment
Производительность при использовании нескольких потоков во многом зависит от того, как вы используете потоки и как вы синхронизируете данные между потоками. Какова производительность при наличии двух потоков? Или просто программа однопоточная?   -  person Some programmer dude    schedule 19.02.2014
comment
@JoachimPileborg У него нет lock и synchronize. Другими словами, каждый поток вычисляет независимо.   -  person Yulong Tian    schedule 19.02.2014
comment
Тем не менее, тестирование с меньшим количеством потоков (особенно без дополнительных потоков) всегда является хорошей идеей. По крайней мере, вы будете знать, в какой момент добавление дополнительных потоков не поможет, и действительно ли вашему алгоритму помогает многопоточность.   -  person Some programmer dude    schedule 19.02.2014


Ответы (4)


Вы можете обнаружить, что гиперпоточность больше помогает в коде, который использует большие объемы памяти, так что процессор регулярно блокируется при выборке из памяти.

По моему опыту, довольно сложно найти «простой код», демонстрирующий преимущества гиперпоточности. Это, как правило, более сложные примеры, которые показывают преимущество. Тем не менее, выгода, скорее всего, не будет в 2 раза выше, чем при «отсутствии гиперпоточности». Рассчитывайте на улучшение на 20-30%.

person Mats Petersson    schedule 19.02.2014

Гиперпоточность использует тот факт, что у ЦП много компонентов, и когда используется один из них, когда нет гиперпоточности, остальные просто простаивают. Вы можете попробовать написать два типа потоков, один из которых выполняет целочисленные вычисления (который, как мы надеемся, будет использовать ALU), а другой выполняет арифметику с плавающей запятой (который, как мы надеемся, будет использовать FPU).

Я не пробовал это сам, но кажется, что в таком сценарии гиперпоточность должна улучшить производительность.

Чтобы показать обратное, вы можете использовать только один тип потоков (либо потоки, выполняющие только целочисленные операции, либо потоки, выполняющие только операции с плавающей запятой).

Также может случиться так, что ваш тест ошибочен, но чтобы узнать, так ли это, нам потребуется больше информации об этом тесте.

person selalerer    schedule 19.02.2014
comment
Гиперпоточность более применима, когда поток инструкций полностью остановлен, например, из-за доступа к памяти, неправильного предсказания ветвления или операции деления. Либо целочисленные операции, либо операции FPU сами по себе, вероятно, занимают диспетчер инструкций настолько, что гиперпоточность никогда не происходит. - person Potatoswatter; 19.02.2014
comment
@selalerer Мой проект очень прост. Чтобы вычислить 1000 точек, каждый поток должен вычислить 250 точек, когда есть 4 потока. С 8 потоками каждый должен вычислить 125 точек. (Что можно назвать SIMD?) - person Yulong Tian; 19.02.2014

Я написал проект, в котором используются некоторые основные функции в openssl, такие как RAND_bytes и des_ecb_encrypt... Мой компьютер имеет i7-2600 (4 ядра и 8 логических процессоров). Когда я запускаю свой проект с 4 потоками, это будет стоить 10 секунд. Когда я запускаю его с 8 потоками, он также стоит 10 секунд.

При использовании RDRAND (что в данном случае будет делать RAND_bytes) шина использует ограничивающий фактор. Вы должны достичь пиковой скорости около 800 МБ/с. Неважно, сколько у вас потоков — шина не может передавать данные достаточно быстро. См. Пересмотр инструкции Intel rdrand.

Если вы использовали AES, вы могли бы увидеть лучшее ускорение по сравнению с наблюдениями DES/3DES. Ваш Ivy Bridge имеет AES-NI, и он может достигать почти 1,3 цикла/байт, и это должно быть примерно вдвое или втрое AES является программным обеспечением. Чтобы убедиться, что вы используете инструкции AES-NI, вы должны использовать интерфейсы EVP_*.


Я нашел здесь, говорит мне, что гиперпоточность не дает мне улучшения в некоторых ситуациях. Кроме того, я нашел здесь, что дает мне некоторые интуитивные результаты.

Я думаю, что @selalerer и @Mats Petersson ответили на ваш вопрос. Проблема не масштабируется линейно, и вы столкнетесь с максимальным ускорением. Intel заявляет, что их около 30%.

В новейшей архитектуре Intel предпочтение отдается внеочередному выполнению, а не гиперпотоковому выполнению, поскольку оно должно быть более эффективным. Прочтите о процессорных ядрах Silvermont.

Но если вы хотите формального глубокого погружения, прочтите книгу по вычислительной технике. Вот книга, которую мы использовали, когда я изучал ее в колледже: Computer Organization и Дизайн (вероятно, сейчас он немного устарел).


Тем не менее, я попытался написать несколько простых тестов и нашел несколько простых примеров, которые покажут, что гиперпоточность не даст мне очевидного улучшения.

OpenSSL также имеет приложение для бенчмаркинга. См. исходный код в <openssl source>/apps/speed.c.

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

person jww    schedule 19.02.2014

Ниже приведены подробности и результаты моих тестов MP для Linux и Windows, которые могут вести себя по-разному. Не так много HT, но тесты Linux включают Atom (1 ядро ​​​​2 потока), а Windows имеет результаты Core i7 (4 + 4).

http://www.roylongbottom.org.uk/linux%20multithreading%20benchmarks.htm

http://www.roylongbottom.org.uk/quad%20core%208%20thread.htm

Выбирайте сами, в зависимости от того, что вы хотите доказать, обеспечивает ли HT лучшую или худшую производительность. Ниже приведены результаты RandMem на i7 (в этом тесте кажется, что Linux лучше). Например, для i7 вам также необходимо учитывать Turbo Boost, который может быть ниже при использовании нескольких потоков.

             CPUs          MBytes Per Second Using Threads        Gain At Threads
             /HTs         1       2       4       6       8     2     4     6     8
 Serial RD
 Core i7     4/8 L1   11458   22661   37039   43717   46374   2.0   3.2   3.8   4.0
 930             L2   10380   20832   32853   41711   42839   2.0   3.2   4.0   4.1
 #### MHz        L3    8828   17743   29610   38414   40330   2.0   3.4   4.4   4.6
 Win 764        RAM    4266    8712   17347   24946   25589   2.0   4.1   5.8   6.0

 Serial RW
 Core i7     4/8 L1   15282   13724   16240   16209   18379   0.9   1.1   1.1   1.2
 930             L2   12223   18216   25326   28104   27047   1.5   2.1   2.3   2.2
 #### MHz        L3   10234   19266   21931   24450   26351   1.9   2.1   2.4   2.6
 Win 764        RAM    4533    7656   13876   14543   13390   1.7   3.1   3.2   3.0

 Random RD
 Core i7     4/8 L1   11266   22548   38174   45592   47141   2.0   3.4   4.0   4.2
 930             L2    6233   12463   20059   24986   25667   2.0   3.2   4.0   4.1
 #### MHz        L3    3499    6915    9211   10002    9531   2.0   2.6   2.9   2.7
 Win 764        RAM     459     909    1241    1398    1364   2.0   2.7   3.0   3.0

 Random RW
 Core i7     4/8 L1   14375    3027    2780    2901    3297   0.2   0.2   0.2   0.2
 930             L2    5887    4555    6117    6693    7281   0.8   1.0   1.1   1.2
 #### MHz        L3    3104    4604    4721    5047    4933   1.5   1.5   1.6   1.6
 Win 764        RAM     428     860     899     948    1026   2.0   2.1   2.2   2.4

 #### 2.8 GHz running at up to 3.06 GHz via Turbo Boost, dual channel 1066 MHz DDR3 RAM 

Затем тест MP Whetstone, который показывает реальный прирост

                      MWIPS  MFLOP  MFLOP  MFLOP   COS    EXP   FIXPT   IF    EQUAL
CPU              MHz            1      2      3    MOPS   MOPS   MOPS   MOPS   MOPS

Core i7 1 Thrd  ####   3115   1065    886    738   79.3   39.7   2447   2936   1154

Core i7 Win7    ####  21690   8676   7621   5844    531    291  16643  12027   5034
Quad Core Thread 1            1091   1027    728   66.4   36.5   2050   1501    629
Plus HT   Thread 2            1089   1037    742   66.0   36.5   2090   1507    630
          Thread 3            1090    946    742   66.8   36.5   2069   1534    631
          Thread 4            1092   1037    727   66.6   36.6   2031   1501    630
          Thread 5            1042    959    736   66.4   36.5   1912   1483    630
          Thread 6            1091    874    723   66.6   36.1   2049   1507    629
          Thread 7            1090    867    725   65.6   36.3   2094   1516    631
          Thread 8            1091    874    722   66.3   36.3   2350   1476    624

Gain %                  696    815    860    792    670    733    680    410    436
person Roy Longbottom    schedule 20.02.2014