Форт-подобная машина Владимира Кладова

← →
homm © (2007-02-17 14:05) [0]

Итак, завел отдельную ветку :)

для тех, кто все еще в танке:
http://kolmck.net/sf/architecture_contrary_to.zip

Все-же есть вопросы. Правильно ли я понимаю, что мы получаем в распоряжение ровно половину памяти от всего имеющегося объема? Остальная идет на описание правд доступа к первой половине в виде 4-х байтных дескрипторов для каждых 4-х байт в основной памяти. Но у каждого процесса должны быть свои права доступа к памяти, соответсвенно такая таблица нужна для каждого процесса? Или я чего-то не догоняю?

← →
Vladimir Kladov (2007-02-17 16:01) [1]

я так понял, что вы не поняли, что дескрипторы в теневой половине памяти - это не таблица прав доступа, а именно дескрипторы, т.е. числа. Они задают принадлежность 1, 2, 3 или 4 байт из основной памяти тому или иному множеству (остальные 3, 2, 1 или 0 недоступны вообще - так обеспечивается точность защиты до 1 байта). А в таблице прав для каждого процесса задаются для каждого из <= 2**20 дескрипторов соответствующие права, по 2 бита на дескриптор. Дескриптор можно считать неким числом, которое выделяется просто по порядку номеров, или из массива свободных дескрипторов. А вот для множества дескрипторов с 0 по N у процесса должны быть выставлены права в его таблице прав доступа. Проще, наверное, представить по аналогии в винде какой-нибудь общий ресурс типа memory mapped file. Его дескриптор - это просто число. Права на доступ от каждого процесса система хранит у себя, вместе с описанием открытого маппированного "файла". Ну или можно попробовать представить себе процедуру проверки прав доступа. Берем из теневой памяти дескриптор, из таблицы AccessT текущего процесса смотрим на 2х-битный набор флажков с соответствующим номером, получаем 2 бита прав доступа.

← →
homm © (2007-02-17 18:18) [2]

Спасибо, что разъяснили подробнее, я правда не так понял, но не кажется ли Вам что подобная система не может иметь преимуществ в скорости по сравнению с РС как раз из-за того что ей понадобится 2-х кратное количество памяти, да еще при обращении к ней нам нужно сходить к теневой памяти, посмотреть дескриптор, затем снова обратится к основной, туда где таблица прав доступа котрая в свою очередь тоже должна иметь теневую часть... Т.е. дополнительно нам нужен большой процессорный кэш, способный вместить как можно большую часть таблицы прав доступа. Того получаем в 2 раза меньше памяти, работающей в 2 раза медленее, да плюс повышеные требования к кэшу процессора (если таковой вообще предпологается). Может вы и расчитываете получить прирост производительности на камне в 10 раз, но большенство забдчь просто тупо упутся в пропускную способность памяти, которая как и процессорная частота не бесконечно, и в последнее время тоже растет не так быстро как раньше.

← →
Vladimir Kladov (2007-02-17 18:53) [3]

да преимущество не в этом. Нет, не медленнее. Кэши нужны в любом случае. Для виртуальной памяти в х86 начиная с 286 - тоже. Нешто вы считаете, что таблицы для виртуализации жрут меньше (памяти и времени)? Даже наверняка больше. Я потому и думаю, чтобы от этого дела хотя бы в простом случае отказаться. В ПЦ механизм виртуализации сохраняется одновременно еще и как средство разделения адресных пространств задач. Собственно, другого механизма разделения адресных пространств у ПЦ (да и у других современных архитекутр) и не предполагается. Я думаю это дело разделить, и просто позволить всем задачам работать в одном адресном пространстве.

Частота не то чтобы растет медленно. Она больше не будет расти скоро, если останутся на той же элементной базе (транзисторы). Дальше возникает противоречие: меньше напряжение - меньше частоты. Больше напряжение - больше тепловыделение. Разве что остается придумать компактный гелиевый охладитель. Для домашнего компа - как-то немножко страшновато.

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

