Из форума противоречивая инфа была.

HT OFF
Тест гилева файловый 8.3
http://snag.gy/bxyTC.jpg 60
Тест гилева серверный MSSQL2012 8.2.19.106
http://snag.gy/X5I1e.jpg 40

HT ON
Файловый http://snag.gy/nlfiK.jpg 61
Серверный http://snag.gy/lCLoL.jpg 38

Тачка самосбор для извращений из купленного на ebay
xeon ES E5-2870 ($500)
память 1600 ecc kingston
супермикро 2 сокетовая
ssd samsung

Вобщем я так понял, что разницы принципиальной нет. А значит HT дб включен, тк нормальные приложения его любят и юзеров можно многа напустить.

Я конечно не знаток глубин архитектур процессоров, но на сколько я понимаю HT на многопотоковых задачах даст прирост

Само собой, просто в форуме муссировалась мысль, что 1с побоку и ей HT вообще вредит.

(2) теплое с мягким перепутали...
во первых какая 1С?

7.7 вообще однопотоковая ей HT вредит, только частота нужна

8-ка а хз как там реализовано но скорее всего если нужна максимальная скорость для одного юзверя, то HT вредит...

если же нужна средняя температура по больнице то да многоядерность и HT врубайте )) не такие тормоза будут особенно когда какой нить антивирь или еще что решит проверить/обновиться ))

(2)Да есть такое.
Многие кричат что гипертрединг вредит 1с, но при этом забывают что 1с не работает в вакууме, паралельно с ней в любом случае работает куча процессов.
Поэтому в большинстве случаев гипертрединг полезен, а в оставшихся случаях,  если и не приносит особой пользы то ни в коем случае не вреден.

Гипертрейдинг - это когда одно ядро обслуживает одновременно два процесса. Иногда может приводить к притормаживанию, если оба процесса активно обращаются в память, а также из-за возможности возникновения взаимоблокировок.
К сожалению, сейчас процессоры или два ядра или четыре полуядра, так что взаимоблокировки всё равно будут - даже если будут работать два ядра, то они могут блокировать друг друга на ожиданиях обращения к ресурсам.
Можно попробовать отключить гипертрейдинг и установить маску исполнения для 1С на одно ядро (причём для всех процессов 1С одной базы) и посмотреть, что изменится.
Сравнивая запуск на двух или четырёх ядрах мы для однопоточного приложения не должны получить никакой разницы.

А тест Гилева разве однопоточный?

(6) Однопоточный процесс прекрасно "перепрыгивает" в процессе исполнения с одного ядра на другое.

(7) Если его не зафиксировать на одном ядре. Хотя нет особого смысла - смена ядра особо на производительности не сказывается.

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

И, насколько я помню, при копировании больших блоков данных в памяти используется контроллер прямого доступа, а не процессор.
Можно, конечно, SQL-сервер заставить работать через TCP-IP, но будет явно не быстрее, зато нагрузка на процессор возрастёт.

(9) Стек зачем? Указатель только перекидывается.
(10) При переключении контекста блоки памяти не копируются. Во всяком случае не должны.

(11) Не стек, а контекст, я их часто путаю.

Блоки памяти копируются при общении клиентской части с SQL-сервером.

При переключении процесса регистры процессора пишутся в память (причём, также и регистры математического сопроцессора) - кеш, по идее, должен спасать.

А насчет гипертрейдинга - по-уму гипертрейдинг всегда дает выигрыш. Так как по сути, глобально, это всего-лишь флаг разрешающий ОС размещать на одном физическом ядре два потока используя простаивающие блоки.
ОСь всегда сначала размещает по одному потоку на ядро, когда физические ядра закончились, начинает размещать по второму. Эффективность конечно маленькая, но это лучше чем поток бы вообще простаивал. А падает эффективность при включенном гипертрединге только на кривых многопоточных приложениях, которые либо не умеют отличать физические ядра от логических, и параллелят на виртуальные ядра алгоритмы с плохой эффективностью распараллеливания, либо с кривыми алгоритмами учета виртуальности ядер.

(0) Запусти вторую (многопоточную)часть теста при включенном HT, посмотришь, изменятся ли результаты, когда сервер приложения и СУБД будут интенсивно конкурировать за вычислительные ресурсы.

Что-то я запутался. Верно ли я понимаю что x32 сервер 1с однопоточный, а сервер x64 многопоточный?
и правильно ли я понимаю что c HT 2 параллельных потока (с узким местом на процессоре) выполняться быстрее чем на том же физическом ядре без НТ последовательно (с использованием многозадачности винды)?

(15) x32 - 32битный, а x64 - 64битный. К многопоточности это никаким боком. А второе верно.

