Система на Ryzen Threadripper 3970X – тест производительности и потребления. Сравнение трех поколений Ryzen

Признаюсь честно, довольно долго сознательно и бессознательно затягивал с выходом этой части материала. И вроде тесты все еще до НГ сделаны, и пазл «как писать» в голове сложился, но как говорится - «материал не идет». Долго не мог понять почему, но причина, как это обычно бывает, лежит на поверхности. Дело в том, что материал получается не классический, не привычный для читателя и как следствие малополезный — тесты в каком-то там Linux, в каких-то никому не понятных задачах. Поэтому, постараюсь быть максимально информативным и пояснять что, как и для чего мы будем делать.

Разумеется что-то привычное тоже будет. Например, мы сравним производительность трех поколений Ryzen, измерим сколько потребляет система на Threadripper 3970X из розетки, и даже немного протестируем игру. В общем погнали.

Начну с краткого описания тестовых систем. Поскольку я не претендую на академичность и не провожу тесты «по науке», то детально описывать все системы не вижу смысла. Сравнение будет по большей части оценочное. Процессоры у всех систем будут в стоке — т.е никакого разгона использовать не будем, даже PBO. За исключением памяти.

В тех случаях, где существенно влияние SSD дисков, тесты будем делать таким образом, чтобы это влияние исключить или минимизировать.

Система на Threadripper 3970X(подробное описание есть в моем профиле):

Память: 64Гб Corsair Vengeance LED, 3000МГц, работает на 2733МГц

Системный SSD: Samsung EVO 960

Материнская плата: Gigabyte TRX40 AORUS XTREME

Видеокарта: ASUS GeForce RTX 2080Ti ROG STRIX GAMING OC

 

Система на Ryzen 1800x:

Память 16Гб GOODRAM IRDM X — 2666МГц, работает на 2666МГц

Системный SSD: Corsair Neutron GTX 240ГБ

Материнская плата: ASRock B450 Pro4

Видеокарта: не установлена.

   

Система на Ryzen 2700x:

Память: Сборная солянка из двух HyperX Fury 4Гб и двух зеленых модулей Samsung 4Гб. Все модули работают на 2400МГц

Системный SSD: AMD Radeon R3 120Гб

Материнская плата: Gigabyte AX370-Gaming K7

Видеокарта: ASUS GeForce RTX 2080Ti ROG STRIX GAMING OC

Частоты памяти указаны максимальные стабильно работающие месяцами, которые удалось достичь. Не во всех тестах будут сравниваться все три системы.

В моих задачах часто приходится обрабатывать большие наборы текстовых данных, в частности сортировать и удалять дубликаты строк из файлов. Вот с этой задачи и начнем наше тестирование.

Чтобы исключить влияние дисков, все тесты будем делать в памяти. Временные файлы тоже будем хранить в памяти - /dev/shm/. Поэтому возьмем файл небольшого размера, чтобы можно было сравнить разные системы. В файле не размеченный текст примерно такого вида:

«divine savior aaron's kiss series book two by kathi s barton world castle publishing httpwww

worldcastlepublishingcom this is a work of fiction

names characters places and incidents are products of the author's imagination or are used fictitiously and are not to be construed as real

any resemblance to actual events locations organizations or person living or dead is entirely coincidental»

Файл: x01part1-text-dataset-for-test.txt

Количество строк в файле посчитаем командой «wc» с ключом -l:

wc -l x01part1-text-dataset-for-test.txt

38735813 x01part1-text-dataset-for-test.txt

Размер:

du -hs x01part1-text-dataset-for-test.txt

2.3G x01part1-text-dataset-for-test.txt

Для 16-ти поточных процессоров тест проводился в 4, 8, 16 потоков.

Для Threadripper в 4, 8, 16, 32, 64 потока.

В общем виде команда выглядит так:

time cat x01part1-text-dataset-for-test.txt | LC_ALL=C sort -u --parallel=16 -S 3G -T /dev/shm > /dev/null

Вот что делает эта мудреная строчка:

Команда «time» - замеряет время выполнения всей конструкции;

«cat x01part1-text-dataset-for-test.txt» - сливает файл построчно на стандартный вывод (экран);

«|» - pipe — он же конвейер, «передает» все данные команде sort;

«LC_ALL=C» - временно устанавливает упрощенную локаль, так sort работает намного быстрее, сортируя чуток хуже;

Параметры sort:

ключ «-u» - означает что нужно удалять дубликаты;