Пропускная способность памяти - это и правда большая проблема. Но если бы это действительно была бы такая большая проблема, то ПЦ не стоило бы даже и пытаться разгонять до 3ГГц, еще и делать многоядерными. Принцип 80/20, знаете? 80% времени в программе работают 20% кода. Из всего массива данных подавляющее время задача работает с 20%, остальные 80% не востребованы. Если бы это было не так, мы и сейчас сидели бы на пне-100, и больше просто не было бы. В общем, приличный размер кэша, причем желательно 2 уровня - это реальный выход по решению проблемы пропускной способности памяти.

← →
Vladimir Kladov (2007-02-17 20:47) [4]

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

1. Разделив стеки (вычислительный и программный) и отделив (отвязав) их от адресумой памяти, тем самым я увеличиваю вдвое пропускную способность автоматически: теперь ядро процессора взаимодействует с этими хранилищами по раздельным шинам, одновременно. Запретив возможность изменения кода (к чему, кстати, пришла, наконец и фирма Майкрософт в своем проекте Сингуларити), я тем самым убираю необходимость отслеживания таких изменений в коде: архитектура остается Фон-Неймановской, но приобретает некоторые черты Гарвардской (раздельное хранение команд и данных - они у меня хранятся в одной памяти, но не пересекаются). В итоге ядро совершенно независимо работает по двум другим шинам с памятью данных - через кэш данных, и с памятью команд - через кэш команд. То же касается и кэша системных таблиц: работа с ним идет через отдельную, пятую шину, так же совершенно независимо и одновременно со всеми прочими кэшами.

Как известно, в Интеловской машине (и в ее АМДшном аналоге) есть только 2 кэша: кэш данных и кэш команд. И при этом процессор еще и вынужден отслеживать возможность записи в память команд. В новых моделях есть так же и отдельные кэши для верхушки стека, иначе вызовы подпрограмм становились бы совершенно неприемлемо долгими, но и здесь процессор вынужден постоянно отслеживать возможность изменения стека, адресуемого как обычная память, командами обычного доступа к памяти (что значительно снижает эффективность такого усовершенствования).

2. Не кажется ли вам, что на настоящий момент, да и вообще с самого начала Интеловская архитектура слишкам раздута по системе команд? Даже если брать только подмножество без плавающей арифметики. И не забудьте помножить все это громадье на огромное количество режимов адресации. Да в такой камень можно без проблем запихать полсотни моих процессоров, и еще место останется на L1-й уровень кэша на десяток Мбайт.

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

3. Длина команды Интел, средняя, среди исполняемого потока, колеблется в районе 5-6 байт. У меня - 2 байта в среднем, т.к. больше половины команд - однобайтовые, и подавляющее число остальных - 2 байта. Есть считанное число 3х-байтных и 5-байтных. (Вывод: в кэш команд влезет в 3 раза больше кода, прогон _того_же_количества_байтов _кода(что и в х86) через декодирование даст в 2.5-3 раза больше команд на такт).

Я уже сделал набросок декодировщика команд, и со всей ответственностью заявляю, что реально за такт прогонять через декодировщик 8хN (где N зависит только от объема логики) байтов команд, поставляя за такт те самые 8xN "инструкций" (см. неподробное описание в архиве), в реальности получается в среднем 4хN физических инструкций. Я так же сделал уже и даже частично протестировал хранилище операционных ячеек, и виртуально подтвердилось мое предположение, что реально организовать одновременный доступ к 8хN ячейкам за такт на чтение и на запись - по двум рядам независимых (внутренних) шин данных. И проверил на программной модели придуманный мной механизм распределения номеров операционных ячеек (модель показала, что за такт спокойно может быть выделено 16xN номеров с вероятностью отказа в выделении <<1% - этот знак означает "пренебрежительно меньше", а не просто "меньше"). Наброски очереди инструкций не завершены пока, и без прочих устройств протестировать их нельзя, но мое предположение таково, что и там есть возможность за такт обработать 8хN инструкций, а освободить можно вообще хоть все отработанные четверки инструкций за раз, было бы желание. Итого: 8хN "инструкций" за такт в пиковом режиме, т.е. 4 в среднем. Полагая, что пиковый режим - это 80% времени исполнения, скорость весьма близко приближается к 4*(тактовая частота).

