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

↓

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

перевод

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

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

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

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

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

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

тактовый генератор

предлагаю убрать параграф про тактовый генератор, потому что написанное в нем а) не связано с конвейером, или связь такая далекая, что без дополнительных разъяснений не понять, а все то, что по существу, уже написано в параграфе "Бесконвейерная архитектура". б) вызывает вопрос: причем здесь повышение быстродействия? То есть, написано нечто неправильное. Если ставить дополнительные триггеры, то один такт станет быстрее, но вычисления в целом замедлятся, потому что они потребуют прохождения всей цепочки триггеров. 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)