Комментарии 52
На реконфигурирование будет уходить время. Поэтому описанный Вами подход используется в схемах с однородными вычислениями.
Этот подход давно используется в специализированном железе. Например, все современные сетевые железки (которые уже давно не совсем коммутаторы и уже не очень маршрутизаторы) именно такой подход используют — маломощный процессор анализирует задачу по условию, программирует специализированную ПЛИС, которая потом уже эту задачу решает со скоростью среды.
Проблема расширения задачи на общие вычисления состоит в том, что вам придётся иметь конфигурацию для ВСЕХ возможных алгоритмов. Если же вы будете решать только ограниченный класс алгоритмов, то чем это отличается от классического CISC подхода, где есть всякие синусы и команды вида «осуществить перепаковку из двоично-десятичного в число», «выгрузить переменные в стек и войти в код фунции»?
Если же вы хотите предложить «каким-то волшебным образом» научить компьютер из императивного кода делать функциональный (то, что вы предлагаете — это и есть реализация функционального программирования аппаратными средствами), то вам следует сначала решить эту задачу, и только потом думать про её аппаратную реализацию. За решение этой задачи в общем виде вам и спасибо скажут, и денег дадут чуть больше, чем очень много.
Проблема расширения задачи на общие вычисления состоит в том, что вам придётся иметь конфигурацию для ВСЕХ возможных алгоритмов. Если же вы будете решать только ограниченный класс алгоритмов, то чем это отличается от классического CISC подхода, где есть всякие синусы и команды вида «осуществить перепаковку из двоично-десятичного в число», «выгрузить переменные в стек и войти в код фунции»?
Если же вы хотите предложить «каким-то волшебным образом» научить компьютер из императивного кода делать функциональный (то, что вы предлагаете — это и есть реализация функционального программирования аппаратными средствами), то вам следует сначала решить эту задачу, и только потом думать про её аппаратную реализацию. За решение этой задачи в общем виде вам и спасибо скажут, и денег дадут чуть больше, чем очень много.
Именно так!
Наверное вы только что убили у топиккастера мечту, описав основные проблемы и пометив их как 'практически не имеют решения'.
А вдруг, он, не зная про это, занялся ее решением и решил бы ее :)
по факту, да, наверное основная задача, разработать компилятор, который бы переводил какой либо привычный/удобный (императивный) язык программирования в функциональный… или придумать новый язык, или выделить подмножество…
А вдруг, он, не зная про это, занялся ее решением и решил бы ее :)
по факту, да, наверное основная задача, разработать компилятор, который бы переводил какой либо привычный/удобный (императивный) язык программирования в функциональный… или придумать новый язык, или выделить подмножество…
В поддержку
" — Голубчики, — сказал Фёдор Симеонович озабоченно, разобравшись в почерках. — Это же проблема Бен Бецалеля. Калиостро же доказал, что она не имеет решения.
— Мы сами знаем, что она не имеет решения, — сказал Хунта, немедленно ощетиниваясь. — Мы хотим знать, как её решать.
— Как-то странно ты рассуждаешь, Кристо… Как же искать решение, когда его нет? Бессмыслица какая-то…
— Извини, Теодор, но это ты очень странно рассуждаешь. Бессмыслица — искать решение, если оно и так есть. Речь идёт о том, как поступать с задачей, которая решения не имеет. Это глубоко принципиальный вопрос…"
Аркадий и Борис Стругацкие. Понедельник начинается в субботу
" — Голубчики, — сказал Фёдор Симеонович озабоченно, разобравшись в почерках. — Это же проблема Бен Бецалеля. Калиостро же доказал, что она не имеет решения.
— Мы сами знаем, что она не имеет решения, — сказал Хунта, немедленно ощетиниваясь. — Мы хотим знать, как её решать.
— Как-то странно ты рассуждаешь, Кристо… Как же искать решение, когда его нет? Бессмыслица какая-то…
— Извини, Теодор, но это ты очень странно рассуждаешь. Бессмыслица — искать решение, если оно и так есть. Речь идёт о том, как поступать с задачей, которая решения не имеет. Это глубоко принципиальный вопрос…"
Аркадий и Борис Стругацкие. Понедельник начинается в субботу
НЛО прилетело и опубликовало эту надпись здесь
>> За решение… задачи в общем виде вам и спасибо скажут, и денег дадут чуть больше, чем очень много.
Не хочу полностью разрушать Вашу наивную веру (иначе зачем жить?), но, жизнь немного другая штука, чем вы привыкли по Голливудским кинам.
Не хочу полностью разрушать Вашу наивную веру (иначе зачем жить?), но, жизнь немного другая штука, чем вы привыкли по Голливудским кинам.
Посмотрите en.wikipedia.org/wiki/Reconfigurable_computing
Так же добавьте к своей концепции идею clockless CPU, чтобы избавится от завязки на единый генератор тактовых импульсов. :)
Если придумаете, как в реальной схеме реализовать такой интерконнект между элементами, который реконфигурировался бы на лету с огромной скоростью, придумаете, как сделать описание конфигураций компактным и как написать ко всему этому компиляторы — может быть из этого что-то интересное получится.
Так же добавьте к своей концепции идею clockless CPU, чтобы избавится от завязки на единый генератор тактовых импульсов. :)
Если придумаете, как в реальной схеме реализовать такой интерконнект между элементами, который реконфигурировался бы на лету с огромной скоростью, придумаете, как сделать описание конфигураций компактным и как написать ко всему этому компиляторы — может быть из этого что-то интересное получится.
Вспомнилcя этот боян, но сейчас за него меня еще больше заминусуют: www.youtube.com/watch?v=khYWkgbuv9s
Также был вот такой спектрум-совместимый компьютер с Альтерой вместо процессора: www.nedopc.org/nedopc/sprinter/ Разработчики в свое время пиарили его за гибкость конфигурации.
Также был вот такой спектрум-совместимый компьютер с Альтерой вместо процессора: www.nedopc.org/nedopc/sprinter/ Разработчики в свое время пиарили его за гибкость конфигурации.
В принципе даже можно было бы добиться совместимости с любыми процессорами. Нужен был бы настоящий аппаратный JITTER — Just-In-Time-Compiler, который бы компилировал на лету код функций в связанные логические схемы. Тогда бы любая функция выполнялась бы за 1 такт. Проблема видится в реализации условных переходов (читай циклов и вызовов функций) и работе с памятью.
Во-первых уложить что-то в один такт не всегда возможно.
Во-вторых OoOE прекрасно умеют резать задачи на микро-инструкции и максимально параллелить.
Опять же боттл-неки в память никуда не деть. То-есть подход-то конечно перспективный, но подводных камней огромная и неповоротливая масса. Не говоря уже о тактовых частотах достижимых на фиксированном кремнии и ПЛИС.
Во-вторых OoOE прекрасно умеют резать задачи на микро-инструкции и максимально параллелить.
Опять же боттл-неки в память никуда не деть. То-есть подход-то конечно перспективный, но подводных камней огромная и неповоротливая масса. Не говоря уже о тактовых частотах достижимых на фиксированном кремнии и ПЛИС.
И это на главной? о_О
В давние времена появилась эта идея, как противоположность архитектуры Фон Неймана — архитектура потока данных. Однако железной реализации так и не появилось.
Хочу добавить: у этой архитектуры не было общей памяти, и счётчика команд (instruction pointer). Команды назывались экторами (actor). У эктора были входы, и он исполнялся тогда, когда у него были данные (токены (token)) на всех входах, после чего входы сбрасывались и на выходе появлялся токен, который согласно конфигурации сети передавался другому эктору. В каждом такте выполнялись все эктора, у которых были данные на входах. Таким образом планировалось извлечь максимум параллелизма. Я этой тематикой уже больше 10ти лет интересуюсь, и даже совтверные решения имеются на эту тему.
Обижаете. В своё время была масса решений на таком подходе — ISA/PCI платы с десятками однотипных процессоров. Программы писались именно по такому принципу — параллельные логические блоки начинающие работу по поступлению данных. Под блоки задействовались свободные ресурсы. Всё это широко применялось в банковской сфере. Массово выпускалось, например, Texas Instruments. Есть даже несколько стандартный языков программирования для описания процессов под это дело (к сожалению забыл название). До сих пор применяется во многих местах. Всё это уже было и применялось в конце 80х.
И назвать всё это дело «РУССКИЙ ПРОЦЕССОР» — долго запрягает, но быстро едет.
«Программа установки завершена. Чтобы получить более 5fps в игре, необходимо перезагрузить компьютер. Приятной игры!»
НЛО прилетело и опубликовало эту надпись здесь
Простите за возможно излишнее упрощение, но вот как человеку, немного далекому от ПЛИС-ов и т.д. можно вот такой простой вопрос:
А в чем будет существенное отличие от обычной программы? Ведь в обычном процессоре есть набор комманд, но последовательность выполнения этих команд не заданы заранее — например, никто не «прошивал» в процессор что за AND идет JE.
Правильно ли я понимаю, что если сильно упростить, суть идеи — более легкая «перепрошивка» микросхем? Т.е. у нас есть абстрактный «чип» с набором узлов, а мы можем его превратить в контроллер прерываний или памяти или USB по своему желанию точно так же, как мы сейчас «перепрошиваем» каждый раз CPU загружая новую программу.
А в чем будет существенное отличие от обычной программы? Ведь в обычном процессоре есть набор комманд, но последовательность выполнения этих команд не заданы заранее — например, никто не «прошивал» в процессор что за AND идет JE.
Правильно ли я понимаю, что если сильно упростить, суть идеи — более легкая «перепрошивка» микросхем? Т.е. у нас есть абстрактный «чип» с набором узлов, а мы можем его превратить в контроллер прерываний или памяти или USB по своему желанию точно так же, как мы сейчас «перепрошиваем» каждый раз CPU загружая новую программу.
Нет. Идея в том, чтобы во время выполнения программы получить такую аппаратную схему, при подаче на вход которой рада логических сигналов получим ряд других сигналов на выходе.Скорость срабатывания такой схемы ограничена по сути только быстродействием компонентов и не зависит от её размера, т.е. длины кода.
Обосрать смело можно любую идею.
Но мне идея показалась интересной.
Но мне идея показалась интересной.
И на конец хит сезона — Искра226 (хрен знает какого года — примерно середина восьмидесятых) с изменяемой системой команд. Всё уже придумано и используется.
Более того, что есть по-вашему «микрокод» в современные процессорах?
Более того, что есть по-вашему «микрокод» в современные процессорах?
По-нашему — микрокод это микропрограмма управляющего устройства процессора, которая получает на вход команду и данные, и в зависимости от них включает и переключает нужные компоненты процессора типа разных мультиплексоров, АЛУ, портов и т.п. (если по простому). Но этот набор устройств в классическом процессоре фиксированный. Изменив микрокод, ты просто изменишь систему команд, но не сами потроха процессора. Мощей у него сильно не прибавиться, но может быть программы будут чуть более компактными по определенные задачи.
А автор предлагает создавать на лету новые компоненты процессора. Например специализированные АЛУ, или специализированные длинные конвейеры под конкретную задачу. Ну к примеру, потребовалось быстрое преобразование Фурье и в процессоре образовались конвейеры с регистрами делающие это преобразование. И не при помощи выполнения подпрограммы или микропрограммы — а на абсолютно аппаратном уровне. Т.е. на регистрах обвязанных логическими вентилями. Короче на конечных автоматах.
Думаю сейчас многие и не представляют, как алгоритмы можно выполнять аппаратно, без каких либо программ и микропрограмм. А на самом деле можно. Это схемы из конечных автоматов + комбинационных схем + и регистров. Скорость на порядки выше классических процессоров. Но разработка подобных схем дело сложное, и сильно отличается от классического программирования. Это уже больше схемотехника, а не программирование. И языки VHDL и Verilog классическому программисту сразу понять тяжело, чуждо это ему.
Мне кажется, что если эту идею реализовывать по простому, то ПЛИС конфигурация должна должна подключаться в обычной программе как некий модуль. Понадобилось программе MP3 кодирование, программа запросила построить соответстующую ПЛИС конфигурацию. Появилось железо под MP3. Программа отправила в это железо данные, получило результат, и потом разрушило железо, освободив ресурсы под другую конфигурацию. Например под шифрование данных, или декодирование MPEG-4. Если размер ПЛИС большой, то можно одновременно создавать сразу несколько разных железных конфигураций, или одинаковых для распараллеливания процессов.
На такой штуке можно будет например строить универсальные железяки по необходимости. Например формировать GSM приемопередетчик, CDMA приемопередетчик, WiFi, WiMax, Bluetooth, приемних TV сигнала и т.п.
Сам когда то мечтал о такой штуке :-) Но реальной области применения пока не нашел.
А автор предлагает создавать на лету новые компоненты процессора. Например специализированные АЛУ, или специализированные длинные конвейеры под конкретную задачу. Ну к примеру, потребовалось быстрое преобразование Фурье и в процессоре образовались конвейеры с регистрами делающие это преобразование. И не при помощи выполнения подпрограммы или микропрограммы — а на абсолютно аппаратном уровне. Т.е. на регистрах обвязанных логическими вентилями. Короче на конечных автоматах.
Думаю сейчас многие и не представляют, как алгоритмы можно выполнять аппаратно, без каких либо программ и микропрограмм. А на самом деле можно. Это схемы из конечных автоматов + комбинационных схем + и регистров. Скорость на порядки выше классических процессоров. Но разработка подобных схем дело сложное, и сильно отличается от классического программирования. Это уже больше схемотехника, а не программирование. И языки VHDL и Verilog классическому программисту сразу понять тяжело, чуждо это ему.
Мне кажется, что если эту идею реализовывать по простому, то ПЛИС конфигурация должна должна подключаться в обычной программе как некий модуль. Понадобилось программе MP3 кодирование, программа запросила построить соответстующую ПЛИС конфигурацию. Появилось железо под MP3. Программа отправила в это железо данные, получило результат, и потом разрушило железо, освободив ресурсы под другую конфигурацию. Например под шифрование данных, или декодирование MPEG-4. Если размер ПЛИС большой, то можно одновременно создавать сразу несколько разных железных конфигураций, или одинаковых для распараллеливания процессов.
На такой штуке можно будет например строить универсальные железяки по необходимости. Например формировать GSM приемопередетчик, CDMA приемопередетчик, WiFi, WiMax, Bluetooth, приемних TV сигнала и т.п.
Сам когда то мечтал о такой штуке :-) Но реальной области применения пока не нашел.
автору: для Вашего железа нужна будет соответствующая дружественная логика программирования.
Посмотрите на en.wikipedia.org/wiki/Graph_rewriting
и на реальную имплементацию вполне шустрого языка на этом принципе:
wiki.clean.cs.ru.nl/Functional_Programming_and_Parallel_Graph_Rewriting
wiki.clean.cs.ru.nl/Clean
Не сдавайтесь, может быть именно Вы поставите на уши этот мир :)
Посмотрите на en.wikipedia.org/wiki/Graph_rewriting
и на реальную имплементацию вполне шустрого языка на этом принципе:
wiki.clean.cs.ru.nl/Functional_Programming_and_Parallel_Graph_Rewriting
wiki.clean.cs.ru.nl/Clean
Не сдавайтесь, может быть именно Вы поставите на уши этот мир :)
Ну хорошо, предположим у вас уже есть стопицот готовых конфигураций. Они должны где-то храниться, как-то искаться и каким-то образом загружаться. А потом — все заново, потому что задача изменилась.
Храниться они могут на диске и подружаться по необходимости. Частая реконфигурация ПЛИС конечно занимает время. Лучше потерять время на реконфигурации, но зато выполнять тажелые задачки на пару порядков быстрее. При правильном планировании использования ресурсов — экономия может быть огромной. Да, переключаться от одного тяжелого процесса на другую 100 раз в секунду не получиться. Но обычно и не надо.
Видимо, это для решение для длинных задач. Например, смотрим мы видео в h264. В процессор (точнее, в его ПЛИС-сопроцессор) загружается схема кодека и теперь он может быстро рендерить видео. Переключились на слушание мызыки — загрузился mp3 кодек.
Идея хорошая. На больших ПЛИС никто не мешает сделать x86 процессор и в том же камне пару реконфигурируемых. Может, проще будет реализовать как PCI-плату с ПЛИСиной. В общем, StarterKit с крупной ПЛИС желаю вам заполучить и экспериментировать ;-)
уже придумали, лет 8 назад
system-on-chip
Design time is reduced since the SoC portion of the design is complete and the designer only has to focus on the portion of logic that would otherwise be in an FPGA.
system-on-chip
Design time is reduced since the SoC portion of the design is complete and the designer only has to focus on the portion of logic that would otherwise be in an FPGA.
Кстати, аппаратная реализация такого рода устройств существует. Например, www.nallatech.com/
И вообще, есть такая вещь, как C to verilog.
И вообще, есть такая вещь, как C to verilog.
Мне кажется такая идея рано или поздно посещает каждого, кто с ПЛИСами.
Когда 5 лет назад делал диплом с близкой тематикой — тоже самое в голову приходило.
Когда 5 лет назад делал диплом с близкой тематикой — тоже самое в голову приходило.
Очень печально, что автор, не разобравшись в вопросе, тут-же бросился писать на хабр. Интереснее было бы посмотреть не на идею, а на идею с анализом.
Какой выигрыш можно было бы получить на специфических задачах, какой проигрыш на прикладных, а главное, каких инструкций автору не хватает в уже существующих наборах MMX, SSE 1, 2, 3, 4.1, 4.a, 4.2, 5, 3DNow!, 3DNow+(и это только на x86)?.. Какой выигрыш эти интрукции дадут по сравнению с хорошо распаралеленным кодом выполняемым на массиве Fermi карточек?
Какова, пориблезительно, стоимость проекта? С разработкой железа, реализацей поддержки ОС, доработкой или написанием компиляторов, адаптацией языков. Сколько времени на это потребуется?
А так что, давайте. Вчера — твердый кремний, сегодня — жидкое ядро, завтра — облачные вычисления. Хм это уже без нас придумали, да? Ну ничего, идей еще великое множество!
Какой выигрыш можно было бы получить на специфических задачах, какой проигрыш на прикладных, а главное, каких инструкций автору не хватает в уже существующих наборах MMX, SSE 1, 2, 3, 4.1, 4.a, 4.2, 5, 3DNow!, 3DNow+(и это только на x86)?.. Какой выигрыш эти интрукции дадут по сравнению с хорошо распаралеленным кодом выполняемым на массиве Fermi карточек?
Какова, пориблезительно, стоимость проекта? С разработкой железа, реализацей поддержки ОС, доработкой или написанием компиляторов, адаптацией языков. Сколько времени на это потребуется?
А так что, давайте. Вчера — твердый кремний, сегодня — жидкое ядро, завтра — облачные вычисления. Хм это уже без нас придумали, да? Ну ничего, идей еще великое множество!
Как-то давно издевался над индусом, предлагая ему писать курсовик на тему regex processor on chip.
На вскидку, для реализации видна такая ниша: плата-расширение и интерфейс для работы с ней, по аналогии с технологией CUDA. Соответственно, плата может использоваться для решения задач со сложными и достаточно однородными вычислениями. Однородными, но всё таки меняющимися в процессе выполнения.
В любом случае идею в первую очередь требуется развить чисто теоретически.
В любом случае идею в первую очередь требуется развить чисто теоретически.
Интересно!
Для демо реализации предложил бы LabView FPGA и достаточно дешёвую SDK на Spartan 3E для всё той же LabView. И алгоритмы опробовать сможете и прогается всё это дело достаточно быстро.
Для демо реализации предложил бы LabView FPGA и достаточно дешёвую SDK на Spartan 3E для всё той же LabView. И алгоритмы опробовать сможете и прогается всё это дело достаточно быстро.
Ваша логика будет работать только для ограниченого класа задач. Реконфигурирование связей это достаточно долго даже для реконфигурируемых матрич на базе оперативной памяти.
А во вторых что более важно, вот вы говорите синус за такт, но только не понимаете что такт может будет разной длины. Сейчас при проэктировании больших схем на ПЛИС львиная доля времени разработки идёт на синхронизацию частей между собой, поскольку технологические нормы таковы что время расспространения сигнала имеет очень большое значение и у ПЛИС приходится очень много элементов вводить для этой синхронизации, как вы динамически будете отлаживать рассинхронизацию?
А во вторых что более важно, вот вы говорите синус за такт, но только не понимаете что такт может будет разной длины. Сейчас при проэктировании больших схем на ПЛИС львиная доля времени разработки идёт на синхронизацию частей между собой, поскольку технологические нормы таковы что время расспространения сигнала имеет очень большое значение и у ПЛИС приходится очень много элементов вводить для этой синхронизации, как вы динамически будете отлаживать рассинхронизацию?
Очень интересная статья, исследования бы по этой теме!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Идея – «Жидкое ядро», меняем подход к вычислениям