«--parallel=» - устанавливает в какое количество потоков производить сортировку;

«-S 3G» - устанавливает буфер в памяти в 3Гб;

«-T» - задает каталог для временных файлов. В нашем случае это оперативная память.

«>» - указываем куда направить вывод команды sort. В нашем случае, чтобы не использовать ни память ни диски выводим все в /dev/null.

Например, для Ryzen 1800x получим примерно такой вывод:

time cat x01part1-text-dataset-for-test.txt | LC_ALL=C sort -u --parallel=16 -S 3G -T /dev/shm > /dev/null

real 0m20.801s

user 1m10.018s

sys 0m3.789s

Нас интересует параметр «real» - условно сколько всего времени заняло выполнение всех команд в строке. Время в секундах.

Вот такие результаты у меня получились:

   

Прошу обратить внимание, что на графике ось Y начинается не от нуля, а от 15 секунд. Так разница во времени видна лучше.

Видно, что время сортировки достаточно быстро снижается с увеличением числа физических ядер. Но этот "ВАУ" эффект, как видно из «столбика» для Threadripper, сходит на нет после 16 ядер. Т.е 32 ядра уже заметно не сокращают время сортировки. В чем причина можно только гадать. Возможно, что утилиту sort просто не оптимизировали для большего количества ядер, возможно ограничивает что-то еще, например скорость работы с памятью.

Также, мы видим как AMD улучшала каждое поколение процессоров. Ryzen 2700x быстрее 1800x примерно на 5%. Threadripper 3970x быстрее 2700x примерно на 4%, при одинаковом количестве ядер конечно же. Улучшения хоть и не значительные, но они есть. Самое время вспомнить про пресловутые 5% за поколение. :)

Архивация 

Для тестов используем многопоточный архиватор pigz - полный аналог gzip, только с многопотоком. В мире unix/linux архивы gzip по-прежнему распространенное явление. Всякие RAR, ZIP, 7Z идут в топку. У них большие проблемы с многопотоком в Linux. :)

Файл будем использовать тот же, что и в предыдущих тестах — x01part1-text-dataset-for-test.txt. Все тесты делаем также в памяти, так как тест дисков не входит в наши задачи.

Для теста используем простой скрипт:

for i in `seq 1 16`; do time pigz -p $i -k x01part1-text-dataset-for-test.txt && rm x01part1-text-dataset-for-test.txt.gz; done

Что делает этот набор команд:

Тело цикла «for i in `seq 1 16`; do» выполняется от 1 до максимального количества потоков.

Внутри цикла:

выводим на терминал количество потоков с которым сжимаем: echo "Количество потоков: $i";

«time» - замеряем время;

сжимаем файл с определенным количеством потоков «$i» - «pigz -p $i -k x01part1-text-dataset-for-test.txt». Ключ -k означает сохранение оригинального файла.

«&&» - условие. Если команда завершилась корректно, то выполним следующую.

«rm x01part1-text-dataset-for-test.txt.gz» - удаляем архив.

«done» - завершаем цикл.

Для Threadripper'а количество потоков сделаем 64, пусть потеет.

Вывод команды будет примерно такого вида:

Количество потоков: 1

real 1m54.367s

user 1m53.911s

sys 0m0.425s

Количество потоков: 2

real 0m58.683s

user 1m59.683s

sys 0m1.472s

Количество потоков: 3

real 0m39.615s

user 2m0.487s

sys 0m1.242s

Далее просто соберем все данные в файл и построим графики.

   

Посмотрев на графики я был как-то не впечатлён. 2700x и Threadripper хоть и опережают Ryzen 1800x, но между собой равны вплоть до 8 ядер. Далее Threadripper берет и просто убивает всех грубой силой. Прирост от ядер конечно впечатляет. Но так и запишем: на ядро в этой конкретной задаче равен 2700x. Попробуем выковырять еще немного информации из собранных данных.

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

Ryzen 1800x:

1 ядро — 147,15 сек, 8 ядер — 20 сек, коэффициент масштабирования получается 7,36 — почти линейно.

Ryzen 2700x:

1 ядро — 114,36 сек, 8 ядер — 15,55 сек, коэффициент масштабирования получается 7,35 — чуть хуже, но почти линейно.

Threadripper 3970x:

1 ядро — 122,34 сек, 32 ядра — 3,98 сек, коэффициент масштабирования получается 30,74 — как-то не совсем линейно. Посчитаем для восьми ядер: 1 ядро — 122,34 сек, 8 ядер — 15,29 сек, коэффициент масштабирования получается 8,001. Ух ты! Даже немного лучше чем просто линейно. Выходит что если ядер много, то задействуя меньшее их количество, можно получить 100% линейное масштабирование.

   

Разбивка текста на энграммы. 

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

Много приходится работать с текстами. Частая задача - выделение из текста n-грамм. Условно n-граммы - это комбинации слов. Бывают разные - два, три, пять, десять слов. Я выполняю такие задачи на Python с помощью инструментария NLTK - Natural Language Toolkit.

Поскольку задача не самая простая и обычно занимает многие сутки, то мы немного упростим себе жизнь, откусив от нашего файла "x01part1-text-dataset-for-test.txt" первые 8 000 000 строк

командой:

head -n 8000000 x01part1-text-dataset-for-test.txt > 8000000-text-dataset-for-test.txt

Размер файла:

du -hs 8000000-text-dataset-for-test.txt

483M 8000000-text-dataset-for-test.txt

Как думаете, какой объем текста в Мбайт или Кбайт, будет после разбивки на энграммы? Напишите свой вариант в комментариях.

Далее разобьем наш файл с предложениями на количество кусков равное количеству физических ядер процессора.

Для 2700X и 1800X - это по 8 кусков, для Threadripper 3970X - 32 куска. Сделаем это при помощи команды split:

Для 8 ядер:

split --additional-suffix=text-dataset-for-test.txt -l 1000000 -a 4 --numeric-suffixes=0001 8000000-text-dataset-for-test.txt

Для 32 ядер:

split --additional-suffix=text-dataset-for-test.txt -l 250000 -a 4 --numeric-suffixes=0001 8000000-text-dataset-for-test.txt

При разбивке текстовых файлов с помощью split есть один важный момент — текстовый файл надо обязательно разбивать построчно, используя ключ -l. Если будете разбивать побайтно, используя ключ -n, то получите куски неполного текста в файлах.

Далее запустим ровно по количеству физических ядер копии вот этого простенького скрипта - extract-ngrams.py:

#!/usr/bin/python
#-*- coding: utf-8 -*-
import time
start_time = time.time()
import random
import string
import os
import sys
import nltk
from nltk.util import ngrams
from nltk.tokenize import sent_tokenize, word_tokenize

filename = ''.join(random.choice(string.digits) for i in range(8))
file = open(("time-test-" + filename + ".txt"), 'w')
tmpfile = open(("tmp-file-" + filename + ".txt"), 'w')

def extract_ngrams(data, num):
    n_grams = ngrams(nltk.word_tokenize(data), num)
    return [ ' '.join(grams) for grams in n_grams]

for stringin in sys.stdin:
        data = stringin.strip().decode('utf-8', errors='replace').encode('ascii', errors='replace')

        phrases = sent_tokenize(data)
        for grams in range(0,len(extract_ngrams(data, 4))):
                twogram = extract_ngrams(data, 2)[grams]
                threegram = extract_ngrams(data, 3)[grams]
                tmpfile.write(twogram + "\n")
                tmpfile.write(threegram + "\n")

file.write("%f seconds" % (time.time() - start_time) + "\n")
file.close()   
tmpfile.close()

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

В общем виде будет примерно такая конструкция:

cat <кусок файла> | ./extract-ngrams.py - запускать будем одновременно по копии для каждого физического ядра. Сделать это можно разными способами.

Например, создав bash скрипт вида:

cat <кусок 1> | ./extract-ngrams.py &

cat <кусок ...> | ./extract-ngrams.py &

cat <кусок N> | ./extract-ngrams.py &

Я запускал через screen. Там конструкция посложнее, но делает то же самое. Просто мне так удобней - иногда нужно контролировать процесс выполнения скриптов. В общем, использовал свои наработки.

Поскольку время выполнения каждой копии скрипта не строго детерминировано, то для более наглядных результатов отсортируем время по возрастанию.

Поскольку я делал замеры для 3-х процессоров: Ryzen 1800x, Ryzen 2700x и Threadripper 3970x, то есть одна маленькая проблема. Из-за того, что размер кусков разный, то результаты 8-ядерных процессоров никак не соотносятся с 32-ядерным. Для того чтобы можно было соотнести производительность всех процессоров, для начала прогоним тест на 8 ядрах и для Threadripper 3970x, таким образом мы сможем соотнести производительность разных поколений процессоров.