continued...

← →
Vladimir Kladov (2007-02-17 20:48) [5]

continue

4. Интеловские инженеры утверждают, что несмотря на все их исхищрения, из-за проблемы зависимости по данным, средняя скорость работы их процессора составляет 1.2 инструкции за такт. Я полагаю, что проблема здесь - в несовершенстве регистровых архитектур. Несмотря на введение переименования регистров, эти самые регистры + регистр флажков остаются тем самым препятствием, которое ограничивает скорость работы программы. Шутка (не штука) в том, что если бы не регистры, то можно было бы смотреть чуть дальше, чем в пределах нескольких подряд вычисляемых выражений. И вот там-то как раз и происходит развязка большинства зависимостей по данным. В файле "Архитектура - перенос состояний.htm" приводится пара примеров, как это работает, поэтому не буду останавливаться. Это только на первый взгляд кажется, что техника стековых вычислений связывает процессор по рукам и ногам. Стоит применить технику переименования регистров (у меня - в виде массива операционных ячеек), и стековая машина с ее безадресным набором команд превращается в идеальный инструмент для разрешения подобных зависимостей. Кроме того, отказ от регистра флажков (фактически, хранение 2х флажков на 1 операционную ячейку) позволяет часто принимать решения о ветвлении еще до того, как выполнится вычисление анализируемого значения. В итоге, я рассчитываю (на первых порах хотя бы) вообще обойтись без каких-либо хитрых предсказателей ветвлений.

И самое интересное то, что чем больше кратность логики, и чем больше очередь инструкций, тем дальше вперед удается "смотреть", и тем больше зависимостей по данным разрешается. Т.е., на многих задачах скорость действительно будет (я надеюсь) расти линейно увеличению объема логики. Так что приведенные мной цифры 3ГГц тактовой -> 32ГГц виртуальной скорости - это, скорее всего, правда (для случая 8x3, т.е. 12 физических инструкций за такт). К сожалению, в случае FPGA N=1 - это, вероятно, предел нынешних возможностей, но и это дает где-то 3х-4х кратное превышение тактовой (т.е. ~1ГГц, что для FPGA вообще-то из разряда "не быва[е]т"). Я все-таки надеюсь сделать "внешнюю" тактовую не ниже 280-320 МГц, хотя тут тоже много ограничений возникает. (Внешняя в кавычках, потому что многие современные плиски не нуждаются в физически внешней, у них кварц и делители частот встроенные).

Дополнительный фокус с использованием префикса условного выполнения только перед инструкциями, не изменяющими высоты вычислительного стека, позволяет обойтись без малейшей приостановки конвейера-водопровода на некоторых классических задачках, для решения которых в обычной архитектуре (неважно, х86 или ARMx) приходится делать условный переход, со всемы вытекающими. Например x = max(a,b). Интел до команд типа CMOV додумался слишком поздно: их не применяет ни один нормальный компилятор С/С++ (а Паскаля подавно), кроме как по требованию программера, уверенного в том, что его прогу не будут запускать на чем-то ниже пня-4.

