Обсуждение:Вычислительный конвейер

Эта статья тематически связана с вики-проектом «Информационные технологии», цель которого — создание и улучшение статей по темам, связанным с информационными технологиями. Вы можете её отредактировать, а также присоединиться к проекту, принять участие в его обсуждении.

???

Статью ещё никто не оценил по шкале оценок проекта

Эта статья была переименована по результатам обсуждения от 24 мая 2010 года.
Старое название Конвейер (процессор) было изменено на новое: Вычислительный конвейер.
Для повторного выставления статьи на переименование нужны веские основания, иначе такое действие будет нарушать правила (см. п. 8).

↓

Пожалуйста, добавляйте новые темы снизу

переводПравить

Последнее сообщение: 13 лет назад2 сообщения2 человека в обсуждении

У этой статьи существует незаконченный вариант Конвейер (процессор)/Перевод, являющийся попыткой перевода с английской википедии. `a5b 00:10, 17 августа 2009 (UTC)Ответить[ответить]

...и этот перевод следует либо закончить и заменить основную статью, либо удалить, либо перенести в пространство того участника, который занимается (занимался) переводом. Потому что это не дело, висеть двум редакциям одной статьи в пространстве статей. -- A^VB ^talk 09:42, 17 августа 2009 (UTC)Ответить[ответить]

Содержание статьиПравить

Последнее сообщение: 12 лет назад1 сообщение1 человек в обсуждении

Статья выглядит достаточно сырой. Навскидку:

Бывают синхронные и асинхронные конвейеры...
«Пузырьки — это как заглушки, в которых не случается ничего полезного при их прочтении, раскодировании, исполнении и записи результата. Они могут быть выражены при помощи инструкции NOP.» — Первое предложение я бы вообще убрал, второе тоже (или переформулировал), так как команда NOP вставляется не для образования пузырей (современные x86-совместимые процессоры ее вообще не допускают до исполнительных устройств, выкидывая на начальных стадиях конвейера)
«Программы типа gcov могут использоваться для того, чтобы определять, как часто отдельные ветки исполняются на самом деле, используя технологию, известную как анализ покрытия кода (англ. Code coverage analysis), хотя на практике подобный анализ является последней мерой при оптимизации» — при чем здесь покрытие кода и предсказание переходов, а тем более последняя мера??? С использованием инструментов покрытия (Code Coverage куда более распространен) составляется набор тестов (который используется не только для анализа переходов); затем программа запускается в тестовом режиме для сбора статистики (какой переход куда пошел), затем компилируется так, чтобы предсказателю процессора было удобно — это называется PGO (Profile Guided Optimization).
Есть статический, динамический и префиксный механизмы предсказания переходов, которые учитываются по разному...
Есть процессоры, которые выполняют сразу 2 ветви команд, потом одну выбрасывают — им не страшны условные переходы...

Исправлять или кто-то другой возмется? Evatutin 13:00, 25 ноября 2010 (UTC)Ответить[ответить]

тактовый генераторПравить

Последнее сообщение: 4 года назад3 сообщения2 человека в обсуждении

предлагаю убрать параграф про тактовый генератор, потому что написанное в нем а) не связано с конвейером, или связь такая далекая, что без дополнительных разъяснений не понять, а все то, что по существу, уже написано в параграфе "Бесконвейерная архитектура". б) вызывает вопрос: причем здесь повышение быстродействия? То есть, написано нечто неправильное. Если ставить дополнительные триггеры, то один такт станет быстрее, но вычисления в целом замедлятся, потому что они потребуют прохождения всей цепочки триггеров. 195.208.175.17 08:53, 11 октября 2018 (UTC)Ответить[ответить]

Традиционно считается, что более длинный конвейер позволяет добиться коротких стадий, т.е. высоких тактовых частот, см POWER6-7-8 но не 9 и их оценку длительности такта в FO4 (и долю в fo4 триггеров перед/после комбинационной схемы). Вычисления "в целом" могут вести себя по-разному (надо считать; переход от бесконв. к среднему конв. повышает производительность), но например, сверхвысокочастотный АЛУ (многостадийный) может изменить видимую программисту задержку между запуском операции и получением её результата в тактах (латентность плавающего или целого сложения или умножения). см https://csdl-images.computer.org/mags/mi/2017/02/figures/mmi20170200403.gif & https://pdfs.semanticscholar.org/presentation/a570/399ead1d75f40b8bccad73cfcf197eac3f61.pdf#page=6 `a5b (обс.) 15:22, 11 октября 2018 (UTC)Ответить[ответить]

Спасибо! Вопрос был вызван тем, что не сразу понятно, зачем вообще этот параграф. Когда читаешь, складывается ощущение, будто автор утверждает: чтобы сделать конвейер, достаточно вставить триггеры. Чтобы все прояснилось, я переименовал параграф, теперь он называется "Связь между сложностью конвейера и тактовой частотой процессора". 195.208.175.17 08:07, 15 октября 2018 (UTC)Ответить[ответить]

Добавить тему