One core per compute unit что это - TurboComputer.ru
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд (пока оценок нет)
Загрузка...

One core per compute unit что это

Введение в GPU-вычисления – CUDA/OpenCL

Введение в GPU-вычисления

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

В этой заметке собрана информация которая поможет понять общие принципы GPU-программирования.

Введение в архитектуру GPU

Разделяют два вида устройств – то которое управляет общей логикой – host, и то которое умеет быстро выполнить некоторый набор инструкций над большим объемом данных – device.

В роли хоста обычно выступает центральный процессор (CPU – например i5/i7).
В роли вычислительного устройства – видеокарта (GPU – GTX690/HD7970). Видеокарта содержит Compute Units – процессорные ядра. Неразбериху вводят и производители NVidia называет свои Streaming Multiprocessor unit или SMX , а
ATI – SIMD Engine или Vector Processor. В современных игровых видеокартах – их 8-32.
Процессорные ядра могут исполнять несколько потоков за счет того, что в каждом содержится несколько (8-16) потоковых процессоров (Stream Cores или Stream Processor). Для карт NVidia – вычисления производятся непосредственно на потоковых процессорах, но ATI ввели еще один уровень абстракции – каждый потоковый процессор, состоит из processing elementsPE (иногда называемых ALU – arithmetic and logic unit) – и вычисления происходят на них.

Необходимо явно подчеркнуть что конкретная архитектура (число всяческих процессоров) и вычислительные возможности варьируются от модели к модели – что несколько влияет на универсальность и простоту кода для видеокарт от обоих производителей.
Для CUDA-устройств от NVidia это sm10, sm20, sm30 и т.д. Для OpenCL видеокарт от ATI/NVidia определяющее значение имеет версия OpenCL реализованная в драйверах от производителя 1.0, 1.1, 1.2 и поддержка особенностей на уровне железа. Да, вы вполне можете столкнуться с ситуацией когда на уровне железа какие-то функции просто не реализованы (как например локальная память на амд-ешных видеокарт линейки HD4800). Да, вы вполне можете столкнуться с ситуацией когда какие-то функции не реализованы в драйверах (на момент написания – выполнение нескольких ядер на видео-картах от NVidia с помощью OpenCL).

Программирование для GPU

Программы пишутся на расширении языка Си от NVidia/OpenCL и компилируются с помощью специальных компиляторов входящих в SDK. У каждого производителя разумеется свой. Есть два варианта сборки – под целевую платформу – когда явно указывается на каком железе будет исполнятся код или в некоторый промежуточный код, который при запуске на целевом железе будет преобразован драйвером в набор конкретных инструкций для используемой архитектуры (с поправкой на вычислительные возможности железа).

Выполняемая на GPU программа называется ядром – kernel – что для CUDA что для OpenCL это и будет тот набор инструкций которые применяются ко всем данным. Функция одна, а данные на которых она выполняется – разные – принцип SIMD.

Важно понимать что память хоста (оперативная) и видеокарты – это две разные вещи и перед выполнением ядра на видеокарте, данные необходимо загрузить из оперативной памяти хоста в память видеокарты. Для того чтобы получить результат – необходимо выполнить обратный процесс. Здесь есть ограничения по скорости PCI-шины – потому чем реже данные будут гулять между видеокартой и хостом – тем лучше.

Драйвер CUDA/OpenCL разбивает входные данные на множество частей (потоки выполнения объединенные в блоки) и назначает для выполнения на каждый потоковый процессор. Программист может и должен указывать драйверу как максимально эффективно задействовать существующие вычислительные ресурсы, задавая размеры блоков и число потоков в них. Разумеется, максимально допустимые значения варьируются от устройства к устройству. Хорошая практика – перед выполнением запросить параметры железа, на котором будет выполняться ядро и на их основании вычислить оптимальные размеры блоков.

Схематично, распределение задач на GPU происходит так:

Выполнение программы на GPU

work-item (OpenCL) или thread (CUDA) – ядро и набор данных, выполняется на Stream Processor (Processing Element в случае ATI устройств).
work group (OpenCL) или thread block (CUDA) выполняется на Multi Processor (SIMD Engine)
Gr >