(16) на счет разрядности я понимаю. Просто неоднократно видел как x64 сервер занимал больше одного потока. К примеру 50% проца на 4-х поточном процессоре.

(17) Не понимаю о чем ты. Если о SQL - то он спокойно параллелит запросы. Хоть 32-битный, хоть 64.

(18) я о процессе rphost 64-х разрядного сервера 1с

(19) Я 32-битного и не видел никогда :)
x64 многопоточный.

Ой я непонял ... Ну такишо ??? Покупать или продавать ..

(13) Глобально, гипертрединг к ОС отношения не имеет, это лишь режим работы процессора, когда он виртуально представляется как несколько. При этом многие блоки дублируются, разделяются в обязательном порядке лишь регистры. Соответственно, ОС может вообще не знать о том, что есть гипертрединг, используя виртуальные ядра как обычные процессоры. Правда, в последних версиях ОС это учитывает, стараясь в первую очередь раскидывать задачи по физическим процессорам.

Отключили Hyperthreading на терминальном сервере, т.к. с ним сервер падал 5-6 раз за 2 недели...

На базах данных многопотоковость конечно очень важна, ага))

(24) А что, нет?

(25) Конечно нет, параллельно обрабатывать данные (не записывать и  не читать) надо крайне редко. в 95% лучаев все упрется в записывать и читать.

по сути обработка в пределах одной транзакции и только, че ее параллелить-то.

(26) ТО есть ты думаешь, что к БД единомоментно идёт один запрос...
Тогда спорить больше не о чём

(28) Еще раз - ХТ полезен на длительной обработке данных, особенно когда результат на выходе предсказуем.. а-ля коирование видеофайла или 3дмакс, реж файл на куски и кодируй. Ничего подобного в базах данных нет. Почти каждая транзакция влияет на следующую, ни предсказать ни ускорить ХТ ничего не может.

(29) Да и замедлить тоже. По сути, гипертрединг смещает точку конкуренции процессов с ядра операционной системы внутрь процессора. Замедление может быть только в одном случае - если ОС при наличии выбора между реальными и виртуальными сделает неправильный выбор, передав квант исполнения виртуальному ядру загруженного процессора. Если же физический процессор (полноценное ядро) одно, то гипертрединг не может привести к падению производительности в принципе.

(29) >Ничего подобного в базах данных нет. Почти каждая транзакция влияет на следующую
Особенно селекты, особенно к разным базам одного сервера, особенно, запускающие функции.

Кстати, клиент-сервер на одной машине - это, как минимум, три процесса: SQL-сервер, сервер приложений и клиент. То, что они работают последовательно, обмениваясь данными, не мешает им быть разными процессами, так что в момент передачи данных от SQL-сервера через сервер приложений к клиенту может быть задействовано даже три ядра.

Другое дело, что в случае работы на одной машине SQL-сервер и сервер приложений обмениваются данными через "окно общей памяти". При этом, SQL-сервер готовит данные, потом все или по частям копирует их в "окно обмена", а сервер приложений в свою очередь копирует их из окна обмена в свою память.
Не забываем, что операции копирования выполняются через DMA (чаще всего) - в итоге, если запрос несложный, а данных много, то мы видит, что процессор просто простаивает, так как всё время тратится на процедуры копирования данных в памяти (их выполняет контроллер памяти и они всегда идут в один поток). Поэтому, на мощном сервере с хорошей дисковой подсистемой можно наблюдать, что программа не может загрузить даже одно ядро процессора.

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

(29)"ни предсказать ни ускорить ХТ ничего не может."
Во первых HT ничего не должен предсказывать и ускорять по определению.
Во вторых именно в ситуации когда предсказать нельзя HT максимально эффективен. Он как раз работает в момент ошибок предсказания.


И еще, по поводу БД разве БД работает в вакууме? На сервере это единственный процесс? А как же система? Сторонние процессы тоже требуют процессорного времени, и делят его с БД.
Вот тут и помогает многопоточность вообще, и гипертрединг в частности.

(34) >Он как раз работает в момент ошибок предсказания.
Понимаешь как он работает? Он посылает на обработку следующую порцию данных, пока предыдущая переподготавливается. Да вот беда в случае баз данных следующая порция данных зависима от предыдущей и ее нельзя обработать пропустив первую.

Про отрисовку форм и прочую шваль и так понятно, но никакой пользы от многопоточности для базы данных нет, что и показывает практика.

(35) а при чем тут БД? Если БД не выгодно использовать виртуальные ядра, то она не будет использовать. Все же в рамках одного приложения, которое наверно не дебилами написано.

