Комментарии 20
читаю начало
Рано или поздно и Вы зададитесь вопросом, каким будет будущее процессоров.
скипаю в конец
Рис. 2. Блок-схема алгоритма управления гильотиной
хмммммммм, ОК!
Что есть в данном контексте "автоматная функция" и чем она отличается от "автоматной программы" ? И как это все взаимодействует с предикатами? Из статьи не понятно.
Про принстонскую и гарвардскую архитектуру явно написана выдержка откуда-то человеком, который что-то где-то прочитал, но не имеет ни малейшего представления о том как оно работает на практике. Наиболее распространенные процесоры сегодня - x64, ARM, etc. выставляют интерфейс по фон Нейману "наружу", на уровень ассемблера - так удобнее работать операционной системе, у которой программы могут быть получены из разных источников. Но при этом на низком уровне разделяют кеши инструкций и данных, то есть на микроуровне имеют гарвардскую архитектуру. Поэтому перечисленные в статье "недостатки" не имеют вообще ничего общего с реальностью, а приписываются какому-то искуственно ограниченному сферическому коню в вакууме.
Ваша "автоматная архитектура" - это крайне малое подмножество того что умеет любой процессор в одну-две инструкции. Это просто передача управления по значению из таблицы переходов. Так работают switch-case конструкции и вектора прерываний. Но городить из этого полноценный автомат мало кому нужно просто потому что он крайне редко является удобной формализацией. И уж тем более, нет никакого смысла делать процессоры, которые умеют только в очень ограниченное подмножество инструкций.
Про остальную часть статьи по существу мне вообще сказать нечего, какой-то лютый бред.
Мне эта статья напомнила, причем очень сильно, курсовой сына в Бауманке про создание МП из конечных автоматов. На базе 556РТ5. В 2017. Про САПР типа Vivado и разговора не было, даже Maxplus не использовался, все ручками и головой, в Ворде и Visio.
Вот, мы что то подобное на первом курсе делали, курсовой был по эмуляторам архитектур процессоров. Интересно было потом под свой же эмулятор код на ассемблере писать, а потом дебагать...
это ж какой-то суперриск получается в итоге? вернее даже просто современный гибридный СISC
Автор — вперед, докажи, что «в два раза быстрее».
Хотя и не нужно ничего доказывать. Всем понятно что одну узкую задачу можно решить на ассемблере и в сотню раз быстрее чем это позволит условный линукс. Но что с того?
В моей картине мире так: как сделать процессор — сказано в «машине Тьюринга». Всё остальное несущественно и мелочи. Далее звезды науки собрались и несколько лет пилили спецификацию Multics. В начале 70х годов на основе этого получился Unix и с тех пор за 50 лет ничего интересного не произошло кроме неграфических вычислений на GPU.
Можно что-то сделать «лучше»? И что значит лучше? Быстрее, но ни с чем не совместимо это лучше?
«Лучше» это то что должно сломать спецификацию Posix как жутко устаревшее.
Я не совсем понял. У нас есть лимит на число проводочков из процессора к памяти. Их объединяют в каналы доступа к памяти. Да, это узкое место.
А теперь, вопрос: что эффективнее - 5-канальный фон-нейман или "конечные автоматы" с 5 независимыми каналами? Очевидно, что 5-канальная память общего назначения будет быстрее, потому что если у нас tight loop, фигачащий по данным, то все 5 каналов достанутся данным. А если у нас рыхлый мономорфизированный код, то один канал будет непрерывно новые инструкции всасывать.
А в вашем варианте с жёсткими каналами большая часть мощностей будет простаивать. Очевидно, что для производительности общая очередь эффективнее набора индивидуальных очередей (хотя для latency важно обратное).
Дж. Бэкус утверждает (см. ссылку в статье): "Основой всякого языка программирования является модель вычислительной системы, которой управляют программы на этом языке". С этим можно согласиться, но в моей "картине мира" это выглядит несколько иначе (она отражена в статье на Хабре (https://habr.com/ru/post/481998/ и других моих статьях): основой языка является алгоритмическая модель (АМ). При этом, для эффективной реализации программ, между моделью вычислительной системы (ВС), как равно ее архитектурой, и АМ должно быть соответствие, которое бы этому способствовало. Современным языкам соответствует модель Поста (МП). На ее реализацию и заточены модели/архитектуры современных процессоров. Модель Тьюринга (МТ) - это иное и она не реализуется современными языками/процессорами. Это первое.
Мою картину и картину мира Бэкуса объединяет только одно слово - "управляют" (см. цитату выше). У меня речь идет о модели управления, характерной для той или иной алгоритмической модели и языку программирования. У МП и МТ они разные. У Тьюринга она автоматная. Это второе и, может быть, наиболее важное.
И третье. Если оптимизировать архитектуру под автоматную модель (равно машину Тьюринга), то скорость ее реализации [резко] повысится (пока речь об этом - скорости). Но будет ли эта скорость выше, чем в случае МП? Будет. Просто потому, что МТ имеет гораздо больше возможностей для распараллеливания кода и создания дополнительных каналов. Где, в чем, за счет чего и как это реализовать и т.п. и повествует статья. При этом, замечу, сравнения самих языков программирования МП и МТ мы пока оставляем в стороне (этому посвящены мои предыдущие статьи). Главное, что "по науке" они абсолютно равнозначны и равносильны. Это к слову об общности, универсальности и ограниченности.
"Мелочи" же типа, что собой представляют "автоматные функции" и т.п., что понимается под "моделью управления" и т.д., что такое параллелизм достаточно подробно, как мне кажется, объяснены в моих же статьях, которые размещены здесь же на Хабре.
Вот такой мой обобщенный ответ на сделанные выше замечания.
Прокомментирую раздельно по технической части и по психиатрической.
По технической:
Современным языкам соответствует модель Поста
Современные языки используют разные модели. От (в первом приближении) машины с произвольным доступом к памяти в С до исчисления конструкций во всяких там Идрисах. При этом они все вычислительно эквиваленты как машине Тьюринга, так и машине Поста, но значительно выигрывают у них в лаконичности. Ведь модель Поста - это всего лишь про то как очень примитивный язык из нескольких инструкций умеет менять содержимое ячеек ленты.
Модель Тьюринга (МТ) - это иное и она не реализуется современными языками/процессорами.
Машина Тьюринга - это в первую очередь про фундаментальную вычислимость. Машинный код для любого процессора является полным по Тьюрингу. Иными словами, "МТ" реализуется любыми "современными языками/процессорами".
То как вы в одну кучу валите языки программирования и процессоры - это вообще отдельная тема. Не делайте так.
Если оптимизировать архитектуру под автоматную модель (равно машину Тьюринга), то скорость ее реализации [резко] повысится
Почему? Докажите.
МТ имеет гораздо больше возможностей для распараллеливания кода и создания дополнительных каналов.
"МТ" - это автомат и лента. Никакого распараллеливания там и близко быть не может, за один такт происходит один переход в автомате, одна запись на ленту, и одно движение ленты. Можно, впрочем, придумать извращения в виде машин с несколькими лентами, или нескольких автоматов, ездящих по одной ленте, но это и для машины Поста работает точно так же. Если же вы используете какие-то определения, отличные от общепринятых, потрудитесь их явно выписать.
Ну и вам про FPGA выше правильно сказали. Лучше написать статью про "зацените какую штуку я на верилоге запилил, какие задачи она решает, и как под нее можно кодить", чем эти ваши стены бессвязного текста.
Теперь по психиатрической части.
Дж. Бэкус утверждает ...
Ссылка на выдернутое из контекста выказывание "авторитета", не имеющее никакой научной ценности.
С этим можно согласиться, но в моей "картине мира" это выглядит несколько иначе
Незамедлительная попытка приравнять себя к оному авторитету.
(АМ), (ВС), (МП), (МТ)
Введение кучи бесполезных аббревиатур без их четких определений, по-видимому для придания тексту ощущения научности и значимости.
Современным языкам соответствует модель Поста (МП).
Ложные, не имеющие связи с действительностью, высказывания преподносятся как факты.
"Мелочи" же типа, что собой представляют "автоматные функции" и т.п., что понимается под "моделью управления" и т.д., что такое параллелизм достаточно подробно, как мне кажется, объяснены в моих же статьях, которые размещены здесь же на Хабре.
Отстутсвие определений используемых терминов, отсылки к таким же бессмысленным статьям без определений в ответ на просьбу пояснить что же все-таки имеется в виду.
Я не психиатр, и не буду вам ставить диагнозы по айпи, но рекомендую обратиться за профессиональной помощью. Проблемы психического здоровья в современном мире стоят очень остро. Если специалист вам скажет что все в пределах нормы, отлично.
Сложно отвечать на подобны агрессивные посты, но попробую...
Действительно, возможно, только ненормальная психика может разглядеть то, что не способен в принципе разглядеть чел с нормальной психикой. Я могу даже согласится, что только психика, "поврежденная" многолетним автоматным мышлением, способна увидеть параллелизм там, где его не видит человек "нормальный". Меня это поражает, но исправить что-то я не берусь. Остается надеяться, что есть или найдутся когда-либо и другие "ненормальные", которые это смогут разглядеть тоже. Конкретно мои представления по МТ представлены в моей же статье на Хабре "МАШИНА ТЬЮРИНГА, КАК МОДЕЛЬ АВТОМАТНЫХ ПРОГРАММ". В ней же есть ссылки [12, 13], в которых говорится и о параллелизме абстрактных машин (как его смог рассмотреть "нормальный псих"). Так что могу порекомендовать только одно - будьте внимательны, обращайте внимание на ссылки и вопреки "нормальной лени"... читайте, читайте и читайте, т.к. втиснуть все пояснения в небольшую статью и, тем более, в рамки краткого ответа вряд ли возможно.
Так вы в итоге и не ответили. Вы снова даете ссылки на тексты без определений и импликации что вы тут один умный, а остальным до вашего уровня читать, читать, и читать.
Вот смотрите, я вам могу дать определение автомата:
Конечный автомат с входным алфавитом I и выходным алфавитом O - это конечное множество состояний S, и множество функций перехода T = {f: S×I →S×O}.
Здесь нет ссылок на километровые простыни текста, нет аппеляций к вашей безграмотности и рекомендаций читать книжки чтобы когда-нибудь это понять. Есть только строгое определение, состоящее из одного предложения. Теперь, когда я говорю об автоматах, вы абсолютно точно знаете что я имею ввиду.
Ваша очередь. Что такое автоматная программа?
Ваша очередь. Что такое автоматная программа?
Ну, Вы явно не любите читать :)
Цитирую "автоматная программа - это программа, имеющая управление в форме модели конечного автомата. " Это цитата из рекомендуемой выше статьи. Но это не та модель, о которой Вы говорите. Хотя ни что мешает взять и ее (она называется, уточню, абстрактный конечный автомат), но в программировании от нее будут одни мучения. Определение модели автомата, которая удобна, дано в статье "Автоматная модель управления программ".
Конечный автомат с входным алфавитом I и выходным алфавитом O - это конечное множество состояний S, и множество функций перехода T = {f: S×I →S×O}.
Поскольку я сейчас тоже мало читаю, то Вам удалось меня ввести в заблуждение :) Ваше определение также дает определение, как изображение, рисунок и т.п. определяет сам объект - человека, пейзаж, натюрморт и т.д. и т.п. Т.е. попросту никак. Что может сказать о человеке его изображение. Очень мало. Так и здесь. На самом деле определение автомата сложно втиснуть в одну строк. Надо было бы так:
Автомат - это шестерка A = (S, I, O, q, w, s1), где S-множество состояний, I-входной алфавит, O-выходной алфавит, q - функция переходов, w - функция выходов, s1 - начальное состояние. q: S×I →S: w:S×I →O. И, самое главное, это закон функционирования. Классический его вариант (см. Баранов С.А. Синтез микропрограммных автоматов. 1979) :
s(t+1) = q(s(t), i(t)); o(t) = w(s(t), i(t), t = 0, 1, 2, ...,
Вот как-то так.
Но в моем варианте, что весьма существенно, должно быть так:
s(t+1) = q(s(t), i(t)); o(t+1) = w(s(t), i(t), t = 0, 1, 2, ...,
Казалось бы, мелочь (вместо о(t) - o(t+1)) , но картина меняется качественно.
А так очень похоже (f: S×I →S×O - это практически один в один таблица переходов, которую я использую при реализации, что меня и сбило), но совсем не определение автомата. "Как говорят у нас в Одессе - это две большие разницы" :)
О, секта свидетелей Шалыто.
О моем отношении к секте Шалыто см. ту же статью "МАШИНА ТЬЮРИНГА, КАК МОДЕЛЬ АВТОМАТНЫХ ПРОГРАММ"
Посмотрите статью - Какой должна быть будущая технология параллельного программирования
И с 2007 г. мало что изменилось (добавилась поддержка корутин в С++). Но я использовал и использую технологию автоматного программирования. Создаю системы реального времени под Windows и Linux. Дискретный такт (тик) < 0.5 мсек. На потоках, насколько я в курсе, такое не достижимо (для взаимодействующих процессов, конечно). И это при том, что автоматы интерпретируются (С++). Если вместо интерпретации сделать аппаратную поддержку, то ускорение будет один-два порядка (это типовая оценка при переходе на аппаратную поддержку). Таким образом, автоматная архитектура по любому будет эффективнее многопоточгой/многоядерной. Это к слову об оценке и доказательствах простого быстродействия. А уж с точки зрения программирования преимущества - небо и земля (и конечно не в стиле Шалыто)..
Вот, как просто! Балакиревская (автоматная) архитектура процессоров