5. Я часто замечал, что быстродействие моих программ (для х86, разумеется) весьма сильно зависит от того, насколько часто вызывается менеджер кучи. Т.е. не то чтобы в разы, а в десятки, сотни, а иногда даже в ты-ся-чи раз. Можно попробовать использовать продвинутые менеджеры кучи, но проблему это решает лишь частично. Поэтому я считаю, что для повышения быстродействия очень важно реализовать функции выделения и освобождения небольших (да хотя бы и не совсем маленьких заодно) блоков памяти ап-па-рат-но. На то у меня в архитектуре предложена пара специальных инструкций, и я _очень_ надеюсь, что это даст существенный прирост производительности на очень большом классе задач.

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

← →
homm © (2007-02-17 20:51) [6]

> Из всего массива данных подавляющее время задача работает
> с 20%, остальные 80% не востребованы.
О! если бы это было так... :) Я вот время от времени запускаю у себя нынче модную и очень требовательную к железу игру Обливион, дак вот она у меня идет ну просто никак!!! Все потому что оперативы 256. Я видел как она идет на 512. Первые 20 минут вообще ничего не тормазит, дальше не знаю, не видел :) Получается что она требует много больше 50% памяти в малом промежутке времени, от всего требующегося ей объема, который (по крайней мере поначалу) полностью помещается в 512мб ОП. Тоже самое с архиваторами. Вы бы знали, как я страдаю от того что у MTsv DN, который делает архивы на колНмск.ру, 512 (или больше) оперативы. У меня распаковка сильно тормозит. Это я все к тому что программы может и гоняют 20% своего кода одновременно, но этот код может ворочаеть данными, требующими много большего количества памяти в малый промежуток времени.
Хотя может и вправду таблицы для виртуализации не более эффективны, НО
Вы же упомянали о том что возможно когдато появится и механизм виртуальзации в том числе, что тоже не может сказатся положительно на производительности, в частности нагрузке на память. Хотя возможно снизить потребление кэша к минимуму, сделав страницу скажем 64кб, и рассматривая теневую память как нечто неотделимое от основной (физически страница получится 128кб).
Кстати, еще один фактор вспомнил. В настоящее время почти что вся память работает в двухканальном режиме, что позволяет одновременно обращатся к теневой и основной памяти! Не такая уж и мрачная картина значит получается :)

← →
Vladimir Kladov (2007-02-17 21:07) [7]

Ну и насчет названия темы: все-таки к Форт-системе отношение весьма маленькое. Только отделение вычислительного стека от программного - это еще не Форт, а недоступность программного стека для программы кроме как по прямому назначению - это уже не форт. Не говоря уже о том, что у меня есть все-таки регистры A, B, C, D, хотя в основном предназначенные для индексации и адресации. В Форте такого в принципе нет и быть не может. Опыт (Collapse) показывает, что чисто Фортовский подход не совсем удобен для ЯВУ. Иногда очень имеет смысл загрузить Self (this) в регистр и пользоваться им на всем протяжении метода, например.

Хотя начал я все-таки (для себя) с удобств программирования/отладки и повышенной надежности. Быстродействие тоже очень важно, ибо кому нужен сверхнадежный тугодумный проц. А то, что памяти вдвое меньше получается... солить ее, что ли, память эту. 8 Гб (т.е. фактически 4Гб) - это достаточно близко к современным верхним границам. Даже на 64-разрядные пока что еще не ставят больше - просто платы не рассчитаны. Мои изыскания направлены в некоторое (хотя и не очень отдаленное) будущее. Мой прогноз таков, что через 2-4 года (если не раньше) FPGA догонят по быстродействию современные пни-4/3.2ГГц, память уменьшится по физическому размеру и увеличится по компактности примерно на порядок, а винчестеры через 3 года перестанут выпускать: перейдут на флэшки (уже сейчас 128Гиг по $1000 за штуку - реально приобрести в магазине даже у нас в глухой Сибири). Так что есть реальный шанс, что когда я завершу эту свою разработку, у меня будет куда ее запихнуть, и она придется очень даже кстати...

← →
homm © (2007-02-17 21:11) [8]