(35)Опять ты за свое.
Вот представь - есть один процессор без гипертрединга, на нем работает БД, и "всякая шваль типа отрисовки окошек".
Итак проц занимается вычислениями для БД, и тут опа, ошибочка предсказания, усе, приехали, запрашиваем новые данные и нервно курим ...дцать тактов пока они подгрузятся, ибо дело это не быстрое. Весь вычислительный конвеер процессора тупо простаивает.
В итоге 70% времени проц считает БД, 20% времени простаивает, и 10% времени считает всякую шваль.

Та же самая задача но процессор с гипертредингом.
После ошибки предсказания, переключается контекст, и вычислительный конвеер процессора просчитывает задачи для "всякой швали, типа отрисовки окошек"
В итоге 100% времени процессор считает БД, а всякая шваль успевает просчитаться во время простоев.

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

(37) Угу если на сервере 1С параллельно запустить рендерится 3Д макс и кодировать видео - по хипергтрединг на 32 ядра безусловно зарулит.
В реальной жизни для 1С советуют выбирать более высокочастотный процессор и это правильно ;)

(38)Да какой нафиг рендеринг?
Ты что думаешь тот же скуль все 100% времени считает твой хитрый запрос??
А лог транзакций кто ведет? А бэкап в фоне кто делает? А запрос другого пользователя кто обрабатывает? А с сетью кто работает?

(38) Вот ты сам и сказал то слово... "для 1с". Это верно.
А вот для MSSQL...

Господа ну хватит бреда

Технология гиперпоточности
На технологии гиперпоточности стоит остановиться из-за того, как она влияет на SQL Server. Технология гиперпоточности фактически предоставляет операционной системе для одного физического процессора два логических процессора. По сути, технология гиперпоточности арендует время физических процессоров для полного использования возможностей каждого процессора. На веб-узле Intel (intel.com/technology/platform-technology/hyper-threading/index.htm) представлено гораздо более подробное описание работы технологии гиперпоточности.
В системах SQL Server DBMS фактически обрабатывает собственные чрезвычайно эффективные очереди и потоки для операционной системы, поэтому в системах с уже существующей высокой загрузкой процессоров технология гиперпоточности только еще больше перегружает физические ЦП. Когда SQL Server осуществляет постановку в очередь нескольких запросов для работы с несколькими планировщиками, операционной системе приходится переключать контекст потоков команд для обеспечения соответствия выполняемым запросам, даже если два логических процессора принадлежат одному физическому процессору. Если показатель «Контекстных переключений/сек» превышает 5000 для одного физического процессора, следует серьезно рассмотреть вопрос об отключении гиперпоточности в системе и повторном тестировании производительности.
Только в очень редких случаях приложения с высокой загрузкой процессора в SQL Server могут эффективно использовать гиперпоточность. Перед реализацией изменений в рабочих системах необходимо всегда проверять приложения в SQL Server с включенной и выключенной гиперпоточностью.
http://technet.microsoft.com/ru-ru/magazine/2007.10.sqlcpu.aspx

(41) кто тебе мешает, раз уж майкрософт не умеет сама писать, зафиксировпть для использования в SQL только физические ядра, четные?

при этом гипертрейдинг включить.

(41) Вот хватит бреда.
Возьми скуль сервер. Натрави на него сервер 1с с другой машины. Забинди скуль на 1 проц и натрави на него тест Гилева или Fragster'а.
Потом отпусти биндинг и повтори.
Покажи результаты. Объясни их.

(41)Ну это как раз тот самый редкий вариант когда накладные расходы на гипертрединг превышают выгоду от него.
На практике встречается, но довольно редко.
А если учесть что зачастую на одном сервере оказываются и SQL сервер, и 1с сервер, и еще какая нибудь хрень, то шансов наткнуться на такую ситуацию ничтожно мало.

(38) В реальности имеется совокупность действительно противоречивых(взаимоисключающих друг друга) параметров -  частота, объем кэша, кол-во физ. ядер и температура(максимальная потребляемая мощность), которая не должна превышать определенных значений. В идеале, для 1С, хороши максимальные значения первых трех. Ну а дополнительных физ.ядер никакой HT не заменит. То есть, все разговоры о том, что бы включать/ не включать HT - от ограниченности финансовых ресурсов и невозможности(нежелания) приобрести  реально(максимально) производительный процессор и систему на его основе.

(46) Ты как-то странно ставишь вопрос. Все современные серверные процессоры Интел уже имеют на борту гипертрейдинг, и вопрос стоит включать его уже на купленном сервере, или нет. Не какой сервер покупать, а включать или нет гипертрейдинг уже после покупки сервера.

(47) http://support.microsoft.com/kb/322385/en
Я всего лишь вольно перевел часть фразы из параграфа " Performance" - "Hyper-threading can be very helpful but hyper-threading cannot replace the full power of an additional physical CPU."
Значит, надо купить такой сервер, чтобы этот вопрос не возникал.

(41) это всего-лишь статья какого-то идиота Zach Nichter, и по сути своей - поебень, не цитируй этого говна больше.