Одно ядро может выполняться на нескольких GPU устройствах (как для CUDA так и для OpenCL, как для карточек ATI так и для NVidia).
Одно GPU-устройство может одновременно выполнять несколько ядер (как для CUDA так и для OpenCL, для NVidia – начиная с архитектуры 20 и выше). Ссылки по данным вопросам см. в конце статьи.

Модель памяти OpenCL (в скобках – терминология CUDA)

Здесь главное запомнить про время доступа к каждому виду памяти. Самый медленный это глобальная память – у современных видекарт ее аж до 6 Гб. Далее по скорости идет разделяемая память (shared – CUDA, local – OpenCL) – общая для всех потоков в блоке (thread block – CUDA, work-group – OpenCL) – однако ее всегда мало – 32-48 Кб для мультипроцессора. Самой быстрой является локальная память за счет использования регистров и кеширования, но надо понимать что все что не уместилось в кеширегистры – будет хранится в глобальной памяти со всеми вытекающими.

Паттерны параллельного программирования для GPU

1. Map

Map – GPU parallel pattern

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

Отношение – как один к одному (one-to-one).

пример – перемножение матриц, оператор инкремента или декремента примененный к каждому элементу матрицы и т.п.

2. Scatter

Scatter – GPU parallel pattern

Для каждого элемента входного массива мы вычисляем позицию в выходном массиве, на которое он окажет влияние (путем применения соответствующего оператора).

Отношение – как один ко многим (one-to-many).

3. Transpose

Transpose – GPU parallel pattern

Данный паттерн можно рассматривать как частный случай паттерна scatter.
Используется для оптимизации вычислений – перераспределяя элементы в памяти можно достичь значительного повышения производительности.

4. Gather

Gather – GPU parallel pattern

Является обратным к паттерну Scatter – для каждого элемента в выходном массиве мы вычисляем индексы элементов из входного массива, которые окажут на него влияние:

Отношение – несколько к одному (many-to-one).

5. Stencil

Stencil – GPU parallel pattern

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

Отношение несколько к одному (several-to-one)

Пример: фильтр Гауссиана.

6. Reduce

Reduce – GPU parallel pattern

Отношение все к одному (All-to-one)

Пример – вычисление суммы или максимума в массиве.

7. Scan/ Sort

При вычислении значения в каждой ячейке выходного массива необходимо учитывать значения каждого элемента входного. Существует две основные реализации – Hillis and Steele и Blelloch.

out[i] = F[i] = operator(F[i-1],in[i])

Отношение все ко всем (all-to-all).

Примеры – сортировка данных.

Полезные ссылки

Введение в CUDA:

Введение в OpenCL:

Хорошие статьи по основам программирования (отдельный интерес вызывает область применения):
http://www.mql5.com/ru/articles/405
http://www.mql5.com/ru/articles/407

Вебинары по OpenCL:

Курс на Udacity по программированию CUDA:

Выполнение ядра на нескольких GPU:

Причем можно пойти по пути упрощения и задействовать один из специальных планировщиков:
http://www.ida.liu.se/

CUDA – grid, threads, blocks- раскладываем все по полочкам

доступные в сети ресурсы по CUDA

UPDATE 28.06.2013

Враперы для взаимодействия с ОпенСЛ:
JOCL – Java bindings for OpenCL (JOCL)
PyOpenCL – для python
aparapi – полноценная библиотека для жавы

Интересные статью по OpenCL – тут.

Читайте также:  Сбой активации Iphone 4s что делать

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

OpenCL: Confused by CL_DEVICE_MAX_COMPUTE_UNITS

I’m confused by this CL_DEVICE_MAX_COMPUTE_UNITS. For instance my Intel GPU on Mac, this number is 48. Does this mean the max number of parallel tasks run at the same time is 48 or the multiple of 48, maybe 96, 144. (I know each compute unit is composed of 1 or more processing elements and each processing element is actually in charge of a «thread». What if these each of the 48 compute units is composed of more than 1 processing elements ). In other words, for my Mac, the «ideal» speedup, although impossible in reality, is 48 times faster than a CPU core (we assume the single «core» computation speed of CPU and GPU is the same), or the multiple of 48, maybe 96, 144.

2 Answers 2

Summary: Your speedup is a little complicated, but your machine’s (Intel GPU, probably GEN8 or GEN9) fp32 throughput 768 FLOPs per (GPU) clock and 1536 for fp16. Let’s assume fp32, so something less than 768x (maybe a third of this depending on CPU speed). See below for the reasoning and some very important caveats.

A Quick Aside on CL_DEVICE_MAX_COMPUTE_UNITS: Intel does something wonky when with CL_DEVICE_MAX_COMPUTE_UNITS with its GPU driver.

From the clGetDeviceInfo (OpenCL 2.0). CL_DEVICE_MAX_COMPUTE_UNITS says

The number of parallel compute units on the OpenCL device. A work-group executes on a single compute unit. The minimum value is 1.

However, the Intel Graphics driver does not actually follow this definition and instead returns the number of EUs (Execution Units) — An EU a grouping of the SIMD ALUs and slots for 7 different SIMD threads (registers and what not). Each SIMD thread represents 8, 16, or 32 workitems depending on what the compiler picks (we want higher, but register pressure can force us lower).

A workgroup is actually limited to a «Slice» (see the figure in section 5.5 «Slice Architecture»), which happens to be 24 EUs (in recent HW). Pick the GEN8 or GEN9 documents. Each slice has it’s own SLM, barriers, and L3. Given that your apple book is reporting 48 EUs, I’d say that you have two slices.

Maximum Speedup: Let’s ignore this major annoyance and work with the EU number (and from those arch docs above). For «speedup» I’m comparing a single threaded FP32 calculation on the CPU. With good parallelization etc on the CPU, the speedup would be less, of course.

Each of the 48 EUs can issue two SIMD4 operations per clock in ideal circumstances. Assuming those are fused multiply-add’s (so really two ops), that gives us:

So your ideal speedup is actually

768. But there’s a bunch of things that chip into this ideal number.

  1. Setup and teardown time. Let’s ignore this (assume the WL time dominates the runtime).
  2. The GPU clock maxes out around a gigahertz while the CPU runs faster. Factor that ratio in. (crudely 1/3 maybe? 3Ghz on the CPU vs 1Ghz on the GPU).
  3. If the computation is not heavily multiply-adds «mads», divide by 2 since I doubled above. Many important workloads are «mad»-dominated though.
  4. The execution is mostly non-divergent. If a SIMD thread branches into an if-then-else, the entire SIMD thread (8,16,or 32 workitems) has to execute that code.
  5. Register banking collisions delays can reduce EU ALU throughput. Typically the compiler does a great job avoiding this, but it can theoretically chew into your performance a bit (usually a few percent depending on register pressure).
  6. Buffer address calculation can chew off a few percent too (EU must spend time doing integer compute to read and write addresses).
  7. If one uses too much SLM or barriers, the GPU must leave some of the EU’s idle so that there’s enough SLM for each work item on the machine. (You can tweak your algorithm to fix this.)
  8. We must keep the WL compute bound. If we blow out any cache in the data access hierarchy, we run into scenarios where no thread is ready to run on an EU and must stall. Assume we avoid this. ?. I’m probably forgetting other things that can go wrong.

We call the efficiency the percentage of theoretical perfect. So if our workload runs at

530 FLOPs per clock, then we are 60% efficient of the theoretical 768. I’ve seen very carefully tuned workloads exceed 90% efficiency, but it definitely can take some work.

Моя первая виртуальная машина: как не накосячить

Итак, вот перед вами свеженькая организация в vCloud Director, и вам только предстоит создать свою первую виртуальную машину. Сегодня расскажу, какие настройки выбирать при создании виртуальной машины, чтобы она работала и не просила есть. Поехали!


Источник: drive2.ru

Операционная система. Выбирайте современные дистрибутивы. Если берете Windows 2008 R2 и более старую или Linux до ядра 4.19.x, ждите проблем. Каких? Ну, например, вендор уже перестал поддерживать актуальное состояние Windows 2008 R2 аж в 2013 году (EOL). Это означает, что он больше не разрабатывает драйвера под вышедшее с тех пор железо, не модифицирует ОС под новое что угодно. С древними операционками вы точно не сможете использовать все возможности, которые предоставляет современный гипервизор. А уже в эти новогодние праздники остро встанет проблема с безопасностью, так как 14 января 2020 года заканчивается расширенная поддержка Windows Server 2008 R2 и перестанут выходить Security Update.

Cores per socket. Оставляйте 1 ядро на сокет, ставьте столько сокетов, сколько вам нужно виртуальных процессоров. Да, логично наоборот, но правильно так. Если у вас нет специализированных лицензионных требований. Например, вы платите за сокет, а больше сокетов означает больше лицензий. Не ставьте 2/2, чтобы получить 4. Сделайте 4/1. Такую машину гипервизор будет обслуживать оптимальным образом. Scheduler гипервизора будет меньше пенализировать такие ВМ.
Объясню на пальцах. Представьте, что проводник рассаживает пассажиров по вагону, вагон – как в Сапсане. В роли проводника scheduler, пассажиры – это ВМ. Пассажиров, которые едут в одиночку (однопроцессорные ВМ), ему распределить проще всего: их можно посадить на любое место. Семью из 4 человек (4-процессорные ВМ) уже сложнее. Им нужно найти 4 места в одном вагоне. А теперь представим, что все в семье хотят ехать только лицом друг другу, а таких групп мест – 4 вокруг стола – в вагоне только 2. С большой вероятностью такой семье придется пройти в следующий вагон (на следующий тик планирования). Это как раз та ситуация, как если бы вы выбрали 2 сокета по 2 ядра, чтобы получить 4. Скорее всего, придется подождать, чтобы нашлись подходящие места. Так же и с ВМ: ей придется ждать дольше, чем менее “прихотливым” ВМ с 1 сокетом и кучкой процессоров.

Хотя эта история актуальнее для старых версий ESXi. Начиная с 6.5 (но не ранее!) механизм vNUMA отвязан от количества виртуальных сокетов, и старая рекомендация “не плодить сокеты” не так категорична. Но все еще зависит от приложения внутри гостевой ОС.

Hot Add для CPU и Memory. Это опция добавления памяти CPU для работающей виртуальной машины. Казалось бы, прекрасная функция: не нужно гасить машину, чтобы докинуть ей ресурсов. Так вот, не все так просто, и не зря они по дефолту отключены. Лучше и не включать, если вы не знаете, что такое NUMA-топология. Допустим, под капотом облака у нас двухсокетный сервер. На каждом сокете 4 ядра. Работает это именно как 4+4, а не 8 ядер. Такая же тема с памятью: если на каждом сокете 128 ГБ, это не дает в сумме 256 ГБ. Каждый процессорный сокет имеет прямой доступ только к определенным слотам памяти. Каждый сокет вместе с причитающейся ему процессором и памятью – это физическая NUMA-нода.

Читайте также:  Билинейная трилинейная анизотропная что лучше

Если виртуальная машина влезает в размер физической NUMA-ноды, то она исполняется внутри этой ноды. Если виртуалка не умещается в NUMA-ноду, например по памяти, то она будет использовать память из соседней NUMA-ноды. Путь к удаленной памяти будет извилист – через межпроцессорную шину. Работать это будет не так быстро, как если бы виртуалка использовала ресурсы одной ноды.

Когда вы включаете добавления виртуальных процессоров и памяти на горячую, все это идет только в нулевую NUMA-ноду. Например, добавилось еще 4 процессора, и на NUMA-ноде 0 стало 6, а на NUMA-ноде 1 – 2 процессора. Машину немного перекосило, и работает она также косо. Это связано с тем, что при включении vCPU Hot-Plug перестает работать vNUMA, через которую vSphere старается оптимизировать топологию NUMA для ВМ. Поэтому, принимая решение о включении CPU Hot-Add, учитывайте физическую топологию NUMA для обеспечения производительности ВМ. Это очень критично, если по каким-либо причинам в ВМ имеется несколько виртуальных сокетов. В этом случае несоответствие физической топологии вызовет сильное падение производительности: CPU Scheduler сойдет с ума, пытаясь предоставить процессорное время такой ВМ, что вызовет рост CPU Ready и Co-Stop.


Все добавленные виртуальные процессоры (5-8) и память попали на NUMA-ноду 0.

Отдельная история в том, что будет происходить внутри ОС и приложения после таких “добавок”. Поэтому если уж решили пользоваться этой опцией, то проверьте, поддерживает ли ваша ОС такое. Non-NUMA-Aware приложения могут сильно просесть по производительности при расположении на нескольких NUMA-нодах.

