Вопрос про «узкое горлышко» фоннеймановской архитектуры

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

А как же конвейеры? Каждый такт может быть необходимость и прочитать данные и записать данные и загрузить инструкции.

Пока непонятно, какое это имеет отношение к совместному или раздельному хранению данных и программ?

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

Что то я не вижу в описании фоннеймановской архитектуры что либо о том, что требуется что то «декодировать»:

Оперативная память представляет собой массив ячеек в каждой из которых хранится некое битовое значение. Каждая ячейка имеет свой уникальный адрес. Оперативная память хранит как инструкции так и данные. Процессор может обратиться к любой ячейке, зная ее адрес.

Действительно, слово «декодировать» отсутствует в вашем тексте. Какой вы из этого делаете вывод?

предположу «подразумевали но не написали», ну не все ж писать до последнего элемента.
тут надо понимать это в контексте тех древних времен, когда процы были очень большими и очень медленными.
если вкратце то читай отсюда и далее.

кроме вышесказанного, выборка инструкций более простая, чаще можно читать в пакетном режиме, некоторые ветвления выборки можно предсказать, писать вовсе не нужно, а в случае кэшей не надо беспокоиться, что данные могли чем-то измениться
в случае risc(или другого случая фиксированного размера инструкций) можно уменьшить разрядность выборки адреса
так или иначе всегда возможно добиться, чтобы очередь команд/конвейеры/итп не простаивали от нехватки кода
а на шине данных ад и израиль творится
ну и всяких ещё плюшек можно вспомнить/придумать
не даром же на тех же х86 начиная с первопней кэши кода и данных раздельные, т.е. внутри они фоннеймовские

По-моему это вообще не относится к обсуждаемому вопросу.

Есть принципы фон неймана, среди которых принцип однородности памяти. вопросы декодирования относятся к деталям реализации а не к вопросу архитектуры.

Вы правы. А что по-вашему относится к обсуждаемому вопросу?

Там все та же непонятная хрень, о том что, якобы, разделение команд и данных должно увеличить быстродействие. Но я сказал выше, это ошибка. Быстородействие ограниченно не каналом а объемом информации, который может обрработать процессор за один такт. Насколько я понимаю, это ошибочная информация, никакого «узкого горлышка» не существует

Там вот, в частности, написанно, что якобы:

В архитектуре фон Неймана процессор в каждый момент времени может либо читать инструкцию, либо читать/записывать единицу данных из/в памяти

Однако в описании модели Фон Неймана такого принципа нет

Но я сказал выше, это ошибка. Быстородействие ограниченно не каналом а объемом информации, который может обрработать процессор за один такт.

процессоры могут исполнять много инструкций за такт

Еще раз. Там некий вася пупкин пишет, что, якобы, за один такт процессор может либо исполнять инструкцию либо читать/писать данные. Но это сказал не Фон Нейман, это сказал вася пупкин, а у Фон Неймана, в сформулированных им принципах, такого ограничения нет

В архитектуре фон Неймана процессор в каждый момент времени может либо читать инструкцию, либо читать/записывать единицу данных из/в памяти

Однако в описании модели Фон Неймана такого принципа нет

Есть.

13.0 Organization of M

Изучайте.

такое ограничение действительно придумал вася, хотя на каких-то процессорах это так

Это не архитектура Фон Неймана, а описание машины EDVAC

каким образом разделение программ и данных может «расширить» это значение?

Таненбаум «архитектура компьютера», в самом начале об этом.

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

ты просто меряешь все категориями современного крайне оптимизированного и форсированного проца.
современное применение принципа «разделяй и властвуй» написал madcore чуть выше.

Перфокарты относились не к процессору, а к устройсвам ввода/вывода, это внешняя память

Это не архитектура Фон Неймана, а описание машины EDVAC

Архитектура фон Неймана, История возникновения термина

конечно :)
это устройство ввода и обеспечивало поток команд в процессор.
а устройство ввода-вывода с электромеханическим регистрами обеспечивало поток обмена данных с процессором.