Вот такой красивый график получился:

Для задачи «раскладываем текст на энграммы» ускорение за три поколения более чем значительное.

Ryzen 2700x в среднем на 9% быстрее, чем Ryzen 1800x. Threadripper 3970x в среднем быстрее чем 2700x на впечатляющие 24%.

А вот так все результаты выглядят на общем графике, где Threadripper 3970x показывает всю свою мощь:

Иными словами, то что раньше на моем Ryzen 2700x считалось час, то теперь я выполню ту же задачу за 13 минут. Ускорение примерно в 4,7 раза.

Вряд ли обычный пользователь overclockers.ru использует свой домашний компьютер для извлечения энграмм из текста. Верно? Да и я тоже не только энграммы ковыряю, иногда и поигрываю. Поэтому мне тоже было интересно, что же там в играх. :)

Сравнить получилось только Ryzen 2700x и Threadripper 3970x, да и то в одном тесте, который меня не то чтобы разочаровал, а скорее озадачил.

Linux система всеядная, и если у вас все установлено правильно, то можно просто вставить старый диск в новую систему и спокойно все запустить. Что я и сделал. Для интереса прогнал тест Superposition Benchmark v1.1 в разных версиях Ubuntu.

В Ubuntu 16.04 Ryzen 2700x и Threadripper 3970x выступили довольно близко.

Результат 2700x — 10150 попугаев:

Результат Threadripper 3970x — 10118 попугаев:

Разница 0,3% - это даже меньше чем погрешность.

А вот результат в Ubuntu 18.04 с новыми драйверами Nvidia меня озадачил — он ниже на 1,3%. Хотя ожидал, что новое будет лучше старого. Результат повторяется постоянно — это означает, что не какой-то случайный всплеск.

В первой Ларке протестировал только Threadripper. Поэтому не знаю хорошие результаты или нет. Настройки и результаты встроенного теста на снимках экрана ниже.

Температуры и потребление электроэнергии. 

В выключенном состоянии компьютер потребляет от сети около 8Вт.

Во включенном состоянии с загруженным Linux система кушает примерно 170Вт.

Можно скинуть 20-30Вт если переключить управление частотами процессора из состояния «performance» в состояние «ondemand». По умолчанию в Ubuntu используется «ondemand». Система работает чуть медленней, потребляя при этом 130-150Вт. Я использую «performance», поэтому без нагрузки система кушает немного больше. Состояния «performance» и «ondemand» - можно в первом приближении считать аналогами планов производительности в Windows.

Далее потребление в нагрузке.

Процессор нагружал с помощью Prime95 v29.8,build 6 в 64 потока, Smallest FFTs. 

Максимальное потребление, которое удалось сфотографировать — 507Вт. Ловил специально. 

Обычно же потребление гуляет в районе 430 — 450Вт.

Значения температур я снимал в двух вариантах корпуса: 

Вариант «классик» — процессор сверху, а снизу его подогревает видеокарта;

Вариант «перевертыш» - процессор снизу, обдувается самым холодным воздухом. Процессор сам немного подогревает видеокарту. 

Для нагрузки процессора использовал Prime95 v29.8,build 6 в 64 потока, Smallest FFTs, для нагрузки видеокарты GPU_BURN - http://wili.cc/blog/gpu-burn.html

Все кочегарилось по 20 минут, потом снимал скрины. Температура входящего в корпус воздуха была в диапазоне 25-26 гр. С. 

Для получения максимального потребления всей системы на видеокарте выкручивал power limit до 325Вт. 

Максимальное потребление всей системы, при такой нагрузке, составляло многим не привычные 763Вт.

В итоге, если включить PBO или немного подразогнать, то можно еще сотню-полторы Ватт накинуть. В общем, когда я проводил все свои расчеты и измерения на 700Вт — получается, не так уж сильно и ошибся - всего на 8,5%. 

Ладно, пора переходить к температурам. Нагружаем только процессор. Напомню, что все разгоны выключены. 

И так, вариант «классик»:

Для Windows юзеров немного не привычно видеть такие мудреные скриншоты.

Если смотреть слева направо: 

1. Показания мониторинга, который поддерживался на момент запуска тестов. K10temp — температура процессора. На плате два чипа мониторинга. Здесь видно только один чип. Поэтому о скорости процессорного кулера и одного из корпусных можно только гадать. Сейчас конечно поддержку второго чипа настроил, но переснимать тесты уже не буду. 

