хм ... есть немного времени, попробую изложить одну мысль ..

Одно время народ увлекался ломанием DES, но компьютер, как и одночиповые' решения делали все медленно .... была идея сделать полностью аппаратный кодер/декодер. Там не сложно, алгоритм DES достаточно прост - проблема в большой размерности данных.
Чтоб меньше писать, сделаю сокращения:
REG - регистр-защелка. По входному clock защелкивает данные и они
появляются на его выходе
ADD - сумматор
CMP - схема проверки на равенство текущего
SH (shift) - переставить биты
DATA - обрабатываемы данные(текущий пароль)
В DES используются перестановки бит, суммирование, XOR,умножение (которое приводится к множественным ADD-SH) и т.д. Самое важное - ТАМ НЕТ ДЕЛЕНИЯ! Короче, реализуемо в "рассыпухе". Кстати ... ... делать на дискрете не рекомендую. )

Поиск нужного пароля методом перебора, т.е.:
1.
DATA-> [ADD-SH]->....->[ADD-SH]->CMP -{если не найдено - модифицировать DATA и на начало}

Вариант 1. в кремнии не работоспособен - буквально через несколько аносекунд произойдет рассинхронизация бит данных. Способ борьбы - введение REG в начало и тактование частотой, медленнее времени выполнения операций всеми блоками. (к слову - там еще и куча параллельных веток )
Т.е. будет так:
2.
DATA->REG-> [ADD-SH]->....->[ADD-SH]->CMP -{если не найдено - модифицировать DATA и на начало}

Чтоб было понятнее, я конкретезирую модель:
цепочек [ADD-SH] будет = 3
время выполнения операции каждым блоком = 1
Т.о., аппаратный "процессор" будет иметь время выполнения
= 1 + 3*(1+1)+1=1+3*2+1=8

Есть ли пути ускорения? Частоту выходных результатов (перебранных паролей) быстрее, чем 1/8 не выйдет - блоки не смогут. Чтож делать?
А что, если поставить REG между цепочками [ADD-SH]?
3.
DATA->REG-> [ADD-SH]->REG->....->[ADD-SH]->REG->CMP -{если не найдено - модифицировать DATA и на начало}

В этом примере общее время увеличилось на 3 REG, но(!!!) но максимальная скорость перебора возрасла из-за того, что сдерживающим фактором является время выполнения логики внутри цепочки [ADD-SH]-REG. {Это трудно понять? увы, сейчас мне трудно об'яснить, sorry}
При этом частота выдачи результатов будет уже 1/3

Есть ли еще резерв? - поставить REG чаще!
4.
DATA->REG-[ADD-REG-SH-REG]-....->[ADD-REG-SH-REG]->CMP -{если не найдено - модифицировать DATA и на начало}
Т.о., каждая арифметико-логическая операция оказалаль 'задемпфирована'
собственным регистром.
Общее время выполнения цикла сильно возрасло:
1+3*4+1=14
при этом скорость выдачи результата составляет 1/2

К чему я? - вот примерно так и происходит взаимосвязь между количеством стадий конвейера процессора и его 'разгонябельностью'.

Эх!

И зачем ты всё это выложил - народ у нас нынче попроще)))

serj_

кому полезно? мы тут процы не разрабатываем а чуваков из AMD и Intel (а вдруг они тоже шарятся по этому форуму ) ИМХО этому учить не надо

Зря вы так.
Knowledge = power.

Ну как тебе сказать ... тебе нравится использовать готовые заготовки
типа "Intel лучше AMD - у него cache 2 level бОльше" не вдумываясь
в смысл фраз?
Сколько раз говОрено, что у P4 конвейер бешенной длины и никто
ведь не задумался "почему и зачем".

Очень мало, кто сможет ответить на такой вопрос(надо знать аппаратуру)
.... я попробовал, может кому будет интересно кроме меня.

serj_ Очень мало, кто сможет ответить на такой вопрос -
наверное, я отвечу.

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

В принципе увеличение частоты совсем не полезно, и ,на самом деле ,для каждой архитектуры существует оптимум частоты, при которой производительность максимальна, потому что
при уменьшении все очевидно,а вот
при увеличении частоты уменьшается время такта, и растут в смысле становится больше потерь на холдах тригеров, к примеру с каждым тактом не зависимо от частоты надо тратиь 0.2нс(к примеру) на холд и сетуп тайм ->чем больше частота тем больше потери,иногда даже очень большие

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

а разгон объяснит еще проще

(в амд точно)процессоры на одном ядре имеют одинаковый фздизайн,
они практически ничем не отличаются,кроме зашитых в мостиках КУ и
качества производства, почему б тогда 1700+ не поработать ак 2600+

j0
Не согласен. Для каждой архитектуры существует предельная частота и при ней, естественно, производительность максимальна.

Тем более не согласен. Вообще, по-моему, время выполнения операций измеряют в тактах процессора. Увеличиваем частоту тактования проца - количество тактов, за которое выполнится операция не изменится, но за счёт уменьшения длительности такта общее время выполнения операции в наносекундах конечно же уменьшится

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



Смысл сказанного j0 несколько другой (j0, не обидешься?) :
Мин. время выполнения какой-то конкретной операции неизменно (зависит только от технологических норм изготовления кристалла). Путем разбивания всей операции на микростадии можно добиться бОльшей потоковой скорости выдачи результатов, но время выполнения самой операции от начала(прихода данных) до конца(получения результатов) только увеличится из-за обслуживания разбиения на микростадии.

serj_
Но ведь это уже будет другая архитектура. А мы говорили о наращивании частоты для одной и той же архитектуры. Или я не прав?

скорее всего нет

Прости, но ... название темы: конвейер и "разгонябельность",
что переводится как "длина конвейера и возможность повышения частоты"




По данным j0 (если я правильно понял его идею!) на каждой буфферезировании(стадии конвейера) теряется ~0.2нс, что совсем не мало по сравнению с текущими частотами в 2-3GHz.
Наверно, цифра в 0.2nS примерна? .... но порядок правильный, я думаю.

оффтоп
CryoMonsteR
а сила есть - ума не надо.

serj_

по поводу темы в целом я высказался в первом посте
далее я обсуждал только конкретные высказывания

разбиение на микрокоманды конечно занимает время, но за счет паралельного выполнения этих микрокоманд общее время выполнения всё равно уменьшится

VanHalen

Имелась ввиду честная частота, то есть когда период равен максимальной критической цепи,а не то что счас ставят производители.
(просто то утверждение я записал на лекции и не сомневаюсь в правоте)

А в умножителе имелись ввиду не микрокоманды а такты.

Ps Да и вообще конвейеры это уже не актуально