LINUX.ORG.RU

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

 ,


0

3

Источники пишут, что, якобы узкое место в том, что память и программы используют одну шину. Я не совсем это понимаю, ведь за один такт процессор все равно не может обрабатывать больше чем установленная разрядность (8, 32, 64), каким образом разделение программ и данных может «расширить» это значение?


Ответ на: комментарий от cobold

Да, поэтому разницы для современных машин увешанных костылями не будет. Да и вообще, непонятно насколько вообще корректно современные машины с конвейерами, предсказаниями, кэшами и пр. называть фон-неймановскими.

Но ТС-то вроде не про это спрашивал, судя про вопросу.

Stanson ★★★★★
()

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

X512 ★★★★★
()
Ответ на: комментарий от madcore

Спасибо, хорошее объяснение.

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

Может быть внутри они НЕ фоннеймовские, или я потерял нить

blex ★★★★
()
Ответ на: комментарий от Saakx

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

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

pfg ★★★★★
()
Последнее исправление: pfg (всего исправлений: 1)
Ответ на: комментарий от pfg

возможно несколько каналов памяти

Я так и написал. На моей конкретной машине четыре.

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

Я и не собирался. Раз каналов несколько, то возможны потоки каждый по своему каналу. Но не больше одного потока на канал. Но каналов несколько. Значит потоков несколько.

нет

Что «нет»? Читать научись?

Saakx
()
Ответ на: комментарий от Saakx

для проца с кешами данных и команд разделение внешних каналов памяти не даст никаких плюсов.
все мудренности и оптимизации сделаны в соответствующих кешах.

pfg ★★★★★
()
Ответ на: комментарий от pfg

для проца с кешами данных и команд разделение внешних каналов памяти не даст никаких плюсов

Какие ваши доказательства? Тем более, что кеши разделены, значит считывание в них происходит раздельно. Ещё и каналы раздельны. Это может дать ускорение.

все мудренности и оптимизации сделаны в соответствующих кешах

Ну и что? Это другое!

Saakx
()
Ответ на: комментарий от blex

Может быть внутри они НЕ фоннеймовские, или я потерял нить

да, гарвардские, заговариваюсь

madcore ★★★★★
()
Ответ на: комментарий от Stanson

Какими костылями? Z80 с остальными одноклассниками машет ногой M1, передавая привет )
Пожалуйста, привязывайся к ноге и декодируй её в память, как хочешь.

GAMer ★★★★★
()
Ответ на: комментарий от Saakx

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

pfg ★★★★★
()

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

Если ты про "вообще", то этот тезис уже не настолько актуален.

ya-betmen ★★★★★
()
Ответ на: комментарий от pfg

считывается все равно из общей памяти

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

Saakx
()
Ответ на: комментарий от Saakx

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

pfg ★★★★★
()
Ответ на: комментарий от GAMer

а для инструкций типа ld a,n - при чтении n m1 тоже будет активен?
тогда прикольно, можно было б напрямую адресовать 64к+64к

madcore ★★★★★
()
Ответ на: комментарий от cobold

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

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

так инструкция-то одна. как ты в параллели будешь выполнять две последовательные инструкции

также, как и на пресловутых х86 начиная с первопней

madcore ★★★★★
()

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

neumond ★★
()
Ответ на: комментарий от madcore

Ну я не электронщик, но судя по мануалу, M1 длится всего ~первые два такта, так что если использовать M1-ногу для чипселекта, то n будет выбираться уже из памяти данных, что логично, однако )
И да, подробностей не помню, но кажется это кто-то использовал в начале 80х, когда пытался делать то ли «рабочие станции», то ли довольно умные терминалы на Z80, но чем это закончилось - очевидно...

GAMer ★★★★★
()
Ответ на: комментарий от no2700

каким образом общая память программ и данных должна препятствовать быстродейсвию процессора

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

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

neumond ★★
()
Ответ на: комментарий от Iron_Bug

так инструкция-то одна…

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

cobold ★★★★★
()
Ответ на: комментарий от Iron_Bug

все давно придумано :) Hyperthreading - одновременое выполнение двух, а то четырех инструкций на одном аппаратном проце, если онные инструкции используют разные функциональные модули процессора.

pfg ★★★★★
()

Источники пишут, что, якобы узкое место в том, что память и программы используют одну шину. Я не совсем это понимаю, ведь за один такт процессор все равно не может обрабатывать больше чем установленная разрядность (8, 32, 64), каким образом разделение программ и данных может «расширить» это значение?

