Многопроцессорнось и CUDA при моделировании описаний на HDL языках Опции

[dvladim]

Вопрос такой:
Какие пакеты моделирования позволяют задействовать ресурсы всех доступных процессоров в системе, кластеры, ресурсы процессора видеокарты (используя CUDA), внешние аппаратные ускорители (какие?) для ускорения моделирования?

Вообще интересно как хорошо распараллеливается моделирование HDL описаний. Насколько линейно влияет увеличение числа процессоров? Насколько важна потоковая скорости и задержки подсистемы памяти?

Желательно (если это возможно) в примерах с конкретными цифрам: каков объем проекта; язык; количество тестовых векроров (событий) при моделировании; использованная система - железо, ОС, софт; время компиляции и моделирования; занятый объем памяти?

[CaPpuCcino]

1)плохо улавливаю, вас что конкретно интересует - среды проектирования использующие параллельные вычислительные архитектуры или распараллеливание тех или иных алгоритмов? 2)если вы говорите о параллельных вычислительных архитектурах, то следует учесть, что архитектуры эти принципиально разные (те же многопроцессорные системы - это MIMD, а графические сопроцессоры - это SPMD /single program multiple data/), и соответственно алгоритмы на них ложатся по-разному. если вас интересует применение именно CUDA, то в статейках NVIDIA кучами можно найти заоблачные показатели ускорения алгоритмов (кстати, почему именно CUDA, а не, к примеру, более универсальные cell-processors) при этом стоит учитывать что для CUDA не все алгоритмы подходят и программировать под неё приходится адаптируя алгоритм под GPU архитектуру всевозможными макросами и дефайнами
в общем широко как-то очень зрите, можно как-нить по-конкретнее формулировать?

[dvladim]

Интересует что из софта и на какой аппаратуре использовать что бы быстрее всего промоделировать проект. Т.е. как ускорить моделирование?

[CaPpuCcino]

относительно CUDA, думаю коммерческие моделяторы её не поддерживают и врядли будут поддерживать, потому как архитектура GPU для универсальных вычислений подойдёт врядли (слишком специфична и требует адаптацию конкретного алгоритма), относительно многопроцессорности с распараллеливанием потоков, то запросто, но только такое распараллеливание идёт на уровне ядра операционки на платформе конкретной конфигурации и для сред моделирования (написаных по техн. multithreding) прозрачно. многопроцессорность модели MPI тоже достаточно специфична(как и GPU), ожидать, что создатели будут обращать внимание на такие архитектуры можно едва ли.

[DRUID3]

относительно CUDA, думаю коммерческие моделяторы её не поддерживают и врядли будут поддерживать, потому как архитектура GPU для универсальных вычислений подойдёт врядли (слишком специфична и требует адаптацию конкретного алгоритма), относительно многопроцессорности с распараллеливанием потоков, то запросто, но только такое распараллеливание идёт на уровне ядра операционки на платформе конкретной конфигурации и для сред моделирования (написаных по техн. multithreding) прозрачно. многопроцессорность модели MPI тоже достаточно специфична(как и GPU), ожидать, что создатели будут обращать внимание на такие архитектуры можно едва ли.

Но есть же расширения для MatLAB и фотожопа)))

А не в курсе какие среды моделирования поддерживают распараллеливание? И какой прирост оно дает?

SciLab. Кластер из 64-х 4-х ядерников собрали и впред)))

[CaPpuCcino]

Но есть же расширения для MatLAB и фотожопа)))

и вы знаете о чём говорите? работали с CUDA + MatLab? эти расширения предназначены для массово-параллельных вычислений (матричной организации).
а на счёт фотошопа - было бы странно, если бы компания позиционирующая себя как лидер ПО для обработки графики, не пользовалась передовыми технологиями графических карт.
какое отношение всё это имеет к средам моделирования цифровых систем на базе HDL-ев?

[DRUID3]

и вы знаете о чём говорите? работали с CUDA + MatLab? эти расширения предназначены для массово-параллельных вычислений (матричной организации).
а на счёт фотошопа - было бы странно, если бы компания позиционирующая себя как лидер ПО для обработки графики, не пользовалась передовыми технологиями графических карт.
какое отношение всё это имеет к средам моделирования цифровых систем на базе HDL-ев?

к HDL-лям пока никаких, но не факт, что крупные компании в это дело не влаживаются, раз другим не зазорно. А о "фотожопе" у Вас димагогия. Обработка 2D изображний и 3D графика практически не пересекаются - и возможность применение CUDA в этом пакете говорит лишь о том, что нашлись люди "секущие фишку".

P.S.: MatLab-ом не пользуюсь (давно игрался, еще с 6-ой версией кажеЦЦо) - это йад заставлящий человека думать что он знает больше чем на самом деле. Ктому же дорогой йад... Н это уже религия ...

[CaPpuCcino]

А о "фотожопе" у Вас димагогия.

ну, собственно из ответа следует, что ни к GPU(в частности CUDA), ни к HDLs, ни к MatLab вы отношения не имеете, на этом и остановимся.
по сабжу: GPU организованы как вектор процессорных элементов выполняющих одинаковый код над разными данными (то самое SPMD), синхронизация этих параллельных потоков очень ресурсоёмка (выполняется как правило на стороне хоста), потому как для задач исполняемых GPU собственно и не требуется, поэтому распараллеливание потоков при симуляции HDL кода на GPU нецелесообразно, т.к. эти потоки требуют интенсивной синхронизации

Для ускорения моделирования лучше HDL использовать только для описания самого проекта, т.е. того, что потом придётся синтезировать.

