Comments 23
Продолжайте, любопытно.
Картинки в чем рисовали?
Картинки в чем рисовали?
Обязательно продолжайте.
1)Не совсем понимаю — почему все ограничивается на однозадачности?
2) А еще интересная мысль — объединить их. То есть один процессор — фон Неймановский, второй такой. Фон Неймановский для реализации многозадачности, управлением чего-н-дь… возможно операционная система на нем. А второй трудоголик используется первым для вычислений.
2) А еще интересная мысль — объединить их. То есть один процессор — фон Неймановский, второй такой. Фон Неймановский для реализации многозадачности, управлением чего-н-дь… возможно операционная система на нем. А второй трудоголик используется первым для вычислений.
1) Однозадачность — результат невозможности установления соответствия между пакетами и задачами, то есть нельзя определить, какой пакет к какой задаче относится. Для этого придумали тегирование пакетов, т.е. многозадачность все-таки возможна.
2) А вот это, по идее, будет трудно, если вообще возможно: модель памяти у таких процессоров — ассоциативная, а у обычных — линейная.
2) А вот это, по идее, будет трудно, если вообще возможно: модель памяти у таких процессоров — ассоциативная, а у обычных — линейная.
1) Ну как мне кажется( а я тут ничего не смыслю:)) тут есть два выхода:
а) пакет может состоять из
ID задачи | ID пакета |флаг готовности | код операции и используемые пакеты в кач-ве операндовZ
б) собственно а зачем устанавливать соответствия?
Ну работает параллельно куча задач. И что? ID пакетов у каждой задачи свои… выдаются автоматом при запуске программы. ну типа как адресные ссылки на операнды в памяти сейчас.
2) ну так в этом то и весь смысл. Вот например я работаю с программой Математика. Тут эта пакетность ой как выгодна бы была. И как бы было мне здорово, если бы операционка — работала как обычно, а конкретно Математика работала бы с таким процессором.
Ну грубо говоря — все как обычно, но в момент запуска моего алгоритма на исполнение программа бы не компилила это в обычный асм код, а компилила бы ее в множ-во пакетов и скармливала бы второму процессору. Как-то так…
а) пакет может состоять из
ID задачи | ID пакета |флаг готовности | код операции и используемые пакеты в кач-ве операндовZ
б) собственно а зачем устанавливать соответствия?
Ну работает параллельно куча задач. И что? ID пакетов у каждой задачи свои… выдаются автоматом при запуске программы. ну типа как адресные ссылки на операнды в памяти сейчас.
2) ну так в этом то и весь смысл. Вот например я работаю с программой Математика. Тут эта пакетность ой как выгодна бы была. И как бы было мне здорово, если бы операционка — работала как обычно, а конкретно Математика работала бы с таким процессором.
Ну грубо говоря — все как обычно, но в момент запуска моего алгоритма на исполнение программа бы не компилила это в обычный асм код, а компилила бы ее в множ-во пакетов и скармливала бы второму процессору. Как-то так…
1) Пакет там такой в реале:
Код_операции | Адр._приемника_рез.1 | Адр._приемника_рез.2 | Операнд1 | готовность1 | Операнд2 | Готовность2
>>>выдаются автоматом при запуске программы. ну типа как адресные ссылки на операнды в памяти сейчас.
Логично, но по какой-то причине этого нету.
2) В принципе возможно, но, опять же, реализаций нет. о_0
Код_операции | Адр._приемника_рез.1 | Адр._приемника_рез.2 | Операнд1 | готовность1 | Операнд2 | Готовность2
>>>выдаются автоматом при запуске программы. ну типа как адресные ссылки на операнды в памяти сейчас.
Логично, но по какой-то причине этого нету.
2) В принципе возможно, но, опять же, реализаций нет. о_0
Мне оно напомнило построения по цифровой микросхемотехнике. Отличная штука для определенных задач: можно к примеру сделать быструю эмуляцию какой-либо сложной цифровой схемы.
Самое интересное — про реализацию-то и пропустили.
Видимо их все еще нет по тому, что не смотря на то, что у них «высокая эффективность вычислений» в одном блоке, дешевле и проще напихать десяток не таких эффективных блоков современных процессоров и получить ту же производительность.
Физическая реализация очень много значит
Видимо их все еще нет по тому, что не смотря на то, что у них «высокая эффективность вычислений» в одном блоке, дешевле и проще напихать десяток не таких эффективных блоков современных процессоров и получить ту же производительность.
Физическая реализация очень много значит
Про реализацию я планирую рассказать в следующем посте, как раз на примере того японского процессора.
>>>дешевле и проще напихать десяток не таких эффективных блоков современных процессоров и получить ту же производительность
Вполне возможно. А еще, может быть, из-за того, что к моменту перехода от концепции до образца, ниша была уже прочно занята, а кадры обучены на ф-Н машины.
>>>дешевле и проще напихать десяток не таких эффективных блоков современных процессоров и получить ту же производительность
Вполне возможно. А еще, может быть, из-за того, что к моменту перехода от концепции до образца, ниша была уже прочно занята, а кадры обучены на ф-Н машины.
А я думаю, что проблема в том, что на фон Неймановской архитектуре такая архитектура эмулируется, а наоборот — нет…
На мой несколько дилетантский взгляд, процессор после парсинга комманд так и работает.
Идея состоит в том что бы поднять их уровнем выше? Чем это принципиально отличается от RISC?
Идея состоит в том что бы поднять их уровнем выше? Чем это принципиально отличается от RISC?
Напомнило функциональные языки программирования (Я с Haskell работал)…
Лисп-машина?
Неожиданно…
Посмотрел википедию про лисп-машины:
>>>В 1973 году Ричард Гринблэтт и Томас Найт, программисты лаборатории ИИ при Массачусетском технологическом институте, начали работу над тем, что впоследствии стало «проектом Лисп-машины MIT». Изначально это был компьютер, аппаратно приспособленный для выполнения некоторых основных операций Лиспа (вместо того чтобы обрабатывать их программно) в 24-битовой теговой архитектуре.
По срокам совпадает, по принципу тоже. Очень даже может быть.
Посмотрел википедию про лисп-машины:
>>>В 1973 году Ричард Гринблэтт и Томас Найт, программисты лаборатории ИИ при Массачусетском технологическом институте, начали работу над тем, что впоследствии стало «проектом Лисп-машины MIT». Изначально это был компьютер, аппаратно приспособленный для выполнения некоторых основных операций Лиспа (вместо того чтобы обрабатывать их программно) в 24-битовой теговой архитектуре.
По срокам совпадает, по принципу тоже. Очень даже может быть.
Я правильно понял, что такой процессор реализует редукцию графов «в железе»?
Есть ещё одна интересная архитектура, которая даже была железно реализована…
Сетунь-70 а впоследствии ДССП
Сетунь-70 а впоследствии ДССП
Да, грустно все это. Вы молодец, что сами решили копнуть эту тему. Но дальше — грустно от того, что целое поколение выросло, полностью потеряв целый пласт знаний и наработок.
В СССР это направление развивалось очень серьезно. Кстати, если Вы хотите найти больше информации на эту тему, поищите data flow graph computers, или reconfigurable computing.
Насчет применений — почитайте материалы о проекте Nvidia Tesla (технология CUDA) — www.oszone.net/5141/nvidia_tesla.
Почитайте о работах академика Бурцева.
В общем, если будет интересно — могу рассказать, где такие системы применяются, в чем их реальная сила и слабости.
В СССР это направление развивалось очень серьезно. Кстати, если Вы хотите найти больше информации на эту тему, поищите data flow graph computers, или reconfigurable computing.
Насчет применений — почитайте материалы о проекте Nvidia Tesla (технология CUDA) — www.oszone.net/5141/nvidia_tesla.
Почитайте о работах академика Бурцева.
В общем, если будет интересно — могу рассказать, где такие системы применяются, в чем их реальная сила и слабости.
Sign up to leave a comment.
Концепция управляемого данными процессора