2. Так выглядит запущенный Prime95 в Linux

3. Частоты процессорных ядер. С показаниями в Windows они никак не соотносятся. Утилита эти частоты вычисляет. Могу только сказать, что в среднем, частоты показывает ниже - примерно на 150-200Мгц относительно Windows.

4. Параметры видеокарты — вывод команды nvidia-smi.

5. Небольшой пруфчик железа. Тут кто-то писал, что никакого процессора у меня нет. :) 

Уважаемы хейтеры, процессор есть! Поскольку с анонсом Threadripper 3990x мой уже превратился в тыкву, то начал откладывать деньги со школьных завтраков на 3990x. :)

Ладно, шутки в сторону. Что мы видим? 

А видим мы вполне хорошую и лично мной ожидаемую ситуацию: грамотно спланированное, рассчитанное и испытанное воздушное охлаждение и корпус вполне справляются с охлаждением процессора без разгона. Напомню, что предельная температура для новых Threadripper-ов — 95гр. С, далее идет сброс частот. У меня в закрытом корпусе получилось 82,2 гр. С. Есть небольшой запас в 10-12гр. В принципе, на этом статью можно было бы закончить, так как такая нагрузка — это 90% моих потребностей. Но иногда бывает так, что процессор и видеокарта нагружены одновременно и под завязку. Поэтому проверим и эту ситуацию. 

Здесь ситуация существенно менее радужная. Видеокарта чувствует себя прекрасно, а процессор греется до 87,5 гр. С. Это конечно допустимо, но уже высоковато. 

Решил «для порядку» проверить в Windows 10 (LTSB). Нагрузка только на процессор. 

Как видно из скриншотов, Prime95 для Windows прогревает процессор немного лучше. Но Hwinfo показывает что тротлинга нет. Но эти показания нельзя рассматривать как опорные, так как я не большой специалист по настройке Windows. Драйвера не ставил, планы питания не ставил, всех тонкостей настройки не знаю. Просто «винда» с обновлениями, поставленная для однократного запуска Prime95. 

В общем, температуры меня в принципе устраивали, жить можно. Но хотелось проверить какие температуры будут в варианте «перевертыш». Для этого пришлось разобрать всю систему, и собрать заново. Первый раз собирал как положено, так как не было уверенности, что буду разбирать. 

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

Вариант "перевертыш": 

Если нагружать только процессор, то температура снизилась не значительно. Была 82,2 гр. С, стала 82 гр. С. Не велик выигрыш. 

Но все меняется, когда в системе одновременно нагружены видеокарта и процессор. 

Все как и хотел, даже лучше. 

Температура процессора вместо 87,5 гр. С, стала всего 84. Как видно видеокарта почти не повлияла на температуру процессора. Да и сама видеокарта нагрелась всего на 2 градуса выше. 

При этом, кулер на процессоре стал работать намного тише. Впрочем, он по моему во всех вариантах не выходил на максимум, так как в биосе максимум для него был прописан на 90гр. Но система в варианте «классик» была заметно более шумная. 

Выводы, основанные в том числе, и на месячном опыте использования:

1. Вентилятор на Silver Arrow TR4 хоть и мощный, но на 2500 оборотов довольно шумный. Поэтому я заменил его на пару тихоходных. Но это совсем другая история. Расскажу отдельно. Тесты в статье конечно же проводил с родным вентилятором. 

2. Как я и ожидал, грамотно спланированное воздушное охлаждение вполне справляется с охлаждением Threadripper 3970x без разгона.

3. Удалось обойтись всего 4-мя корпусными вентиляторами.

4. Мне все нравится, я доволен. :) Но вот память смогла заработать только на 2733МГц. А ведь AMD нам рассказывала, что они улучшили работу с памятью. В общем, жду пару релизов биоса, если не исправят, буду менять на 128Гб UDIMM. 64Гб все равно местами уже мало. 

5. Шум. Каких-то специальных замеров не проводил. Тут только субъективно. Для себя оцениваю шум по критериям: напрягает / не напрягает / не слышу. В случае с родным вентилятором на процессоре — напрягает. В случае с двумя тихоходными — не напрягает. Слышу тихий шелест. Что до пресловутых скачков температуры — тут ничего внятного сказать не могу, так как компьютер постоянно нагружен. Скачки иногда бывают, но поскольку система получилась довольно тихая, то изменения скорости вращения вентиляторов не раздражают.