как верно замечает al1, сейчас существуют другие методы увеличения произв. при симуляции, в частности оптимизация самой модели (но не только SystemC) - по вопросам оптимизации думаю стоит обратиться либо в ветку по языкам описания либо по SOPC раздела Программируемая логика

[Stanislav]

ну, собственно из ответа следует, что ни к GPU(в частности CUDA), ни к HDLs, ни к MatLab вы отношения не имеете, на этом и остановимся.
по сабжу: GPU организованы как вектор процессорных элементов выполняющих одинаковый код над разными данными (то самое SPMD), синхронизация этих параллельных потоков очень ресурсоёмка (выполняется как правило на стороне хоста), потому как для задач исполняемых GPU собственно и не требуется, поэтому распараллеливание потоков при симуляции HDL кода на GPU нецелесообразно, т.к. эти потоки требуют интенсивной синхронизации

Не вдаваясь в подробности дискуссии, скажу только, что у Вас весьма примитивное (или, если хотите, устаревшее) представление об архитектуре современных GPU, а также об их возможностях при решении различных задач, допускающих распараллеливание процессов.

относительно CUDA, думаю коммерческие моделяторы её не поддерживают и врядли будут поддерживать, потому как архитектура GPU для универсальных вычислений подойдёт врядли...

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

[CaPpuCcino]

Не вдаваясь в подробности дискуссии, скажу только, что у Вас весьма примитивное (или, если хотите, устаревшее) представление об архитектуре современных GPU, а также об их возможностях при решении различных задач, допускающих распараллеливание процессов.

это весьма может быть, ведь я сейчас программирую под CUDA на не самом современном чипе (GeForce 8800 GTS). вы как всегда оставляете интригу после своего комментария - рассказали бы о современных архитектурах более подробно, мне очень интересно чем они сейчас отличаются от моих представлений о GPU

Здесь Вы попали пальцем в небо. Первая ласточка уже появилась.

не, я тыканьем пальцем в такие обширные области не занимаюсь - стараюсь делать выводы с помощью логических заключений. конечно безупречность результатов данного процесса гарантировать не берусь.
на сколько я понимаю, обсуждаемый здесь пакет занимается обсчитыванием физических полей. на сколько я представляю симуляция HDL-модели достаточно сильно отличается от подобных расчётов. у HDL модели параллельность проявляется в наличие множества сигналов, каждому из которых свойственнен собственный набор перобразований/операций над его значением/, т.е. множество разнородных(по составу и длинне) потоков инструкций, синхронизирующимися с помощью набора ассоциированных событий, т.о. принцип SIMD по которому построен каждый мультипроцессор в архитектуре NVIDIA G80, подходит здесь очень плохо, а синхронизация мультипроцессоров через общую память на плате/Device Memory/ достаточно накладна

[Stanislav]

это весьма может быть, ведь я сейчас программирую под CUDA на не самом современном чипе (GeForce 8800 GTS). вы как всегда оставляете интригу после своего комментария - рассказали бы о современных архитектурах более подробно, мне очень интересно чем они сейчас отличаются от моих представлений о GPU

G80 - вполне современный проц, по крайней мере Nvidia ничего принципиально отличного с точки зрения программной модели пока что не выдумала. У меня G92 (9800 ПЕЧ+), но это практически то же самое, за исключением некоторых аппаратных доработок, впрочем, производителем открыто не документированных.
Если что-то не так написал - простите великодушно. Меня смутила лишь Ваша мысль о невозможности расспараллеливания процессов моделирования на GPU. Который всё-таки является не SIMD - процессором, в коем выполнение разнородных операций представить себе действительно трудно. Главный боттлнек GPU, на мой взгляд, - возможность исполнения только одного кернела в конкретный момент времени, но это и понятно - толщина каналов обмена с внешним миром у GPU не безгранична. Однако, его "куски" могут быть раскиданы по разным вычислительным блокам с помощью аппаратного диспетчера (в тонкостях я ещё не разобрался: куду начал ковырять только недавно, да и времени на это мало).

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

Предлагаю всё же отталкиваться от фактов.
Вот, поглядите ещё сюда (вероятно, и ув. al1 также будет интересно).
http://www.nascentric.com/omegasim_gx.html
Фильмец ещё посмотреть можно, в картинку ткнув мышом.
Интересно будет почитать Ваши комментарии.

Контора на таких вещах специализируется, и сомневаться в достоверности данных нет особых оснований.
http://www.nascentric.com/product_guide.html
От аналогового моделирования процессов внутри цифровых ИС всё равно никуда не уйти, и здесь подобные продукты могут значительно потеснить "тяжеловесов". А для расчётов на физическом уровне GPU очень даже подходит.

...на сколько я понимаю, обсуждаемый здесь пакет занимается обсчитыванием физических полей. на сколько я представляю симуляция HDL-модели достаточно сильно отличается от подобных расчётов. у HDL модели параллельность проявляется в наличие множества сигналов, каждому из которых свойственнен собственный набор перобразований/операций над его значением/, т.е. множество разнородных(по составу и длинне) потоков инструкций, синхронизирующимися с помощью набора ассоциированных событий, т.о. принцип SIMD по которому построен каждый мультипроцессор в архитектуре NVIDIA G80, подходит здесь очень плохо, а синхронизация мультипроцессоров через общую память на плате/Device Memory/ достаточно накладна

Да почему накладна, когда она, если так можно выразиться, "бесплатна"?
Даже если процессы моделирования не получается распараллелить на несколько тредов внутри каждого из мультипроцессоров (хотя, это представляется весьма странным), кто мешает использовать их как множество SISD-структур в подмогу хосту? В Вашем G80 их целых 12 штук, а в RV770 от ATI-AMD - аж 160 (и 800 тредов), если не ошибаюсь.

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