Хотел бы оптимизировать свои проги под гипер-трейдинг как я понял надо тупо создать два потока один на целочисленные вычисления второй на вычисления с плавающей точкой вот.. что почитать по теме подробнее и на какие подводные камни можно наткнуться? ...манулов на русском не нашёл
Всё куда сложней. Операции надо грамотно смешивать в рамках каждого потока, а не просто разделять целочисленную и вещественную арифметику. Плюс поддержка HT была упразднена с выпуском процессоров Core и вновь вернулась, но под вывеской SMT, в Core i7, ну а оптимизация под последние отличается от таковой под просто Пень-4. Ну а на русском, скорей всего, ничего и нету.
и каким образом их надо смешивать, может быть кто нибудь даст более подробный ответ.. хотя бы сам принцип и куда копать, я канеш понимаю что сейчас эта технология уже устаревает но машин с P4 PD довольно много так что говорить о потере актуальности ещё рановато... короче что почитать и по каким правилам оптимизировать?..
ну почитал там и сказано типа если у вас гипотетически операции с массивом 0..1000 то разделите на два - 0..500, 500..1000 ничего подробнее не нашол.. или что можете опять же в общих чертах разделить вещественные и целочисленные операции по разным потокам.. исчерпывающего ответа я так и не получил
int_13h И не получишь Идея HT изначально исходит из предположения о том, что "некие средние" программы никогда не работают на максимуме пропускной способности (3 мопа за такт) и соотв-но параллельное исполнение двух потоков может повысить общую среднню проп.способность системы. Поэтому выигрыш, если он вообще достигается, то в основном на неоптимизированных или не поддающихся оптимизации программах (кои по мнению Intel и составляют больш-во). А если и не достигается, то и фиг с ним, т.к. взамен юзер все равно получает плюс в виде недорогой "квазидвухпроцессорной системы". Поэтому проще перечислить основные ограничения HT, препятствующие оптимизации, чем давать какие то общие рекомендации. Во-первых, проп.способность NetBurst по любому ограничена 3 мопами за такт (в среднем). Поэтому если удается оптимизировать один из потоков и достичь на нем заветных 3 мопов, то HT в принципе ничего улучшить не может, разве только ухудшить (в этом сл. м.б. лучше отключить HT либо совсем в биосе, если считаешь для себя на своей тачке, либо например, запустить доп.поток с холостым циклом из fdiv или fsqrt). Поэтому первая рекомендация от Интел - попытаться оптимизировать один поток и только если не удается добиться максимума проп.способности, то думать о том, как задействовать HT. Во-вторых, при вкл. HT все общие in-order ресурсы делятся поровну между двумя потоками (ROB и очереди планировщиков, line-fill буферы чтения ОЗУ, store-to-load и WC-буферы), а исполнительные ресурсы (порты запуска и исп.блоки) являются общими. И то и другое ес-но накладывает определенные ограничения. Например, что касается "разделения" вещ. и целочисленных операций - да, исп.блоки у них разные, но порты запуска то одни и те же, поэтому простые fpu-операции также могут занимать все порты и мешать целочисленным. Регистровые fpu-пересылки и сохранения в память идут в порт p0, сами вычисления в p1, загрузка из памяти в p2, вычисления адресов в p3 - в итоге простые fpu-циклы типа прибавления к элементам массива фикс.значения или умножения на фикс.значение могут выполняться на макс.скорости (если данные в кэше) и занимать все порты. Поэтому само по себе разделение на вещественные и целочисленные ничего не дает и выигрыш может получиться только при наличии простоев в вычислениях, т.е. на цепочках зависимых операций, или на ошибках условных переходов, или на ожидании загрузки данных из ОЗУ. (То, что порты p0 и p1 могут дополнительно принимать во втором полутакте простые целочисленные операции не сказавается существенно на среднем быстродействии, т.к. средняя проп.способность по любому ограничена 3 мопами за такт). Аналогично, и деление общих ресурсов пополам между потокаи может сказываться негативно, т.к.каждый из потоков может юзать только половину ресурсов несмотря на то, используются они др.потоком или нет. В-третьих, общее ограничение и для HT и многоядерных процессоров - общая шина памяти. Поэтому, если оба потока одновременно интенсивно обращаются к памяти, то по любому производительность несколько падает, т.к. запись\чтение из ОЗУ всегда быстрее идет при последовательном доступе, поэтому частые прыжки по разным адресам и чередования чтения и записи ухудшают проп.способность. При HT работа с памятью может усугубляться делением line-fill буферов чтения и WC-буферов записи пополам между двумя лог.процессарами, т.е. если даже второй поток их не юзает или юзает реже, то первому все равно доступна только их половина и соотв-но чаще возникают переполнения и остановки, чем при отключенном HT
leo благодарю за разъяснение короче явных механизмов оптимизации под HT нет - не оптимизировать и всё будет =) авторы прог с надписью "optimized for HT CPU" видимо пишут для красоты... толку от HT немного, а возможно даже больше вреда.. ладн займусь лучше MMX/SSE оптимизацией...
int_13h Во-первых, не "явных", а общих, и пишут не "для красоты", а под конкретную задачу. Ты же в своем вопросе все с ног на голову переворачиваешь - не имея конкретной задачи, спрашиваешь: чем бы занять два потока, один целочисленными, другой вещественными ? Как будто твоей проге пофиг чего считать, хошь целые, хошь вещественные, хошь и то и другое для галочки (или для курсовой ?) Во-вторых, и в однопоточной оптимизации хватает своих хитростей, требующих знания особенностей микроархитектуры, а для HT тем более. Поэтому в мануалах в основном и зостряют внимание на хитростях, подводных камушках и возможных граблях HT, т.е. на том чего и как делать не стоит. А дальше сам смотришь - или плюешь на все это дело (как собс-но простые смертные и поступают, особенно с учетомтем того, что на HT свет клином не сошелся или как отдельные "авторы" пытаешься экспериментировать\оптимизировать - авось чего и получится. А получиться может запросто само-собой, т.к. если в одном из потоков тормозит например чтение данных из памяти и из-за этого он значительную часть времени простаивает, то второй поток может в это время выполнять что-то полезное.
ну во первых - почему курсовая я в этом деле далеко не бегиннер во вторых не от балды а речь идёт о софтварном mpeg декодере и рисовальщике того что "надекодил" декодер в полноэкранное direct draw окно.. собсно имеет ли смысл делить их на потоки... как раз один поток крутил бы вещественные (SSE) вычисления второй достаточно "целочисленный".. но не суть просто хочу понять сам принцип которым следует руководствоваться да и останавливаться не собираюсь.. может результатом моих изысканий станет статья на васме - кто знает =)
По всей вероятности, декодить есть смысл в несколько потоков -- по числу логических процессоров в системе. Хотя тут надо знать тонкости кодирования, а я с этим не знаком совершенно -- никогда не интересовался. Ну а конкретно с HT не заморачиваться: считать, что все имеющиеся процессоры -- физические, и всё. Ситуации, когда HT вредит производительности, крайне редки.
SII Если конечно не наступать на известные грабли. Например, избегать конфликта данных в L1 - виртуальные адреса одновременно обрабатываемых данных в разных потоках не должны быть кратны 64К на еще не списанных в утиль Northwood-ах, и 2Mb на Prescott-ах и выше. А ведь 64К это гранулярность выделения памяти VirtualAlloc, и как следствие гранулярность базы стека всех потоков и больших блоков кучи - поэтому если не предпринимать спец.мер, рекомендуемых Интел, то вероятность конфликта, по кр.мере на Northwood-ах, м.б. отнюдь не "крайне редкой".
