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

[Anticitizen1]

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

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

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

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


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

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

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

[zzzzzzzz]

Это что, у Вас хобби такое, реконфигурируемые многоядерники сочинять?
Если это ОКР, то д.б. конкретное ТЗ.
Если Вы только сочиняете ТЗ, то успели ли задать себе вопросы типа "нахрена все это нужно?" и "кто за это готов заплатить?"
Если не успели, то поспешите, - ответы нынче суровые бывают...

И вообще, в чем, собственно, вопрос?

Сорри, напомнило классическое "мы тут подумали немного и собрались Интелов с Паккардами порвать на куски..."

[Anticitizen1]

Это что, у Вас хобби такое, реконфигурируемые многоядерники сочинять?
Если это ОКР, то д.б. конкретное ТЗ.
Если Вы только сочиняете ТЗ, то успели ли задать себе вопросы типа "нахрена все это нужно?" и "кто за это готов заплатить?"
Если не успели, то поспешите, - ответы нынче суровые бывают...

И вообще, в чем, собственно, вопрос?

Сорри, напомнило классическое "мы тут подумали немного и собрались Интелов с Паккардами порвать на куски..."

Вы под реконфигурацией что понимаете переключение как у FPGA programmable interconnect ? Если так то не верно управление сигналом вызывает деление на ядра как например сигнал переключения с логич операций на арифметические.Да это задание которое взял в рамках одного проекта.Но пока не знаем JAVA процессор может лучше но он как то сырым кажется.ULTRA SPARC лучше отлажен хотя огромное число разных блоков и сложный слишком процессор.Да я не только сочиняю довольно много подбирал архитектур для этого.Я не интелы рвать собираюсь а архитектуру апробировать для портативок.
Идея зародилась с техники программирования.
Ну представте себе комп игру - где много разных событий приходится обрабатывать - логические переходы, подсчет большого числа парралельных явлений событий.Чем больше процесссов тем больше потоков обработки надо но при меньшей разрядности. Кодирование большого числа событий происходящих в перспективе можно осуществить меншей разрядностью.

И не лишне будет подумать о том, как компилить подо все вот это?
Второе: не проще ли будет такое сделать в духе Intel Larrabee - на маленьких, но гордых процессорах? Кстати, все к этому и идет.

PS. На словах, "происходит взрыв", ушки сделали стойку.

Да взрыв это просто наглядный пример для того что бы показать необходимость увеличения числа потоков.Ну не взрыв а например другой многопоточный процесс с взаимозавиимыми и нет явлениями - да сколько угодно.Я вообще рань на ассемблере писал еще задавался такими вопросами.Насволько можно оптимально вентили использовать.

Эх, мечты, мечты...

Если оставить в стороне вопрос производительности, для того чтобы изделие было конкурентно-способным, нужно
1) Поддержка софта - как минимум GCC+работоспособный Linux+основной софт. Для разваливающихся процессоров вы GCC допиливать будете годами.
2) Тираж. Нет, даже ТИРАЖ. Чем ниже тираж - тем выше стоимость 1 чипа. Вы сможете продавать 10млн чипов в год при цене 300$ штука? Кто вам сделает это на 65нм по нормальной цене (при которой вы сможете хоть как-то конкурировать с банальными i7)?



Larabee делать не нужно, уже есть серийные супер-дешевые GPU для таких целей. 3 терафлопа за 400$ - это вам не шубу в трусы заправлять :-)

1)Про софт я понимаю.Но вы перепрыгнули через стадии до софта еще надо довести.Я думал посоветуют как резать чтобы на этапах симуляции не затрять.Софт не должен в небеса улететь если не сильно с архитектурой изголяться.Я повторяю в рамках одного элементарного разбиения-адресация , основные наборы инструкций для всех видов операций теже , регистры общего пользования и специализированные остантся теми же дополнительные адреса добявятся и инструкции( сигналы) разбиений- как же это по вашему должно поменять софт - сильно или нет?Здесь будут проблемы с оборудованием серьезные
2) банальный i7?Да прямо уж банальный)).Помимо интел есть много других архитетур.Я хочу архитектуру опробовать а не с интел бороться.Помимо интел есть и куча других архитектур.Мы предполагаем для портативных устройств делать.


3) Проблемы будут с такой вещью как инструкции условного перехода- если прыжки делать в одно и тоже "устройство" а разрядность не рассчитать.

4)Другая проблема. Излишня вентильная загруженность - 10-20 %.американцы разгоняли ядро бьщееся на 2 или 3(проект 2003-2004 годов) и получили рост в 2 и 3 раза то мне кажется вещь себя оправдывает.Более того могу предположить что рост производительности должен быть пропорционален числу разбиений.


Не... "банальность i7" здоровао сказано.))))

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

[BarsMonster]

Не... "банальность i7" здоровао сказано.))))

