Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Какие САПР СВЧ поддерживают рассчеты на игровых картах?
Форум разработчиков электроники ELECTRONIX.ru > Аналоговая и цифровая техника, прикладная электроника > Rf & Microwave Design
ikolmakov
Притащили мне ASUS GeForce GTX 1080 с целью ускорить расчеты :-) Но я посмотрел по основным программам (MWO, HFSS, FEKO...) и увидел только разговор про Tesla. А CUDA на простых картах кто-то поддерживает?
Hale
архитектура Tesla=Cuda
ATI=OpenCL

в графических картах есть два типа вычислительных ядер, 32 и 64 битные(двойной точности). Вторых в несколько раз меньше чем первых, за исключением карт Titan и самих Tesla как продукта, где соотношение single:double доходит до 2:1. Если речь о тесли как продукте, то сейчас она как и 1080 имеет итерацию "Pascal".

1080 сделан на итерации чипа GP104, как и Tesla P4
"One Pascal SM on the GP100 combines 64 single-precision (FP32) shader processors and also 32 double-precision (FP64) "
SM=Streaming Multiprocessor. В Тесле их вроде бы 60, т.е. нас интересуют 1920 64-разрядных исполнительных блока.
А в 1080 - не ясно. Но суюдя по всему, GFLOPs увеличены примерно пропорциональны частоте. Т.о. судя по всему, проме драйверов и объема памяти, 1080 практически идентичен Тесле P4.

Но есть одно но. Хорошо параллелятся и считаются на дискретных бордах только тайм-домейн методы. Для начала потому что ни меньше памяти занимают и легче разбиваются на домены. Полноволновые методы по моему никто серьезно еще на ускорителях не решал. Т.о. HFSS, в котором Transient поддерживаешь конечно ускорители, по основному своему FEM солверу отпадает, т.к. в нем задача может занимать и 60 и 100 гигабайт за раз, в зависимости от материалов и сложности модели. Остальные наверняка надо узнавать у производителя, какой солвер вам нужен и какой поддерживает.
PCBtech
Цитата(ikolmakov @ Feb 24 2017, 00:17) *
Притащили мне ASUS GeForce GTX 1080 с целью ускорить расчеты :-) Но я посмотрел по основным программам (MWO, HFSS, FEKO...) и увидел только разговор про Tesla. А CUDA на простых картах кто-то поддерживает?


Можно посмотреть САПР Empire XPU. Очень быстро считает большие объекты, по сравнению с теми же MWO, HFSS...
Ей нужен CPU Intel, желательно i7, чем больше ядер, тем выше скорость. А тип графической карты не так важен.

Сравнивали недавно по точности расчетов с другими САПР - результаты очень близкие, при скорости вычислений в разы более высокой.
khach
Хакать надо NVIDIa карты для для использования их в качестве ускорителя. http://www.eevblog.com/forum/chat/hacking-...l-counterparts/
Hale
Цитата(khach @ Feb 26 2017, 04:54) *
Хакать надо NVIDIa карты для для использования их в качестве ускорителя. http://www.eevblog.com/forum/chat/hacking-...l-counterparts/

только там где тупой софт проверяет DevID.

Это не вина nVidia, а вина разработчиков софта. CUDA-C компилится под любой современный ускоритель nVidia. Иначе бы многие игры стояли в сторонке и поглядывали на AMD/ATI.

Традиционно, nVidia "хакают" не для CUDA, а для 3D графики Quadro. Quadro заточены на отображение проволок в CAD и на повышенное качество отрисовки, в ущерб производительности. Короче, другие оптимизации дров, да и сами дрова отдельные.
Во времена Riva GeForce 3, 4 чипы Quadro были идентичны игровым, только с лочками по DevID. Сейчас в игровых чипах пережигают аппаратно доступ к специализированных блокам используемым в CAD-ах, в.т.ч. антиалаясные проволоки и пр. Но iD все еще сменить можно. Как софтово(с глюками, но и возможностью откатить) так и перепайкой резисторов.
Pir0texnik
Так собственно вопрос, который всех волнует: кому-то удалось "перековать" игровую карту(пусть NVIDIA) таким образом, чтобы эффективно использовать ее в качестве ускорителя расчетов?
Применительно к CST, HFSS(только транзиент вроде?), ADS (там есть галочка...), MWO или Sonnet (они умеют в это вообще?).
Читая http://www.eevblog.com я так и не понял что поменялось после замены ID GTX980 на теслу...
DmitryHF
CUDA поддерживает Savant. Метод расчета - трассировка лучей.
Видеокарты это хорошо умеют делать. Пробовал использовать Ge Force 650 ti, работало.
Сейчас Savant в составе Ansys Electromagnetics. Удобно использовать для быстрого анализа мест установки антенн.

