Методы повышения производительности фиттера, рассуждаем Опции

[ilkz]

Хао, други!

Осенило тут вопросом - а можно ли использовать для ускорения фиттинговых вычислений CUDA? Честно говоря, не очень понятно почему Альтера (на ее примере, т.к. работаю только с ней) к этому не пришла. Мне кажется, фиттеровские алгоритмы идеально лягут на куду... Или это уже как-то реализовано и я такой непросвященный?

Давайте порассуждаем на эту тему.

Помогу начать.

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

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

Так вот - что мешает фиттеру укладывать одновременно несколько кучек? На тот же GPU это бы легло очень продуктивно, мне кажется... А там и до сетевого кластерного фиттера недалеко. Правда, сегодня фиттеры до сих пор не могут нормально использовать даже несколько ядер внутри обычного ЦП (лично у меня альтеровский фиттер Processors Usage не поднимал еще ни разу выше 1.2 - и это при наличии 4-х ядер.)

Сообщение отредактировал ilkz - Oct 10 2011, 11:46

[ilkz]

Насколько мне известно, графическая память гораздо быстрее обычной. Соответственно, что мешало бы выгружать в GPU небольшие (относительно) партиции, компилировать их, а уже само "сведение" партиций делать на центральном процессоре ПК? Эдакий "конвеер партиций".

[DmitryR]

что мешало бы выгружать в GPU небольшие (относительно) партиции

Нежелание юзеров выделять такие партиции и невозможность делать это автоматически.

[ilkz]

... и невозможность делать это автоматически.

Мне кажется, для определения партиции можно использовать сами модули. Модуль - партиция. Ну либо несколько модулей, вложенных в один (а часто так и бывает) - тоже, по сути, партиция.
Кстати, лично я не особо доверяю инкрементальной компиляции, т.к. она, бывает, глючит - компилятор иногда не может что-то с чем-то свести и все времянки либо логика летят к черту )) Такое уже не раз было. Помогает снос incremental_db.

Сообщение отредактировал ilkz - Oct 10 2011, 12:24

[DmitryR]

Мне кажется, для определения партиции можно использовать сами модули. Модуль - партиция.

Ага. Прощай трансграничная оптимизация - здравствуй лишний объем и снижение Fmax.

[ilkz]

Ага. Прощай трансграничная оптимизация - здравствуй лишний объем и снижение Fmax.

Я просто предположил Обычно же стыки крупных модулей делают такими, чтобы они (модули) были друг от друга максимально отвязаны (например, это два модуля, работающих в двух разных тактовых доменах). Отсюда и возникла такая мысль.

[DmitryR]

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

Да, но вы правильно тут говорите - стыки крупных модулей. А их в проекте обычно немного: у меня в UltraSPARC-системе количество партиций до десятка кажется не дотягивало. Но чтобы система хорошо на CUDA легла - их должны быть многие десятки.