> [4] Vladimir Kladov (17.02.07 20:47)
> [5] Vladimir Kladov (17.02.07 20:48)
Когда писал [6], этого еще не видел :) Просто класс!!! Аплодисменты стоя :)

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

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

Остается только один вопрос: собственно что это? :) Я имею ввиду что должно получится в окончательном виде? Четко сформулированое описание этой платформы, опятные образцы, или все-же ожидается выпускать это в промышленных масштабах, хотя-бы как встрамые решения поначалу?

ЗЫ Не обижусь, если Вы не ответите на мой вопрос, сославшись на кммерчискую тайну.

← →
Vladimir Kladov (2007-02-17 21:12) [9]

Насет мультимедийных игр - там ситуация такова, что в видюху не влазят все текстуры, и на каждом кадре проц качает туда через AGP оченно много данных. Ессно из ОЗУ. Но ведь ему еще в ОЗУ надо и других данных кучи держать. И вовсе не факт, что он обращается при этом ко всей памяти постоянно. Все просто: пусть у вас есть таблица A[10000][65536], и вы на кадре делаете проход по всем 10000 элементам, но обращаетесь из каждых 64К байтов только к одному. В итоге, системе понадобится присутствие за кадр всех 10000 64Кбайтных страниц, хотя из них нужен только 1 байт. Возникает жуткий своп. Вот такие пироги.

← →
Vladimir Kladov (2007-02-17 21:19) [10]

Что это? Считайте - мечта. Как для мужика: посадить дерево, построить дом, вырастить сына. У меня, как современного мужика - дополнительно к первым трем - сделать свою библиотеку, свой язык, свой компилятор, свою компьютерную архитектуру, и свою операционную систему. Ну, может еще чего-нибудь :)

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

Патентовать чтобы... ну, это надо изрядно повозиться. Был бы я поближе к этим патентным агентствам, может быть. На самом деле, я рассчитываю на то, что никому не захочется из них (Интел, Майкрософт) связываться с архитектурой, которая еще только "на бумаге", и для которой нет ни наработанного ПО, ни компиляторов... Так что может, и получится "успеть" раньше их.

← →
homm © (2007-02-17 21:22) [11]

> [10] Vladimir Kladov (17.02.07 21:19)
Владимир, не заставляете будущим поколения россиян доказывать будущим поколения буржуев, что архетектура современных (для них) компьютеров придама Кладовым, а не Марконни :)))

← →
Galkov © (2007-02-17 21:28) [12]

> для тех, кто все еще в танке:
> http://kolmck.net/sf/architecture_contrary_to.zip

Извините за вмешательство в происходящее...
А нельзя ли уточнить с чего начинать чтение, и в какой последовательности.
Что ни взгляну (пока не долго, правда) - оно вроде ПРОДОЛЖЕНИЕ чего-то...

← →
homm © (2007-02-17 21:29) [13]

Наверное правильнее гачать с "Архитектура вразрез2.htm"

← →
Vladimir Kladov (2007-02-17 21:31) [14]

Вы знаете, и я знаю, что радио первым изобрел Попов. И что первый самолет (взлетавший с рельсов), и первая подводная лодка - были сделаны в России. И никакое патентное право не может этого отменить. Есть авторское право, а оно выше. А само патентное право я считаю самым ретроградским изобретением, какое только можно было изобрести для тормоза прогресса. Именно "благодаря" этому патентному праву мы до сих пор ездим на вонючих машинах с бензиновым двигателем, например, а не летаем на бесшумных летающих тарелках...

← →
homm © (2007-02-17 21:37) [15]

Ну это не повод что-бы люди, захотевшие использовать ВАШУ архитектуру начали отстегивать деньги третьим лицам. котрые оказались проворнее.

Я вот тоже не признаю например ПДД. Я пешеход! Машины у меня никогда не было, и не понимаю, как я, свободный человек, не могу ходить там где мне хочется... Тем не менее штрафуют... %)

