Core thread enablement что это
Что за зверь CPU Affinity и с чем его едят при майнинге
При майнинге на процессоре продвинутые майнеры используют возможность тонкой настройки параметров вычислений путем установки параметра CPU Affinity. Это дает потенциальную возможность выиграть дополнительные 1-2 процента в хешрейте.
Некоторые не знают значение данного параметра и для чего он служит. Между тем, правильная установка CPU Affinity на майнинг ригах с достаточно мощными процессорами способна обеспечить небольшое увеличение хешрейта при майнинге на процессоре при сохранении необходимой для основного майнера и системы вычислительной мощности CPU.
Рассмотрим подробнее, что такое параметр CPU Affinity, как он влияет на распределение ресурсов процессора и производительность майнинга.
Что такое CPU Affinity и как этот параметр влияет на режим работы процессора?
CPU Affinity – это программная привязка (закрепление) к ядрам процессора определенных вычислительных процессов. Такая привязка отдает ресурс назначенного пользователем физического ядра процессора нужному сервису/программе (например, майнеру), минуя автоматические (неэффективные) алгоритмы, использующиеся операционной системой. Ручная установка параметра AFFINITY прекращает прыгание исполняемой программы по ядрам процессора, которое бесполезно расходует машинное время и кэш CPU.
Закрепление ядра CPU позволяет увеличить время работы процессора по выполнению задач выбранной программы, в том числе майнера и тем самым увеличить хешрейт.
При включенной по умолчанию технологии Hyper Threading (HT) число доступных ядер удваивается за счет виртуализации. В этом случае нужно задействовать только физические ядра (нужно включать affinity для нечетного номера соответствующего виртуального потока).
Как на практике настроить параметр CPU Affinity для предоставления ресурсов процессора выбранным приложениям?
При настройке параметра CPU Affinity нужно выделать ресурсоемким приложениям физические, а не виртуальные ядра процессора. Например, при использовании процессора с двумя физическими и 4 виртуальными ядрами (0,1,2,3) нужно задействовать либо ядра 0, 2, либо 1 и 3
Для этого в батнике майнера для параметра cpuaffinity указывается маска с числовым значением, задающим номера ядер процессора, которые будут использоваться при проведении вычислений.
Эта опция будет полезна на практике только на достаточно производительных процессорах, у которых есть свободные мощности. На CPU с одним ядром и парой виртуальных потоков включение опции CPU Affinity ничего хорошего не даст.
Не стоит выделать майнеру все имеющиеся физические ядра при одновременном майнинге на видеокартах и выполнении других приложений на компьютере, так как это может привести к подвисаниям или уменьшению хешрейта на GPU.
В bat-файле майнера под Windows задействование 5 физических ядер из общего количества 6 реальных и 12 виртуальных будет выглядеть так:
Операционные системы Windows и Linux иногда по-разному нумеруют реальные и виртуальные ядра, поэтому для одинаковых процессоров значения CPU-affinity в этих системах могут быть разными.
Для удобства пользователя далее приведены значения аргумента cpu-affinity для Linux и Windows для вставки в батник xmrig в зависимости от количества использующихся физических ядер.
Таблица значений CPU affinity в соответствии с задействованными физическими ядрами процессора для Windows:
Физические ядра CPU
Intel I3-8100
Чтобы посчитать значение аффинити для Windows для своей конфигурации задействования ядер, нужно использовать написать в бинарном виде включенные/выключенные ядра/потоки (единица означает включение ядра) с последующей конвертацией в шестнадцатиричный формат.
Вычисление значения cpu-affinity на примере процессора Intel Core i7-8700K (6/12 ядер/потоков)
Чтобы найти значение affinity для процессора Intel Core i7-8700K:
Полученное число 555 записываем в формате 0x555 и проставляем в батник майнера в качестве аргумента параметра cpu-affinity.
Если задействуется 5 ядер из 6, то берем значение cpu-affinity для 0,2,4,6,8-х ядер, равное 155.
Пример батника для xmrig с использованием параметра cpu-affinity для задействованных 5 ядер:
Значения cpu-affinity для Linux
В Linux ядра/потоки считаются по другому, ниже приводятся значения CPU affinity для Linux.
Таблица значений CPU affinity в соответствии с задействованными физическими ядрами процессора для Linux:
Физические ядра CPU (Cores)
Значение cpu-affinity для майнера xmrig
Закрепление ядер за процессом штатными средствами Windows
В Windows закрепить ядра процессора за программой/сервисом можно с помощью диспетчера задач (ctrl+alt+del, задать сходство):
В открывшемся окне выбирают задействованные ядра (нужно выбирать одно физическое из пары реальное-виртуальное ядро):
Что на практике дает включение опции CPU Affinity при майнинге?
Активация функции CPU Affinity при майнинге на процессоре дает прирост хешрейта до 3-4% на алгоритмах типа RandomX. На других algo прирост может быть более существенным.
Хешрейт без включенной опции CPU Affinity на 4 потоках процессора Intel I7-7700 при майнинге Safex на алгоритме RandomSFX составляет примерно 2500 h/s (Windows 8.1):
С включенным режимом CPU Affinity выдает хешрейт около 2620 h/s (на 4 процента больше):
Многопоточность — одна из самых сложных тем в программировании, с ней постоянно возникает масса проблем. Без четкого понимания внутренних механизмов будет очень трудно предсказать результат работы приложения, использующего несколько потоков. Мы не будем здесь дублировать массу теоретической информации, которой очень много в сети и умных книгах. Вместо этого сконцентрируемся на конкретных и наиболее важных проблемах, на которые нужно обращать особое внимание и обязательно помнить о них в процессе разработки.
Потоки
Потоки делятся на background (фоновый) и foreground (основной, тот, что на переднем плане). Основное отличие между ними в том, что foreground-потоки препятствуют завершению программы. Как только все foreground-потоки остановлены, система автоматически остановит все background и завершит выполнение приложения. Чтобы определить, является поток фоновым или нет, необходимо вызвать следующее свойство текущего потока:
По умолчанию, при создании потока при помощи класса Thread мы получим foreground-поток. Для того, чтобы его поменять на фоновый, мы можем воспользоваться свойством thread.IsBackground.
В приложениях, которые имеют пользовательский интерфейс (UI), всегда есть как минимум один главный (GUI) поток, который отвечает за состояние компонентов интерфейса. Важно знать, что возможность изменять состояние представления есть только у этого, так называемого «UI-потока», который создается для приложения обычно в единственном экземпляре (хотя и не всегда).
Стоит также упомянуть про исключительные ситуации, которые могут возникать в дочерних потоках. В такой ситуации приложение будет экстренно завершено, и мы получим Unhandled Exception, даже если обернем код запуска потока в блок try/catch. В таком случае, обработку ошибок необходимо вынести в код дочернего потока, в котором уже можно будет отреагировать на конкретную исключительную ситуацию.
Применяя глобальную обработку исключений (Application_Error в ASP.NET, Application.DispatcherUnhandledException в WPF, Application.ThreadException в WinForms и т.д.) важно помнить, что при таком подходе мы сможем «ловить» исключительные ситуации, которые произошли ТОЛЬКО в UI потоке, то есть мы не «поймаем» исключения из дополнительных фоновых потоков. Также мы можем воспользоваться AppDomain.CurrentDomain.UnhandledException и вклиниться в процесс обработки всех необработанных исключительных ситуаций в рамках домена приложения, но мы никак не сможем воспрепятствовать процессу завершения приложения.
Потоки — это дорогостоящие объекты, которые занимают память, могут использовать различные ресурсы системы и находиться в разных состояниях. Для их создания требуется время. В сравнении с процессами они менее ресурсоемки, но все же требуют довольно больших затрат на создание и уничтожение. Более того, за освобождение занимаемых конкретным потоком ресурсов отвечает разработчик. Например, для выполнения массы небольших задач неэффективно запускать множество потоков, так как издержки на их запуск могут превысить выгоду от использования. Для того, чтобы иметь возможность повторно использовать уже запущенные потоки и избавиться от издержек на создание, был введен так называемый пул-потоков (ThreadPool).
ThreadPool
В рамках каждого процесса CLR создает одну дополнительную абстракцию, которая называется пул потоков. Он представляет собой набор потоков, которые находятся в режиме ожидания и готовы выполнять любую полезную работу. При запуске приложения пул-потоков запускает минимальное количество потоков, которые находятся в состоянии ожидания новых задач. Если активных потоков недостаточно для эффективного выполнения задач в пуле, он запускает новые и использует их по тому же принципу повторного использования. Пул довольно умный и умеет определять необходимое эффективное количество потоков, а также останавливать лишние или запускать дополнительные. Можно задавать максимальное и минимальное количества потоков, но на практике это делают редко.
Потоки внутри пула разделяются на две группы: worker и I/O-потоки. Рабочие потоки фокусируются на работе, связанной с загрузкой CPU (CPU based), в то время как I/O-потоки — на работе с устройствами ввода/вывода: файловая система, сетевая карта и другие. Если пытаться выполнять I/O-операцию на рабочем потоке (CPU based), то это будет напрасная трата ресурсов, так как поток будет находиться в состоянии ожидания завершения I/O-операции. Для подобных задач предназначены отдельные I/O-потоки. При использовании пула потоков это скрыто в явном виде от разработчиков. Получить количество разных потоков в пуле можно при помощи кода:
Для того, чтобы определить, является текущий поток взятым из пула или созданным вручную, необходимо воспользоваться конструкцией:
Запустить задачу на выполнение при помощи потока, взятого в пуле, можно с помощью:
Синхронизация
При построении многопоточного приложения необходимо гарантировать, что любая часть разделяемых данных защищена от возможности изменения их значений множеством потоков. Учитывая, что управляемая куча является одним из разделяемых потоками ресурсов, а все потоки в AppDomain имеют параллельный доступ к разделяемым данным приложения, очевидно, что доступ к таким общим данным необходимо синхронизировать. Это гарантирует, что в один момент времени доступ к определенному блоку кода получит лишь один поток (или указанное количество, в случае использования Семафора). Таким образом, мы можем гарантировать целостность данных, а также их актуальность в любой момент времени. Давайте рассмотрим возможные варианты синхронизации и частые проблемы. Говоря о синхронизации, обычно выделяют 4 вида:
Blocking
Под блокировкой понимается ожидание одним потоком завершения другого или нахождение в режиме ожидания в течение некоего времени. Обычно реализуется при помощи методов класса Thread: Sleep() и Join(), метода EndInvoke() асинхронных делегатов или при помощи тасков (Task) и их механизмов ожидания. Следующие конструкции являются примерами плохого подхода к реализации ожидания:
Подобные конструкции требуют много ресурсов процессора, хотя не выполняют никакой полезной работы. В то же время ОС и CLR думают, что наш поток занят выполнением важных расчетов и выделяют для него необходимые ресурсы. Данного подхода следует всегда избегать.
Похожим примером может быть следующая конструкция:
Здесь вызывающий поток периодически засыпает на короткое время, но его достаточно для того, чтобы система могла переключить контексты и выполнять параллельно другие задачи. Данный подход гораздо лучше предыдущего, но все же не идеален. Основная проблема возникает в тот момент, когда необходимо изменять флаг proceed из разных потоков. Подобная конструкция будет эффективным решением в том случае, когда мы ожидаем, что условие в цикле будет удовлетворено через очень короткое время и повлечет за собой небольшое количество итераций. Если итераций много, то системе потребуется постоянно переключать контекст данного потока и тратить на это дополнительные ресурсы.
Locking
В таблице представлены самые популярные механизмы для организации блокировок. При помощи Мютексов можно реализовать межпроцессорную блокировку (а не только для нескольких потоков одного процесса). Семафор отличается от Мютекса тем, что позволяет указать количество потоков или процессов, которые могут получить одновременный доступ к конкретному участку кода. Конструкция lock, которая является вызовом пары методов: Monitor.Enter() и Monitor.Exit(), применяется очень часто, поэтому рассмотрим возможные проблемы и рекомендации по её использованию.
Статические члены классов, которыми часто оперируют разработчики, всегда потоконебезопасны, и доступ к таким данным нужно обязательно синхронизировать. Отличием может быть только статический конструктор, так как CLR блокирует все обращения из сторонних потоков к статическим членам класса до тех пор, пока не завершит свою работу статический конструктор.
При использовании блокирования при помощи ключевого слова lock следует помнить о следующих правилах:
В большинстве случаев нет смысла в реализации собственной подобной коллекции — намного проще и разумней использовать готовые протестированные классы.
Асинхронность
Отдельно хотелось бы выделить так называемую асинхронность, которая, с одной стороны, всегда непосредственно связана с запуском дополнительных потоков, а с другой — с дополнительными вопросами и теорией, на которых тоже стоит остановиться.
Покажем на наглядном примере разницу между синхронным и асинхронным подходами.
Предположим, вы хотите пообедать пиццей в офисе и у вас есть два варианта:
1-й, синхронный вариант: прогуляться пешком в пиццерию, выбрать интересующую вас пиццу, сделать заказ, дождаться, пока его принесут, добраться с пиццей в офис или пообедать непосредственно в пиццерии, после чего вы вернетесь и продолжите работать. В процессе прогулки и ожидания заказа вы будете находиться в режиме ожидания и не сможете заниматься другой полезной работой (для простоты, здесь понимается именно работа в офисе, которая приносит деньги и которую вы не можете выполнять вне рабочего места).
2-й, асинхронный вариант: заказать пиццу по телефону. После заказа вы не заблокированы, можете выполнять полезную работу на рабочем месте, пока ваш заказ обрабатывается и доставляется в офис.
Эволюция
Данный подход можно встретить во множестве технологий и классов, но он чреват усложнением и избыточностью кода.
В версии 2.0 была введена новая модель под названием EAP (Event-based Asynchronous Pattern). Класс, поддерживающий асинхронную модель, основанную на событиях, будет содержать один или несколько методов MethodNameAsync. Он может отражать синхронные версии, которые выполняют то же действие с текущим потоком. Также в этом классе может содержаться событие MethodNameCompleted и метод MethodNameAsyncCancel (или просто CancelAsync) для отмены операции. Данный подход распространен при работе с сервисами. В Silverlight применяется для обращения к серверной части, а Ajax по сути представляет из себя реализацию данного подхода. Стоит опасаться длинных цепочек связанных вызовов событий, когда по завершении одной долгосрочной операции в событии ее завершения вызывается следующая, потом еще следующая и так далее. Это чревато дэдлоками и непредвиденными результатами. Обработка исключений и результаты асинхронной операции доступны только в обработчике события посредством соответствующих свойств параметра: Error и Result.
В последних версиях фреймворка появились новые возможности на основе все тех же задач, которые упрощают написание асинхронного кода и делают его более читабельным и понятным. Для этого введены новые ключевые слова async и await, которыми помечаются асинхронные методы и их вызовы. Асинхронный код становится очень похожим на синхронный: мы просто вызываем нужную операцию и весь код, который следует за ее вызовом, автоматически будет завернут в некий «колбек», который вызовется после завершения асинхронной операции. Также данный подход позволяет обрабатывать исключения в синхронной манере; явно дожидаться завершения операции; определять действия, которые должны быть выполнены, и соответствующие условия. Например, мы можем добавить код, который будет выполнен только в том случае, если в асинхронной операции было сгенерировано исключение. Но не все так просто, даже несмотря на массу информации на эту тему.
async\await
Рассмотрим основные рекомендации по использованию этих ключевых слов, а также некоторые интересные примеры. Чаще всего рекомендуется использовать асинхронности «от начала до конца». Это подразумевает использование только одного подхода в конкретном вызове или функциональном блоке, не смешивайте синхронные вызовы с асинхронными. Классический пример данной проблемы:
Данный код отлично работает в консольном приложении, но при вызове метода DeadlockDemo.Test() из GUI потока возникнет взаимоблокировка. Это связано с тем, как await обрабатывает контексты. По умолчанию, когда ожидается незавершенный Task, текущий контекст захватывается и используется для возобновления метода по окончании выполнения задачи. Контекстом является текущий SynchronizationContext, если только он не равен null, как в случае с консольными приложениями. Там это текущий TaskScheduler (контекст пула потоков). GUI- и ASP.NET-приложения имеют SynchronizationContext, который разрешает единовременно выполнять только одну порцию кода. Когда выражение await завершает выполнение, оно пытается выполнить остальную часть async-метода в рамках захваченного контекста. Но он уже имеет поток, который (синхронно) ожидает завершения async-метода. Получается, что каждый из них ждет друг друга, вызывая взаимоблокировку.
Также рекомендуется избегать конструкций вида async void (асинхронный метод, который ничего не возвращает). Async-методы могут возвращать значения Task, Task и void. Последний вариант был оставлен для поддержки обратной совместимости и позволяет добавлять асинхронные обработчики событий. Но стоит помнить про некоторые специфичные отличия подобных методов, а именно:
Данная рекомендация очень актуальна при разработке каких-либо библиотек, которые ничего не знают про GUI.
Рассмотрим еще несколько примеров применения новых ключевых слов, а также некоторые особенности их использования:
На экране сначала появится «work», затем «started», и только потом «finished». На первый взгляд кажется, что первым должно быть выведено слово «started». Не забывайте, что в данном коде присутствует проблема с дэдлоком, которую мы рассмотрели. Это связано с тем, что метод, помеченный ключевым словом async, не запускает дополнительных потоков и обрабатывается синхронно до тех пор, пока не встретит внутри ключевое слово await. Только после этого будет создан новый объект типа Task и запущена отложенная задача. Чтобы исправить данное поведение в приведенном примере, достаточно заменить строку с Thread.Sleep(…) на await Task.Delay(…).
Можно предположить, что мы будем ожидать 1 секунду перед вторым выводом на экран, но это не так — оба сообщения будут выведены без задержек. Это связано с тем, что метод Task.Delay(), как и многие другие асинхронные методы, возвращает объект типа Task, но мы проигнорировали эту задачу. Мы не ожидаем ее завершения ни одним из возможных способов, что влечет за собой немедленное выведение на экран обоих сообщений.
Несмотря на использование ключевых слов, данный код не является асинхронным и выполняется синхронно, потому что мы создаем задачу и явно ожидаем ее выполнения. В данном случае вызывающий поток заблокирован и ожидает завершения запущенной задачи.
Заключение
Как видите, у разработчиков имеется довольно много возможностей для работы с многопоточными приложениями. Важно не только знать теорию, но и уметь применять эффективные подходы для решения конкретных задач. Например, использование класса Thread почти однозначно говорит о том, что у вас устаревший код в проекте, хотя вероятность возникновения необходимости его использования весьма мала. В обычных ситуациях использование пула всегда оправданно, по понятным причинам.
Использование многопоточности в приложениях с GUI обычно влечет за собой дополнительные ограничения, не забывайте о них!
Также стоит помнить и про другие готовые реализации, такие как потокобезопасные коллекции. Это избавляет от написания дополнительного кода и предотвращает возможные ошибки реализации. Ну и не забывайте про особенности новых ключевых слов.
CPU Core, Multi-Core, Thread, Core vs Threads, Hyper-Threading
Updated October 7, 2021
What is Concurrency or Single Core?
In Operating Systems, concurrency is defined as the ability of a system to run two or more programs in overlapping time phases.
Concurrent execution with time slicing
As you can see, at any given time, there is only one process in execution. Therefore, concurrency is only a generalized approximation of real parallel execution. This kind of situation can be found in systems having a single-core processor.
In this Concurrency tutorial, you will learn
What is Parallel Execution or (Multi-Core)?
In parallel execution, the tasks to be performed by a process are broken down into sub-parts, and multiple CPUs (or multiple cores) process each sub-task at precisely the same time.
Parallel Execution
As you can see, at any given time, all processes are in execution. In reality, it is the sub-tasks of a process which are executing in parallel, but for better understanding, you can visualize them as processes.
Therefore, parallelism is the real way in which multiple tasks can be processed at the same time. This type of situation can be found in systems having multicore processors, which includes almost all modern, commercial processors.
KEY DIFFERENCE
What is Thread?
A thread is a unit of execution on concurrent programming. Multithreading is a technique which allows a CPU to execute many tasks of one process at the same time. These threads can execute individually while sharing their resources.
What is Multithreading?
Multithreading refers to the common task which runs multiple threads of execution within an operating system. It can include multiple system processes.
How Multithreading Works?
For example, most modern CPUs support multithreading. A simple app on your smartphone can give you a live demo of the same.
When you open an app that requires some data to be fetched from the internet, the content area of the app is replaced by a spinner. This will rotates until the data is fetched and displayed.
In the background, there are two threads:
Both of these threads execute one after the other to give the illusion of concurrent execution.
What is CPU Core?
A CPU core is the part of something central to its existence or character. In the same way in the computer system, the CPU is also referred to as the core.
There are basically two types of core processor:
What is the Main Issue with Single Core?
There are mainly two issues with Single Core.
The Solution Provided by Multi-Core:
Benefits of Multi-core Processor
Here are some advantages of the multicore processor:
Difference between Core vs. Threads
| Parameters | Core | Threads |
|---|---|---|
| Definition | CPU cores mean the actual hardware component. | Threads refer to the virtual component which manages the tasks. |
| Process | The CPU is fed tasks from a thread. Therefore, it only accesses the second thread when the information sent by the first thread is not reliable. | There are many different variations of how CPU can interacts with multiple threads. |
| Implementation | Achieved through interleaving operation | Performed through suing multiple CPU’S |
| Benefit | Increase the amount of work accomplished at a time. | Improve throughput, computational speed-up. |
| Make use of | Core uses content switching | Uses multiple CPUs for operating numerous processes. |
| Processing units required | Requires only signal process unit. | Requires multiple processing units. |
| Example | Running multiple application at the same time. | Running web crawler on a cluster. |
What is Hyper-Threading?
Hyper-threading was Intel’s first effort to bring parallel computation to end user’s PCs. It was first used on desktop CPUs with the Pentium 4 in 2002.
The Pentium 4’s at that time only featured just a single CPU core. Therefore, it only performs a single task and fails to perform any type of multiple operations.
A single CPU with hyper-threading appears as two logical CPUs for an operating system. In this case, the CPU is single, but the OS considers two CPUs for each core, and CPU hardware has a single set of execution resources for every CPU core.
Therefore, CPU assumes as it has multiple cores than it does, and the operating system assumes two CPUs for each single CPU core.