Наиболее эффективная инструкция для очистки регистра
Уважаемые Коллеги!
На сайте www.linkedIn.com вступил в серьезную дискуссию с зарубежными профессионалами о наиболее эффективной инструкции IBM z Series для очистки регистра (GPR). Казалось бы – простой вопрос. Однако дискуссия оказалась весьма бурной. Уже более 80 постов !!! Много различных мнений, но нет результата. Чемпион не выявлен.
Приглашаю ознакомиться с материалами дискуссии. Приглашаю также обсудить эту тему на нашем сайте.
Для себя хотел бы получить ответы на следующие вопросы: 1. Какая из инструкций более эффективна для очистки регистра? 2. Насколько производительней эта инструкцию по сравнению с другими? 3. Если разница в производительности велика, то хотелось бы понять причину такой разницы. 4. Насколько способен Mainframe CPU выполнять несколько инструкций однозадачной программы в параллель?
Я считаю, что ответы на вышеперечисленные вопросы очень важны для понимания основных принципов функционирования современных процессоров IBM Mainframe!
К сожалению, сейчас у меня нет доступа к реальному Mainframe (только эмуляторы).
Коллеги, имеющие доступ к реальным Mainframe-ам . Пожалуйста, прогоните две тестовые программы на своих железках. Это займет у Вас несколько минут, а у процессора несколько миллисекунд. Полный исходный код этих программ можно найти здесь. https://docs.google.com/open?id=0BzTo154ZVtfSMVVRVUtFSHE2UDg
Надеюсь, что результаты теста будет интересны.
Заранее благодарен.
С уважением, Рустам Ахметов
Перенесено из комментария Рустама в текст статьи АКост-ом
Для облегчения запуска теста подготовил детальную инструкцию по выполнению теста с использованием программ ZINS100 и ZINS100N. Инструкция размещена здесь.
Рустам, поддержу большинство ваших оппонентов, бесперспективное это занятие, мерить на современных процессорах скорость выполнения инструкций. Да, вы получите, в конкретных условиях, относительную скорость, но это нисколько не гарантирует, что я получу то же самое. Побочных факторов влияния слишком много, число процессоров, количество LPAR и их веса, WLM-политка, версия микрокода, разные модели процессоров и т.д. К тому же после появления милликода, реализация команды может быть совершенно различной. "Настоящие" команды превращаются в сделанные на милликоде и наоборот. Параллельность выполнения тоже весьма условна, главное чтобы за конкретной командой стояли не зависящие от нее и попадающие в один такт процессора. И понятно, что здесь слишком много вариантов.
Давайте разберемся. Вы проанализировали исходный код моих программ? Что в них некорректно? Вы пропускали тест моей программы? Если пропускали, то на какой модели CPU?
Рассуждения оппонентов - это лишь теория. Теория должна быть проверена на практике. Главный тест - реальное выполнение программы на реальной машине, лучше на разных машинах в различных условиях, а далее анализ результата. Обращаю Ваше внимание. Не один из них не выполнил мой тест на реальной машине. Не один из них не предложил другой текст программы для оценки относительной производительности инструкций CPU по очистке регистра.
Обратите внимание, что предлагал Dave. Dave - I think the only way to know for sure would be to code each method in a tight loop of say a couple million iterations, clock each one and compare the difference.
К моему глубокому сожалению рассуждения оппонентов не дают ответы на поставленные вопросы (см. вопросы по теме).
Предлагаю прогнать тесты и дискутировать с конкретными цифрами в руках.
У Вас есть возможность прогнать тесты на реальной машине?
Рустам, программы ваши посмотрел, код понятный и наверное работает. Разве, что среди 1079 инструкций для z196 возможно есть ещё какая-то другая команда очистки регистра. Выполнить в данный момент не смогу, мой z9 в процессе переезда на новую площадку дислокации. Правда смысла в выполнении особенного не вижу, говорил о причинах ранее. Насчет параллельности, вернее "out of order", если я не ошибаюсь, то она есть только на процессорах z10 и выше. На z10 может выполняться 2 инструкции, на z196 - пять за один цикл
Я совершенно согласен с AKonev, что результаты теста не будут прямолинейны, потому что есть кэши, есть опережающие выборки и прочее. Но мне кажется, что если в одной программе последовательно одинаковым образом зациклить похожие функционально команды, то должны получится похожие результаты, хотя бы в рамках одной конкретно машины. У меня при прогоне на z800 получилось именно так. На z9 - сильно по-другому. И мне тоже интересно, почему так.
Александр, Прошу обратить внимание, что я не пытаюсь измерить скорость каждой инструкции, а хочу найти наиболее эффективную инструкцию для выполнения простейшего действия - зачистки регистра.
О побочных факторах. Для анализа влияния побочных факторов необходимо запустить тесты и проанализировать их результаты. Вы запускали тесты?
Относительно милликода. Тимоти в дискуссии упоминал о том, что короткие команды на продвинутых процессорах выполняются аппаратно без использования микрокода и милликода. Я с ним согласен.
О параллельном выполнении инструкций на одном CPU. Моя программа ZIN100N как раз и предназначена для проверки возможности выполнения инструкций в параллель (для одного примитивного случая). Запустите и узнаете каковы возможности СPU.
Там что-то с правами доступа - мне не дает посмотреть эту инструкцию (хотя я предполагаю, что там написано). Google требует, чтобы я попросил у Вас разрешения не просмотр. С исходными текстами такого не было.
Слушайте, а вот меня мысль пробила.... В реальных программах очистка регистра занимает малые доли процента от общего количества выполняемых команд. Мы вот за что боремся? Решаем академическую задачу или пытаемся поиметь реальную прибыль?
Конечно это задача в большей степени теоретическая, чем практическая. Реальная польза может измеряться в долях процента. Однако, дискуссии по данной теме позволяет понять особенности архитектуры современных процессоров z Series.
Мое мнение. Каждый уважающий себя программист профессионал должен уметь использовать в своих программах оптимальные инструкции и алгоритмы для достижения поставленных задач.
Потешить свое эго например. Хочется думать что ты разбираешься глубже и тд. Я такой же вопрос задавал тут на форуме. Но сейчас моя позиция - максимальная читаемость, чтобы исходник было проще передавать из рук в руки. Поэтому мой ответ LA, так как она же используется для установки других не нулевых значений.
Вам не кажется что не стоит относить всё на свой счет? Задавая такой же вопрос на форуме, я отнес себя в ту же группу риска и главное объяснил свои причины такого вопроса. Кроме эфемерной теоретической технической ценности это обсуждение вообще не представляет никакой реальной пользы. Жизненная правда такова, что в условиях нехватки специалистов, а также бюджета и времени на столь детальные ревью и оптимизации, реальная _современная_ задача - это как получить оптимальный результат с средних программистов. В этом плане правильнее всего писать на C, отдавая компилятору заботу о построении оптимального кода в зависимости от используемой архитектуры. Там даже опции разные для каждой архитектуры. Гораздо больший выигрыш будет от группировки инструкций работающий с той же областью для включения Out Of Order, чем банальная игра с заменой одной инструкции разными вариантами.
Сергей, твоя позиция мне понятна и во многом импонирует. Как профессионал я отдаю себе отчет в неоптимальности массы моих инструкций, но я всегда выбираю максимально простые и удобочитаемые решения. Но как академическое упражнение - да, интересно.
Руслан, так граждане у нас разные (что отражает многообразие мира), и позиции у них разные... А я вот что хочу спросить: а у Вас получилось прогнать тесты в соответствии со свежеявленной инструкцией? А то в письме, что мне пришло, нет нужных циферок, они в дампе остались невытащенными, вроде.
Предварительные результаты тестирования сравнительной производительности некоторых инструкций по очистке регистров общего назначения размещены в каталога файлов.
Там же размещены исходные тексты программ, которые использовались при тестировании.
Обратите внимание на различное поведение инструкций на моделях z9 BC, z114 и z10 BC.
К сожалению пока нет результатов тестов на z10EC и z196.
Интересные результаты. Не правда ли ?
Давайте подискутируем и попытаемся сделать выводы по результатам тестов. Прошу Ваших оценок и комментариев.
В конец статьи добавил прямые ссылки на программы и на результаты тестирования.
Кстати, Рустам, было бы интересно ознакомиться с Вашей интерпретацией результатов, чтобы начинать дискуссию не с голого листа. Ну хотя бы в виде коротких выводов в хвосте основной статьи.
Давайте посмотрим на результаты тестов в таблице и порассуждаем.
z800 Тут все ясно - LHI, SLR, XR, SR имеют одинаковую производительность. CPU не способен выполнять инструкции в параллель.
z9 BC LHI в два раза быстрее SLR, XR, SLR. SLR, XR, SR имеют одинаковую производительность. CPU не способен выполнять инструкции LHI в параллель (!!! ???). CPU может выполнять инструкции типа SLR в параллель, но не более двух.
Обратите внимание на частоту процессора и время выполнения цикла. В данном тесте CPU работает на полной скорости. Для случая ZINS100 CPU выполняет одну инструкцию за цикл для LHI и одну инструкцию за два цикла для SLR, XR, SR. Для случая ZINS100N выполняет одну инструкцию за цикл для LHI и две инструкцию за два цикла для SLR. Средняя производительность не превышает одной инструкции за цикл.
Z10 BC Отличная картина от z9 BC. Для случая ZINS100 CPU производительность инструкций LHI, SLR, XR, SR одинакова. Для случая ZINS100N средняя скорость выполнения инструкций типа SLR в два раза выше LHI. Для данных тестов процессоры работают не на полной скорости. Опять вопрос – почему CPU не может выполнять инструкции LHI в параллель?
Z114 Поведение инструкций похоже на z9 BC и отличается от z10 BC.
Про кэш. Полагаю, что в тестах все инструкции находятся в кэше. Все подготовительные действия по выполнению инструкций выполняются в параллель с логикой выполнения основных действий инструкций .
Про преобразование виртуальных адресов в реальные. В основных циклах программы нет преобразования адресов. Быть может только для команды перехода.
LHI vs SLR Напрашивается вопрос - откуда такая разница в выполнении инструкций для z9 и z144? Что отличает LHI от SLR? Установка CC. Может в этом дело ?
Прерывания. При коротком кванте цикла вероятность возникновения прерывания уменьшается. Об этом говорят стабильные цифры минимума времени выполнения цикла. По этому поводу можно написать целую статью, а может и диссертацию.
Вышеприведенные рассуждения носят предварительный характер. Конечно, детальные ответы на приведенные особенности поведения инструкций и вопросы может дать только IBM. Хотя, порассуждать на эту тему можно всем.
Прошу высказывать Ваши соображения.
P.S. Для полноты картины хорошо бы иметь результаты тестов на z9 EC, z10 EC и z196.
Новая версия программ тестирования производительности инструкций z Series.
В каталоге файлов выложена новая версия программ для тестирования сравнительной производительности некоторых инструкций CPU z Series по очистке регистров общего назначения.
Изменить программу мне посоветовал один коллега из США.
Теперь не надо искать по дампу значения тайминга. Все это теперь вместе с номером модели CPU загружается в регистры и показываются в SYMPTOM DUMP OUTPUT.
Сразу видно результат в следующем виде. 17.49.24 JOB00038 IEA995I SYMPTOM DUMP OUTPUT 721 721 SYSTEM COMPLETION CODE=0C1 REASON CODE=00000001 721 TIME=17.49.23 SEQ=00013 CPU=0000 ASID=001A 721 PSW AT TIME OF ERROR 078D3000 80007FB6 ILC 2 INTC 01 721 ACTIVE LOAD MODULE ADDRESS=00007B20 OFFSET=00000496 721 NAME=ZINS100 721 DATA AT PSW 00007FB0 - 980BF4B0 00000000 CA454B05 721 GR 0: 00002064 1: F0F3F840 721 2: 00000064 3: 00002710 721 4: 00000000 5: 0011109C 721 6: 00000000 7: 0007266C 721 8: 00000000 9: 0008447C 721 A: 00000000 B: 0009615C 721 C: 833E7B4A D: 00006F60 721 E: 80FDDDB8 F: 80007B20 721 END OF SYMPTOM DUMP
R0 - CPU model R1 - CPU model Index R2 - количество инструкций в цикле R3 - количество циклов R5 - LHI тайминг в микросекундах R7 - SLR тайминг в микросекундах R9 - XR тайминг в микросекундах RB - SR тайминг в микросекундах
Есть такой мужик – Боб Роджерс (Bob Rogers - https://share.confex.com/share/116/webprogram/Person3650.html -), IBM-овский евангелист, разработчик zOS, инженер и активно пишущий человек. В 2012 году он опубликовал несколько очень интересных статей, относящихся к теме реализации милликода, конвейеров и прочих моментов, связанных с работой современных процессоров системы z. Особенное место среди его работ (в контексте нашего обсуждения) занимают следующие:
есть еще, но главное - в первой, остальные - приятный десерт.
Так вот, главная мысль, на которую бы хотелось обратить внимание, такая: в каждом поколении и серии процессоров длина конвейера, реализация милликода и алгоритмы распараллеливания разные, и достаточно сложные.
Поэтому удивляться тому, что в каких-то машинах конкретная команда выполняется быстрее, чем в другой, не приходится – другая реализация милликода, другая отработка конвейера и так далее. Я правда не понимаю, что тут такого удивительного, если учесть, что на реализацию контейнеров и пайплайнов кинуто такое количество кода, и сложность алгоритмов там соизмерима со сложностью самой операционной системы.
Более того, я отчетливо понимаю, что при такой сложной логике даже последовательность команд имеет значение – при последовательном выполнении тысячи одинаковых команд единичная команда может выполняться медленнее, чем в смеси с другими, потому что алгоритмы выборки и обработки результатов становятся другими.
Иными словами, для меня становится актуальным следующий вопрос: какое сакральное знание архитектуры мы получаем, если узнаем, что при цикле в 1000 команд одна команда выполняется быстрее другой, и на разных моделях это по-разному? Ведь в другой смеси это может оказаться совершенно иначе?
Я думаю, что особенно никакого. У нас теперь есть интересное наблюдение, но без далеко идущих практических результатов. В реальной жизни для очистки регистра я все равно буду использовать максимально наглядную команду, а не максимально эффективную с точки зрения милликода, тем более, что это будет относительная эффективность (зависящая от модели, смеси и таланта милликод-программиста). В конечном итоге пока я буду вспоминать, что же я сделал и почему, например, использовал SLR вместо XR, пролетит столько времени, сколько я не сэкономлю с помощью применения более быстрой команды!
Таким образом, главным практическим результатом данного обсуждения я считаю то, что Рустам подвиг меня прочитать статьи Роджерса и понять, насколько далеко продвинулась архитектура процессора. И я Вам искренне за это благодарен, Рустам!
Я думаю, что особенно никакого. У нас теперь есть интересное наблюдение, но без далеко идущих практических результатов. В реальной жизни для очистки регистра я все равно буду использовать максимально наглядную команду, а не максимально эффективную с точки зрения милликода, тем более, что это будет относительная эффективность (зависящая от модели, смеси и таланта милликод-программиста). В конечном итоге пока я буду вспоминать, что же я сделал SLR вместо XR, пролетит столько времени, сколько я не сэкономлю с помощью применения более быстрой команды!
Да-да и ещё раз да! К тому же, если в прошлой жизни было достаточно легко запомнить и оперировать сотней ассемблерных команд ЕС ЭВМ, то управляться с более чем тысячью современных практически нереально. Да и зачем, если через очередные два года командный ландшафт будет выглядеть иначе. А материал по первой ссылке конечно великолепен, презентация была также в материалах весеннего Share 2011 года
Пожалуйста взгляните на иллюстрацию по ссылке (Pipeline View of Instructions and Superscalar multiple instruction overlap). https://docs.google.com/open?id=0BzTo154ZVtfSR0hvY204c3hia1U
Иллюстрация подготовлена для пояснения основной идеи использования циклов для сравнительной оценки производительности этапа "'Execute" разных инструкций по очистке регистра общего назначения.
Не претендуя на абсолютную точность, иллюстрация показывает упрощенную схему выполнения инструкций в CPU z Series (Pipeline View of Instructions and Superscalar multiple instruction overlap).
Посмотрите также материал Боба Роджерса (IBM Corporation) https://share.confex.com/share/117/webprogram/Session9682.html
Взгляните на результаты тестов с с использованием программ ZINS100 и ZINS100N для z196. https://docs.google.com/open?id=0BzTo154ZVtfSYkNRYlUtM29CUnc
Пожалуйста обратите внимание на стабильность результатов. Как Вы думаете, что это могло бы значить?
Давайте обсудим, могут ли циклические тесты дать информацию о сравнении производительности нескольких инструкций по очистке регистра?
Уважаемые Коллеги, если не хочется обсуждать, то может просто проголосуем ?
Есть две основные точки зрения.
1. z Series Mainframe CPU очень сложен и умен. Программист должен рассматривать Mainframe CPU как черный ящик. Используй любую инструкцию, не разбираясь какая лучше. CPU найдет наилучший вариант исполнения функции за программиста. Невозможно оценить сравнительную производительность инструкций по очистке регистра с использованием тестовых программ с циклами. Невозможно оценить способность CPU выполнять несколько инструкций в параллель, используя программы с циклами. Тестовые программы бесполезны.
2. Программист может использовать тестовые программы для оценки сравнительной производительности инструкций (например, по очистке регистров для z Series Mainframe CPU). Программист может использовать тест программы для оценки способности CPU выполнения нескольких инструкций в параллель. Тестовые программы могут дать полезную информацию об архитектуре CPU и сравнительной производительности различных CPU IBM z Series.
Перед принятием решения пожалуйста проанализируйте иллюстрацию и опубликованные результаты тестирования на реальных Mainframe.
Добавлять комментарии могут только зарегистрированные пользователи. [ Регистрация | Вход ]