Не знаю, про историю, но под архитектурой Фон Неймана понимают машину, построенную на принципах Фон Неймана, а принципы Фон Неймана не предполагают этих фантазий, которые этой архитектуре приписывал Бэкон

Гарвардская архитектура может одновременно записывать результат предудущей команды в память данных и читать следующую команду из памяти команд. Теоретически. Например.

На практике, мне не встречались реальные процессоры/МК на гарвардской архитектуре где внешние шины адресов и данных для памяти программ и данных были бы раздельными. Возможно, какие-то из них имели отдельные шины адреса и данных для памяти данных находящейся на том же кристалле что и процессор, но обычно этой памяти было слишком мало, чтобы обсуждаемое преимущество имело какое-то существенное значение.

Устройства I/O и их реализация не влияют на основополагающие принципы архитектуры. Они могут быть любыми

Не знаю про историю

понимают машину, построенную на принципах Фон Неймана

Приведите пожалуйста документы по которым вы изучаете эти принципы и, желательно, обозначте места, которые вызывают у вас ваши вопросы. Спасибо.

Везде пишут одно и то же, там нет никаких разночтений. Главный концепт - это совместное хранение данных и программ, однотипная обработка данных и программ

Везде пишут одно и то же, там нет никаких разночтений

Конкретнее, пожалуйста.

Чтобы стало понятно глянь на то как устроена Гарвардская архитектура с раздельной памятью для кода и данных. Живой пример pic-контроллеры от microchip

Не хочу тратить время, открывайте любой учебник и читайте. Мне не интересны «трактовки». Общепринято понимать, что это означает совместное хранение программ и данных, этого достаточно для обсуждаемого вопроса. Вопрос в том, каким образом общая память программ и данных должна препятствовать быстродейсвию процессора (как это часто утверждается, миф про некое «узкое горлышко»). Кроме этого меня ничего не интересует

Не хочу тратить время

Взаимно. Хорошего вам дня.

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

да полностью согласен - пофиг до реализации :)
главное что аппаратно потоки команд (перфокарты) и потоки данных (регистры) разделены - наглядно и понятно.

Чтобы преимущество было значимо, начни сравнивать сравнимое. Например два микроконтроллера с одинаковым объемом встроенной памяти

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

Вы же слышали про simd(aka векторные) инструкции?

каким образом разделение программ и данных может «расширить» это значение?

Вроде достаточно самоочевидным вещь.

Процессору для выполнения инструкции нужно прочитать:

• инструкцию
• данные для инструкции

Если шина одна, то он это будет делать последовательно. Если шины две, то он это может делать параллельно

главное отличие не прост совместное хранение, а хранение в перемешку, «виннегретом». к примеру за слова данных сразу же следует оператор их использующий, потом снова данные, а может и операнд, если данные не нужно или несколько слов данных подряд если нужно и т.д.
на современный лад, наиболее близкий вариант расположения данных и команд в памяти «фон неймана» это «польская нотация» (или обратная польская нотация, не сильно важно).
понятно что из этого винегрета будет сложно выковыривать команды и к примеру заставить работать предсказатель ветвления. или что подобное.

хотя и архитектура фон неймана на момент предложения выглядела очень хорошей.
последовательное развитие однака…

и еще друзья давайте вспомним, что на тот момент (задолго до появления конвейера команд) выполнение команды происходило емнип за десятки тактов процессора.
это другое !!

Например два микроконтроллера с одинаковым объемом встроенной памяти

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

Вот если бы сравнить гипотетический гарвардский процессор с раздельными шинами и фон-неймановский, чтобы памяти так гигабайты - там может и была бы заметна разница.

Быстородействие ограниченно не каналом а объемом информации, который может обрработать процессор за один такт. Насколько я понимаю, это ошибочная информация, никакого «узкого горлышка» не существует

