Сколько ускорения дает гиперссылка? (теоретически)

11097
Mikhail

Мне интересно, каково теоретическое ускорение от гиперпоточных процессоров. Предполагая 100% распараллеливание и 0 коммуникаций - два ЦП дадут ускорение в 2. Как насчет гиперпоточного ЦП?

34

4 ответа на вопрос

56
Konrad Rudolph

Как уже говорили другие, это полностью зависит от задачи.

Чтобы проиллюстрировать это, давайте посмотрим на реальный тест:

enter image description here

Это было взято из моей магистерской диссертации (в настоящее время недоступно онлайн).

Это показывает относительное ускорение 1 алгоритмов сопоставления строк (каждый цвет - это отдельный алгоритм). Алгоритмы были выполнены на двух четырехъядерных процессорах Intel Xeon X5550 с гиперпоточностью. Другими словами: всего было восемь ядер, каждое из которых может выполнять два аппаратных потока (= «гиперпотоки»). Таким образом, тест производительности тестирует ускорение до 16 потоков (это максимальное количество одновременных потоков, которые может выполнить эта конфигурация).

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

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

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

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


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

Лучший ответ :-) Sklivvz 13 лет назад 0
Каковы фактические скорости алгоритмов, построенные в зависимости от количества ядер? Т.е. каков прирост скорости для самого быстрого алгоритма в этих тестах? Просто интересуюсь :). crazy2be 13 лет назад 1
@ crazy2be Для синей линии ([алгоритм Хорспула] (http://en.wikipedia.org/wiki/Boyer%E2%80%93Moore%E2%80%93Horspool_algorithm)) время работы уменьшается с 4,16 секунды до 0,35 секунд с 16 потоками. Таким образом, ускорение составляет 11,74. Тем не менее, это с гиперпоточностью. В зависимости от количества ядер, скорость этого алгоритма составляет 7,17 на 8 ядрах. Konrad Rudolph 13 лет назад 0
@Konrad - Это интересная статья, но этот график не поможет нам без соответствующего графика времени выполнения в зависимости от количества потоков. Сравнение алгоритмов по коэффициенту ускорения действительно работает, только если они имеют сопоставимую скорость в первую очередь. Если алгоритм «Наивный» выполняется в два раза дольше, чем алгоритм «Shift-or» (например), то гиперпоточность может просто возместить часть потерь от использования менее эффективного алгоритма. Mark Booth 13 лет назад 0
@ Марк, я демонстрирую * относительное * ускорение. Фактическая скорость этих алгоритмов не имеет значения для сопоставимости. В частности, входные данные достаточно велики, так что гарантированно будет * нет * «возмещение некоторых потерь от использования менее эффективного алгоритма» для многопоточности в целом. Наивный алгоритм также не может волшебным образом компенсировать потери, для этого должен быть какой-то механизм, и в этом случае он снижает нагрузку на память. Konrad Rudolph 13 лет назад 0
@ Марк Но я понимаю, что ты говоришь. Я должен отметить, что для наивного алгоритма и алгоритма Хорслпу нагрузка на память заполняет шину, поэтому полоса пропускания полностью используется. Для параллельных алгоритмов это уже не так. Konrad Rudolph 13 лет назад 0
Единственная проблема с этим ответом - я могу только проголосовать один раз. Это потрясающе объективный ответ на субъективный вопрос;) Journeyman Geek 13 лет назад 5
@ Конрад - я понимаю, но относительное ускорение - это только один из факторов. Если один алгоритм работает в 12 раз быстрее с 16-ю гиперпотоками, но все же занимает в два раза больше времени для работы на одном ядре, чем на другом, который масштабируется только до количества физических ядер (7x), то последний по-прежнему лучше использовать , поскольку он дает вам ваши результаты на 17% быстрее. Я знаю, что мои ученые предпочли бы завершить анализ данных через час, а не через 70 минут. * 8' ) Mark Booth 13 лет назад 0
@ Отметьте «тогда последний еще лучше использовать» - конечно. Но это был не вопрос (ни здесь, ни в моей диссертации). ;-) Konrad Rudolph 13 лет назад 0
@Konrad - Вопрос был "Сколько ускорения дает гиперпоток?" и ваш (ИМХО правильный) ответ: «Это полностью зависит от задачи». Проблема в том, что вы затем оправдываете это только половиной необходимых данных. Возможно, что для некоторых алгоритмов гиперпоточность приведет к замедлению (т. Е. При использовании 16 гиперпотоков будет медленнее, чем при использовании 8 реальных потоков), поэтому многие люди отключают гиперпоточность в своих BIOS, поскольку они провели сравнительный анализ и обнаружили, что гиперпоточность является недостатком для их применения. Mark Booth 13 лет назад 0
`@ Конрад` - отличный ответ! Не могли бы вы обновить ваш пост полезной информацией из комментариев? На заметку - я думаю, что времена "имеют значение". Снижение скорости ниже 1 секунды делает накладные расходы сопоставимыми. Если бы вы могли использовать тот же алгоритм, но с более высокой нагрузкой, такой, что максимальное ускорение привело бы к 10 секундам - ​​это, IMO, лучшая фракция для просмотра. Mikhail 13 лет назад 0
@Konrad, [могу ли я вас заинтересовать в написании поста об этом ответе в блоге] (http://meta.superuser.com/questions/2542/super-user-questions-of-the-week-15/2545#2545) ? Ivo Flipse 13 лет назад 2
Захватывающий ответ @KonradRudolph! И интересно почитать за дипломную работу. Я второй запрос @ Ivo для сообщения в блоге об этом. KronoS 13 лет назад 0
@ Ivo Angry Birds для Chrome только что вышел! Но конечно, я посмотрю, смогу ли я найти немного свободного времени на выходных. ;-) Konrad Rudolph 13 лет назад 0
Ссылка на тезис загружается «навсегда», и Firefox в конечном итоге сдается. Tshepang 10 лет назад 0
@Tshepang Да, к сожалению, веб-сайт уже несколько месяцев не работает, потому что технический контакт моего хоста не отвечает на запросы, и я слишком занят, чтобы позаботиться об этом, в настоящее время у меня нет места для замены. Konrad Rudolph 10 лет назад 0
Очень поздно на эту вечеринку, но все же: очень хороший ответ, я наконец понял, что за дело с этой гиперпоточностью! Спасибо! sebhofer 6 лет назад 0
18
geoffc