Информация из справки:

GPU Hardware

The Savant GPU plug-in requires an NVIDIA GPU. Most recent NVIDIA GPUs (manufactured in the last three years) work well, with the best performance typically coming from the higher-end GTX, Quadro and Tesla cards. NVIDIA GPUs are produced for many different types of computers, including laptops, desktops and compute servers. The GPUs are also produced for many different market segments. This section provides an overview of many key concepts that are helpful to understand.

Please contact us if you have specific questions or would like us to recommend the best GPU to use with Savant for your application and budget.

NVIDIA GPU product lines

NVIDIA markets workstation GPUs in three different product lines. They market mobile GPUs in two different product lines.

GeForce or GTX: the consumer, desktop product line, focused on maximizing graphics-throughput for home users. These cards work well the Savant GPU plug-in. To maximize graphics refresh rates, the GeForce cards run at faster clock rates than other product lines. This leads to somewhat higher speed-up in Savant, but also produces more heat and may lead to higher error rates. As a result, NVIDIA recommends using Tesla cards for GPU compute servers. Sample GeForce model numbers include: GTX 670, 680, 750Ti, 770, 780, Titan, 960, 970, 980.

Tesla: the GPU compute server product line. Tesla GPUs run at slightly slower clocks to produce less heat and higher reliability. They also utilize ECC ram to detect and correct hardware memory errors. Tesla GPUs typically cost 3x to 4x more than comparable GeForce cards. Sample Tesla model numbers are K10, K20, K40. The Maxwell architecture is now available in the Tesla product line with models M40 and M60 but has not been tested with Savant. Pascal GPUs are available in the Tesla product line with models P4, P40, and P100 but have not been tested with Savant.

Quadro: the high-end visualization product line. These cards have the same GPU hardware as GTX and Tesla cards but are marketed to professional users. These cards tend to be more expensive than the GTX product line. They can work well with Savant GPU but the added cost of the Quadro may not translate to extra acceleration in Savant. A GTX card with the same internal hardware may provide the same level of acceleration at a lower price. Some Quadro cards have low numbers of processing cores and may not provide much speedup.
Mobile GPUs

NVIDIA sells mobile versions of GeForce and Quadro GPUs. The mobile versions typically have similar model numbers as the desktop versions, with an 'M' added to the model number. The mobile versions tend to have fewer cores and run at slower clock speeds, compromises that are necessary to reduce power consumption and heat. Savant GPU works well on recent mobile GPUs, but because of the hardware restrictions, it is not expected to achieve the same level of acceleration as it does on desktops and servers. Speed-ups of 8x to 15x are more typical for Savant GPU on mobile GPUs.

GPU architecture

There are different generations of GPU architecture. These are analogous to the CPU generations such as Pentium III, Pentium IV and most recently, Core I7. The NVIDIA GPU architectures from newest to oldest are Pascal, Maxwell, Kepler, and Fermi. Savant GPU performs well on all of them, but the best performance generally comes from the newer architectures. Savant GPU may run on GPUs from older architectures but may not perform well due to hardware limitations of those older GPUs.

Pascal: the current generation of NVIDIA GPU processor. Pascal processors generally have faster processing (GFLOPS/sec) and more memory than previous generations. Pascal also has much higher memory bandwidth (GB/sec) on the Tesla product line. Pascal GPUs are very new for Savant 18.0. Savant has not been tested on Pascal but should be compatible.

Maxwell: the previous generation of NVIDIA GPU processor. Maxwell processors generally contain more GPU cores, larger cache and other memory, and improved instruction scheduling compared to Kepler GPUs. Specifics vary by individual models. Maxwell processors are found on GeForce GTX 750xx, some GeForce GTX 8xxM (mobile) models, and GeForce GTX 9xx models. Some GeForce model series contain a mixture of Maxwell and Kepler GPUs, so it is important to check the particular model to be sure it has the desired GPU architecture.