Я к тому что нелюбить можно, а непризнавать эти бюро - чревато.

> homm © (17.02.07 21:29) [13]
> Наверное правильнее гачать с "Архитектура вразрез2.htm

А если еще раньше ???
Или только для избранных ???

> А если еще раньше ???
> Или только для избранных ???
Избраный здесь лишь один, и "раньше" только у него в голове, как я понимаю :)
Это же не книжка по физики за 6-й класс, где все разжовано..
"Таблица команд (MODE 64)" для общего представления в том документе не нужна, а дальше можеш взятся за
"Архитектура - проект FPGA (ХХХ).htm" Потом без разницы наверное, я сам нечаяно наткнулся на эти документы, незнаю почему Владимир не афишировал здесь.

← →
Vladimir Kladov (2007-02-18 08:49) [18]

Ну наверное потому что это не совсем про программирование. Я нечаянно в конце прошлого года полез узнавать про HDL, много чего узнал, и просек, что теперь можно пробовать делать железо, не хватаясь за паяльник, и не разбираясь в номенклатурах множетсва мелких микросхем. Для меня стало откровением, что железо спокойно описывается языком, весьма похожим на С или Аду, просто параллельным. В общем, мне сразу понравился Verilog, я заказал софт (синтез, моделирование), и стал вспоминать свои давние идеи. Куда раньше-то? То, что было в 94-98, я уже в точности и не вспомню. Помню, что было очень похоже, но не было индексно-адресных регистров. Это уже по следам недавних экспериментов и в результате тесной работы с объектным программированием пришло. Да и трансляторов/компиляторов в купе с эмуляторами за прошедшие годы пришлось написать немало (даже для основной работы).

Мне бы, конечно, не помешала какая-то помощь. Проблема в том, где искать единомышленников в этой области. Нужно ведь или знание, или желание познакомиться с Verilog HDL, например. Там, где люди уже что-то на нем делают, мало желающих подхватывать чужую идею, и куда-то ее тащить. Но я думаю, что и для одного эта задача все еще выполнима. Опыта только не хватает. Все-таки, тут есть вещи, написать которые можно весьма по-разному, и надо, чтобы все работало быстро, а проверить сразу не удается. Та же очередь инструкций. Без взаимодействующих устройств синтезатор после полчаса компиляции просто создает пустую схему из 0 логических элементов - если засунуть внутрь CPU. А если не засовывать, то как отдельное устройство эта очередь просто не влазит в чип - не хватает ножек (надо > 1000). Очень много независимых шин в разные стороны потому что.

← →
AndreyRus (2007-02-18 14:31) [19]

> Интел до команд типа CMOV додумался слишком поздно: их
> не применяет ни один нормальный компилятор С/С++ (а Паскаля
> подавно), кроме как по требованию программера, уверенного
> в том, что его прогу не будут запускать на чем-то ниже пня-
> 4.

Команда CMOV появилась в Pentium II, вернее даже раньше в "Pentium Pro" и компиляторы ее поддерживают, в том числе и Pascal"я ("Free Pascal").

← →
Vladimir Kladov (2007-02-18 14:38) [20]

У меня комп какой-то из 2х старых не захотел запускать. Правда, я сейчас не могу сказать точно, какой именно, пень100 или II/450.
Ну да, в асм-вставках можно хоть что закодировать и на Delphi. Имеется в виду, что компилятор сам эту команду не применяет, когда сам код из ЯВУ синтезирует.

← →
Sapersky (2007-02-19 12:30) [21]

Относительно FPGA/Verilog:

http://www.elphel.com/index_rus.html

"Исходные тексты для FPGA и программного обеспечения всех продуктов доступны согласно лицензии GNU GPL".

Хотя это совсем не CPU общего назначения, а весьма узкоспециализированная разработка, но может чем-то поможет.

Форт-подобная машина Владимира Кладова Найти похожие ветки