Если вы все-таки добавили процессоры или память на горячую, сразу планируйте перезагрузку ВМ (не только ОС) на ближайший запланированный даунтайм.


Галочки не ставим.

Дисковый контроллер (Bus type). Для дисков выбирайте дисковый контроллер Paravirtual. Этот тип контроллера требует установки драйверов в ОС VMware Tools. Paravirtual – это специальное виртуальное устройство, которое создавалось для работы в виртуализации и не эмулирует работу какого-то другого аппаратного устройства. Любая эмуляция аппаратного устройства всегда работает медленнее.

Если вы не хотите использовать Paravirtual (но почему?), выбирайте LSI Logic SAS. Если ОС не поддерживает и его — LSI Logic Parallel. Никогда не используйте SATA и IDE. ВМ будет медленно работать, в итоге вы не получите производительности, за которой идут в облако.

При инсталляции ОС даже свежая версия Windows может не найти драйвер для Paravirtual адаптера. В этом случае примонтируйте к ВМ два ISO файла — ваш загрузочный образ Windows и диск с VMware tools. На последнем есть необходимый драйвер.

Сетевой адаптер. Правильный выбор – VMXNet3. VMXNet3, как и дисковый адаптер Paravirtual, это паравиртуальное устройство. Оно также требует драйверов, которые входят в VMware Tools.

Если вдруг VMXNet3 не подходит (проявляется какая-то несовместимость), то на крайний случай используйте E1000E. Но не ожидайте от адаптера E1000E производительности больше, чем 1 Гбит.

В общем, E1000E без прямых указаний вендоров не используйте. Казалось бы, оно новее, но сделано для обеспечения еще большей совместимости c legacy.


Вот не надо E1000E.

VMware Tools. Следите, чтобы они были установлены в ОС, запущены и актуальны. В VMware Tools входят драйвера устройств и разные другие компоненты, которые позволяют общаться ОС виртуальной машины с гипервизором, и наоборот. Через них происходит синхронизация времени ОС с хостом виртуализации (отключаемо), ходят heartbeat’ы, которые показывают гипервизору, что виртуалка жива, и прочее. Для работы ОС на виртуальной машине нужны как минимум драйверы сетевой карточки, дискового адаптера. Свежие версии всего вот этого входят в VMware Tools.

По умолчанию актуальные версии Windows и Linux имеют драйвера для работы с виртуальными устройствами VMware, но если у вас будут VMware Tools, то эти драйвера будут всегда свежими. Для Linux рекомендуется использовать open-vm-tools. Это не просто лучшая интеграция с ОС, но и обновление драйверов вместе с системой.

Отдельные диски для данных. Используйте разные виртуальные диски под данные и операционную систему. Да и на физических серверах стоит так делать. Вы сможете отдельно бекапить эти диски (с разным расписанием, например), сможете переключить диск с данными или его клон на другую ВМ и прочее.

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

Кастомизация. При первом включении ВМ нужно кастомизировать, чтобы все настройки из облака (например выданный облаком IP-адрес) применились к ОС. После уберите эту галку от греха подальше, чтобы нечаянно не сбросить настройки ОС: SID, пароль администратора и т. п.

Конечно, все вышесказанное – упрощенная картина, слова “капитана О” и, вообще, “все же это знают”. Но, как показывает практика, более 70% ВМ в облаке содержат одну или сразу несколько описанных ошибок.

OpenCL: Confused by CL_DEVICE_MAX_COMPUTE_UNITS

I’m confused by this CL_DEVICE_MAX_COMPUTE_UNITS. For instance my Intel GPU on Mac, this number is 48. Does this mean the max number of parallel tasks run at the same time is 48 or the multiple of 48, maybe 96, 144. (I know each compute unit is composed of 1 or more processing elements and each processing element is actually in charge of a «thread». What if these each of the 48 compute units is composed of more than 1 processing elements ). In other words, for my Mac, the «ideal» speedup, although impossible in reality, is 48 times faster than a CPU core (we assume the single «core» computation speed of CPU and GPU is the same), or the multiple of 48, maybe 96, 144.