Kepler: a previous generation of NVIDIA GPU processor. Contains 2x to 5x more GPU cores than Fermi (the exact core count depends on on the model). Kepler processors are found in GeForce 6xx models, Tesla K10, K20 and K40 models, and Quadro K2000 through K5000. Savant began to provide support for Kepler GPUs in Savant 3.0 and fully supports Kepler since Savant 4.0. Our tests show that Savant GPU performs electromagnetic calculations very well on Kepler GPUs.

Fermi: the generation of NVIDIA GPU processor prior to Kepler. Contains up to 512 compute cores and increased memory bandwidth. Savant GPU performs very well on Fermi GPUs. Fermi processors are found in GeForce 4xx and 5xx models, Tesla 20x0 models and Quadro 600, 2000, 4000, 5000 and 6000.
Hale
Цитата(Pir0texnik @ Feb 27 2017, 05:21) *
Так собственно вопрос, который всех волнует: кому-то удалось "перековать" игровую карту(пусть NVIDIA) таким образом, чтобы эффективно использовать ее в качестве ускорителя расчетов?
Применительно к CST, HFSS(только транзиент вроде?), ADS (там есть галочка...), MWO или Sonnet (они умеют в это вообще?).
Читая http://www.eevblog.com я так и не понял что поменялось после замены ID GTX980 на теслу...

Я еще ни разу не слышал, чтобы софт, способный считать через CUDA не жрал игровые карты nVidia.

Еще раз - наличие Tesla, Quadro, или GTX с точки зрения CUDA не имеет никакой разницы. С аппаратной точки зрения есть разница в объеме памяти и в ограничении 64-битных исполнительных унитов на младших версиях карт. Старшие GTX/Quadto/Tesla отличаются частотами(в пользу GTX) и памятью (в пользу Tesla).


То что CG софт типа 3DS Max выводит не очень хорошую картинку в АППАРАТНЫЙ(!) preview на неперекованных картах, это факт, для этого его и перековывают (причем, на поколениях карт GS перековка не помогала ничем, кроме возможности поставить специализированные дрова без оптимизаций. Квадровые инструкции были выжжены лазером).
Но тут еще штука - для этого эффекта мониторы нужны порядка 1600 строк. На мониторах низкого разрешения, напротив, размазанные антиалаясные линии Quadro выглядят хуже "рваной паутины" выдаваемой на GTX.
Но к CUDA это отношения не имеет! Если я не ошибаюсь, до того как маркетологи приняли туманную расшифровку "Compute Unified Device Architecture", существовала достаточно понятная "Common Unit Data Access".

По поводу софта.
CUDA поддерживается в Matlab, но через прокладки, которые сжирают больше 50% теоретического прироста.

Существует nVidia cuBLAS библиотека не совместимая с оригинальным BLAS, но реализующая некоторые его функции, для желающих покодить.

Поскольку никто кодить не хочет, также была попытка сделать прокладку симулирующую настоящий BLAS и вызывающую cuBlas, либо нормальный Blas по необходимости. Но попытка была реализована только для линуксов, также с серьезными потерями производительности. Есть статья по акселерации в Octave с известной долей корпоративного преувеличения результатов.
https://devblogs.nvidia.com/parallelforall/...ion-gnu-octave/
Под Windows реализации нет, кроме упомянутого нестандартного cuBLAS
Pir0texnik
Цитата(Hale @ Feb 27 2017, 10:53) *
Я еще ни разу не слышал, чтобы софт, способный считать через CUDA не жрал игровые карты nVidia.

А я вот только и вижу один этот софт...... CST вот хоть. И как его приспособить не под теслу/квад?
Grizzzly
Цитата(PCBtech @ Feb 25 2017, 23:13) *
Можно посмотреть САПР Empire XPU.

Интересный пакет. Впервые слышу спасибо. А есть где-нибудь подробное описание организации вычислительного процесса? Это коммерческая тайна, но всё-таки вдруг где-то написано. Пока непонятно, за счет чего такой выигрыш по сравнению с GPU...
Читаю здесь: http://media.wix.com/ugd/cc9e5f_f1b100a1d1...50966de696a.pdf