Банальность i7 в том, что его себестоимость производства порядка 50$(а то и меньше), тиражи семизначные, а производительность на SIMD инструкциях - до 160 млрд вещественных операций в секунду. Собственно, это ваше разделение там в некотором роде и реализовано - в одном SSE блоке можно делать или 2 64-х битных операции, или 4 32-х битных, и т.д.

Теперь вы говорите про портативные устройства - причем тут тогда симуляция взрывов?
В большинстве портативных устройств стоят процессоры даже без FPU - это же не спроста.

ИМХО производителям портативных устройств продать что-то не-ARM совместимое невозможно, пусть оно и будет в 2 раза быстрее и 2 раза дешевле. Стоимость внедрения отличается на порядки. А с АРМом - склепали платку, накатили стандартный софт - и можно китайцам отдавать на штамповку.

[yes]

а чем эта идея лучше/отличается от SIMD (векторной обработки) - всяческих MMX/SSE AltiVec NEON и т.д. ?

кажется, что "разбивания" ядер возможно только на уровне датапасов - то есть в инструкции указывается как трактовать ну например 256 разрядное слово - 32 байта ... 4 дабла

ну а исполнения потоков (идея SPARC T1/T2) чтоб ядра не простаивали - в теории выглядит хорошо, а на практике не встречал (последняя станция с 1.5ГГц Sparc IIIi, которую "трогал" вживую, тормозила безбожно)

[Anticitizen1]

а чем эта идея лучше/отличается от SIMD (векторной обработки) - всяческих MMX/SSE AltiVec NEON и т.д. ?

кажется, что "разбивания" ядер возможно только на уровне датапасов - то есть в инструкции указывается как трактовать ну например 256 разрядное слово - 32 байта ... 4 дабла

ну а исполнения потоков (идея SPARC T1/T2) чтоб ядра не простаивали - в теории выглядит хорошо, а на практике не встречал (последняя станция с 1.5ГГц Sparc IIIi, которую "трогал" вживую, тормозила безбожно)

Да можно разбивать по разному на независимы потоки, ядра и как векторные операции .Схемотехнические решения позволяют такое сделать.Более того можно опробовать более динамичную систему предсказани ветвлений.Структура программ будут иметь вложенные в друг друга дескрипторы сегментов кода, данных и стека.Синхронизация тоже должна иметь много уровневую систему.
Есть ряд приемов, которые задачу плавающей ядерности очень упрощают.

[yes]

Да можно разбивать по разному на независимы потоки, ядра и как векторные операции .Схемотехнические решения позволяют такое сделать.Более того можно опробовать более динамичную систему предсказани ветвлений.Структура программ будут иметь вложенные в друг друга дескрипторы сегментов кода, данных и стека.Синхронизация тоже должна иметь много уровневую систему.
Есть ряд приемов, которые задачу плавающей ядерности очень упрощают.

не знаю, для дела пишите или просто поразвлекаться

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

да, есть всяческие потоковые узкоспециализированные ускорители - когда одно "ядро" передает данные другому "ядру" и какой-либо "общей" памяти нет, это как раз используется во всяких медиа, все пропиентарно, можно погуглить Silicon Hive (и таких проектов реально тьма, сам участвовал)
но проблема не захардварить, а написать компилятор, который нормальный код по этому нive-у распихает

возможно, что хотите сделать что-то подобное - флаг в руки - проект востребован, но сомневаюсь, что получится сделать (не хардварь, а всю систему) разворачивающую GP процессор в специализированный потоковый ускоритель

[Anticitizen1]

не знаю, для дела пишите или просто поразвлекаться

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

да, есть всяческие потоковые узкоспециализированные ускорители - когда одно "ядро" передает данные другому "ядру" и какой-либо "общей" памяти нет, это как раз используется во всяких медиа, все пропиентарно, можно погуглить Silicon Hive (и таких проектов реально тьма, сам участвовал)
но проблема не захардварить, а написать компилятор, который нормальный код по этому нive-у распихает

возможно, что хотите сделать что-то подобное - флаг в руки - проект востребован, но сомневаюсь, что получится сделать (не хардварь, а всю систему) разворачивающую GP процессор в специализированный потоковый ускоритель

Silicon Hive посмотрел- да таких много проектов, знаю.Таких 80-90%.Но вы до какого уровня разбирали системы?Просто на уровне SOC я не объясню.Наверное я не на тот форум зашел.....

"Здесь другой вопрос.разбив одно ядро на много маленьких, пропускные способности систем памяти не увеличить, и откуда взяться приросту производительности непонятно. если в режиме "единое ядро" ядро сильно тормозное и доступ к памяти более широкий - то это как-то не хорошо изначально и сомневаюсь, что конкурентоспособно"-замечено правильно на все 100%)) с одной стороны.Но перейдем из лабораторной в другую систему исчисления, систему корабля!))

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

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

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

Теперь, кажется вижу проблему.Каждый разработчик видит мир дизайна в своем русле.Я пытаюсь найти универсальный способ объяснения.

Сообщение отредактировал Anticitizen1 - Mar 31 2010, 05:18