Современный процессор может обрабатывать намного больше данных, чем может прислать ему современная оперативная память. Если бы не кеш и регистры, процессор бы простаивал 90%+ времени (ожидая приход запрошенных данных из памяти) и соответственно всё бы работало в 10+ раз дольше. Так что возможность увеличить канал однозначно положительно сказывается на работе проца. Собственно, в современных процах он так и увеличен: кроме внешней оперативной памяти проц может одновременно читать данные из разных своих кешей и из регистров.

Что касается конкретных уточнений про «память для данных», «память для инструкций» - это один из вариантов как распараллеить память, на данный момент не единственный, но на тот - скорее всего наиболее понятный. И вообще, нафига тебе обсуждать тезисы более чем полувековой давности? Они представляют скорее исторический интерес теперь, а не прикладной.

Меня вот что волнует: В современных процессорах встроенные контроллеры памяти, и у них есть «каналы». Если я правильно понимаю, может по разным каналам идти параллельное одновременное обращение к разным участкам памяти. Ну вот, располагайте данные и код в таких разных участках, и всё будет по-гарвардски.

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

Открой структурную схемку современного процессора(например вот https://jia.je/cpu/zen5.html) и узри на нем шину ведущую к L1D и шину ведущую к L1I. Регистры это уже внутри ядра, их данные через внешнюю шину не ходят. Ни с чем более ядро непосредственно не взаимодействует

Перфокарты относились не к процессору, а к устройсвам ввода/вывода, это внешняя память

Так никто и не говорит о том какая это должна быть память. Хранение данных это не только про память. В те времена вообще могло не быть никакого ОЗУ в современном понимании. Программа исполнялась прямо с магнитного барабана и молотила данные на перфокарты. Вот тебе и «раздельное хранение». Если данные писать на тот же барабан, то это медленнее т.к. нужно ждать пока барабан провернётся в нужное положение, а на карту/ленту данные можно валить сразу. Я уж не говорю про то, что лента может быть «бесконечной», а барабан не резиновый.

инструкцию

данные для инструкции

Если шины две, то он это может делать параллельно

Нет, не может. Потому что не будет знать по какому адресу данные надо прочитать до того, как прочитает инструкцию.

Зато может записывать в память результат предыдущей инструкции одновременно с чтением следующей.

Потому что не будет знать по какому адресу данные надо прочитать до того, как прочитает инструкцию

Может, например в стековой машине.

Ну то есть про конвейер ты таки слыхал, но всё равно нет? Баба-яга против?

Может, например в стековой машине.

Не думаю что в реальной чисто стековой машине стек будет реализован в виде RAM c шинами адреса и данных по которым процессор будет обращаться при обращении к стеку, там скорее всего вершина (или дно, кто как привык) будет представлена регистром процессора или группой оных.

там скорее всего вершина (или дно, кто как привык) будет представлена регистром процессора или группой оных

Вершина может быть, но таки её нужно будет читать из ОЗУ. В современных реалиях это будет именно RAM, а не что-то другое.

Ну так если обвешиваться всякими костылями, то и фон-неймановскую машину можно просто сделать с двумя разными шинами адреса/данных для лазания в одну и ту же RAM.

Вершина может быть, но таки её нужно будет читать из ОЗУ.

Не обязательно

В современных реалиях это будет именно RAM, а не что-то другое.

Да неужели. Гигантский FILO регистр тоже можно сделать.

Гигантский FILO регистр тоже можно сделать

Можно. Как это влияет на мой пример? В стековой машине процессор знает заранее где что читать. Для этого команду читать/декодировать не нужно. Можно обновлять внутренние регистры верхушки стека превентивно и параллельно чтению/исполнению команд.

Так оно так и работает в высокопроизводительных машинах. На уровне first level cache - гарвардская, а дальше уже фоннеймановская. Что в arm, что в x86. Чистые архитектуры наверное только в микроконтроллерах и остались

В стековой машине процессор знает заранее где что читать.

Но и понятия адреса данных тоже нет. Я не спорю что процессор стековой машины сможет одновременно прочитать команду и данные, я сомневаюсь что стековую машину корректно сравнивать с машинами с произвольным доступом к памяти даных.