UPD.:
Получается, что софт сугубо под Intel. То есть они как-то договорились с Intel и получили все сведения о тонкостях работы кэшей, конвейеров и т.д. Я правильно понимаю, что на AMD работать не будет?
ikolmakov
Да.. Жалко что по делу почти никто так и не высказался. Вместо этих пустых простыней я думал что кто-то напишет об использовании Tesla хотя бы. Какой софт, на сколько быстрее в каких задачах.
Pir0texnik
Цитата(Grizzzly @ Feb 27 2017, 20:16) *
Получается, что софт сугубо под Intel. То есть они как-то договорились с Intel и получили все сведения о тонкостях работы кэшей, конвейеров и т.д. Я правильно понимаю, что на AMD работать не будет?

Ну так они все используют Intel MKL, которое на все случаи жизни.
C AMD Core Math Library (ACML) видимо все не так однозначно... Кто девушку кормит, то ее и танцует и не надо конспирологии.
Hale
Цитата(Pir0texnik @ Feb 27 2017, 11:38) *
А я вот только и вижу один этот софт...... CST вот хоть. И как его приспособить не под теслу/квад?

Скорее всего дело не в Тесле, а в том что ваша ишровая карта не обладает необходимыми ресурсами, как то памятью, количеством 64битных блоков, или устаревшая версия Куды. Драйверы тоже надо обновлять, но иногда надо обновлять и ускоритель (это как с переходом с DX10 на DX11)
Hale
Цитата(Grizzzly @ Feb 27 2017, 20:16) *
Пока непонятно, за счет чего такой выигрыш по сравнению с GPU...

За счет I/O и случайного доступа к памяти.
У GPU сравнительно ограниченные возможности, заточенные на векторное вычисление. Как только в схеме сбой - для смены задачи приходится прокачивать и преекладывать огромные объемы памяти.
Если программа аккуратно написана СПЦИАЛЬНО для векторных регистров CPU, то она может и на CPU гоняться с переменным успехом за GPU младшего и среднего сегментов. Intel 10 лет вел разработки своего лучевого рендерера для графики под CPU. Хотя проект и провалился, но родил промежуточный тип ускорителей Xeon Phi, которые гораздо более гибкие чем GPU в программировании и I/O.

Цитата(Grizzzly @ Feb 27 2017, 20:16) *
Получается, что софт сугубо под Intel. То есть они как-то договорились с Intel и получили все сведения о тонкостях работы кэшей, конвейеров и т.д. Я правильно понимаю, что на AMD работать не будет?

Никто ни о чем не договаривался. Все задокументированно и предоставлено разработчикам. И нет никакого смысла начинать писать под изначально ущербную платформу. AMD просто отстал и заигрался... при этом у AMD нет такого ресурса как у интела, когда они занимались дурью с NetBurst и Rambus
Pir0texnik
Тогда я не понимаю почему CST пишет именно, что ему надо ТЕСЛА, а не GTX1080?
Что значит не хватает ресурсов? Ну запустись хоть как-то, быстрее будет или нет и зачем такое надо - это второй вопрос уже.
Grizzzly
Цитата(Hale @ Feb 28 2017, 05:22) *
И нет никакого смысла начинать писать под изначально ущербную платформу. AMD просто отстал и заигрался...

Спорный вопрос. CERN для своих серверов выбирают AMD: http://www.hardwareluxx.com/index.php/news...h-32-cores.html
Третий в мире по производительности сервер тоже на AMD: https://www.top500.org/lists/2016/11/
Для многопоточных вычислений как раз AMD интереснее смотрится. Если все делают софт с использованием Intel MKL, то, разумеется, Intel на порядок смотрится выигрышнее.
В эти состоялся выпуск новой линейки AMD Ryzen, которая в чем-то даже превосходит Intel'овские процессоры. Дома у меня Intel, на работе AMD. Для конкретных задач - свой процессор. Поэтому я бы не стал так принижать AMD.
PCBtech
Цитата(Grizzzly @ Feb 27 2017, 20:16) *
Интересный пакет. Впервые слышу спасибо. А есть где-нибудь подробное описание организации вычислительного процесса? Это коммерческая тайна, но всё-таки вдруг где-то написано. Пока непонятно, за счет чего такой выигрыш по сравнению с GPU...
Читаю здесь: http://media.wix.com/ugd/cc9e5f_f1b100a1d1...50966de696a.pdf

UPD.:
Получается, что софт сугубо под Intel. То есть они как-то договорились с Intel и получили все сведения о тонкостях работы кэшей, конвейеров и т.д. Я правильно понимаю, что на AMD работать не будет?


Вот тут есть рекомендации по железу для оптимальной скорости моделирования:

http://www.empire.de/page4.html

Hardware recommendations:

• Intel Core i5, i7, Xeon
• 4 GB RAM or more
• Graphic card “OpenGL certified” (1280*1024 Pixel or more )
• Nvidia GTX 750 or better
• ATI Raedon HD77xx or better
• Hard disk space 3 GB
• Three button wheel mouse


PC recommendations:

Workstation (eg. Dell Studio XPS 8100):
•64bit Quad Core, Intel Core i7
•At least 3 Memory Modules

Multi CPU Workstation (eg. Dell Precision T7500):
•64bit Quad Core, Intel Xeon Series 5600
•At least 3 Memory Modules

LAPTOP (e.g. Dell Precision M2400 or M6500):
•Intel Core2 Duo, or Intel Core i7 Quadcore
•2 Memory Modules
Grizzzly
Цитата(PCBtech @ Feb 28 2017, 12:26) *
Вот тут есть рекомендации по железу для оптимальной скорости моделирования:

Спасибо.
Hale
Цитата
CERN для своих серверов выбирают AMD

потому что 1)цели другие. Как серверы они очень даже неплохие. Но для расчетов, особенно на FPU - полный провал в производительности. 2)Дешевле 3) Лобби.

Есть еще одно соображение. У AMD FPU размазывает (нойз-шейпинг типа) ошибку FSIN, немножко уравнивая ее по диапазонам значений. Intel делает более грубые округления при деноминации больших аргументов, что приводит к более грубым "ступенькам" дисбалансам на графике ошибок.
http://notabs.org/fpuaccuracy/scatterplots/scatterplots.htm
Для ученых CERN это может быть существенно, например, чтобы не видеть нелинейные фракталы в спектрах там где их нет. Для нас, электромагнитных инженеров, это несущественно. Гораздо существенней скорость переваривания больших массивов данных.

Цитата
Спорный вопрос.

Чего там спорного. 1 FPU на два ядра, да и тот тормозной. Плюс проблемы с переходами между C-состояниями питания ядер.

Третий в мире по производительности сервер тоже на AMD
Это все брехня. Это как китайцы сделали второй в мире суперкомпьютер по производительности, который складывать и умножать массивы по немкольку мегабайт может. Но если сложить все RISC ядра, то очень быстро.
Мораль: девять баб за месяц ребенка не родят.
Большинство солверов до сих пор упирается в производительность однопоточных процедур. Может что-то что ученые ЦЕРНА пишут и параллелится лучше, но они это еще не продают в форме продкта. Кроме того, еще раз, x86 архитектура на научных суперкомпьютерах не используется. Не пользуется популярностью и SMT распараллеливание. Все эти x86/x64 бегемоты - чисто утилитарные датацентры.

Интересный пакет. Впервые слышу спасибо.
я с ними пообщался.
Пустышка. Изначально ущербный солвер потому что разработчики - не физики, а ленивые программисты.
- Они свято верят, например, что гиротропия и нелинейность в FDTD не считается. Хотя у меня знакомый еще аспирантом прекрасно решал НУШ с комплексными значениями через FDTD для распространения волн, в матлабе конечно.
- Методу уже лет 90, они до сих пор не намерены реализовывать неоднородный меш и упрощение в протяженныз однородных участках.
- До сих пор тупой кубический меш, никакого намека на аккуратную тетраэдральную разбивку.
Так что ничего интересного не ждите. Просто умелые программеры хорошо оптимизировали чей-то простейший алгоритм. Получилось "из пушки по воробьям". Тупиковый вариант.
OpenEMS предлагает это бесплатно, с намного меньшей производительностью и большими усилиями конечно. Но совершенно бесплатно. И даже где-то лучше.
Grizzzly
Цитата(Hale @ Mar 1 2017, 03:45) *

Огромное спасибо за подробный ответ! С такими формулировками и объяснениями согласен.
PCBtech
Цитата(Hale @ Mar 1 2017, 03:45) *
Интересный пакет. Впервые слышу спасибо.
я с ними пообщался.
Пустышка. Изначально ущербный солвер потому что разработчики - не физики, а ленивые программисты.
- Они свято верят, например, что гиротропия и нелинейность в FDTD не считается. Хотя у меня знакомый еще аспирантом прекрасно решал НУШ с комплексными значениями через FDTD для распространения волн, в матлабе конечно.
- Методу уже лет 90, они до сих пор не намерены реализовывать неоднородный меш и упрощение в протяженныз однородных участках.
- До сих пор тупой кубический меш, никакого намека на аккуратную тетраэдральную разбивку.
Так что ничего интересного не ждите. Просто умелые программеры хорошо оптимизировали чей-то простейший алгоритм. Получилось "из пушки по воробьям". Тупиковый вариант.
OpenEMS предлагает это бесплатно, с намного меньшей производительностью и большими усилиями конечно. Но совершенно бесплатно. И даже где-то лучше.