В наушниках с шумоподавлением шум не слышу. :)

6. Если будете собирать аналогичную систему и вам лень что-то считать, испытывать и дорабатывать, а также у вас жаркий регион, то я бы рекомендовал обратить внимание на жидкостное охлаждение. Имея риск протечки и выхода всей системы из строя, вы снизите температуру градусов на 10. Возможно снизите и шум. Но в любом случае, системы на таких мощных процессорах уже не будут абсолютно тихими. Возможно через некоторое время появятся новые воздушные системы охлаждения, специально заточенные под новые Threadripper-ы. 

7. 64Гб памяти может не хватить. Во всяком случае, пока у меня было мало ядер, я за год всего пару раз столкнулся с нехваткой памяти. А при 32-х ядрах за месяц уже 4 раза пришлось оптимизировать свои программы. Поэтому, могу порекомендовать исходить из минимума 1,5Гб на поток - 96Гб. Разумным будет 2Гб на поток — 128Гб. Впрочем, все будет зависеть от ваших задач. В «тытрубке» видел ролики чушков, которые разгоняют по 16Гб памяти на Threadripper-ах, и очень гордятся. Но, как по мне, такая конфигурация абсолютно не юзабельна для таких процессоров. 

8. Кто-то в комментариях говорил, что есть проблемы с установкой Linux на NVMe диски. Ответственно заявляю: никаких проблем c установкой Linux на NVMe диски нет! Речь о Kubuntu 18.04. Однако есть небольшая проблема с установкой — дефолтное ядро в дистрибутиве не грузится. Для установки надо загрузчику в параметрах ядра указать «mce=off»

Сейчас использую с ядром 5.3.18. В целом все что нужно работает. За исключением звука по SPDIF - а вот он то мне и нужен. Но обещают только в ядре 5.5. Поэтому пока использую Bluetooth. С аналоговым звуком никаких проблем нет. Все работает — работают обе звуковые карты. Была проблема с одними «очень экзотическими» bluetooth наушниками — с первого раза подключались как «моно гарнитура», со второго раза все нормально. Проблема решается установкой последней версии blues. Я собирал из исходников, но говорят есть и в пакетах. 

9. Uptime (время работы без перезагрузки). Пока ничего особенного не скажу, так как система в процессе настройки и тестов, поэтому была необходимость перезагружать. Пока рекорд — неделя при полной загрузке всех физических ядер — load average 33-38. В целом, разумная рекомендация по параметру load average для Linux — это <количество физических ядер> умноженное на 1,25. Или <количество физических ядер> плюс 25%. Можно грузить и выше, но это уже относится к оптимизированному коду, например, визуализаторы (рендеринг по русски). 

10. Нагрев VRM в рабочих и максимальных нагрузках не превышает 60гр. Нагрев чипсета также не превышает 60гр. Вентиляторы не крутятся.

За кадром. 

Дополнительно сделал тесты в Blender в phoronix test suite. Температуры не снимал, но по памяти — иногда на пару градусов может быт выше, чем в Prime95. 

Сравнить можно по ссылке.

Мои показатели получились такие: 

Сцена BMW27 — 45,11 сек. 

Сцена Classroom — 114,99 сек.

Сцена Pabellon Barcelona — 148,45 сек. 

Моя система получилась немного медленней чем у Phoronix'a. Возможно из-за скорости памяти, возможно из-за выключенного PBO. А скорее всего из-за памяти и PBO вместе взятых. 

Пока возился с настройкой системы, прогнал в своих задачах с включенным и выключенным PBO — разницы не более 1%, а температуры выше на 5 градусов. В общем выключил. Без PBO тише и холоднее. AMD сделала очень хороший процессор, которому разгон в принципе не нужен, так как никакого существенного повышения производительности нет. 

Предыдущие части: 

Часть 1

Часть 2 

Часть 3

Часть 4 

Часть 5

P.S. Сайт сильно пережимает картинки, в ряде картинок может страдать разборчивость текста. Если кому-то сильно надо, напишите в комментариях, скину оригинал. 

P.P.S Огромное спасибо Anatoli Che. Благодаря ему стало возможным сравнить не только процессоры AMD разных поколений, но и добавить к сравнению процессор Intel. На графике ниже производительность 4-х процессоров в задаче "извлечение энграмм из текста". Набор данных был одинаковый для всех процессоров. 

Но сравнение ниже, на мой взгляд, более показательно. 

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