Персональные компьютеры и ноутбуки с многоядерными процессорами имеют огромные вычислительные способности. Благодаря параллельной работе всех ядер устройство способно показывать впечатляющие показатели в компьютерных играх и программах. В данной статье мы разберемся, как включить все ядра на Windows 10, с помощью каких приложений можно посмотреть информацию о процессоре и так далее.
В зависимости от загруженности компьютера уровень занятости каждого ядра может отличаться от других. К тому же каждое ядро способно работать на отдельно установленной частоте из-за настроек BIOS или программного обеспечения материнской платы. Нагрузка на комп распределяется равномерно, из-за чего вы получаете высокую производительность.
Существует только один случай, когда двухъядерный процессор не будет задействовать второе ядро, – это процедура включения PC. Чтобы запустить операционную систему и привести компьютер в готовность, BIOS использует ресурсы только одного ядра. Вы можете задействовать все ресурсы и немного ускорить процесс включения компьютера. Однако ждать существенных изменений не стоит – ускорения включения ПК необходимо добиваться другими методами (например, установить ее на SSD).
Вы можете активировать все 4 ядра в 4-ядерном процессоре при загрузке компьютера следующими способами:
Описанные далее инструкции подходят для 32 bit и 64 bit OS. Поддерживаются версии Home, Pro и Enterprise. Для того, чтобы компьютер начал использовать всю мощность при запуске, необходимо провести следующую операцию:
Совет: нельзя устанавливать максимальный объем памяти менее 1024 МБ, чтобы не добиться обратного эффекта – замедления загрузки компьютера.
После сохранения настроек необходимо посмотреть, сколько ядер работает теперь. Если все параметры сбросились, то уменьшите «Максимум памяти» и снова протестируйте. Чтобы не проводить повторно данную процедуру, в окне «Конфигурация системы» поставьте галочку напротив пункта «Сделать эти параметры загрузки постоянными» и завершите работу кнопкой «ОК».
Стоит предупредить, что изменение настроек BIOS рекомендуется только в том случае, если ваш персональный компьютер перестал загружаться. Без минимальных знаний не советуем вам пользоваться данным методом, если работает вышеописанный.
Итак, для включения многоядерного процессора необходимо:
Теперь вы знаете, как сделать загрузку компьютера с помощью всех ядер процессора.
Вы можете узнать, сколько ядер работает в вашем ПК и какие характеристики имеет ЦП следующими способами:
Сначала разберемся со встроенными возможностями операционной системы.
Посмотреть информацию о процессоре и его характеристиках вы можете следующим образом:
Подробнее узнать об оборудовании вы сможете через «Диспетчер устройств». Все способы открыть данную программу представлены ниже:
Окно приложения выглядит так:
В нем необходимо развернуть ветку «Процессоры». На скриншоте представлен 4-ядерное устройство, поскольку вы видите 4 одинаковые строки. Кликните правой кнопкой мыши по одной из строк и выберите пункт «Свойства». В открывшемся окне вы можете найти всю информацию по процессору.
Если вас не устраивает функционал «Диспетчера устройств», вы можете установить одну из сторонних утилит. Самыми распространенными являются CPU-Z, AIDA64 и Everest.
CPU-Z можно загрузить с официального сайта по ссылке . При первом запуске утилита соберет данные о вашей конфигурации ПК. В первой вкладке вся информация о ЦП:
В остальных вкладках вы найдете подробное описание другого оборудования. Например, в SPD будет подробное описание оперативной памяти (Module Size, Manufacturer и так далее).
Программа AIDA64 загружается с ресурса создателей . В левой части окна необходимо открыть ветку «Системная плата» и перейдите в подраздел ЦП. В графе Multi CPU будет указано количество процессоров:
Последняя утилита – Everest . Она очень схожа с предыдущим софтом. В ней также вся интересующая вас информацию о ЦП находится в разделе «Системная плата»:
Включение многопоточности возможно только для операции запуска персонального компьютера. Во всех остальных случаях ЦП задействует все ресурсы одновременно, поэтому надобность ручной настройки отпадает.
Ниже представлена видеоинструкция с подробным описанием всех действий и операций из данной статьи. С помощью наглядного пособия вы сможете разобраться в непонятных для вас моментах и шагах руководства.
С появлением многоядерных процессоров возникла необходимость в создании игрового движка на основе параллельной архитектуры. Использование всех процессоров системы - как графического (ГП), так и центрального (ЦП) - открывает гораздо больше возможностей по сравнению с однопоточным движком на базе только ГП. Например, используя больше ядер ЦП, можно улучшить визуальные эффекты, увеличив количество физических объектов, используемых в игре, а также добиться более реалистичного поведения персонажей за счет реализации продвинутого искусственного интеллекта (ИИ).
Рассмотрим особенности реализации многопоточной архитектуры игрового движка.
Для понимания представленных материалов нужно хорошо разбираться в современных методах создания компьютерных игр, поддержки многопоточности для игровых движков или для улучшения производительности приложений в целом.
Рисунок 1. Состояние выполнения в свободном пошаговом режиме
Рисунок 2. Состояние выполнения в жестком пошаговом режиме
Рисунок 3. Общая архитектура движка
Обратите внимание, что функциональные игровые модули, или системы, не являются частью движка. Движок лишь объединяет их между собой, выступая в роли связующего элемента. Подобная модульная организация дает возможность загружать и выгружать системы по мере необходимости.
Взаимодействие движка и систем осуществляется при помощи интерфейсов. Они реализованы таким образом, чтобы предоставить движку доступ к функциям систем, а системам - к менеджерам движка.
Подробная схема движка представлена в приложении A, «Схема движка».
Фактически все системы независимы друг от друга (см. раздел 2, «Состояние одновременного выполнения»), то есть они могут выполнять действия параллельно, не влияя на работу других систем. Однако любое изменение данных повлечет за собой определенные сложности, поскольку системам придется взаимодействовать между собой. Обмен информацией между системами необходим в следующих случаях:
Рисунок 4. Основной цикл игры
Движок работает в оконной среде, поэтому на первом шаге цикла игры необходимо обработать все незавершенные сообщения окон ОС. Если этого не сделать, движок не будет реагировать на сообщения ОС. На втором шаге планировщик назначает задачи с помощью менеджера задач. Этот процесс подробно описан в разделе 3.1.1 ниже. После этого менеджер состояний (см. раздел 3.2.2) рассылает информацию о выполненных изменениях системам движка, на работу которых она может повлиять. На последнем шаге, в зависимости от статуса выполнения, фреймворк определяет, следует ли завершить или продолжить работу движка, например, для перехода к следующей сцене. Информация о состоянии движка хранится у менеджера среды. Подробнее см. в разделе 3.2.4.
Рисунок 5. Расширение универсальной сцены и объекта
Рассмотрим принцип работы расширений на следующем примере. Допустим, выполнено расширение универсальной универсальная сцены сцена расширена на для использование использования графических, физических и других свойств. В этом случае за инициализацию дисплея будет отвечать «графическая» часть расширения, а за реализацию физических законов для твердых тел, например силы тяжести, - его «физическая» часть. Сцены содержат объекты, поэтому универсальная сцена тоже будет включать в себя несколько универсальных объектов. Универсальные объекты также можно расширить намогут быть расширены для использование использования графических, физических и других свойств. Например, прорисовка объекта на экране будет реализована графическими функциями расширения, а расчет взаимодействия твердых тел - физическими.
Подробная схема взаимодействия движка и систем приведена в приложении B, «Схема взаимодействия движка и систем».
Следует заметить, что универсальная сцена и универсальный объект отвечают за регистрацию всех своих «расширений» в менеджере состояний, для того, чтобы все расширения могли получать уведомления об изменениях, внесенных другими расширениями (то есть другими системами). В качестве примера можно привести графическое расширение, зарегистрированное для получения уведомлений об изменениях положения и ориентации, выполненных физическим расширением.
Подробную информацию о компонентах системы см. в разделе 5.2, «Компоненты системы».
Планировщик передает менеджеру задач список задач для выполнения, а также информацию о том, завершения каких задач необходимо дождаться. Он получает эти данные от различных систем. Каждая система получает только одну задачу для выполнения. Такой метод называют функциональной декомпозицией. Однако для обработки данных каждую такую задачу можно разделить на произвольное количество подзадач (декомпозиция данных).
Ниже приведен пример распределения задач между потоками для четырехъядерной системы.
Рисунок 6. Пример пула потоков, используемого менеджером задач
Помимо обработки запросов планировщика по доступу к основным задачам менеджер задач может работать в режиме инициализации. Он последовательно опрашивает системы от каждого потока, чтобы они могли инициализировать локальные хранилища данных, необходимые для работы.
Советы по реализации менеджера задач даны в приложении D, «Советы по реализации задач».
Механизм работает следующим образом. 1. Наблюдатель сообщает контроллеру изменений (или менеджеру состояний), изменения каких субъектов он хочет отслеживать. 2. Субъект уведомляет контроллер обо всех своих изменениях. 3. По сигналу фреймворка контроллер оповещает наблюдателя об изменениях субъекта. 4. Наблюдатель отправляет субъекту запрос на получение обновленных данных.
В режиме свободного пошагового выполнения (см. раздел 2.1.1) реализация этого механизма несколько усложняется. Во-первых, обновленные данные придется отправлять вместе с уведомлением об изменении. В этом режиме отправка по запросу неприменима. Действительно, если на момент получения запроса система, ответственная за изменения, еще не закончит выполнение, она не сможет предоставить обновленные данные. Во-вторых, если какая-то система еще не готова получить изменения в конце такта, менеджер состояний должен будет удерживать измененные данные до тех пор, пока все зарегистрированные для их получения системы не придут в состояние готовности.
Во фреймворке для этого предусмотрено два менеджера состояний: для обработки изменений на уровне сцены и на уровне объекта. Обычно сообщения, касающиеся сцен и объектов, независимы друг от друга, поэтому использование двух отдельных менеджеров исключает необходимость обработки ненужных данных. Но если в сцене необходимо учитывать состояние какого-либо объекта, ее можно зарегистрировать на для получение получения уведомлений о его изменениях.
Чтобы не выполнять лишней синхронизации, менеджер состояний формирует очередь уведомлений об изменениях отдельно для каждого потока, создаваемого менеджером задач. Поэтому при доступе к очереди никакой синхронизации не требуется. В разделе 2.2 описан метод, который можно использовать для объединения очередей после выполнения.
Рисунок 7. Уведомление о внутренних изменениях универсального объекта
Уведомления об изменениях не обязательно рассылать последовательно. Существует способ их параллельной рассылки. Выполняя задачу, система работает со всеми своими объектами. Например, по мере того как физические объекты взаимодействуют друг с другом, физическая система управляет их перемещением, расчетом столкновений, новых действующих сил и т. п. При получении уведомлений объект системы не взаимодействует с другими объектами своей системы. Он взаимодействует со связанными с ним расширениями универсального объекта. Это означает, что универсальные объекты теперь независимы друг от друга и их можно обновить одновременно. Такой подход не исключает крайних случаев, которые следует учитывать в процессе синхронизации. Однако он позволяет использовать режим параллельного выполнения, когда казалось, что действовать можно только последовательно.
Рисунок 8. Пример менеджера служб
У менеджера служб есть и другая функция. Он предоставляет системам доступ к свойствам других систем. Свойствами называются специфичные значения конкретных систем, которые не передаются в системе обмена сообщениями. Это может быть расширение разрешение экрана в графической системе или величина силы тяжести в физической. Менеджер служб открывает системам доступ к таким данным, но не позволяет напрямую их контролировать. Он помещает изменения свойств в специальную очередь и публикует их только после последовательного выполнения. Обратите внимание, что доступ к свойствам другой системы требуется достаточно редко и не стоит им злоупотреблять. Например, он может понадобиться для включения и отключения режима каркасной сетки в графической системе из окна консоли или для изменения разрешения экрана по запросу игрока из интерфейса пользователя. Данную возможность преимущественно используют для установки параметров, которые не изменяются от кадра к кадру.
Менеджер платформы также отвечает за предоставление информации о процессоре, например о поддерживаемых SIMD-инструкциях, и за инициализацию определенного режима работы процессов. Других функций формирования запросов системы использовать не могут.
Интерфейсы определяют набор функций, необходимых для использования стандартного метода доступа. Это избавляет фреймворк от необходимости знать детали реализации конкретных систем, поскольку он может взаимодействовать с ними только посредством определенного набора вызовов.
Рисунок 9. Компоненты системы
Подробная схема связей между системами движка приведена в приложении B, «Схема взаимодействия движка и систем».
В определенных случаях в системном объекте необходимо учитывать изменения универсального объекта или одного из его расширений. Для этой цели можно создать специальную связь, которая позволит отслеживать выполненные изменения.
Рисунок 10. Инициализация менеджеров и систем движка
Рисунок 11. Инициализация универсальной сцены и объекта
Рисунок 12. Менеджер задач и задачи
Шаблон «Наблюдатель» - это функция механизма обмена сообщениями. Важно хорошо понимать принцип ее работы, чтобы выбрать оптимальный способ ее реализации для движка. Фактически это механизм взаимодействия между различными системами, который обеспечивает синхронизацию общих данных.
Важную роль в распределении нагрузок играет управление задачами. В приложении D приведены советы по созданию эффективного менеджера задач для игрового движка.
Как видите, многопоточность игрового движка удается реализовать благодаря четко определенной структуре и механизму обмена сообщениями. С ее помощью можно значительно повысить производительность современных и будущих процессоров.
Основная идея данной модели заключается в следующем: если каким-то элементам необходимо получать уведомления об изменениях других элементов, они не обязаны просматривать список всех возможных изменений, пытаясь найти в нем нужные данные. Модель подразумевает наличие субъекта и наблюдателя, которые используются для отправки уведомлений об изменениях. Наблюдатель отслеживает любые изменения субъекта. Контроллер изменений выступает в роли посредника между этими двумя данными компонентами. Следующая схема иллюстрирует данную связь.
Рисунок 13. Шаблон «Наблюдатель»
Ниже описан процесс использования данной модели.
Твитнуть
Заблуждений, касающихся работы компьютера, предостаточно. Какие-то очень популярны, какие-то широко известны в узком кругу. Я выбрал парочку особо живучих, поддерживаемых верой тех, кто любит заниматься оптимизацией компьютера . Их опровержение не требует долгих объяснений нюансов работы операционной системы, программ и процессора. Достаточно использовать логику.
Прежде чем приступлю к описанию мифов, напишу несколько тезисов, на которые буду опираться в дальнейшем. Если вы не согласны со мной - подумайте дважды, почему. Может быть, мы с вами живём в параллельных вселенных?
Итак, вот тезисы, которые для меня являются истиной, подкреплённой фактами и знаниями. Надеюсь, после внимательного прочтения вы поймёте, к чему я веду.
1.Операционная система (ОС) - посредник между «железом» компьютера и программами (играми в том числе). В данном случае речь о Windows. Именно ОС и запущенные драйвера рисуют на экране картинку, обеспечивают запуск программ и позволяют запущенному софту использовать ресурсы компьютера: процессор, оперативную память, видеокарту, сеть и тому подобное. Фактически Windows состоит из ядра - небольшой, но сложной программки, которая регулирует приоритеты выдачи ресурсов, отвечает за изоляцию программ и делает много чего ещё, связанного с функционированием софта, запущенных драйверов, которые взаимодействуют с железом компьютера посредством функций ядра и собственно изолированной от железа части, где и крутятся наши игры, браузеры и прочее. Кто хочет узнать подробнее, может почитать статью на Википедии «Архитектура Windows NT», но это не обязательно. Главное знать, что система - посредник между физической частью ПК и теми программами, с которыми обычно работаем мы, люди.
2. Возможности операционной системы определяют возможности софта. У прикладных программ и игр, которые мы видим на экране, нет прямого доступа к железу компьютера, они всегда работают через посредника - ОС. Если Windows (и установленные в неё драйвера) чего-то не умеют, то программы до этого «чего-то» не доберутся. Например, для звуковой карты моего старого ноутбука есть несколько версий драйверов. Так получилось, что в одном драйвере можно регулировать усиление звука микрофона, а в другом такой регулировки нет, зато можно включить улучшение звука технологией Dolby Surround. Поэтому, если я хочу послушать музыку, мне приходится ставить драйвер с Dolby Surround. Когда записываю видеоурок, ставлю другой, где микрофон работает гораздо лучше. Увы, ни одна программа не может обойти эти ограничения и дать доступ ко всему сразу, потому что нет драйвера, где есть обе упомянутые функции. Это правило соблюдается всегда. У игр нет прямого доступа к железу, только через посредника. Например, графика часто создаётся с помощью команд но в контексте данной статьи это не важно.
3. Создатели операционных систем никогда не стремятся намеренно ограничивать производительность компьютера. Иначе будет а-та-та и много исков. Например, Apple наказали штрафом на 5 000 000 евро, когда выяснилось, что ОС старых моделей айфонов снижает производительность со временем. И ещё на 5 миллионов евро за то, что функция замедления работала тайно, без уведомления владельцев устройств. То есть нужно понимать, что если бы в Windows была какая-то функция, без явного уведомления пользователей как-то снижающая скорость вычислений ЦП, отключающая ядра процессора или ограничивающая возможности железа, то об этом бы писали во всех технических (и не только) СМИ. Были бы иски и репутационные потери. Но этого нет и не будет, потому что семейство Windows исследовано вдоль и поперёк, там не осталось спорных моментов.
Надеюсь, вы прочли написанное выше. Мифы оптимизации компьютера, связанные с отключением и включением ядер, о которых я расскажу ниже, как раз построены на неверии в правдивость этих тезисов. Почему-то многие верят в то, что Microsoft не даёт «раскрыться» компьютеру без ковыряния в настройках.
Совет изменения настроек в системной утилите MSConfig основан на допущении, что Windows при загрузке не использует все ядра процессора и мегабайты оперативной памяти. Якобы нужно указать их нужное количество с помощью «секретной» настройки, чтобы компьютер быстрее включался и всё быстрее работало.
До «секретной» опции можно добраться так: Пуск - Выполнить (в Windows 10 используйте поле поиска вместо Выполнить ) - msconfig - OK.
Запустится программа Конфигурация системы (msconfig.exe). Вкладка :
Нужно нажать Дополнительные параметры, чтобы открыть параметры загрузки Windows и там будут вожделенные «суперсекретные» опции:
Пока очумелые ручки не добрались до настроек, здесь ничего указано не будет, галочки проставлены не будут. С чего бы разработчикам Windows ограничивать производительность системы?
Но люди, не использующие критическое мышление, думают иначе: раз изначально галка не стоит, значит, ограничение включено. Якобы отсутствие галочек не даёт операционной системе узнать, сколько ядер у процессора и сколько оперативной памяти установлено. И якобы нужно указать вручную:
И после перезагрузки компьютер начнет использовать все ресурсы. Это противоречит третьему тезису о том, что Microsoft не ограничивает производительность изначально.
Вариантов у этого совета несколько. Я прошёлся по сайтам, посвящённым оптимизации Windows, выбрав парочку. Например, некий Юрий считает, что по умолчанию установлена загрузка с одного ядра:
Другие вспоминают про оперативную память. «Блог мастера ПК» утверждает, что с ней та же беда.
Начало совета
Я обрезал часть текста, чтобы не было длинного скриншота. Вот что автор советует дальше:
Он советует указать не только количество ядер, но и размер памяти. А в конце говорит, что можно снять галочку.
Стоп. Где логика? Устанавливается опция, после отключается, как такая манипуляция может на что-то влиять в принципе?
Откуда миф? Полагаю, дело не только в незнании матчасти советчиков и отсутствии логического мышления, но и неоднозначной официальной справке по MSConfig. В статье MSConfig the System Configuration Tool на официальном сайте Microsoft описание опций действительно оставляет место домыслам, если не знать контекста:
Перевод: «Если вы нажмете на Advanced Options (в любой ОС), вы можете установить такие параметры, как количество процессоров, выделенных для операционной системы при загрузке, или максимальный объем оперативной памяти. (Как правило, обычно не отмечено)».
Текст официальной инструкции по использованию MSConfig не противоречит мифу: действительно можно указать, сколько процессоров и оперативной памяти использовать при загрузке. Вот только предназначены эти опции не для повышения производительности, а для ограничения в целях тестирования.
На самом деле Windows всегда использует все процессоры и ядра процессоров и всю оперативную память. Никто не думал ограничивать систему, да еще во время загрузки.
Опции в msconfig нужны программистам для тестирования программ, чтобы ограничить доступные ресурсы, сымитировав медленный ПК на быстром.
Если задуматься о репутационных потерях, о штрафах и прочем, возникает понимание, что миф о настройке в MSConfig - полная чушь. В каком бреду можно утверждать, что Windows не задействует все возможные ресурсы при загрузке компьютера? Ведь в интересах разработчиков Windows сделать так, чтобы компьютер включался как можно быстрее без шаманств в настройках. Вводить ограничения глупо.
Некоторые «гении» пытаются доказать, что опция «Число процессоров» ускоряет компьютер, потому что при значении 1 игры начинают тормозить. Логики в этом аргументе нет. При включенном лимите на одно ядро производительность действительно снижается (особенно это заметно в играх), но по умолчанию ограничения выключены и программы вольны использовать все ядра, как им вздумается. То есть опции в MSConfig работают так, как задумано - позволяют при желании пользователя ограничивать ресурсы ПК.
К счастью, данный совет о настройках в MSConfig безвреден. Установка максимальных значений никак не влияет на работу компьютера, ведь результат тот же, что и при выключенных опциях.
Для самых непонятливых: просто снимите галочки.
Не имеет никакого значения, что там в полях - одно ядро или миллион. Не важно, что там в поле «Максимум памяти». Во что вы играете, насколько старое у вас железо - тоже не имеет никакого значения. Просто снимите все галки, нажмите ОК и живите спокойно дальше. Нет никаких тайных настроек в MSConfig для «разблокирования» процессорных ядер и памяти.
Второй миф объяснить сложнее. Дело в том, что программы работают совсем не так, как представляется пользователям ПК. А где много невежества, там много эффекта Даннинга - Крюгера и, конечно, мифов.
Недовольные скоростью запуска программ, частотой смены кадров в играх, люди любят смотреть потребление ресурсов ЦП в Диспетчере задач и заниматься бессмысленными попытками что-то оптимизировать . К примеру, пытаются регулировать параметры вроде предыдущей настройки, чтобы их любимая программа загружала на 100% все ядра процессора.
Проблема в том, что многие манипуляции, популярные благодаря магическому мышлению, на деле в лучшем случае бесполезны. Это сродни использованию чехлов для телефонов, защищающих тело от «вредной» радиации. Знающие физику люди только покрутят пальцем у виска, в то время как остальные скупают чехлы пачками и рекомендуют знакомым поступать так же.
Но вернёмся к работе программ на многоядерных процессорах. На границе знания и незнания возникла «гениальная» идея использовать программу CPU Control для назначения играм всех ядер.
Совет начал встречаться более десяти лет назад. Например, при обсуждении игры Gothic 3, которая любила тормозить на любом, даже самом мощном ПК:
На скриншоте выше пользователь s063r посчитал, что игра не задействует второе ядро процессора. Товарищ Shifroval посоветовал использовать программу CPU Control.
Что же это за чудо-зверь такой , который залезает в программный код и заставляет программу изменить логику своей работы? CPU Control - это примитивная утилита для назначения процессу одного или нескольких ядер процессора:
К сожалению, разработчики этой софтины поступили глупо, сделав так, что при запуске все запущенные программы автоматически «назначаются» на первое ядро процессора (включается некий режим «Manual»). Обратите внимание на столбец «CPU» при запуске CPU Control:
Единица и три нуля означают, что программе назначено только первое по счету ядро процессора (четырёхъядерного, по мнению CPU Control). И это происходит после запуска самой утилитой. То, что до запуска ситуация была иной, с помощью CPU Control увидеть нельзя. Можно, конечно, до всех манипуляций глянуть назначения процессов на ядра в Диспетчере задач, но кто в наше время мыслит критически и проверяет работу программ родными утилитами Windows?
То есть получается нехорошая ситуация: человек запускает CPU Control и видит - о ужас - все программы назначены только на одно ядро!
Ложный совет звучит так: программы работают только на одном ядре, в чем можно убедиться, запустив CPU Control. И там можно назначить программе использование всех ядер процессора.
Но это абсолютно неверное утверждение легко опровергнуть. Если до запуска утилиты CPU Control запустить Диспетчер задач и на вкладке «Подробности» нажать по любому процессу правой кнопкой мыши и выбрать пункт «Задать сходство», то становится понятно, что изначально программам всегда доступны все ядра:
На самом деле до запуска CPU Control ограничений на одно ядро не было. Это сама утилита при запуске назначает всем программам первое по счёту ядро. Назначение через CPU Control на все ядра возвращает настройку по умолчанию. Только и всего.
Если задействовать критическое мышление, возникнут вопросы:
Ответ прост: CPU Control не делает того, что ей приписывают. Более того, на умение софта «задействовать» все ядра процессора нельзя повлиять извне. Это, в общем-то, внутреннее дело программ - в зависимости от алгоритмов некоторые задачи могут выполняться параллельно на нескольких ядрах, а могут только на одном. Даже слово «назначить» тут не совсем верное - правильнее употреблять «ограничить».
Без переписывания исходного кода программ как-то повлиять на то, сколько и как ядра ЦП будут «задействоваться», невозможно. Ограничить или дать потенциальную возможность - да, можно. А «задействовать», если изначально программа этого не умеет - нет, никак. Это как если бы человеку, который привык считать на калькуляторе, подсунули второй и сказали: считай на двух! Это бы ускорило его работу? Нет, конечно.
Задачу, которая предназначается для одного потока, нельзя запараллелить влиянием извне. Нужно менять саму задачу, применять другие алгоритмы. Это касается не только компьютеров, а вообще всех сфер деятельности - от производственных процессов до офисной работы.
Однако в интернете и в комментариях под этим текстом люди на полном серьёзе убеждают, что утилита помогает, что игры начинают работать быстрее. Неправы ли они? Не совсем!
Миф очень живуч, потому что иногда переназначение софта на разные ядра делает компьютер отзывчивее. Происходит в ситуации, когда в системе запущен процесс, сильно нагружающий процессор, о которой юзер из-за неумения пользоваться системным Монитором ресурсов не знает. Это может быть какой-нибудь скрытый вирус-майнер или вкладка браузера с большим количеством тяжёлых элементов на странице (видео, онлайн-игр, рекламы). Тогда назначение только на одно ядро ограничивает доступные зловреду ресурсы и дает возможность остальным ядрам процессора работать на благо игры, ведь пользователь назначит ей все ядра. Но это лечение симптома, не решение проблемы.
Как нужно настраивать на самом деле?
Тогда получите что хотели: увеличение производительности ПК.
Кстати, CPU Control на восьмиядерных системах видит только четыре ядра. Ждём советы по включению пропавших ядер?
Сегодня существуют компьютеры, вычислительной мощностью которых уже мало кого удивишь. 4-х или 6-ти ядерные ПК и ноутбуки не удивляют людей, но находятся и новички в этой области, которым все интересно и хочется узнать, как можно больше информации. Сегодня мы разберем интересный вопрос: как включить все ядра на компьютере с Windows 10 для увеличения его производительности.
Если вы хотите узнать, то это можно узнать, например, с помощью программ, руководству к компьютеру или штатных возможностей Windows. Теперь разберем все возможные способы.
Если у вас есть документы к компьютеру, то сведения о ядрах можно посмотреть там, в разделе о ЦП. Тоже самое можно сделать и в интернете, вбив модель своего процессора, и посмотреть все необходимые характеристики.
Сведения о ЦП можно посмотреть, если перейти в соответствующее меню. Для этого нажимаем правой кнопкой мыши по меню Пуск, выбираем «Система» , смотрим на блок «Система» . Но там показывается только модель процессора, остальное придется искать где-то еще.
Откроем диспетчер устройств. Это можно сделать, если ввести в поле поиска «диспетчер устройств» .
Находим вкладку «Процессоры» и раскрываем ее. Сколько там пунктов находится, столько и ядер на вашем процессоре.
Теперь разберем несколько сторонних программ, которые помогут нам определить количество ядер в процессоре.
CPU-Z
Полезная и бесплатная программа CPU-Z отображает множество характеристик компьютера, а точнее, его компонентов. Она легка и не требовательна.
Для того, чтобы посмотреть информацию о ядрах, переходим во вкладку ЦП и смотрим строчку «число активных ядер» .
Эту программу я упоминал уже не раз в своих статьях. Она содержит полный комплект информации о всех компонентах компьютера.
Скачайте программу, запустите, потом переходите во вкладку «Системная плата» , далее «ЦП» . Блок «Multi CPU» отображает нам количество ядер.
В той же самой программе можно перейти во вкладку «Компьютер» , потом «Суммарная информация» в блоке «Системная плата» нажимаем на названии процессора, где строка «Типа ЦП» .
Некоторые думают, что в многоядерном компьютере работают не все ядра, на самом деле это не так, работают они все и всегда, но на разной частоте.
Дело в том, что при большом количестве ядер, происходит лишь оптимизация работы, то есть, данные обрабатываются быстрее. Еще один момент. Если программа не оптимизирована под несколько ядер, то, сколько бы их не было в компьютере, программа все равно будет использовать только определенное количество.
Никак. Ядра на всех современных компьютерах всегда работают без ограничений. Зачем разработчикам ограничивать работу процессора и памяти, особенно при запуске Windows.
Заметьте, что если галочки в утилите MSConfig, которая описана ниже выключены, это значит, что ограничений никаких нет. Но вы можете сами это сделать, поскольку эта утилита предназначена для тестирования программного обеспечения.
Даже если вы сейчас попробуете изменить настройки на максимальные, то ничего не изменится, можете убедиться в этом сами, используя нижеследующую инструкцию.
Здесь все просто, следуем вот этой инструкции:
После того, как все сделаете, сохраните изменения и перезагрузите компьютер.
Тут все немного сложнее. В стоит лезть только в случае нестабильной работы компьютера. Если глюков и тормозов не замечается, то все нормально и ядра обычно включены автоматически.
Если решили попробовать включить ядра через BIOS, то вам нужно перейти в раздел Advanced Clock Calibration и установите значение «All Cores» , либо «Auto» .
Сложность тут заключается в том, что в разных версия материнских плат и ноутбуках разделы в BIOS называются по-разному, сказать куда точно заходить не могу.
Таким образом, мы разобрали, как посмотреть ядра процессора, как задействовать все ядра для сокращения времени загрузки компьютера и бесполезность этого действа.))
При написании этой статьи я не ставил себе задачу описать некую программную реализацию, с помощью которой будут решены все проблемы связанные с применением многопоточности (МП) в . Здесь приводится пример всего лишь одной из возможных реализаций многопоточности в игровом движке, который был на практике использован в игре PulseRacer для Xbox. В последнее время тема МП в играх, как мне показалось, вызывает большой интерес у многих программистов. Причём существует много различной информации о системных функциях, различных синхро-объектах для использования многопоточности в программах, но как-то слабо освещена тема того, как применить все эти возможности в игре, не вынуждая каждого программиста работающего с этим проектом разбираться в принципах работы многопоточности, способах использования синхро-объектов и других ненужных ему вещах. Сейчас ведь мало кого удивишь тем что, игровой программист может слабо разбираться в системных функциях, D3D или , и действительно, зачем ему это, ведь есть графические движки (и их разработчики). Но тогда вполне логично предположить, что должен также существовать МП движок, который будет решать схожие проблемы. Вот об одной из возможных реализаций такого движка, причинах побудивших его написать, о проблемах и некоторых, на мой взгляд, удачных решениях и пойдёт речь в этой статье. Здесь я сразу предупрежу, что тема использования многопоточности в играх очень обширна и мне пришлось для уменьшения размера статьи некоторые очевидные или мало принципиальные, с моей точки зрения, решения не упоминать и не обосновывать, поэтому если возникнут вопросы, то я всегда готов их обсудить.
В самом деле, прежде чем рассуждать на тему реализации МП игрового движка стоит сперва определиться, нужна ли МП как таковая в играх, какие плюсы и минусы даст её применение. Вот несколько основных достоинств и недостатков МП, повлиявших на мои решения, при разработке движка.
1. Увеличение скорости работы программы, в том числе и в однопроцессорных системах. Может возникнуть вопрос, а откуда вообще появится прирост быстродействия у МП программ в однопроцессорных системах? Причина в том что, хотя центральный процессор всего один, он не единственный процессор, в компьютере есть ещё процессор видеокарты, контроллера дисков, звуковой карты, сетевой карты, контроллеры DMA, различной периферии и т.п., так вот, благодаря распараллеливанию операций со всеми этими процессорами и появится прирост производительности системы в целом. Примеры такого распараллеливания приведены ниже. Также не стоит забывать о таких технологиях как HyperThreading, благодаря которым даже в обычных игровых компьютерах начинает появляться многопроцессорность.
2. Ускорение отклика программы на внешние события , например от устройств ввода или от сетевых устройств. Ведь не секрет, что зачастую сетевой код выносят в отдельный поток, так как не мотивированное ожидание при приёме или отсылке сетевых пакетов может плохо сказаться на и без того не высокой скорости передачи по сети. Обработку устройств ввода (клавиатура, джойстик, мышь …) также, имеет смысл для удобства поместить в отдельный поток, так как очевидно, что работа с ними не должна зависеть от загруженности игры и замедленная реакция на них может ухудшить динамичность игры и вызвать приступ агрессии у пользователя с последующей порчей им периферийных устройств.
1.Усложнение кода игры и его читабельности, так как постоянные вызовы различных синхро-объектов уродуют код и затрудняют его понимание.
2. Необходимость разработки новых приёмов написания программы , так как старые не всегда приемлемы. Например, использование глобальных статических переменных в МП среде, где с переменной одновременно работают из разных потоков, неприемлемо из-за возможности порчи их содержимого.
3. Усложнение процесса отладки программы. Так в случае одновременного вызова одних и тех же функций из разных потоков становится проблемным использование внутри них точек останова и других стандартных приемов отладки.
4. Увеличение количества скрытых ошибок, не всегда выявляемых при отладке. Постоянное использование всеми программистами, работающими над проектом, различных синхронизирующих механизмов увеличивает шансы на возникновение dead lock или live lock в трудно обнаружимые моменты времени.
5. Снижение предсказуемости в работе программы , т.к. порядок выполнения некоторых операций заранее не известен. Программа на разных машинах в разных условиях работает по-разному. К примеру, усложняется ловля утечек и порчи памяти, т.к. карта распределения памяти с каждым запуском программы может меняться.
Итак, недостатков хватает, а достоинств немного. Из чего можно сделать вывод, что если у программы нет проблем с быстродействием или с реакцией на внешние события, то МП ей нужна как собаке пятая нога и вопрос вроде как закрыт. Однако речь идёт о современных играх, которые страдают именно от этих проблем, так как хочется и на ввод пользователя быстро реагировать и fps большой иметь, при этом физику сделать реалистичной, AI продвинутый, анимацию сложной, и т.п. При таких запросах никакое быстродействие не будет лишним, борьба ведётся за каждую лишнюю наносекунду. В такой ситуации использование МП является не роскошью, а крайней необходимостью. Вот и в моём случае быстродействие перевесило все недостатки. Перевесило, но не исправило. В связи с чем и возникла необходимость написать МП движок, который решал хотя бы некоторые из перечисленных проблем.
Когда я начинал писать свой МП движок, мне пришлось перепробовать множество различных вариантов и многократно переписывать свой код. Самое обидное, что его написание походило на изобретение велосипеда, вроде МП всюду и давно используют, а информации о применении её в играх мало, только слухи и ничего конкретного. Поэтому за основу мне пришлось вначале взять уже отработанные методы, применявшиеся мной для написания МП серверов. В данном случае использовался класс потока, объект которого можно было динамически создавать и удалять. Класс потока мог выполнять функции, адреса которых ему передавались в процессе работы программы. Способ хорош тем, что его реализация проста, позволяет упростить процесс создания потоков и исполнения ими кода. Недостатки: сложности с синхронизацией потоков при использовании общих переменных, и относительно невысокая скорость динамического создания новых потоков. В случае применения этого метода в серверных приложениях недостатки нивелировались малым количеством общих переменных, так как каждый клиент на сервере достаточно независим и обособлен, а также невысокой скоростью сети по сравнению с процессором, что частично компенсировало медленное создание новых потоков. Но в игре последствия от применения данного метода оказались катастрофичны. Что привело к возникновению очередной модификации, где вместо создания и удаления потоков использовался созданный при старте программы пул потоков, а все общие переменные были помещены в специальные классы с методами Lock() и Unlock() , для синхронизации работы с ними. Данные изменения устранили недостатки, но привели к возникновению побочного эффекта, в частности ухудшение читабельности кода и провоцирования ошибок связанных с dead lock и live lock . Попытки устранить эти проблемы, сами по себе оказались мало эффективны и сильно усложнили код МП движка. В результате, попробовав еще несколько вариантов, мне пришлось отказаться от такой реализации, признав её неперспективной для применения в играх.
Экспериментируя с различными вариантами МП приложений, я заметил одну интересную особенность у МП оконных программ, а именно их неожиданную устойчивость работы и редкое появление в них dead и live lock в случае использования ими функции PostMessage(). При этом в этих программах почти полностью отсутствовал код посвященный синхронизации. Поэтому я решил попробовать взять за основу своего движка принцип, реализованный в очереди сообщений Windows. Из-за невысокой скорости работы очереди сообщений и её излишней функциональности, в движке была реализована специализированная очередь сообщений с похожим принципом работы. Окна были заменены специальными классами секциями (SECTION) с аналогичной функциональностью плюс некоторые новые возможности связанные непосредственно с многопоточностью.
В результате очередная версия выглядела так:
1. Имеется пул потоков (массив классов THREAD).
2. У потока имеется список всех запущенных на нём секций (SECTION).
3. Секция может принимать и отсылать асинхронные команды другим секциям, а также создавать др. секции и завершатся.
4. Завершение программы происходит, когда в пуле потоков не останется ни одной секции.
Данная реализация действительно имела, в сравнении с предыдущими версиями, более высокую устойчивость и меньшую вероятность появления в коде ошибок. Однако обнаружился ряд очень неприятных недостатков, от которых пришлось избавляться.
Для наглядности небольшой псевдокод объявления секции в hpp файле:
class A_SECTION: public THREAD_SECTION { //Вызывается при приёме сообщения virtual void SystemMessage(int command, DWORD param, const ...* data, const ...* from) ; //Вызывается при создании секции из другой секции virtual void Start(DWORD param, const ...* data, const ...* from) ; public : //Команды static THREAD_MESSAGE INIT; static THREAD_MESSAGE ERROR; };
Поясню, что THREAD_MESSAGE это класс, предназначенный для создания уникальных идентификаторов команд отсылаемых секциями:
class THREAD_MESSAGE { static int curr_max; int message; public : THREAD_MESSAGE(int count_=1 ) ; inline operator int () const {return message;} };
int THREAD_MESSAGE::curr_max=0 ; THREAD_MESSAGE::THREAD_MESSAGE(int count_) { message=curr_max; curr_max+=count_; ASSERT(curr_max< 32768 ) ; }
По коду сразу видно несколько проблем:
1. Сразу бросается в глаза входной параметр функции SystemMessage() - int command , его использование неизбежно приведёт к применению в теле обработчика SystemMessage() этакого мохнатого switch-а. Это не очень хорошо скажется на читабельности кода программы и быстродействие тоже не улучшит.
2. Использование сладкой парочки DWORD param и const ...* data связанно с необходимостью передавать параметры команды. Если параметр один, то его преобразуют и передают в param , в data пишется NULL . Если параметров несколько в data пишется указатель на структуру с параметрами, в param размер структуры. Здесь вообще плохо всё, начиная с ухудшения наглядности и заканчивая необходимостью применения преобразований типов в param и в указателе data , что рано или поздно приведёт к порче памяти и другим трудно обнаружимым ошибкам.
3. И наконец с указателем from , который используется для ссылки на секцию адресата сообщения, тоже не всё гладко. Так как адресат может находиться в другом потоке, то далеко не факт что при получении сообщения или при его обработке он ещё существует и не удалён, что ставит под сомнение его валидность.
Проблему обеспечения валидности указателя на секцию можно решить, если использовать вместо обычного указателя умный указатель с подсчетом количества ссылок, тогда если он у кого-то сохранился, то объект, на который он указывает, не удаляется до тех пор, пока не исчезнет последний из указателей. Недостаток такой схемы заключается в том, что память постоянно замусорена ненужными, но не удалёнными объектами, а из-за постоянного копирования этого указателя, при отсылке команды, чрезмерно часто вызываются функции InterlockedIncrement() и InterlockedDecrement(), что не желательно. Поэтому для идентификации секций, вместо указателей я решил использовать уникальные идентификаторы (UID). Так как системные GUID-ы были, на мой взгляд, слишком громоздкими и обладали излишней функциональностью, я использовал свои, которые были компактней и имели аналогичную функциональность. В моём случае использовался класс с четырьмя полями: номер потока, индекс в массиве секций, порядковый номер секции в момент создания, время создания секции в тиках. Поэтому для разных секций одинаковый GUID мог быть создан только в случае переполнения счётчика порядкового номера секции в течении одного тика. В моёй реализации это возможно, только если в течение одной миллисекунды будет создано более 4294967296 секций, что маловероятно. Таким образом, когда происходил поиск секции, для передачи ей команды, всегда можно было корректно определить, существует ли ещё эта секция или уже удаленна. В случае если адресат команды был уже удалён, то команда благополучно игнорировалась, без попыток вызвать удалённую секцию. Такой GUID позволял его легко копировать и хранить, а также исключал возможность использования его как указателя, для прямого доступа к переменным и функциям секции из другого потока.