Речь про разработчиков Empire XPU, правильно?
Интересно, как Вы ловко их смешали с грязью.
"Ущербный солвер", "ленивые программисты", "тупой кубический меш", "из пушки по воробьям", "тупиковый вариант". "OpenEMS совершенно бесплатно... и даже где-то лучше". Ууххх...

Я понимаю, что это форум, свободное общение, но может, будем как-то более аргументированно выступать?

По существу дела:
я лично знаю людей, которые использовали для своих СВЧ-расчетов CST, а потом перешли на Empire XPU - банально именно из-за существенно более высокой скорости вычислений, при той же точности.
И им не нужны никакие нелинейности, неоднородный меш, упрощение в протяженных однородных участках, тетраэдральная разбивка и прочие вкусности и красивости. Зачем, если и без этого алгоритм "молотит" со страшной скоростью на всех ядрах и кешах Интеловского процессора, и задействует всю доступную память компьютера очень эффективно?
Вы попробуйте-ка ваш тетраэдральный меш на графическом ускорителе применить для большой СВЧ-системы. Застрелитесь, пока он будет из памяти в кеш и обратно данные переливать.

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

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

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

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

http://www.empire.de/page45.html&sid=a...8a71b7f2807cd4f

Да, и там есть импорт из других САПР и из ODB++, так что можно посравнивать на конкретике.
iiv
Ну йопэрэсэтэ, вы сами-то хоть раз (хоть кто-то из форума) программировал и оптимизировал пакеты линейной алгебры на CUDA/OpenCL? Точно нет? Ну так и чеж говорить, что "почему он не поддерживает".

Да потому, что замучаешся.

Чтобы считаться на ГПУ, надо, чтобы данные сидели там, но и надо, чтоб большая часть алгоритма тоже там крутилась.

Вот Вы попробуйте, имея огромный массив в обычной оперативной памяти его отсортировать на ГПУ, и чтоб получилось быстрее, чем в оперативной. Да хоть на тесле, да хоть на перетесле! А? Нет? Кишка тонка? Руки не их того места? Или аппаратно не получится?

Во!!!

Не всякая задача хорошо ложится на ГПУ, а если и ложиться, то ГПУ программерам вподляк поддерживать все архитектуры, который Нвидия наплодила как кроликов.

И часто происходит так, что софтвер с кудой есть, но поддерживает только 1-2 карты/чипа, ибо на остальных ГПУ он как черепашка ниньзя - вроде и ГПУ, но и ползает как оно самое.

Да и АМДшник со своим Ронмом и ОпенЦэЭлем не лучше себя ведет.

С уважением

Официальный представитель-консультант по CUDA по Германии
Pir0texnik
Анекдот вспомнил про "... ты так слона не продашь"...
А в целом очень из инженеров свч "хоть раз программировал и оптимизировал пакеты линейной алгебры на CUDA/OpenCL?". Было бы удивительно если наоборот.

Кстати, так а КУДА разве не для того, что бы не сильно зависеть от аппаратной конфигурации?..
Hale
Цитата(PCBtech @ Mar 1 2017, 15:38) *
И им не нужны никакие нелинейности, н

А комплексно-анизотропный тензор проницаемости нужен. И я считают это позором инженерного программирования, что спустя 90 лет после первого описания метода, и 60 лет после работ Сула и Волкера до сих пор ферриты можно посчтать только в FEM (HFSS) или "на бумажке" (в Матлабе).

