Гиперпоточность приводит к нестабильным системам?
Если подпись односторонняя и используется, то ее изменение приведет к поломке мест ее использования, если только изменения не совместимы с тем, как она использовалась (изменение int на Integer, для например, часто совместим благодаря авто-боксу).
Обычно добавляется перегрузка с новой сигнатурой, оставляя оригинальный метод на месте (хотя вы можете изменить его реализацию). Например, если оригинал был:
void m(Something a, SomethingElse b, YetAnotherThing c) {
// ...
}
добавление перегрузки / некоторых перегрузок:
void m(Something a, SomethingElse b, YetAnotherThing c, ANewThing d) {
// ...
}
// or
void m(Something a, SomethingElse b) {
// ...
}
// or
void m(ANewThing d) {
// ...
}
не сломает клиентов, используя этот оригинальный метод (при условии, что реализация продолжает делать то, что это было раньше, даже если он делает это по-другому).
15 ответов
Устойчивость, вероятно, не будет затронута, так как абстракция является очень низким уровнем, и ОС просто рассматривает его как другой ЦП для обеспечения работы. Однако производительность является другим вопросом.
Во всей честности я не могу сказать, имеет ли это все еще место, но по крайней мере когда центральные процессоры HT-enabled сначала вышли, были известные проблемы по крайней мере с некоторыми приложениями. Например, MySQL и многопоточные приложения как JAVA-приложение, которое я поддерживаю для своего дневного задания, как было известно, уменьшили производительность, когда HT был включен. Мы всегда рекомендовали, чтобы это было удалено, по крайней мере, для нашего конкретного варианта использования корпоративного приложения серверной стороны.
Возможно, что это больше не проблема, и в настольной среде это, менее вероятно, будет проблемой для большинства вариантов использования. Способность разделить работу над ЦП обычно приводила бы к большему количеству быстро реагирующих приложений, когда ЦП в большой степени используется. Однако контекстное переключение и наверху могло быть удерживанием, когда приложение является уже в большой степени поточным и интенсивным ЦП такой как в случае сервера базы данных.
Поздно стороне, но для будущей ссылки;
У меня в настоящее время есть проблема с этим с SQLServer. В основном моим пониманием является Гиперпоточность на тех же долях процессора тот же L1 и кэш L2, который может вызвать проблемы между двумя. Citrix также, кажется, имеет эту проблему от того, что я читаю.
Slava Ok записал хорошее сообщение в блоге на нем.
Короткий ответ: да.
Длинный ответ, как почти с каждым вопросом, "он зависит". Зависит от ОС, программного обеспечения, пересмотра ЦП, и т.д. Я должен был лично отключить гиперпоточность в двух случаях для получения программного обеспечения, работающего правильно (один, с приложением Совместных действий, и два, с установщиком Windows NT 4.0), но пробег может варьироваться.
Пока Вы добираетесь, окна установили обнаружение нескольких ядер HT с начала (оно загружает некоторые соответствующие драйверы и такой), можно всегда отключать (и повторно включать), HT "после факта". Если у Вас есть причудливые проблемы устойчивости с определенным программным обеспечением, которое Вы не можете разрешить, не трудно отключить HT, чтобы видеть, оказывает ли это какое-либо влияние.
Я не отключил бы его для запуска с того, потому что, откровенно говоря, это будет, вероятно, хорошо работать в 99,99% ежедневного использования. Но знайте, что да, это может иногда вызывать причудливые поведения, не исключайте его, если Вы, оказывается, диагностируете что-то очень нечетное в будущем.
Кроме слушания нескольких отчетов о SQL Server, все, о чем я могу сообщить, положительно. Я получаю приблизительно на 25% лучшую производительность на тяжелых многопоточных приложениях с HT на. Никогда не сталкивались с проблемой с ним, и я использую процессор HT первого поколения...
Лично, я нашел, что гиперпоточность, не вызывая проблем, на самом деле не помогает всему так очень также. Это могло бы быть похожим на наличие дополнительных.1 из процессора. На моей машине HT на работе я только очень seldomly вижу, что мой ЦП выходит за предел 50%. Я не знаю, добралась ли HT немного лучше с более новыми процессорами как i7, но я не оптимистичен.
Я владею i7 системой, и у меня не было проблем.
Если это работает w/несколько ядер, это работает с гиперпоточностью.
У меня была гиперпоточность ПК в течение пары лет теперь. Не то, чтобы много ядер, но это хорошо работало для меня.
Жаль, что у меня не было данных тестирования для доказательства коллег неправильно, но они кажутся, что это - просто мое мнение по сравнению с их в этой точке.;)
Насколько я знаю с точки зрения ОС, она не видит гиперпоточность как несколько отличающийся от наличия фактического несколько ядер. С точки зрения ОС нет никакого различия - она изолируется.
Так, кроме того, что "дополнительные ядра гиперпоточности" не "реальны" (в строго техническом смысле) и не имеют полной производительности "реальных" ядер процессора, я не вижу, что это было бы немного менее надежно. Медленнее, возможно, в некоторых редких экземплярах, но не менее надежный.
Конечно, это зависит от того, что Вы выполняете - я предполагаю, что некоторые приложения могли бы "уделить внимание и грязный" с ЦП, и гиперпоточность могла бы смутить их, но это, вероятно, довольно редко.
Я сам выполнял ПК с гиперпоточностью в течение нескольких лет теперь, и я не видел проблем устойчивости.
Извините у меня нет более конкретных данных!
До любого градуса Windows нестабилен, очень маловероятно, что гиперпоточность значительно способствует (или он сделал бы большие новости к настоящему времени.)
Ненадежный? Я сомневаюсь так. Единственный недостаток гиперпоточности, о которой я могу думать, является тем, что, если ОС не знает о нем, это могло бы запланировать два потока на один физический процессор, когда другие физические процессоры неактивны, который ухудшит производительность.
Была проблема с SQL-сервером и гиперпоточностью для некоторых запросов, потому что SQL-сервер имеет свой собственный планировщик, maxdop 1 решил бы это
Первое, что пришло на ум я могу думать о нескольких причинах, Ваши коллеги могли бы сказать это.
Несколько статей о производительности sql, страдающей при гиперпоточности. Я полагаю, что это завершает выполнение слишком много перегрузка кэша или контекстные переключения. не может помнить точно.
Рано при движении от единственного proc до multi-proc или более вероятно для большинства людей гиперпоточный procs, преданный гласности много проблем поточной обработки. Условия состязания, мертвые блокировки, и т.д., который они никогда не видели прежде. Даже при том, что это - проблема кода, некоторые люди обвинили procs.
Они предъявляют те же претензии о multi-core/multi-proc или примерно гиперпоточные?
Что касается меня, я разрабатывал на гиперпоточном поле в течение 4 лет теперь, только проблемой была проблема мертвой блокировки UI моего собственного создания.
Потоки в гиперпоточной доле ЦП, которую тот же кэш, и как таковой не переносит от проблем непротиворечивости кэша, что несколько архитектура ЦП могут. Хотя, если разработчик части программного обеспечения программирует с несколькими CPU в памяти, они будут (или если) писать с семантикой чтения (iirc, это - термин). т.е. все записи сразу сбрасываются от кэша.
Гиперпоточность будет главным образом иметь значение в поведении/производительности планировщика при диспетчеризации потоков тому же ЦП в противоположность другому ЦП...
Это покажет в плохо кодированном приложении, которое не обрабатывает условия состязания между потоками...
Таким образом, это - обычно плохой дизайн/код...., что suddendly находят условие вида отказа
Я здесь очень поздно, но нашел эту страницу через Google. Возможно, я обнаружил очень тонкую проблему. У меня i7 950 работает под управлением 2003 Server, и это здорово. Первоначально я оставил гиперпоточность в BIOS, но во время некоторых тестов и упорных усилий я запустил программу под названием «crashme» от Carrette. Эта программа пытается вызвать сбой ОС, порождая процесс и скармливая ему мусор, чтобы попытаться запустить. Моя двойная установка Opteron работала вечно без проблем, но 950 разбился в течение часа. Он не падал ни из-за чего, если только я не сделал какую-нибудь глупость, поэтому это было очень удивительно. По прихоти я выключил HT и снова запустил программу. Он работает всю ночь, даже несколько раз. Один анекдот ничего не значит, но попробуйте и посмотрите, что получится. Также, кажется, что при выключенной HT процессор немного круче при любой нагрузке. YMMV.