Проблема в том, что это зависит от задачи.

Идея гиперпоточности заключается в том, что все современные процессоры имеют более одной проблемы с выполнением. Обычно ближе к дюжине или около того сейчас. Делится на Integer, с плавающей точкой, SSE / MMX / Streaming (как бы это ни называлось сегодня).

Кроме того, каждая единица имеет разные скорости. Т.е. для обработки чего-либо может потребоваться целочисленный математический блок 3 цикла, но 64-разрядное деление с плавающей запятой может занять 7 циклов. (Это мифические цифры, не основанные ни на чем).

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

Однако ни одна задача не будет использовать каждую единицу выполнения каждый момент. Даже разделение потоков не может помочь полностью.

Таким образом, теория состоит в том, чтобы притворяться, что есть второй ЦП, другой поток может работать на нем, используя доступные неиспользуемые исполнительные модули, скажем, ваше транскодирование аудио, которое на 98% состоит из SSE / MMX, а модули int и float полностью простаивает, за исключением некоторых вещей.

На мой взгляд, это имеет больше смысла в мире с одним ЦП, поскольку имитация второго ЦП позволяет потокам легче преодолевать этот порог с небольшим (если вообще) дополнительным кодированием для обработки этого поддельного второго ЦП.

В мире ядра 3/4/6/8 с процессорами 6/8/12/16 это помогает? Не знаю. Столько? Зависит от поставленных задач.

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

Говорят, что некоторые «классы» вычислительных ресурсов выигрывают (в общих чертах). Но нет жесткого и быстрого правила, а для некоторых классов оно замедляет ход событий.

