Плавающая ядерность Опции

[Anticitizen1]

Начал проект по разработке схемы с плавающей ядерностью то есть ядра - из стандартных блоков вычслений распадаются на ядра с более мелкими разрядами и наоборот.Это своего рода аналог VLIW процессора но с архитектурой плавающей ядерности. Ядра процессора управляемые специальными дескрипторами в специальных сегментах кода будут распадаться на множество мелких ядер (меньшая разрядность и меньшее число блоков процессора) и собираться в большие ядра с большой разрядностью и полным набором блоков работы с памятью и вычислениями. Данный процессор сможет входить в режим графических вычислений без использования видеокарт и прочего графического оборудования.Предполагается исследование возможности ускоренной обработке зависимых частей программ путем слияния отдельных блоков ядер- формирования общих переносов к примеру .

Данный проект нацелен на проблему простоя вентилей у многоядерных процессоров и процессоров с VLIW архитетурой.

Мы предполагаем использование Ultra Sparc T2 как базовый - заложенная многопоточность позволит несколько у простить задачу.Но есть проблема "резки" управляющих сигналов и меж разрядых переносов в вычислениях.В Ultra Sparc резать придется FPU.Мы бы хотели помножить блоки и потом вставить между ними управляющие ядерностью сигналы.С памятью таких проблем меньше так она в целом более симетричная.

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


Пример вычислений где такая ядерность нужна:
происходит взрыв и программа моделирует поведениен множества незавиимых/зависимых процессов.Ядра разбиваются на множество низкоразрядных.В следующий момент взрыв передается на плиту и потребуется вычисление большого среднего значения большого числа частиц воздействия на объект- ядра собираются и разрядность вырастает.Возможные иные комбинации в случае зависмых множественных процессов.

В дальнейшем хотим пустить по 65 нм процессу.Сейчас моделирование типа Cadence Virtuoso позволяет до 45 нм вообще с RTL сразу под сканер идти вроде как.

Сообщение отредактировал Anticitizen1 - Mar 24 2010, 06:42

[dvladim]

Что же мешает?Или не дает покоя желание научить мир жить.А то как же без вас?

Судя по теме как раз вам и не дает. Без обид пожалуйста, просто вся рота не в ногу, один старшина в ногу.

Но все же, попробуйте дать более менее развернутый ответ на вопрос о программировании такого процессора. Вы же прекрасно понимаете что архитектура x86 жива и да здравствует за счет богатого программного прошлого. И для успешного применения вашего процессора нужно предложить маршрут перевода программ (читай компилятор), а, насколько я знаю, gcc фокусов с изменяемой разрядностью делать не умеет. А то так и получится: железо сделаем самое крутое на свете, а применить его не получится.

А если мучает несогласованнось конвеера с современных процессорах

Итак понятно что герцы низки для энергопотребления но не только число вентилей снижает герцы , ассиметрия архитектуры снижает - схема всегда дожидается самого медленного элемента (герцы это и есть частота самомого медленного простым языком).Выч блок (ALU точно,FPU не уверен)вообще можно до 5-6 ггц разогнать

то посмотрите в сторону самосинхронных схем.

[Anticitizen1]

Судя по теме как раз вам и не дает. Без обид пожалуйста, просто вся рота не в ногу, один старшина в ногу.

Но все же, попробуйте дать более менее развернутый ответ на вопрос о программировании такого процессора. Вы же прекрасно понимаете что архитектура x86 жива и да здравствует за счет богатого программного прошлого. И для успешного применения вашего процессора нужно предложить маршрут перевода программ (читай компилятор), а, насколько я знаю, gcc фокусов с изменяемой разрядностью делать не умеет. А то так и получится: железо сделаем самое крутое на свете, а применить его не получится.

А если мучает несогласованнось конвеера с современных процессорах

то посмотрите в сторону самосинхронных схем.

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

Ну вот представьте, какие здесь проблемы возникнут.Например в много ядерных при переносе программ на них две основные проблемы - нарушение адресации в случае переходов (вызываемы в одном ядре адресс в случае направильной резки проги оказался в другом ядре) и нарушение взаимозависимых вычислений.Здесь другая проблеима - переходы в устройство с разрядностью меньшей, чем сумма текущих операций для данного устройства-соответственно это и надо будет прослеживать.Скорее всего будет либо запрет на такую ситуацию либо приоритетная обработка.Но я предполагаю, что запас разрядности это решит.Соответственно добавятся исключения.НО здесь не надо прослеживать эти изощренные связи, которые возникают при резке "дедовским" на ядра методом.Компилятор будет относительно простой поэтому!!!Ну предствате граф из миллиона взаимозависимых линий и вам надо их распутать.Надо выследить все зависмые связи и по сотням сществующих алгоритммов в одну сторону перекинуть другие связи в другую. Выделить независмые вычислений.Разделить это по mutexam, так что бы была симетричная загрузка-да это океан работы..

По поводу GCC вы хорошо заметили что разрядность он не меняет.И я тоже как то это заметил.По сравнению с резкой на 2,4,6 8 и более ядер проблема создания компилятора для плав ядерности достаточно проста.От обычной отличат вышеуказанные исключения + упаковка/распаковка формата.Более того можно упаковать формат так что бы отсутсвие дескрипторов ядерности априори воспринималось как обычный формат.И ядра работают без разбиений.

Вам бы читать следует про методики распаралеливания - море литры которое перелопатил в свое время, что бы понять насколько это проще. Думаю тогда сами все поймете.

Да, без нас никак. По меньшей мере, такие заявления, типа "сечем на раз". И пытаемся помочь "фантастам" сберечь мозг для более приземленных задачек, которые были бы им по силам.

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

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

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

У вас прямо старческий прагматизм развился.У меня не вызывает адреналина мой проект.Но вы то что мозг свой бедный мучаете на этом форуме.

Есть технологии разбиения архитектур.Есть технологии масштабирования и наоборот.А VHDL или Verilog кодинг для вас не фантастика?Сами то какие архитектуры считаете земными?А что для вас не высокий уровень? Cудя по вашей мегалогике высказываний- прошивать FSM -генераторы флуда.Не так?НЕ посчитайте за оскорбление. Но признайтесь, здесь дело не в нереалистичности проекта, а в каком то личном ущемлении достоинства.Не так?Не все за пределами вашего Бобруйска(или Урюпинска) - слабоумные.))


"Вы будете весьма одиноки в своих изысканиях".Тут вы относительно правильны, но есть те кто в тему сразу вошел - многоядерщики-программисты, SOC дизайнеры, разработчики ASIC. Есть и куда более изощренные проекты.

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

"Вы не обижайтесь, Вам тут не враги-ренегаты письма пишут".Мое дело выявить отношение и уровень понимания темы.

Сообщение отредактировал Anticitizen1 - Mar 28 2010, 04:54