HT это одна из технологий multi-threading, а конкретно раздача одного физического ядра на несколько потоков, коии есть и у Sun и у IMB, с другой реализацией, но одинаковым смыслом. Во время когда поток ожидает чего-то, ядро может заняться другим потоком, а не простаивать. При этом поток "ожидающий" с точки зрения ОС находится в состоянии running, иначе он был бы снял с процессора. Это уровень ниже приложения, которое только видит, что поток выполняется и всё, никакие очереди тут не помогут.

Даже если параллелить запросы не надо, в ОС всегда есть куча других потоков, которым нужен процессор.

Никакого смысла отключить HT нет, кроме разве что багов каких-то, когда приложение падает.

(48)В упор не понимаю каким образом покупка другого сервера снимет вопрос "выключать или нет гипертрединг"?
Разве что процессор АМД купить, где выключать нечего.

(49) у меня случай был когда драйвер модема валил сервак с гипертрейдингом :)

а вообще его следует рассматривать как виртуалку без отдельной памяти и другой перефирийки.

самые большие проблеммы для всех виртуалок это
1. приложение не видит реального железа и пытается что-то оптимизировать видя не реальную проблемму
2. конфликт блокировок к ресурсам

вторая проблемма возникает во всех многопоточных приложениях
первая проблемма возникает только в приложениях которые пытаются работать напрямую с железом. 1с сервер никогда не пытался работать напрямую с железом. про сервера БД - это отдельная песня.

(51) Если драйвер криво написан и ожидает данных от устройства, то даже небольшой "простой" при переходе к исполнению другого потока может приводить к тому, что данные будут получены кем-то другим или просто потеряны.

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

Также не стоит забывать про "бутылочное горлышко" доступа к памяти - если память - слабое место, то добавление ядер (и даже полуядер) будет приводить только к снижению производительности, так как всё упрётся в обмен с памятью, а количество ядер просто добавит ещё операций с памятью при переключении потоков. Но, данный случай можно рассматривать как сильно перегруженный сервер.

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

Ну и не забываем, что если программа считает, что ядер в два раза больше и создаёт количество потоков по количеству полуядер, то при оптимальной загрузке мы получаем, что два потока начинают конкурировать за одно ядро - в такой ситуации гипертрейдинг нужно отключать, так как можно будет наблюдать некоторое снижение производительности, однако, если программисты были умные, то они должны понимать, что потоков должно быть по числу обычных ядер, а не полуядер.

(52)
1. Система (ОС) создает потоки не ориентируясь на число ядер.
2. если софт создает лишние потоки, не умея отличать виртуальные ядра от физических, возникает простой вопрос - зачем ставить на сервер софт написанный школотой?

(53)
1. Система создаёт потоки только по потребности и командам от исполняемых приложений - при этом, решение о создании нового потока система может принимать только в одном случае - не создать его тогда, когда обнаруживается нехватка каких-то ресурсов. Всё остальное зависит от приложений и драйверов на этой системе исполняющихся.
2. В некоторых "хороших" программах число потоков задаётся в параметрах, и "школотой" оказывается не программист, а админ, который обычно не читает инструкцию, так как всё итак заработало.

Вообщем подводя итоги "пилите шура они золотые" т.е. тестировать надо в каждом конкретном случае как лучше с HT или без него... ))

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

(55)ИМХО в том что касается 1с думаю тестировать нечего.
В результате все равно выяснится что в среднем HT в худшем случае не уменьшает быстродействия.

Вот во всяких узкоспециализированных областях, возможно незначительное ухудшение, но не в 1с.

(57) если на компе кроме 1С ничего нету то да быстродействие не уменьшится...

а если это не "сферический конь в ваккууме" а рабочая система со всякими антивирусами, скайпами и прочими оффисами то результат непредсказуем без тестов...

о5 25. если это нормальный многоядерный сервер баз данных а не помойка широкого назначения, то ХТ ничего ускорить не может в силу специфики задач, а скорее всего будет несколько медленнее из-за разделения кэша. Приложение ххх оптимизировано для ХТ - означает лишь использование правильных параметров компилятора и теоритическую поддержку данной технологии.

(59) wtf XT?

вроде про HyperThreading(HT) разговор?

(57)Ровно наоборот.
Чем больше приложений, тем больше эффекта от HT.

(60) HyperThreading - через дефис пишется.

(62) да хоть через через тире или :

что такое XT?

(60)Не цепляйся за слова, ясно же что в данном контексте ХТ это кривая попытка транслитерировать HT.
(62)Да пофиг. Суть от этого не меняется.

(64) даже не думал )) просто вдруг отстал я от жизни и новые технологии какие то появились

(65) Всё новое - "хреновое" ^_^