2 Answers 2

Summary: Your speedup is a little complicated, but your machine’s (Intel GPU, probably GEN8 or GEN9) fp32 throughput 768 FLOPs per (GPU) clock and 1536 for fp16. Let’s assume fp32, so something less than 768x (maybe a third of this depending on CPU speed). See below for the reasoning and some very important caveats.

A Quick Aside on CL_DEVICE_MAX_COMPUTE_UNITS: Intel does something wonky when with CL_DEVICE_MAX_COMPUTE_UNITS with its GPU driver.

From the clGetDeviceInfo (OpenCL 2.0). CL_DEVICE_MAX_COMPUTE_UNITS says

The number of parallel compute units on the OpenCL device. A work-group executes on a single compute unit. The minimum value is 1.

However, the Intel Graphics driver does not actually follow this definition and instead returns the number of EUs (Execution Units) — An EU a grouping of the SIMD ALUs and slots for 7 different SIMD threads (registers and what not). Each SIMD thread represents 8, 16, or 32 workitems depending on what the compiler picks (we want higher, but register pressure can force us lower).

A workgroup is actually limited to a «Slice» (see the figure in section 5.5 «Slice Architecture»), which happens to be 24 EUs (in recent HW). Pick the GEN8 or GEN9 documents. Each slice has it’s own SLM, barriers, and L3. Given that your apple book is reporting 48 EUs, I’d say that you have two slices.

Maximum Speedup: Let’s ignore this major annoyance and work with the EU number (and from those arch docs above). For «speedup» I’m comparing a single threaded FP32 calculation on the CPU. With good parallelization etc on the CPU, the speedup would be less, of course.

Each of the 48 EUs can issue two SIMD4 operations per clock in ideal circumstances. Assuming those are fused multiply-add’s (so really two ops), that gives us:

So your ideal speedup is actually

768. But there’s a bunch of things that chip into this ideal number.

  1. Setup and teardown time. Let’s ignore this (assume the WL time dominates the runtime).
  2. The GPU clock maxes out around a gigahertz while the CPU runs faster. Factor that ratio in. (crudely 1/3 maybe? 3Ghz on the CPU vs 1Ghz on the GPU).
  3. If the computation is not heavily multiply-adds «mads», divide by 2 since I doubled above. Many important workloads are «mad»-dominated though.
  4. The execution is mostly non-divergent. If a SIMD thread branches into an if-then-else, the entire SIMD thread (8,16,or 32 workitems) has to execute that code.
  5. Register banking collisions delays can reduce EU ALU throughput. Typically the compiler does a great job avoiding this, but it can theoretically chew into your performance a bit (usually a few percent depending on register pressure).
  6. Buffer address calculation can chew off a few percent too (EU must spend time doing integer compute to read and write addresses).
  7. If one uses too much SLM or barriers, the GPU must leave some of the EU’s idle so that there’s enough SLM for each work item on the machine. (You can tweak your algorithm to fix this.)
  8. We must keep the WL compute bound. If we blow out any cache in the data access hierarchy, we run into scenarios where no thread is ready to run on an EU and must stall. Assume we avoid this. ?. I’m probably forgetting other things that can go wrong.
Читайте также:  Da dl all with checksum что это

We call the efficiency the percentage of theoretical perfect. So if our workload runs at

530 FLOPs per clock, then we are 60% efficient of the theoretical 768. I’ve seen very carefully tuned workloads exceed 90% efficiency, but it definitely can take some work.

Thread: Per core overclocking

Thread Tools
Search Thread
Display
  • Linear Mode
  • Switch to Hybrid Mode
  • Switch to Threaded Mode

Per core overclocking

Hey guys, just a quick question, i currently have my CPU running stable, however it is running 3 cores at 45x and one core at 44x, is this optimal, the 4th core doesnt seem to want to go over 44x without a BSOD? will the 3 cores work at 45x whilst the one runs at 44x? Sorry i’ve never really messed with per core overclocks before 😛

Also, CPU Cache, is it better to be higher or lower? im guessing higher but i’ve currently left mine at 35x

Bclck is 100mhz btw

Last edited by Smithy1294; 03-30-2014 at 03:31 PM .

ROG Guru: Blue Belt Array jab383 PC Specs