Хотя я искал что-то вроде «ускорения в 1,7 раза», этот ответ очень хорош, поскольку он не дает чёрно-белого взгляда на эту проблему. Mikhail 13 лет назад 2
@Mikhail: Дело в том, что не существует простого фактора - это зависит, как часто в жизни :-). sleske 13 лет назад 0
Суть права. Однако есть одно замечание: нет априорной причины, по которой одно ядро ​​должно получить большую выгоду от гиперпоточности, чем многоядерные. За неправильную задачу ни прибыли. Для правильной задачи обе прибыли на один и тот же фактор. Konrad Rudolph 13 лет назад 3
@Konrad: Я думаю, что я понял, что разница между одним ядром и двумя ядрами может быть более ценной, чем разница между 4 и 8 или 2 и 4. Т.е. наличие второго ядра для плохопоточного приложения может помочь еще немного. geoffc 13 лет назад 0
«Для плохопоточного приложения» - это важный момент. Но на самом деле поддержка многопоточности большинства приложений оставляет желать лучшего. Konrad Rudolph 13 лет назад 0
5
Mokubai

У меня есть несколько неопровержимых доказательств, которые я могу добавить к ответу geoffc: у меня фактически есть процессор Core i7 (4-ядерный) с гиперпоточностью, и я немного поиграл с транскодированием видео, что является задачей, требующей некоторого количества связи и синхронизации, но достаточной параллелизм, что вы можете эффективно полностью загрузить систему.

Мой опыт работы с тем, сколько процессоров назначено для выполнения задачи, обычно с использованием 4-х сверхпоточных «дополнительных» ядер, эквивалентно эквивалентному примерно 1 дополнительному процессору на вычислительную мощность. Дополнительные 4 «гиперпоточных» ядра добавили примерно столько же полезной вычислительной мощности, что и переход от 3 до 4 «реальных» ядер.

Конечно, это не совсем честный тест, так как все потоки кодирования, вероятно, будут конкурировать за одни и те же ресурсы в ЦП, но для меня это действительно показало, по крайней мере, незначительное увеличение общей вычислительной мощности.

Единственный реальный способ показать, действительно ли это действительно помогает, - это запустить несколько разных тестов типа Integer / Floating Point / SSE одновременно в системе с включенной и отключенной гиперпоточностью и посмотреть, сколько вычислительной мощности доступно в управляемой среда.

Хорошо ясный момент - это зависит от приложения. Я уверен, что высокоскоростные вычисления могут быть ускорены, поскольку ядро ​​0 и ядро ​​0-h будут связываться через один и тот же кеш, без использования медленной оперативной памяти. Mikhail 13 лет назад 1
@ Михаил, тогда проблема в том, что если обоим потокам требуется большой объем вычислительной мощности, то они оба будут конкурировать за одни и те же ресурсы и им было бы намного лучше общаться через кэш L3 общего процессора (в i7 есть кэш L1 и L2). на ядро ​​и общий кэш L3) или даже системную память и выполняют свои задачи отдельно. Это все массивное [карусели] (http://idioms.thefreedictionary.com/it%27s+swings+and+roundabouts) упражнение ... Mokubai 13 лет назад 1
3
Stephen Darlington

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

Intel говорит :

Измеренная производительность на процессоре Intel® Xeon® MP с технологией Hyper-Threading демонстрирует увеличение производительности до 30% по сравнению с обычными тестами серверных приложений для этой технологии.

(Мне это кажется немного консервативным.)

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

Архитектура AMD Bulldozer может быть интересной . Они описывают каждое ядро ​​как эффективно 1,5 ядра. Это своего рода экстремальная гиперпоточность или нестандартный многоядерный процесс, в зависимости от того, насколько вы уверены в его возможной производительности. Числа в этой части предполагают ускорение комментариев от 0,5x до 1,5x.

Наконец, производительность также зависит от операционной системы. Надеемся, что ОС будет отправлять процессы на реальные процессоры, отдавая предпочтение гиперпотокам, которые просто маскируются под процессоры. В противном случае в двухъядерной системе у вас может быть один простаивающий процессор и одно очень загруженное ядро ​​с двумя процессорами. Кажется, я вспоминаю, что это произошло с Windows 2000, хотя, конечно, все современные операционные системы имеют соответствующие возможности.

ОС должна убедиться, что потоки не блокируют часы друг друга :) Mikhail 13 лет назад 1

Похожие вопросы