От бесконечных заявок на конференциях и выставках FDTD меня честно уже тошнит. Как дети малые. "Мы не будем делать сложные вещи, мы лучше сделаем то что все на 3 курсе проходят чуть быстрее и зарядим цену как за полноценный продукт".И все хотят за это бабло. Квадратное уравнение решить - давайте бабло.
Да, это ловкие умелые, но все те же coding monkey.
Из их ответа я точно, на 145% понял, что эти ребята не заинетресованы в улучшении функциональности софта и даже не предлагают "подождать", или инвестировать в будущее. Им просто по фигу - "мы быстрее всех", боьше ничего не надо.
На вопрос, а сколько задачка будет занимать в памяти.... аой а 5 гигабайт без оверхеда.. Дааа?? И очень быстро вы 5 гигабайт будете перекладывать? Если задача не решается до обеденого преерыва, то честно говоря пофигу, решится она завтра, или послезавтра. Есть полно может и не такого быстрого, но более перспективного софта. Есть даже бесплатный софт с аналогичными возможностями.
Цитата
сейчас попробовать мульти-процессорную лицензию

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

Цитата
Вы попробуйте-ка ваш тетраэдральный меш на графическом ускорителе применить для большой СВЧ-системы. Застрелитесь, пока он будет из памяти в кеш и обратно данные переливать.

тетраэдральный меш хорош тем, что он в разы, на порядки экономичнее кубического, при обводке непрямоугольных контуров, и по той же причине выдает большую точность. Он же позволяет аккуратно ввести неоднородную плотность узлов, для еще большего сокращения работы.
Слабость ортогонального сеточного меша FDTD в том что он не может быть физически применим к сколько-нибудь объемным задачам, а следовательно и ограничен в диапазоне частот, т.к. при приближении к оптике - ни один суперкомпьютер не способен всосать в себя эти данные и тем более перкладывать из домена в домен при разбиении. Удел FDTD - плоские узкие полоски при прогоне дискретных элементов. Чуть расширить, или углубить задачу, и 80% времени тратится на пустопорожние вычисления там, где ничего нет и быть не может.

Цитата(iiv @ Mar 1 2017, 23:10) *
Чтобы считаться на ГПУ, надо, чтобы данные сидели там, но и надо, чтоб большая часть алгоритма тоже там крутилась

Совершенно точно. А поскольку обхъемы задач выходят далеко за 3 Гб, пересылка по PCIe - приводит только к замедлению. Кроме того полноволновые методы вообще хрен решишь.

Господа, вы в курсе, что четырехядерный i7 4ГГц на задачках около 8-12 Гб в HFSS(FEM) частенько обгоняет 8x2 процессорный Xeon 3.4ГГц.
А знаете почему? А из-за того что часть данных, часто попадает в область ответственности CPU1, в результате чего CPU0 вынужден лезть без срезаний пути через оба внутрипроцессорных кольца и QPI. Ну и гораздо меньшая латентность безрегистровой памяти (в принципе, на GPU верхнего диапазона она еще быстрее, но ее хронически мало)

Цитата
И часто происходит так, что софтвер с кудой есть, но поддерживает только 1-2 карты/чипа, ибо на остальных ГПУ он как черепашка ниньзя - вроде и ГПУ, но и ползает как оно самое.

тут дело не в ГПУ, а в маркетинге. Как я сказал, Невидь из-за игроманов прячет свои спеки и хрен поймешь, где Даблпресижн вычислительных блоков больше, в GTX 780, или в 970. Ну, пока не начнешь писать свой код, там все станет ясно.
По хорошему, для вычислений в куда (именно с приростом производительности) годятся только карты x70Ti, x80, x90/Titan и их одночиповые аналоги Quadro/Tesla. При этом у GTX клоки раза в два выше.

Цитата(Pir0texnik @ Mar 2 2017, 03:02) *
Кстати, так а КУДА разве не для того, что бы не сильно зависеть от аппаратной конфигурации?..

ага. толко у нее там 12 разных версий, не с полной совместимстью. Куда жила, а процессорные архитектуры менялись. Ну, по крайней мере кто на ней пишут, говорят что намного проще пишется чем под АМД
iiv
Цитата(Hale @ Mar 2 2017, 09:45) *
Ну, по крайней мере кто на ней пишут, говорят что намного проще пишется чем под АМД


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

В то же время, если у тебя есть четкий и понятный алгоритм для распараллеливания, и есть бюджет, из которого будет оплачиваться железо и свое время в виде зарплаты самому себе, то почти всегда в выигрыше АМДшник, так как у АМДшника есть достаточно удобные и успешные модели карт, на которых все будет работать, и реально в разы быстрее, чем на Нвидишных камнях за те же деньги.
Hale
совершенно точно.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.