jab383 PC Specs
Motherboard24/7 rig : Maximus VI Extreme
Processori7 4790K
Memory (part number)16GB Mushkin Redline 2400 10-12-12-28 + 16GB Corsair Vengeance 2400 10-12-12-31
Graphics Card #1AMD Firepro W5000
Sound CardM6E Supreme FX
MonitorDell U2413
Storage #1Kingston SH103S3240G SSD
Storage #2Seagate ST1000DM003 1TB
CPU CoolerCustom water loop, Delidded, Liquid Metal TIM
CaseCoolerMaster HAF XM
Power SupplyCorsair HX-750
KeyboardLogitech G710+
MouseLogitech M705
OSWindows 7 64 Pro

Join Date Feb 2014 Reputation 107 Posts 848

We’ll need a few more details to be of real help — motherboard and CPU to start.

Guessing that you have a Haswell, they are all different and need to be individually stroked. I haven’t personally had a case where one core had to lag behind the others to avoid blue screens.

Cache is better higher, but only by a little. It’s often best to leave cache clock low to avoid uncertainty when the setup crashes. After you get a stable core overclock, then raise cache. Most commonly, cache ends up 200 to 300 MHz lower than core with about the same Vcache as Vcore.

Motherboard — Maximus VI Hero
CPU — I7 4770K

huh, i’ve literally been testing this setup all morning, just did another stress test and get WHEA_UNCORRECTABLE_ERROR which is the vcore error right? i’ll try bumping my vcore up but like i say i’ve had it working fine all morning o.O

Nevermind i think its AI Suite 3 lying to me, in bios all cores are at 44x

ROG Guru: Green Belt Array Tokens210 PC Specs

Tokens210 PC Specs
MotherboardMaximus VI Formula
ProcessorI7-4770K
Memory (part number)F3-2400C10D-16GTX Gskill TridentX (8gbx2)
Graphics Card #1EVGA GTX 550TI 1gb
Sound CardSupreme FX on board
Storage #12x Samsung Evo 120gb
Storage #2WD 1TB
CPU CoolerSwiftech H320
CaseCoolermaster HAF 932 Advanced
Power SupplyCorsair HX850 80+ Platinum
OSWindows 7 64-bit

Join Date Feb 2014 Reputation 25 Posts 517

the haswells are super touchy, i had mine running 45 on all cores with a min max cache of 45 on 1.380v and it worked flawless and stable for like 3 days then wouldnt boot anymore till i bumped it to 1.400v

also the processor can ramp up or down if you have balanced power plan on (this is the plan you want for everyday use)
meaning it may show different cores at different speeds depending on what there doing at that time

to answer your cache question, closer to your core number is better
meaning you have 44 on all cores
then 44 or closest to 44 as you can get would be best
problem is with some of these chips they cant push a «native» cache as its called without a butt load more power

so heres how youd wanna go about it
1. remember your current setup just in case
2. in bios load optimized defaults (sometimes you dont need to, but its usually best to wipe other setting out first cause some can actually stick)
3. sync all cores (44)
4. min/max leave on auto for now
5. voltage go manual and start at 1.200v work you way up by .025 so (1.200, 1.225, 1.250, 1.275, 1.300) until the pc will boot you didnt list what kind of cooler you have so id say for now just keep checking temps and dont just jump into anything higher then 1.380 just yet till you know you can cool it
6. once pc boots run a stress test or even the realbench benchmark test, have a temp program like realtemp, something that show you core temps as ai suite is only showing you cpu package temp and your actual temps are probly much higher then its showing
7. if it crashes and your temps were ok, increase voltage a little, try again
8. if it doesnt crash and alls good, slowly start raising the min/max cache up to 44, by default it should be at 39 so start there 39 on min/max cache boot and test
9. if it fails and temps are good go a bit more voltage, if it passes raise the min/max to 40 and try again, so on and so forth

as i said above some of these chips its hard to get the min/max to match the cores without a lot of power so you may end up a bit lower

i personally max at out 45 on all cores but my min/max has to be 44 or it requires so much power i cant cool it good enough and im running a 360mm closed loop cooler

Last edited by Tokens210; 03-30-2014 at 05:35 PM .

Ссылка на основную публикацию
Adblock
detector