Часть 6: Intel Core i7, частотаЧасть 1: AMD Phenom II, количество ядер
Часть 2: AMD Phenom II, подсистема памяти
Часть 3: Intel Core i7, технологии Turbo Boost и Hyper-Threading
Часть 4: Intel Core i7, Hyper-Threading «в чистом виде»
Часть 5: Intel Core i7, количество ядер
Мы продолжаем серию материалов, посвящённых исследованию производительности современных процессоров в реальных задачах и влиянию различных их характеристик на производительность. В этой статье мы затронем тему, которую ранее не исследовали: влияние на производительность частоты работы ядра. Теоретически данный вопрос в достаточной степени проработан: в любой конкретной архитектуре при росте частоты работы ядра, производительность процессора должна сначала практически линейно расти, потом, на определённом этапе, темпы роста должны замедляться, и, наконец, начиная с некой частоты, дальнейшее её наращивание становится уже бессмысленным т.к. перестаёт приводить к росту производительности процессора. Причина этих явлений также давно обозначена: производительность «упирается» в подсистему памяти, которая просто не успевает доставлять данные и код с такой скоростью, с которой их обрабатывает ядро CPU.
Нас же, как практиков, заинтересует простой вопрос: где именно наступают эти «переломные частотные моменты» в случае с конкретными процессорными архитектурами? Сегодня мы исследуем данный вопрос применительно к процессору Intel Core i7.
Конфигурация тестовых стендов
Тестовый стенд остался таким же, как и в двух предыдущих сериях, посвящённых процессору Intel Core i7:
- Процессор: Intel Core i7 950;
- Кулер: ASUS Triton 81;
- Системная плата: ASUS P6T SE (чипсет Intel X58);
- Память: 3 модуля по 2 ГБ Corsair DDR3-1800 в режиме DDR3-1600;
- Видеокарта: Palit GeForce GTX 275
- БП: Cooler Master Real Power M1000.
Для исследований было решено взять 4 «процессора» с частотами от 1,86 до 3,06 ГГц, и шагом ровно в 400 МГц. Навскидку, мы посчитали, что для выявления основных тенденций этого хватит (не ошиблись). Штатная частота используемого CPU — как раз 3,06 ГГц (множитель ядра 23). Меньшие частоты получались путём уменьшения множителя, соответственно:
- x20 — 2,66 ГГц;
- x17 — 2,26 ГГц;
- x14 — 1,86 ГГц.
Множитель внеядра* (да простят нас читатели за этот новояз, но попробуйте сами перевести одним словом англоязычный термин «uncore») у всех процессоров серии Core i7 одинаков — x16 (частота работы внеядра, соответственно — 2,13 ГГц). Технология Hyper-Threading была включена, а вот Turbo Boost пришлось выключить т.к. в данном исследовании нам был нужен процессор, работающий на строго определённых частотах.
* — Часть процессоров Core i7, находящаяся «снаружи ядра», и работающая на своей, отличной от ядра частоте. Две наиболее значимые части внеядра — контроллер памяти и контроллер процессорной шины.Тестирование
На первом графике приведена кривая роста производительности, построенная на основании баллов производительности каждого «процессора», вычисленных, согласно нашей методике тестирования (красная линия). Синяя же линия олицетворяет собой «идеально масштабируемую» производительность, которая вычисляется, исходя из предыдущего результата и предположения о том, что следующий результат будет настолько же больше, насколько выросла частота процессора. Т.е. если 1,86 ГГц CPU продемонстрировал в некой группе производительность X, подразумевается, что «идеальная» производительность 2,26 ГГц CPU будет равна Y=X*2,26/1,86. Соответственно, производительность 2,66 ГГц процессора будет равна Z=Y*2,66/2,26. Зачем эта линия на графике? Нам кажется, что она позволяет сделать результаты данного тестирования существенно более наглядными. В конце концов, конкретные цифры всегда можно взять из таблицы с подробными результатами, а вот степень расхождения между практикой и идеалом проще оценивать визуально.
На втором графике (если в нём есть необходимость) линии олицетворяют прирост производительности по мере увеличения частоты для каждого приложения из данной тестовой группы в отдельности. Отсчёт начинается с системы с частотой CPU 1,86 ГГц, производительность которой, соответственно, принята за 100% — поэтому все линии выходят из одной точки. Этот график позволяет нам более точно отследить поведение отдельных программ.
И, наконец — таблица с результатами тестов (также по каждому приложению в отдельности). Начиная со столбика «2,26 ГГц», в ней присутствуют не только абсолютные величины результатов, но и некие проценты. Что это? Это цифра, отражающая прирост производительности данной системы по отношению к предыдущей. Запомните, это очень важно: по отношению к предыдущей, а не к исходной. Таким образом, если мы видим в столбике «2,66 ГГц» цифру 22% — это значит, что система в данном приложении показала на 22% более хороший результат, чем при частоте процессора 2,26 ГГц.
Вообще, нелишним будет озвучить «идеальные» значения прироста производительности, чтобы читателям было проще ориентироваться в содержимом таблиц. Значения эти равны, соответственно:
- при переходе 1,86 ГГц → 2,26 ГГц: ~+22%;
- при переходе 2,26 ГГц → 2,66 ГГц: ~+18%;
- при переходе 2,66 ГГц → 3,06 ГГц: ~+15%.
Учитывая то, что разброс +/-2% у нас принято считать допустимой погрешностью измерений, мы получаем 3 диапазона: от +20 до +24%, от +16 до +20%, и от +13 до +17%. Хотя, впрочем, нижние границы нас не очень интересуют: масштабируемость запросто может являться неидеальной, и даже равняться нулю (отрицательной, теоретически, быть не может). А вот суперлинейный прирост с идеальной точки зрения невозможен — поэтому значения выше +24%, +20% и +17%, соответственно, придётся как-то объяснять.
Также, традиционно, мы даём любознательным читателям ссылку на таблицу в формате Microsoft Excel, в которой приведены все результаты тестов в самом подробном виде. А также, для удобства их анализа, присутствуют две дополнительные закладки — «Compare #1» и «Compare #2». На них, как и в таблицах, присутствующих в статье, произведено сравнение четырёх систем в процентном отношении. Разница очень простая: в случае с Compare #1, проценты вычисляются так же, как в таблицах в статье, — по отношению к предыдущей системе, а в случае с Compare #2, все системы сравниваются с базовой (1,86 ГГц).
3D-визуализация
| 1,86 GHz | 2,26 GHz | 2,66 GHz | 3,06 GHz | ||||
| 3ds max ↑* | 10,57 | 12,64 | 20% | 15,43 | 22% | 16,43 | 6% |
| Lightwave ↓ | 23,02 | 18,64 | 23% | 15,28 | 22% | 12,87 | 19% |
| Maya ↑ | 2,55 | 3,12 | 22% | 3,84 | 23% | 4,22 | 10% |
| SolidWorks ↓ | 70,64 | 64,5 | 10% | 60,72 | 6% | 57,8 | 5% |
| Pro/ENGINEER ↓ | 1457 | 1235 | 18% | 1093 | 13% | 1023 | 7% |
| UGS NX ↑ | 2,35 | 2,72 | 16% | 2,73 | 0% | 3,23 | 18% |
| Group Score ↑ | 94 | 111 | 18% | 127 | 14% | 140 | 10% |
* — здесь и далее в таблицах стрелочкой вверх (↑) помечены те тесты, где лучшим является больший результат, стрелочкой вниз (↓) — тесты, где лучшим является меньший результат.
Ждать от группы визуализации идеальной масштабируемости не стоило — всё-таки, по идее, в данном процессе не последнюю роль должна играть видеокарта. Однако, как оказалось, пакеты трёхмерного моделирования при интерактивной работе весьма существенно зависят от процессора, несмотря на использование различных 3D API (Lightwave и Maya — OpenGL, 3ds max — Direct3D). Собственно, чемпионом является как раз Lightwave, график которого представляет собой практически идеально прямую линию. Инженерные пакеты намного более скромны в аппетитах (то есть, получается, лучше используют видеокарту). Сверхлинейный рост производительности наблюдается при переходе с частоты 2,26 ГГц на частоту 2,66 ГГц (три раза) и при переходе с частоты 2,66 ГГц на частоту 3,06 ГГц (один раз). Пока что просто запомним это.
Трёхмерный рендеринг
| 1,86 GHz | 2,26 GHz | 2,66 GHz | 3,06 GHz | ||||
| 3ds max ↑ | 11,15 | 13,41 | 20% | 15,9 | 19% | 17,6 | 11% |
| Lightwave ↓ | 120,9 | 99,06 | 22% | 84,66 | 17% | 74,41 | 14% |
| Maya ↑ | 03:35 | 02:57 | 21% | 02:31 | 17% | 02:13 | 14% |
| Group Score ↑ | 108 | 131 | 21% | 154 | 18% | 173 | 12% |
Рендеринг, как и следовало ожидать, масштабируется практически идеально, причём независимо от пакета (и, соответственно, рендер-движка) — линии 3ds max, Maya и Lightwave на индивидуальном графике практически слились в одну толстую линию.
Научные и инженерные расчёты
| 1,86 GHz | 2,26 GHz | 2,66 GHz | 3,06 GHz | ||||
| Maya ↑ | 5,77 | 6,97 | 21% | 8,33 | 20% | 9,82 | 18% |
| SolidWorks ↓ | 60,48 | 51,06 | 18% | 41,31 | 24% | 40,96 | 1% |
| Pro/ENGINEER ↓ | 2658 | 2186 | 22% | 1725 | 27% | 1539 | 12% |
| UGS NX ↓ | 3,57 | 4,19 | 17% | 4,96 | 18% | 5,57 | 12% |
| MAPLE ↑ | 0,1296 | 0,1569 | 21% | 0,1925 | 23% | 0,2197 | 14% |
| Mathematica ↑ | 1,8134 | 2,225 | 23% | 2,7142 | 22% | 3,0364 | 12% |
| MATLAB ↓ | 0,063229 | 0,052212 | 21% | 0,045011 | 16% | 0,0406 | 11% |
| Group Score ↑ | 85 | 102 | 20% | 123 | 21% | 137 | 11% |
Напомним, что в «вычислительной» группе участвуют приложения трёх типов: инженерные CAD, математические пакеты, и даже один пакет трёхмерного моделирования. Ситуация сложилась забавная: ни в одной группе, состоящей более чем из одного члена, «согласья нет». MAPLE и Mathematica возглавляют рейтинг самых хорошо масштабирующихся приложений (к ним присоединяется пакет трёхмерного моделирования Maya), однако у MATLAB с масштабируемостью скорости при росте частоты всё существенно хуже, особенно под конец. Инженерные CAD и вовсе разбрелись кто куда: у Pro/ENGINEER с масштабируемостью всё отлично, у UGS NX — похуже (его линия практически совпадает с MATLAB), а SolidWorks при переходе с 2,66 ГГц на 3,06 ГГц вообще практически никакого ускорения не получил. Соответственно, бессмысленно пытаться рассуждать о каких-то тенденциях при таком разнобое. Впрочем, благодаря приложениям-лидерам, средняя масштабируемость по группе вышла очень высокой (см. первый график — расхождение с идеалом весьма незначительно и начинается только под конец). И снова мы наблюдаем случаи сверхлинейного роста производительности, причём наиболее массовые при переходе с частоты 2,26 ГГц на 2,66 ГГц. Обратите внимание: учитывая количество случаев, это уже можно смело считать обозначившейся тенденцией.
Растровая графика
| 1,86 GHz | 2,26 GHz | 2,66 GHz | 3,06 GHz | ||||
| ACDSee ↓ | 07:36 | 06:09 | 24% | 05:22 | 15% | 05:21 | 0% |
| Paint.NET ↓ | 00:24 | 00:20 | 20% | 00:17 | 18% | 00:15 | 13% |
| PaintShop Pro ↓ | 15:42 | 13:05 | 20% | 10:24 | 26% | 09:48 | 6% |
| Photoimpact ↓ | 10:13 | 08:25 | 21% | 07:15 | 16% | 06:33 | 11% |
| Photoshop ↓ | 08:52 | 07:32 | 18% | 06:20 | 19% | 05:50 | 9% |
| Group Score ↑ | 90 | 108 | 20% | 129 | 19% | 138 | 7% |
В группе растровой графики можно отметить поведение двух программ, выбивающихся из общей колеи: пакет ACDSee, который под конец перестал масштабироваться вообще (несмотря на то, что до этого у него всё было в норме и из общей группы он ничем не выделялся), и PaintShop Pro, у которого наблюдается резкий сверхлинейный скачок производительности... опять при переходе 2,26 → 2,66 ГГц! Чтобы не томить читателей, скажем сразу: увидим мы этот феномен ещё не раз и не два, а возможное объяснение ему мы дадим после комментариев ко всем тестам, т.к. по нашей версии оно универсальное, и от типа программного обеспечения совершенно не зависит.
Сжатие данных без потерь
| 1,86 GHz | 2,26 GHz | 2,66 GHz | 3,06 GHz | ||||
| 7-Zip ↓ | 06:06 | 05:02 | 21% | 04:12 | 20% | 03:46 | 12% |
| WinRAR ↓ | 01:57 | 01:34 | 24% | 01:18 | 21% | 01:15 | 4% |
| Group Score ↑ | 89 | 110 | 24% | 132 | 20% | 142 | 8% |
Почти идеальная масштабируемость — и опять у WinRAR сверхлинейный рост в уже хорошо нам знакомой точке.
Компиляция
И снова мы наблюдаем «горб» на графике в районе 2,66 ГГц, где реальная производительность несколько превосходит идеальный прогноз. Однако расхождение не очень большое (см. таблицу с подробными результатами), около 2%, поэтому нельзя утверждать точно, имеем ли мы дело с вышеописанным феноменом, или же с банальной погрешностью измерений. Хотя, конечно, то, что эта «погрешность» опять возникла именно на точке 2,66 ГГц — конечно, наводит на определённые размышления. :)
Кодирование аудио
Достаточно странный результат, требующий дополнительных исследованний. Создаётся впечатление, что тест во что-то «упёрся», и это явно не процессор. Судя по данным предыдущих тестов, подозревать подсистему памяти не стоит. Быть может, жёсткий диск?..
Кодирование видео
| 1,86 GHz | 2,26 GHz | 2,66 GHz | 3,06 GHz | ||||
| Canopus ProCoder ↓ | 05:28 | 04:33 | 20% | 03:39 | 25% | 03:18 | 11% |
| DivX ↓ | 05:58 | 05:02 | 19% | 04:22 | 15% | 03:53 | 12% |
| Mainconcept VC-1 ↓ | 08:34 | 07:09 | 20% | 06:01 | 19% | 05:26 | 11% |
| x264 ↓ | 09:53 | 08:12 | 21% | 07:02 | 17% | 06:10 | 14% |
| XviD ↓ | 03:40 | 03:05 | 19% | 02:39 | 16% | 02:22 | 12% |
| Group Score ↑ | 97 | 117 | 21% | 138 | 18% | 154 | 12% |
Одна из самых хорошо масштабируемых групп в этом тестировании, причём график по приложениям тоже очень плотный — все кривые, кроме одной, почти что складываются в одну толстую линию. Как ни странно, лидером группы является довольно старый Canopus ProCoder. Впрочем, данный феномен можно попытаться объяснить тем, что он же не очень хорошо использует многоядерность: более современные кодеки, умеющие задействовать все 8 ядер, должны создавать большую нагрузку на подсистему памяти — и, соответственно, зависеть ещё и от неё. А Canopus ProCoder остаётся зависеть исключительно от процессора.
Java
Ситуация настолько похожа на предыдущую, что можно было бы сэкономить на диаграммах, использовав оба раза одну и ту же. :) Впрочем, ничего странного в этом нет: коль SPECjvm способен создавать хорошую нагрузку для процессоров с любым количеством ядер — неудивительно, что он и масштабируется хорошо при повышении быстродействия CPU.
Трёхмерные игры
| 1,86 GHz | 2,26 GHz | 2,66 GHz | 3,06 GHz | ||||
| STALKER: Clear Sky ↑ | 48 | 55 | 15% | 59 | 7% | 60 | 2% |
| Devil May Cry 4 ↑ | 195 | 198 | 2% | 199 | 0% | 202 | 2% |
| Far Cry 2 ↑ | 49 | 57 | 16% | 62 | 9% | 65 | 5% |
| Grand Theft Auto 4 ↑ | 58 | 63 | 9% | 65 | 3% | 66 | 2% |
| Lost Planet ↑ | 43 | 43 | 0% | 43 | 0% | 43 | 0% |
| Unreal Tournament 3 ↑ | 129 | 142 | 10% | 155 | 9% | 165 | 6% |
| Crysis: Warhead ↑ | 46 | 48 | 4% | 54 | 13% | 56 | 4% |
| World in Conflict ↑ | 45 | 48 | 7% | 50 | 4% | 50 | 0% |
| Left 4 Dead ↑ | 101 | 116 | 15% | 142 | 22% | 150 | 6% |
| Group Score ↑ | 102 | 109 | 7% | 116 | 6% | 118 | 2% |
Тройка лидеров по процессорозависимости: Left 4 Dead*, Far Cry 2 и Unreal Tournament 3, причём Left 4 Dead идёт впереди всех с весомым отрывом. Следует заметить, что вхождение в тройку Unreal Tournament 3 может быть объяснено особенностью самого теста: в отличие от других игровых бенчмарков, бенчмарк для UT3 не воспроизводит заранее записанную демку, а имитирует реальную игру (CTF), с той только разницей, что всеми игроками на поле управляет компьютер. Потенциально, это действительно гораздо более сложная для процессора задача т.к. управление 8-ю игроками в режиме реального времени создаст хорошую вычислительную нагрузку даже при самом примитивном «искусственном интеллекте». Однако в целом всё плохо (или хорошо — зависит от того, с какой стороны смотреть): игровая группа демонстрирует самую низкую процессорозависимость, являясь по данному параметру «лидером наоборот» сегодняшнего тестирования.
* — мы привели результаты Left 4 Dead в таблице и на диаграмме т.к. они оказались самыми показательными с точки зрения зависимости от процессора, но не стоит забывать о том, что данный бенчмарк входит в группу «опциональных тестов», и, соответственно, не влияет на общий балл игровой группы.Заключение
Карты на стол!
Что ж, настала пора наконец-таки дать объяснения последнему неразгаданному феномену: массовым случаям сверхлинейного роста производительности при переходе от частоты 2,26 ГГц к частоте 2,66 ГГц. Быть может, мы кому-то покажемся несколько занудными :), однако давайте все вместе «станцуем от печки» — честное слово, так интереснее.
Итак: что нужно для того, чтобы на одном из «переходов» образовался сверхлинейный прирост производительности? Вопрос кажется дурацким (ибо ответ в первом приближении: «чтобы следующий по частоте процессор был сверхлинейно быстрее»), однако подождите делать преждевременные выводы: быстрее — отнюдь не единственный вариант. Если представить нашу гипотетическую идеальную производительность как функцию от частоты, т.е. быстродействие (S) = частота (F) * некий коэффициент (K), то сверхлинейный рост невозможен. Что нужно для того, чтобы он появился? Для этого нужно, чтобы следующему по частоте процессору спустился с небес некий бонус (+B) или... чтобы предыдущий процессор получил бонус отрицательный (-B) т.е. оказался бы медленнее, чем ему положено согласно его частоты. Итак, чувствуете, как изменилась наша задача? Теперь нам нужно найти ответ не на один вопрос, а на один из двух: либо на вопрос «почему 2,66 ГГц процессор такой быстрый?», либо «почему 2,26 ГГц такой медленный?» При этом также нельзя исключать того, что существуют ответы на оба вопроса*.
* — Вы правильно догадались: так оно на самом деле и есть. :)
Искали бы мы эти ответы, наверное, намного дольше, если бы не один счастливый факт: мы-то чётко понимали, что де-факто, физически, процессор был один и тот же. Изменялся только коэффициент умножения, с помощью которого получается частота работы ядра. Значит, если отбросить магию маленьких зелёных человечков, ответ может быть один: дело именно в коэффициенте умножения. Впрочем, это ещё не ответ. Это лишь область для поисков.
Ещё одно наше везение состояло в том, что коэффициенты умножения «быстрого» и «медленного» процессора уж очень сильно разнятся: 17 и 20. Первое число — вообще простое, т.е. делится только само на себя и на единицу. Второе — делится на 2, 4, 5 и 10. И вот как раз на цифре «4» прозвучала та самая «эврика!» — ну да, конечно же — коэффициент умножения внеядра во всех случаях был равен 16, а это число тоже делится на 4!
Подводя итоги: видимо, расходы на согласование между ядром и внеядром, когда они работают на разных частотах — действительно существенный фактор, способный влиять в том числе на быстродействие процессора. Соотношение между коэффициентами умножения ядра и внеядра в случае с частотой первого 2,26 ГГц, довольно «неудобное» — 17:16. И ввиду того, что 17 — простое число, сократить эту дробь невозможно. В случае с 2,66 ГГц процессором, соотношение составляет 20:16, что легко сокращается до 5:4. Судя по всему, универсальное правило «чем сильнее асинхронность — тем хуже», работает и в данном случае. Косвенным подтверждением этого служит вторая диаграмма, где сравнивается идеальный и реальный средний прирост производительности: чётко видно, что 2,66 ГГц процессор намного ближе к своему идеалу, чем 2,26 ГГц.
Разумеется, мы не можем сейчас настаивать на том, что изложенная гипотеза является доказанной: выявленный феномен требует дополнительного исследования, вполне возможно, с привлечением низкоуровневых тестов, которые в подобных случаях обеспечивают большую точность и больший разброс, нежели тесты с помощью реального ПО. Однако в рамках ныне проведенного исследования, гипотеза выглядит вполне непротиворечиво, и, к тому же, никакого другого объяснения вышеизложенным фактам, мы придумать пока не смогли.
Что же касается двух случаев сверхлинейного роста при переходе границы 2,66 / 3,06 ГГц — то их нам, увы, остаётся объявить «артефактами» данного тестирования т.к. с логической точки зрения они необъяснимы, а количество случаев настолько невелико, что списать всё на случайность ещё можно.
Конечно, несколько неожиданно наблюдать настолько стремительно возрастающую разницу между идеальным (под идеальным мы подразумеваем соответствующий росту частоты) приростом производительности и реальным уже на частоте 3,06 ГГц. Фактически, это означает, что даже в лучшем случае производительность гипотетического Core i7 3,46 ГГц будет равна примерно 156 баллов по нашей шкале (3,46 умножить на предполагаемую эффективность порядка 45 баллов за гигагерц) — и это ещё достаточно оптимистичный прогноз. С другой стороны — может, увеличение объёма кэша третьего уровня позволит поднять общую эффективность системы, так что бить тревогу ещё рановато. Собственно, это косвенно подтверждается достаточно спокойной позицией Intel, которая отнюдь не торопится с анонсами новых процессорных архитектур, предпочитая «подтягивать хвосты» в других областях — например, в области графических решений и их интеграции с CPU. Поэтому в целом, мы бы сказали, ничего удивительного нам сегодняшнее тестирование не открыло: да, как правило, в рамках одной и той же архитектуры, чем больше частота — тем меньше эффективность. Это давно всем известно, и блестяще подтвердилось практическими результатами.
Однако раз уж мы провели такое полномасштабное тестирование, грех было бы останавливаться на одной только процессорной тематике, не затронув сами программы. Давайте посмотрим: а какие группы ПО из используемой методики как реагируют на увеличение частоты работы процессорного ядра? Для начала, возьмём разницу между двумя крайними точками: 1,86 ГГц и 3,06 ГГц.
Распределение вполне ожидаемое: научные и инженерные вычисления, рендеринг, архивация, кодирование видео. Несколько правда, странно наличие в нижних строчках группы кодирования аудио. Самая нижняя позиция игровой подгруппы, наоборот, лишь подтверждает правильность нашего выбора опций для тестирования: с нормальными графическими настройками производительность в играх и не должна сильно зависеть от процессора.
А теперь давайте посмотрим на тот же рейтинг, но уже с точки зрения разницы между двумя последними позициями: 2,66 ГГц и 3,06 ГГц. Эта диаграмма позволит нам ответить на вопрос: какие приложения сохраняют хорошую масштабируемость даже на самом верхнем пределе частот?
Первый сюрприз связан как раз с первым же местом: лучше всего масштабируются на верхних частотах, как оказывается, Java-приложения. Больше сюрпризов не наблюдается: все те же рендеринг, кодирование видео, научные и инженерные расчёты. В целом, можно констатировать, что никаких расхождений с нашими интуитивными ощущениями две последних диаграммы не вызывают: даже не видя результатов, руководствуясь одними только логикой и здравым смыслом, пятёрку лидеров любой из редакторов процессорного раздела назвал бы легко.
Подводя итоги, можно продолжить мысль, высказанную абзацем выше: несмотря на отсутствие откровений, тестирование получилось весьма полезное — именно ввиду теоретической предсказуемости результатов. Нет ничего лучше, чем время от времени, обстоятельно, с толком, с расстановкой, экспериментально убедиться в том, что старые добрые, чисто теоретическим путём выведенные закономерности, до сих пор действуют. А то иной раз задумаешься: а вдруг их уже отменили, а мы до сих пор по старинке рассуждаем? :)
Модули памяти для тестовых стендов предоставлены российским представителством Corsair Memory |  |
Процессор Intel Core i7 950 и плата ASUS P6T SE предоставлены компанией Ulmart |  |
