Я разработал высокопроизводительную процедуру факторизации Холецкого, которая должна иметь пиковую производительность около 10,5 Гфлопс на одном процессоре (без гиперпоточности). Но есть один феномен, которого я не понимаю, когда тестирую его работоспособность. В своем эксперименте я измерил производительность при увеличении размерности матрицы N от 250 до 10000.
- В моем алгоритме я применил кэширование (с настроенным коэффициентом блокировки), и доступ к данным всегда осуществляется с единичным шагом во время вычислений, поэтому производительность кеша оптимальна; Устранены проблемы TLB и пейджинга;
- У меня 8 ГБ доступной оперативной памяти, а максимальный объем памяти во время эксперимента составляет менее 800 МБ, поэтому подкачки не происходит;
- Во время эксперимента ни один ресурсоемкий процесс, такой как веб-браузер, не запускается одновременно. Только какой-то действительно дешевый фоновый процесс записывает частоту процессора, а также данные о температуре процессора каждые 2 секунды.
Я ожидал, что производительность (в GFLOP) должна поддерживаться на уровне 10,5 для любого N, которое я тестирую. Но в середине эксперимента наблюдается значительное падение производительности, как показано на первом рисунке.
Частота и температура процессора показаны на 2-м и 3-м рисунке. Эксперимент заканчивается через 400 секунд. Когда начался эксперимент, температура составляла 51 градус, а при загрузке процессора быстро поднималась до 72 градусов. После этого он медленно вырос до самого высокого уровня в 78 градусов. Частота процессора в основном стабильная, при повышении температуры она не падала.
Итак, мой вопрос:
- если частота процессора не упала, почему страдает производительность?
- как именно температура влияет на производительность процессора? Неужели увеличение с 72 до 78 градусов действительно ухудшает положение?
Информация о процессоре
System: Ubuntu 14.04 LTS
Laptop model: Lenovo-YOGA-3-Pro-1370
Processor: Intel Core M-5Y71 CPU @ 1.20 GHz * 2
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0,1
Off-line CPU(s) list: 2,3
Thread(s) per core: 1
Core(s) per socket: 2
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 61
Stepping: 4
CPU MHz: 1474.484
BogoMIPS: 2799.91
Virtualisation: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 4096K
NUMA node0 CPU(s): 0,1
CPU 0, 1
driver: intel_pstate
CPUs which run at the same hardware frequency: 0, 1
CPUs which need to have their frequency coordinated by software: 0, 1
maximum transition latency: 0.97 ms.
hardware limits: 500 MHz - 2.90 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 500 MHz and 2.90 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 1.40 GHz.
boost state support:
Supported: yes
Active: yes
обновление 1 (контрольный эксперимент)
В моем первоначальном эксперименте ЦП постоянно занят работой от N = 250 до N = 10000. Многие люди (в первую очередь те, кто видел этот пост до повторного редактирования) подозревали, что перегрев ЦП является основной причиной снижения производительности. Затем я вернулся и установил lm-sensors
пакет linux для отслеживания такой информации, и действительно, температура процессора повысилась.
Но для полноты картины я провел еще один контрольный эксперимент. На этот раз я даю процессору время охлаждения между каждым N. Это достигается за счет того, что программа делает паузу на несколько секунд в начале итерации цикла через N.
- для N от 250 до 2500 время охлаждения составляет 5 с;
- для N от 2750 до 5000 время охлаждения составляет 20 с;
- для N от 5250 до 7500 время охлаждения составляет 40 с;
- наконец, для N между 7750 и 10000 время охлаждения составляет 60 с.
Обратите внимание, что время охлаждения намного больше, чем время, затрачиваемое на вычисления. Для N = 10000 требуется всего 30 секунд для факторизации Холецкого при максимальной производительности, но я прошу время охлаждения 60 секунд.
Это, безусловно, очень неинтересный параметр для высокопроизводительных вычислений: мы хотим, чтобы наша машина работала все время с максимальной производительностью, пока не будет завершена очень большая задача. Так что такая остановка не имеет смысла. Но это помогает лучше узнать влияние температуры на производительность.
На этот раз мы видим, что пиковая производительность достигается для всех N, как и утверждает теория! Периодическая характеристика частоты и температуры процессора является результатом охлаждения и ускорения. Температура все еще имеет тенденцию к увеличению просто потому, что с увеличением N увеличивается рабочая нагрузка. Это также оправдывает большее время охлаждения для достаточного охлаждения, как это сделал я.
Достижение максимальной производительности, похоже, исключает все эффекты, кроме температуры. Но это действительно раздражает. В основном это говорит о том, что компьютер устанет в HPC, поэтому мы не можем получить ожидаемого прироста производительности. Тогда в чем смысл разработки алгоритма HPC?
Хорошо, вот новый набор графиков:
Не знаю, почему мне не удалось загрузить 6-ю цифру. ТАК просто не позволяет мне отправить правку при добавлении 6-го числа. Прошу прощения, я не могу приложить данные о частоте процессора.
обновление 2 (как я измеряю частоту и температуру процессора)
Спасибо Zboson за добавление тега x86. Для измерения я использовал следующие bash
команды:
while true
do
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq >> cpu0_freq.txt ## parameter "freq0"
cat sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq >> cpu1_freq.txt ## parameter "freq1"
sensors | grep "Core 0" >> cpu0_temp.txt ## parameter "temp0"
sensors | grep "Core 1" >> cpu1_temp.txt ## parameter "temp1"
sleep 2
done
Поскольку я не привязал вычисления к одному ядру, операционная система будет поочередно использовать два разных ядра. Имеет смысл взять
freq[i] <- max (freq0[i], freq1[i])
temp[i] <- max (temp0[i], temp1[i])
как общее измерение.
monitor laptop hardware temperatures
- например, openhardwaremonitor.org, также: cpuid.com/softwares/hwmonitor.html. Найдите свой конкретный ноутбук. imo, я подозреваю, что аппаратные ограничения, так как длительная работа процессора без нагрузки приведет к нагрузке на оборудование и будет «дросселировать». Возможно, стоит повысить приоритет матричных задач. Имейте в виду - я действительно предполагаю - вам нужно собрать некоторые данные. - person Ryan Vincent   schedule 01.04.2016grep MHz /proc/cpuinfo
, но/sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
OP, вероятно, хорош, если он знает о турбо. В противном случае вам, вероятно, потребуется использовать.../cpuinfo_cur_freq
(для чтения которого требуется root, что подразумевает, что это может быть более дорогостоящая операция, чем чтение текущего решения регулятора масштабирования. Это будет иметь смысл, если он запрашивает оборудование о турбо-режиме, но текущая частота/proc/cpuinfo
может быть в турбо-диапазоне.) - person Peter Cordes   schedule 03.04.2016