Это всё устарело 40 лет назад. В настоящее время уже нет никакой там «фоннеймановской архитектуры», современная реализация такого устройства как «компьютер x86» в виде какого-нибудь ноутбука или сервера - это уже давно франкенштейн из кучи разных архитектур, применённых в неописуемой сложности комбинации таким образом, чтобы БЫЛО БЫСТРО. Там, где было медленно - там везде тупо взяли и ускорили, расширили шину, запрефетчили и прочее. Во что железо стоит, то и ускоряют. Это уже никакая там не «архитектура», это «как получилось, так получилось».

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

lesopilorama
()
Последнее исправление: lesopilorama (всего исправлений: 1)
Ответ на: комментарий от ya-betmen

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

«Видеокарта» называют этот кусок железа щас.

lesopilorama
()
Ответ на: комментарий от Stanson

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

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

lesopilorama
()
Ответ на: комментарий от pfg

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

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от no2700

Главный концепт - это совместное хранение данных и программ, однотипная обработка данных и программ

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

lesopilorama
()
Ответ на: комментарий от lesopilorama

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

ya-betmen ★★★★★
()
Последнее исправление: ya-betmen (всего исправлений: 1)
Ответ на: комментарий от pfg

все давно придумано :) Hyperthreading - одновременое выполнение двух, а то четырех инструкций на одном аппаратном проце, если онные инструкции используют разные функциональные модули процессора.

HT - это вроде бы просто маркетинговое название некой аппаратной реализации проца, когда догадались сделать побольше «фронтендов», выглядящих как отдельный проц, имеющих свой набор РЕГИСТРОВ и свой конвейер. Фронтенд декодировал инструкции, предсказывал переходы, планировал к исполнению на реальных исполнительных внутренних блоках ядра проца, разделяемых между несколькими фронтендами. Идея была нужна, потому что был длинный конвеер (31 шаг) в pentium 4 и когда проц ошибался в предсказании переходов, этот конвейер приходилось чистить и всё выкидывать и проц простаивал. Тогда прикрутили второй такой же конвейер - вероятность что будут ошибаться сразу два ниже, поэтому ядро проца удавалось загрузить сильнее. Но если НЕ ошибались оба, то была жопа. Но производительность одного ядра такой хрени проигрывала иногда даже Pentium-3 и AMD Athlon XP. Чтобы оно не проигрывало, надо было ещё наращивать частоту Pentium 4 (длинный конвейер был плох на низких частотах). А если растить частоту, оно начинало так греться как треш и угар. В итоге выкинули, пойдя по пути увеличения числа нормальных, но более медленных ядер - фича оказалась более профитной, чем HT.

lesopilorama
()
Последнее исправление: lesopilorama (всего исправлений: 2)
Ответ на: комментарий от ya-betmen

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

Ну линий PCI express может быть много заведено в видеокарту, можно достаточн обыстро в неё залить 128 гигов какого-то мяса. А дальше оно там лежит и новое лить долго не нужно. Кому нужно ещё жощще, у тех есть отдельные решения, про которые никто никогда не слышал из-за цены, редкости и специфичности. К ним туда даже оптический сигнал в ядро прямо заводят иногда.

lesopilorama
()
Последнее исправление: lesopilorama (всего исправлений: 1)

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

buddhist ★★★★★
()
Ответ на: комментарий от lesopilorama

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

cobold ★★★★★
()

как по мне на вики сея проблема описана очень хорошо — прям так как и есть.

safocl ★★
()
Ответ на: комментарий от madcore

Разумно, в общем случае наверное никак, там же получается вся память в дырах, что код, что данные. И работать с этим неудобно, плюс, нужно будет городить менеджер памяти, чтобы как-то загружать код.

GAMer ★★★★★
()

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

А если бы код и данные были на разных шинах, можно было бы инструкции доступа к памяти исполнять за один такт.

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

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

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 4)
Ответ на: комментарий от cobold

Причина появления ht не в ошибках предсказания ветвления, а в более широком желании более полно утилизировать имеющиеся в ядре исполнительные механизмы.

В ошибках причина. А точнее, в ошибках на ДЛИННОМ конвейере, который был а P4. Именно в ошибках причина - когда была ошибка, конвейер чистили, а он был слишком длинный чтобы его чистить невозбранно. Хотелось чистить возбранно - так появился HT.

lesopilorama
()
Ответ на: комментарий от ya-betmen

Так у тебя всё равно выходят 2 копии данных, одна полезна одна бесполезная.

Одна долговременная, вторая кратковременная. А сколько копий всем вообще похрен, чем больше тем лучше - бекапчики все любят.

lesopilorama
()
Ответ на: комментарий от lesopilorama

Это не бакап, это именно бесполезная копия.

ya-betmen ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.