=AlexD= (31.05.2022 14:26, просмотров: 339) ответил LightElf на Вот тут есть халяльноеЭто моё личное предвзятое мнение. Любое совпадение с реальностью является случайным и непреднамеренным.
-
- Смотрим на VexRiscv и грустим... - Evgeny_CD(1 знак., 01.06.2022 18:56, ссылка)
- Вообще, интересный вопрос, требующий своего исследователя - на
сколько (не)эффективно предки использовали транзисторный бюджет, и
почему. Если не изменяет склероз, то 1801 исполнял за 10 тактов
регистровые операции, по сути внутри все функции ложились на
микрокод, который рулил абстрактными арифметическими секциями. Есть
подозрение, что это от неразвитости систем проектирования и на
той-же площади можно было сделать гораздо более интересный
процессор. - =AlexD=(02.06.2022 10:06)
- Можно было (наверно), но задачей была совместимость с PDP-11. - LightElf(02.06.2022 11:16)
- На мой взгляд в системе команд PDP-11 было избыточное количество
адресаций. Поэтому никто её не повторяет в МК. Неэффективно. - =AlexD=(02.06.2022 15:32)
- PDP-11 - продукт своего времени. Операции "память-память" вполне
себе рулят, если память работает со скоростью проца. - LightElf(02.06.2022 16:22)
- Ну давай сравним, 32х разрядный ARM1 работал на частоте 8МГц, имел
3х ступенчатый конвейер и его производительность была ограничена
памятью до примерно 3MIPS, 1801 работал на частоте 5МГц и его
производительность в 0.5MIPS не была ничем ограничена. Разница в 6
лишних команд не достаточно, чтобы скомпенсировать отсутствие
команд память-память? А если крохотный кеш добавить и даже просто
очередь команд? - =AlexD=(02.06.2022 16:48)
- В данном разрезе бессмысленно рассматривать 1801 отдельно от PDP-11 и Q-Bus как таковых. Ибо стояла задача сделать микропроцессор, сохранив бинарную совместимость с более ранними мини-ЭВМ и электрическую совместимость с шиной Q-Bus (которая сама по себе ограничивает производительность на уровне, емнип, 1Мипс). - LightElf(02.06.2022 17:06)
- Ну давай сравним, 32х разрядный ARM1 работал на частоте 8МГц, имел
3х ступенчатый конвейер и его производительность была ограничена
памятью до примерно 3MIPS, 1801 работал на частоте 5МГц и его
производительность в 0.5MIPS не была ничем ограничена. Разница в 6
лишних команд не достаточно, чтобы скомпенсировать отсутствие
команд память-память? А если крохотный кеш добавить и даже просто
очередь команд? - =AlexD=(02.06.2022 16:48)
- оно архисложно конвейеризуется из-за огромного числа зависимостей,
а короткий конвейер = низкая частота. а на низкой частоте такие
решения очень эффективны. неспроста экономичные в момент своего
появления MSP430 разменяли всего один бит типа адресации на бит
количества регистров, а в целом повторяют идею PDP-11. - Mahagam(02.06.2022 15:47)
- Это всё несущественно, при желании можно и конвейеризировать, и
ускорить регистровые команды и даже ОоОЕ прикрутить. Там проблема в
том что коды операций зарезервированы за редко используемыми
комбинациями адресаций, которые проще было бы отдельными командами
реализовать. - =AlexD=(02.06.2022 15:59)
- всё это "несущественное" мы частично видим в развитии x86 -
сложнейший декодер команд, и всякие там прикрученные OoOE сами по
себе чуть ли не толще целого ядра арма. а биты, что уходили на
адресацию адресаций, теперь уходят на адресацию регистров, которых
нужно дохрена. - Mahagam(02.06.2022 16:10)
- И чего плохого? Сравни любые процессорные ядра с РОН внутри АЛУ и в ОЗУ (авр и 51й) - арифметика на первых просто на голову эффективнее. - POV(02.06.2022 16:19)
- В том то и дело, что память тормознутее процессора, поэтому
адресация из памяти в память никак программу не ускоряет, а
расширение регистрового банка - ускоряет. Пака данные подтянутся,
можно не только новые адреса вычислить, но и ещё остальную
регистровую арифметику успеть. - =AlexD=(02.06.2022 16:16)
- зависит от алгоритмов и задач. иногда слазить в кэш намного
быстрее, чем прочитать лишних три команды. собственно, любые
алгоритмы которые что-то там жирное считают регистрами не обойдутся
- в память так или иначе лазить придётся, потому и без кэша сейчас
ничего нет (ну или TCM на случай контроллеров) - Mahagam(02.06.2022 16:46)
- Если есть кеш данных, то есть и кеш команд, и это разные кеши с
разными шинами, и эти три команды считай бесплатны. Слазить в кеш
это пара тактов, а регистровые команды все утрамбовываются в
конвейер без зазоров. - =AlexD=(02.06.2022 16:53)
- все равно нельзя ж бесконечно играцца в песочнице и считать в
регистрах - один хрен эти регистры надо заполнять свежими данными,
и сохранять в память результаты. а это все равно обращения к
памяти/кэшу. - Mahagam(02.06.2022 17:01)
- Верно, проблемы начинаются когда места в песочнице не хватает, и
нужно пихать в стек промежуточные результаты. Чем шире регистровый
файл, тем реже такая ситуация возникает. Единственное препятствие к
расширению регистрового файла это ширина команды. - =AlexD=(02.06.2022 17:12)
- тьма алгоритмов которые работают с килобайтами/мегабайтами
информации. всякие там перемножения конских матриц, обработка
картинок, фильтры аудио над буферами, там никакое расширение
регистрового файла не спасёт. как только в регистрах умещается вся
инфа для удобной адресации входных и выходных данных, так сразу
дальнейшее расширение регистров не нужно. и один фиг - всё сводится
к большому кэшу. да и вообще - к трём уровням кэшей. - Mahagam(02.06.2022 17:28)
- Если одни не ускоряются, это не значит что нужно забить на другие,
которые ускоряются. Тем более потоковые алгоритмы ускоряют
массово-параллельными вычислителями, там важнее не количество
регистров, а их эффективная "ширина". Одно другому в общем не
мешает. - =AlexD=(02.06.2022 17:43)
- потоковые алгоритмы без конских кэшей и без быстрой памяти не
обходятся. иначе им некуда пихать результаты своих потоков. - Mahagam(02.06.2022 17:52)
- Для потоковых алгоритмов размер кеша не играет рояли, они любой кеш забивают, достаточно кешировать по крайней мере две страницы драм. =AlexD=(380 знак., 03.06.2022 07:58)
- потоковые алгоритмы без конских кэшей и без быстрой памяти не
обходятся. иначе им некуда пихать результаты своих потоков. - Mahagam(02.06.2022 17:52)
- Если одни не ускоряются, это не значит что нужно забить на другие,
которые ускоряются. Тем более потоковые алгоритмы ускоряют
массово-параллельными вычислителями, там важнее не количество
регистров, а их эффективная "ширина". Одно другому в общем не
мешает. - =AlexD=(02.06.2022 17:43)
- тьма алгоритмов которые работают с килобайтами/мегабайтами
информации. всякие там перемножения конских матриц, обработка
картинок, фильтры аудио над буферами, там никакое расширение
регистрового файла не спасёт. как только в регистрах умещается вся
инфа для удобной адресации входных и выходных данных, так сразу
дальнейшее расширение регистров не нужно. и один фиг - всё сводится
к большому кэшу. да и вообще - к трём уровням кэшей. - Mahagam(02.06.2022 17:28)
- Верно, проблемы начинаются когда места в песочнице не хватает, и
нужно пихать в стек промежуточные результаты. Чем шире регистровый
файл, тем реже такая ситуация возникает. Единственное препятствие к
расширению регистрового файла это ширина команды. - =AlexD=(02.06.2022 17:12)
- все равно нельзя ж бесконечно играцца в песочнице и считать в
регистрах - один хрен эти регистры надо заполнять свежими данными,
и сохранять в память результаты. а это все равно обращения к
памяти/кэшу. - Mahagam(02.06.2022 17:01)
- Если есть кеш данных, то есть и кеш команд, и это разные кеши с
разными шинами, и эти три команды считай бесплатны. Слазить в кеш
это пара тактов, а регистровые команды все утрамбовываются в
конвейер без зазоров. - =AlexD=(02.06.2022 16:53)
- зависит от алгоритмов и задач. иногда слазить в кэш намного
быстрее, чем прочитать лишних три команды. собственно, любые
алгоритмы которые что-то там жирное считают регистрами не обойдутся
- в память так или иначе лазить придётся, потому и без кэша сейчас
ничего нет (ну или TCM на случай контроллеров) - Mahagam(02.06.2022 16:46)
- всё это "несущественное" мы частично видим в развитии x86 -
сложнейший декодер команд, и всякие там прикрученные OoOE сами по
себе чуть ли не толще целого ядра арма. а биты, что уходили на
адресацию адресаций, теперь уходят на адресацию регистров, которых
нужно дохрена. - Mahagam(02.06.2022 16:10)
- Это всё несущественно, при желании можно и конвейеризировать, и
ускорить регистровые команды и даже ОоОЕ прикрутить. Там проблема в
том что коды операций зарезервированы за редко используемыми
комбинациями адресаций, которые проще было бы отдельными командами
реализовать. - =AlexD=(02.06.2022 15:59)
- PDP-11 - продукт своего времени. Операции "память-память" вполне
себе рулят, если память работает со скоростью проца. - LightElf(02.06.2022 16:22)
- На мой взгляд в системе команд PDP-11 было избыточное количество
адресаций. Поэтому никто её не повторяет в МК. Неэффективно. - =AlexD=(02.06.2022 15:32)
- Можно было (наверно), но задачей была совместимость с PDP-11. - LightElf(02.06.2022 11:16)
- Потактовая совместимость с древним наследием требует жертв. - LightElf(01.06.2022 19:11)
- Это да. Пару NOP слишком быстро исполнятся - вместо Вашингтона во
Флориду попадет :) - Evgeny_CD(01.06.2022 19:15)
- В БК-шные игрушки будет невозможно играть - LightElf(01.06.2022 19:21)
- Это да. Пару NOP слишком быстро исполнятся - вместо Вашингтона во
Флориду попадет :) - Evgeny_CD(01.06.2022 19:15)
- Вообще, интересный вопрос, требующий своего исследователя - на
сколько (не)эффективно предки использовали транзисторный бюджет, и
почему. Если не изменяет склероз, то 1801 исполнял за 10 тактов
регистровые операции, по сути внутри все функции ложились на
микрокод, который рулил абстрактными арифметическими секциями. Есть
подозрение, что это от неразвитости систем проектирования и на
той-же площади можно было сделать гораздо более интересный
процессор. - =AlexD=(02.06.2022 10:06)
- Смотрим на VexRiscv и грустим... - Evgeny_CD(1 знак., 01.06.2022 18:56, ссылка)