ilkz 0 10 октября, 2011 Опубликовано 10 октября, 2011 (изменено) · Жалоба Хао, други! Осенило тут вопросом - а можно ли использовать для ускорения фиттинговых вычислений CUDA? Честно говоря, не очень понятно почему Альтера (на ее примере, т.к. работаю только с ней) к этому не пришла. Мне кажется, фиттеровские алгоритмы идеально лягут на куду... Или это уже как-то реализовано и я такой непросвященный? Давайте порассуждаем на эту тему. Помогу начать. Вот смотрите. По сути, ПЛИС - это очень большая и сложная сетка (граф, но не Дракула :)). Возьмем некий сферический фиттер в вакууме. По сути, его задача - отобразить синтезированную ранее логику на эту сетку таким образом, чтобы результат удовлетворял заданным ограничениям. Я не знаю достоверно как работает фиттер - могу лишь сидеть и фантазировать, но думаю что трассировку этой сетки он выполняет не путем тупого перебора всех возможных ее комбинаций, и не пытается уложить в сетку сразу всю логику сразу, а делает все по-частям. И я так понимаю, все нынешние фиттеры делают это последовательно - сначала одну кучку логики, потом другую, потом еще одну и т.д., после чего уже работают на уровне этих разведенных "кучек". Так вот - что мешает фиттеру укладывать одновременно несколько кучек? На тот же GPU это бы легло очень продуктивно, мне кажется... А там и до сетевого кластерного фиттера недалеко. Правда, сегодня фиттеры до сих пор не могут нормально использовать даже несколько ядер внутри обычного ЦП (лично у меня альтеровский фиттер Processors Usage не поднимал еще ни разу выше 1.2 - и это при наличии 4-х ядер.) Изменено 10 октября, 2011 пользователем ilkz Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DmitryR 0 10 октября, 2011 Опубликовано 10 октября, 2011 · Жалоба Если дизайн поделить на партиции - CPU usage будет нормальный. Но проблема в том, что трассировка больших дизайнов требует значительно больше памяти, чем есть в современных графических ускорителях. У меня при трассировке под Stratix IV - 230 уходило шесть гигов где-то, при этом затраты времени были около часа (на четырех ядрах), что вовсе не приводит к мысли пробовать задействовать CUDA. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ilkz 0 10 октября, 2011 Опубликовано 10 октября, 2011 · Жалоба Насколько мне известно, графическая память гораздо быстрее обычной. Соответственно, что мешало бы выгружать в GPU небольшие (относительно) партиции, компилировать их, а уже само "сведение" партиций делать на центральном процессоре ПК? Эдакий "конвеер партиций". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AJIEKCEu 0 10 октября, 2011 Опубликовано 10 октября, 2011 · Жалоба Помогу начать. Так вот - что мешает фиттеру укладывать одновременно несколько кучек? На тот же GPU это бы легло очень продуктивно, мне кажется... А там и до сетевого кластерного фиттера недалеко. Правда, сегодня фиттеры до сих пор не могут нормально использовать даже несколько ядер внутри обычного ЦП (лично у меня альтеровский фиттер Processors Usage не поднимал еще ни разу выше 1.2 - и это при наличии 4-х ядер.) Для CUDA подходят далеко не все задачи. Из wiki: Ideal GPGPU applications have large data sets, high parallelism, and minimal dependency between data elements. Кроме того, там упоминается понятие Arithmetic intensity. Грубо говоря - количество арифметических операции приходящихся на одно обращение к памяти. Оно желательно должно быть высоким. Если короче - он может выполнять очень много обработок одновременно, но они должны быть независимы. Данных должно быть много, но обращений к памяти - мало. И кроме того, насколько я себе представляю, в GPU не предусмотрено ветвления алгоритма. А сделать fitter без ветвления.... В моем представлении это как раз очень плохо соотносится с задачами fitter'а. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DmitryR 0 10 октября, 2011 Опубликовано 10 октября, 2011 · Жалоба что мешало бы выгружать в GPU небольшие (относительно) партиции Нежелание юзеров выделять такие партиции и невозможность делать это автоматически. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ilkz 0 10 октября, 2011 Опубликовано 10 октября, 2011 (изменено) · Жалоба ... и невозможность делать это автоматически. Мне кажется, для определения партиции можно использовать сами модули. Модуль - партиция. Ну либо несколько модулей, вложенных в один (а часто так и бывает) - тоже, по сути, партиция. Кстати, лично я не особо доверяю инкрементальной компиляции, т.к. она, бывает, глючит - компилятор иногда не может что-то с чем-то свести и все времянки либо логика летят к черту )) Такое уже не раз было. Помогает снос incremental_db. Изменено 10 октября, 2011 пользователем ilkz Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DmitryR 0 10 октября, 2011 Опубликовано 10 октября, 2011 · Жалоба Мне кажется, для определения партиции можно использовать сами модули. Модуль - партиция. Ага. Прощай трансграничная оптимизация - здравствуй лишний объем и снижение Fmax. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ilkz 0 10 октября, 2011 Опубликовано 10 октября, 2011 · Жалоба Ага. Прощай трансграничная оптимизация - здравствуй лишний объем и снижение Fmax. Я просто предположил :) Обычно же стыки крупных модулей делают такими, чтобы они (модули) были друг от друга максимально отвязаны (например, это два модуля, работающих в двух разных тактовых доменах). Отсюда и возникла такая мысль. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DmitryR 0 10 октября, 2011 Опубликовано 10 октября, 2011 · Жалоба Обычно же стыки крупных модулей делают такими, чтобы они (модули) были друг от друга максимально отвязаны Да, но вы правильно тут говорите - стыки крупных модулей. А их в проекте обычно немного: у меня в UltraSPARC-системе количество партиций до десятка кажется не дотягивало. Но чтобы система хорошо на CUDA легла - их должны быть многие десятки. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dvladim 0 10 октября, 2011 Опубликовано 10 октября, 2011 · Жалоба Осенило тут вопросом - а можно ли использовать для ускорения фиттинговых вычислений CUDA? Честно говоря, не очень понятно почему Альтера (на ее примере, т.к. работаю только с ней) к этому не пришла. Мне кажется, фиттеровские алгоритмы идеально лягут на куду... Или это уже как-то реализовано и я такой непросвященный? Потому что алгоритмы как размещения так и трассировки плохо распараллеливаются даже на процессорах общего назначения, а на CUDA и того хуже. А основная проблема - зависимости между потоками. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jojo 0 10 октября, 2011 Опубликовано 10 октября, 2011 · Жалоба Что-то мне кажется, что основная проблема в коде программ САПР, а не в вычислительной сложности алгоритмов. Например, у меня конфигурационный файл для Virtex-6 bitgen-ом формируется 20 минут. Размещение и трассировка здесь уже выполнены, куда ему на DRC столько времени? Как спросили на одном семинаре у Xilinx-немцев - когда ISE станет нормально работать? Когда выйдет Rodin, ответили. И то сомнительно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dvladim 0 11 октября, 2011 Опубликовано 11 октября, 2011 · Жалоба Что-то мне кажется, что основная проблема в коде программ САПР, а не в вычислительной сложности алгоритмов. Дело не в сложности алгоритмов, а в самих алгоритмах. Итерационные алгоритмы, например, плохо распараллеливаются. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jojo 0 11 октября, 2011 Опубликовано 11 октября, 2011 · Жалоба Так будет точнее. Но есть ощущение (см. bitgen), что ISE медленно работает просто из-за плохого качества программного кода. Дрябленько сделано, развесисто написано, без оптимизации. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
iiv 27 13 октября, 2011 Опубликовано 13 октября, 2011 · Жалоба Осенило тут вопросом - а можно ли использовать для ускорения фиттинговых вычислений CUDA? одна фирма - оффициальный CUDA Nvidia консультант год назад и с Альтерой и с Ксилинксом и с Латтисом этот вопрос обсуждали - в портфолио кудовской фирмы - под двадцать лет работы на массивно-параллельных платформах. Вопрос обсуждался на уровне деректоров по развитию. Решили забить, так как игра не стоит свеч - те кому надо - купят побыстрее проц и SSD, а остальные подождут. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VladimirB 1 13 октября, 2011 Опубликовано 13 октября, 2011 · Жалоба ...Решили забить, так как игра не стоит свеч - те кому надо - купят побыстрее проц и SSD, а остальные подождут. Куда уж быстрее: у нас штеуд I7-2600K ещё и разогнанный на 10% компилит Xilinx VLX240T порядка 1-1.5 часа. Это с Planahead'om. Без него вообще ISE крутил яйцами неопределённо долгое время (рабочий день раньше заканчивался). Разве что за жидким азотом в магазин сходить. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться