Доброе время суток,уважаемые форумщики!
Собственно,минимальная конфигурация оборудования расписана для каждого программного пакета. Но меня интересуют несколько иные вопросы,ответы на которые я с ходу не смог найти. Надеясь на вашу помощь и поддержку,размещаю их в этой теме.
1. Могут ли программные пакеты эффективно использовать многоядерные (2-х, 4-х) процессоры?
2. Насколько эффективно софт использует оперативную память компа?
3. Нужно ли делать какие-либо настройки софта (не только САПР,но возможно,и ОС) для увеличения скорости расчетов?
Иными словами-как "выглядит" оптимальная система для СВЧ-софта.
Конкретно же меня интересуют MicroWave Office, Sonnet, CST MWStudio, Ansoft Designer, Zeland (платформа-Windows).
Может кто-то располагает данными по конкретному пакету (ссылки на форумы, статьи, личный опыт...). Буду благодарен за любую помощь в решении вышеперечисленных вопросов.

По настройке ОС сложно что-то сказать - никогда не возился. Когда можно спокойно поставить 3 Гига памяти, то бороться за лишние 10-20 Мб как-то нет особого смысла.

По CST недавно тестили на двухядерном на полностью одинаковых задачах 2006 и 2008 версию. Прирост в скорости от 40% и иногда более 100% (в этом случае 2008 ЦСТ увеличил величину шага по времени раза в 1.5, но результат расчета совпадает с 2006 версией и стабилен). 2006 версия не использовала 2 ядра, 2008 использует - так что выгода очевидна. Где-то тут же на форуме встречал заметку от 4-ядерной машине. Сами еще не прикупили такую, так что сказать о количестве ядер более 2 что-то конкретное сложно.

За ЦСТ еще замечено, что на момент расчета матриц он требует больше памяти, чем когда идет уже непосредственно Transient анализ.

Ну и при больших задачах наверное имеет смысл переходить на 64-разрядную ОС (более 3 Гб памяти).

По CST,двухядерный, изьезженная тема, много ссылок на форуме...

Используем MWO на 2-х ядерных и на 2-x процессорном железе. Время расчета EMStructure приблизительно одинаковое (два ядра по 50% загруженности против 4 по 25%). Сравнение чисто субъективное, т.к. машины отличаются как "самокат с машиной", но вывод напрашивается "зачем платить больше, если разницы никакой".

Спасибо за информацию. Думаю,что с CST вопрос решенный.


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

Если программа использует Intel MKL, то для активации мульти-ядерного использования достаточно заявить переменную окружения 'OMP_NUM_THREADS=<CPU Cores Number>'.
MKL предоставляет встроенный параллелизм на основе мульти-поточности.

Очень интересная информация,спасибо. Мы проводили подобные изыскания,но с Sonnet. Результат получился очень похожий-двухпроцессорный сервер с HT раскидывал примерно одинаково на все 4 (условно) ядра. А вот на двухядерной машине мы не тестили,т.к. их нет. Вот сейчас и думаем-какие машины брать... Кстати,тот же Sonnet но на 4-м пне, считал тестовую структуру ненамного больше (меньше минуты разница) чем на сервере. Вот и возник вопрос по поводу настроек ОС. Может,менять приоритет на "реального времени"?

поделюсь чисто соображениями, на примере, решения СЛАУ, без необходимости которого не может обойтись ни один ЭМ софт

насколько я знаю, в FEKO, EMC Studio да похоже и в Concept для решения СЛАУ используется библиотека LAPACK, а это уже ПОЧТИ однозначно говорит о том, что для решения СЛАУ используется много процессорность...

А как узнать использует она его или нет? Можно это где-то посмотреть?

При расчете на ФЕКО 100% загрузки я не вижу. Все колебается возле 50% (Ноутбук Centrino Duo). Стоит версия Feko 5.2. Может в 5.3 что-то и поменялось

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

В MoM-солверах на основе MKL 100% загрузка будет только на стадии как-раз матрикс-солвинга (применяя LAPACK). Заполнение матрицы и расчет полей зависят от разработчика и требуют специальной параллелизации. Возможно поэтому при указанном OMP_NUM_THREADS загрузка всё-же скачет около 50%.

Zeland:
Использует точно - см. библ. mkl_def.dll (Intel® Math Kernel Library ver.7). Версия старая, в 14 не изменилась. Использует не один процессор (причем даже виртуальный HT) только во время решения матрицы, во время заполнения - нет. На форуме разработчики стыдливо отмалчиваются на подобные вопросы. Выигрыш от мультикора есть, зависит от соотношения fill/solve, на практике достаточно небольшой.
Sonnet:
In Release 11, the Sonnet EM Analysis Engine is a single-thread application; therefore, it will only use one core of one processor to run.
Однако: There is a way to use more of the cores on your dual-socket, quad-core workstation, however...
см. ветку форума (вернее, веточку )"Multicore CPU and Sonnet": http://www.sonnetlist.com/phpBB2/viewtopic.php?t=467

А разве сами программы, которые используют Intel MKL не задают количество процессоров, которые будут использоваться.

Во всяком случае Matlab, Ansoft, CST заведомо работающие на последних версиях Intel MKL задают количество процессоров внутри себя.
Если ваша идея работает, то тогда можно не покупать опции поддержки многопроцессорного счета (достаточно не дешевые) и просто включить 'OMP_NUM_THREADS=<CPU Cores Number>', но что-то сомнительно, что это работает.

полностью согласен....

вот как дело обстоит с софтом основанным на, например, FDTD или FEM я пока не разбирался....

но им по сути вообще переход к распараллеливанию должен оказаться очень простым, поскольку они как правило используют итерационные методы решения разреженных систем (sparse iterative methods)
данные методы широко развиваются (например, см. работы Y.Saad, H. van der Vorst) и существует достаточно много библиотек с их реализацией.

я вот чего то в описаниях не шибко находил упоминания какие итерационные методы испольуются в FDTD, TLM, FEM .....