Кофигурацыя системы на базе Tesla C2050/C2070 (C2075)

Здравствуйте! Возникла задача внедрения GPU-Computing для решения задач численного моделирования (симуляция и оптимизация фабрик полупроводников с помощью эвристик, докторская работа). Считать действительно много, и есть довольно хороший потенциал для распараллеливания расчетов, никакой роботы с видео, рендерингом и прочим. Помогите, пожалуйста дельным советом начинающему. Сначала Hardware, надо собрать систему, здесь следующие вопросы:
1. Присматриваюсь к Nvidia Tesla видеоадаптерам. Какой из них выбрать С2050, С2070 или С2075? И объясните, пожалуйста, разницу в цене (есть же попроще карточки, у которых тоже свыше 400 ядер, но стоимость в районе пол тысячи у.е., а не двух)?
2. Нужно ли отдельно покупать простенький видеоадаптер для видео вывода? Если не обязательно, то есть ли смысл? Если покупать, тогда надо материнскую плату з двумя PCI-Ex x16, подскажите какую или хотя бы на каком чипсете лучше взять?
И ещё по софту:
1. В силу некоторых ограничений есть привязка к Windows 7 и Visual Studio 2008 SP1. Правильно ли я понял, что если возникнет потребность установить Windows Server 2008, чтобы несколько человек могли работать з GPU одновременно, тогда нужно выбирать совсем другие адаптеры (S1070 или как-то так)? Если да, то в чем здесь причина?
2. Как я должен понимать 448 ядер значит ли это, что я могу одновременно считать 448 потоков?
3. Распараллеливание расчетов осуществляется автоматически, или надо будет программировать, что на каком ядре считать?
4. Если нет никаких параллельных расчетов, можно ли приблизительно сравнить производительность одного потока, скажем, на Intel Core i7 и Tesla C2075?

Заранее спасибо за ответы!

Forums: 

1. Присматриваюсь к Nvidia

1. Присматриваюсь к Nvidia Tesla видеоадаптерам. Какой из них выбрать С2050, С2070 или С2075? И объясните, пожалуйста, разницу в цене (есть же попроще карточки, у которых тоже свыше 400 ядер, но стоимость в районе пол тысячи у.е., а не двух)?
Карты C2050 уже сняты с производства, поэтому вам правильнее выбирать либо C2070, либо C2075. Разница между этими картами в ревизии чипа, так что расценивайте её как переходная карта для C2070. Поэтому если есть возможность, то берите C2075. Что касается стоимости, тот тут есть множество факторов, которые вы не учитываете: поддержка ECC, объём графической памяти, работа с двойной точность. То, что есть карты GeForce, где больше CUDA ядер, ещё не значит что она будет быстрее для вашего приложения, т.к. производительность у GF в двойной точности ниже, чем у Тесел. Так же нет ниодной карты GeForce где есть поддержка ECC и более 1.5GB видеопамяти.

2. Нужно ли отдельно покупать простенький видеоадаптер для видео вывода? Если не обязательно, то есть ли смысл? Если покупать, тогда надо материнскую плату з двумя PCI-Ex x16, подскажите какую или хотя бы на каком чипсете лучше взять?
Карты Tesla поддерживают только базовые операции, проще говоря там нет поддержки 3D функционала. Таким образом, если вам не нужна поддержка 3D (например Windows Aero, OpenGL, DirectX) то вы можете пользоваться только одной картой. Но лучше всего взять отдельную видеокарту для графики - какую конкретно решать вам. Если вы хотите работать с OpenGL приложениями, то следует брать Nvidia Quadro 400 и выше, если вам нужны игры, то любой GeForce. Материнскую плату вы можете взять любую, поддерживающую 2 PCIe x16 слота.

1. В силу некоторых ограничений есть привязка к Windows 7 и Visual Studio 2008 SP1. Правильно ли я понял, что если возникнет потребность установить Windows Server 2008, чтобы несколько человек могли работать з GPU одновременно, тогда нужно выбирать совсем другие адаптеры (S1070 или как-то так)? Если да, то в чем здесь причина?
Одновременно с GPU может работать только одно приложение. Т.е. может работать и 10 и 20 человек, но все будут ждать очереди, пока не освободится ресурс. Это требование справедливо и для центральных процессоров, когда требуется высокая производительность приложения. Поэтому вы можете работать с любой ОС, с которой вам удобно работать. Не следует смотреть на GPU как на обычный процессор.

2. Как я должен понимать 448 ядер значит ли это, что я могу одновременно считать 448 потоков?
Подробности тут: http://ru.wikipedia.org/wiki/SIMD. Вы можете одновременно использовать 448 потоков, но не в том смысле, в котором вы привыкли при работе с центральным процессором. Говоря простым языком - вы не можете запустить 448 приложений и каждому отдать по одному CUDA ядру, но вы можете превратить обычные циклы в последовательный код, используя в качестве индексов номера потоков. Таким образом циклическая операция превращается в большое кол-во последовательных операций, выполняемых одновременно.

3. Распараллеливание расчетов осуществляется автоматически, или надо будет программировать, что на каком ядре считать?
Можно использовать сторонние продукты и директивно производить распараллеливание (как в случае с OpenMP). Можно самому программировать и управлять поведением приложения на GPU.
Вот вам набор ресурсов по книгам и документации:
http://developer.nvidia.com/cuda-books
http://developer.nvidia.com/nvidia-gpu-computing-documentation
http://www.caps-entreprise.com/fr/page/index.php?id=49&p_p=36
http://www.pgroup.com/resources/cudafortran.htm
ftp://geophyslab.srcc.msu.ru/Events/CUDA2010/

4. Если нет никаких параллельных расчетов, можно ли приблизительно сравнить производительность одного потока, скажем, на Intel Core i7 и Tesla C2075?
Нет сравнить нельзя, т.к. назначение и принципы работы разные.

Большое спасибо за ответ и

Большое спасибо за ответ и полезные ссылки! Уже заказал систему на базе PNY Nvidia Tesla C2075 и Intel Core i7-960 (Intel X58 Express Chipset). Дополнительно для видео вывода заказал Nvidia Quadro NVS295. Поддержка 3D или работа з OpenGL не интересует, так как речь идет исключительно о численном моделировании, но в тех. поддержке сказали, что возможно минимальное падение производительности (до 5-10% в зависимости от приложения), если видео-вывод тоже нагружать на Теслу.
Я понимаю, что прямо сравнивать производительность CPU и GPU не совсем корректно из-за принципиальной разницы в архитектуре, но все же вернусь к этому вопросу и постараюсь изложить свой случай более правильно. Грубо говоря, у меня есть задача, требующая больших вычислений и состоящая из некоторого числа итераций. На каждой итерации задачу довольно быстро можно разделить на почти полностью независимые подзадачи (их будет где-то 60-80). Кроме того, решение подзадач также можно частично распараллелить (если коммуникация между параллельными блоками будет достаточно быстрой). Сейчас работаю над алгоритмической частью, как только приедет система, возьмусь за реализацию. Реализация тех же алгоритмов планируется тремя способами:
1. Однопоточная процессорная реализация на С++.
2. 1 + OpenMP, в итоге 4 потока или 8, если использовать Hyper-Threading (как я уже упоминал, использоваться будет Intel Core i7-960)
3. Реализация на CUDA C/C++ (Nvidia Tesla C2075)
Перед тем как заказать систему, руководитель, конечно же, поинтересовался, какой Speedup варианта 3 ожидается по сравнению с вариантами 1 и 2, и дал четко понять, что если он тратит деньги на такую систему, то и результат соответствующий хочет видеть. Я, конечно же, ответил Да, шеф, результат будет. Вопрос заключается только в разработке алгоритмов, а потенциала железа нам хватит с головой . Исходя из нескольких прочитанных статей по применению GPU Computing к похожим задачам, но его так же интересуют конкретные цифры, так сказать, о каком конкретном спидапе идет речь. Отсюда и вопрос - можно ли хоть приблизительно оценить, какой производительности я должен ожидать? Хотя бы для того, чтобы потом можно было самому оценить свою реализацию. Я имею в виду, что когда будут первые результаты, что бы я хоть сам мог оценить, действительно ли я по максимуму использовал имеющийся потенциал, или где то не учел особенностей роботы з памятью или еще чего-то, и на самом деле можно еще повысить производительность.
По ходу анализа, возник еще один интересный вопрос. Относительно Heterogeneous Computing, т.е., одновременного использования CPU и GPU. Может кто-то поделиться полезными ресурсами на эту тему? В частности, интересуют примеры реализации. Может, какие-то уже готовые фреймворки на базе CUDA. Также интересует интеграция С++ - ого кода с CUDA (что-то более продвинутое чем пример CppIntegration из Nvidia GPU Computing SDK, где интеграция реализована в виде вызова внешних функций Си). Буду благодарен за любую информацию по теме, спасибо.

speed-up бывает очень разный

speed-up бывает очень разный и очень зависит от задачи и от того, с чем сравнивать.

Ну вот например целый спектр вариантов:
0) Задачи с низкой арифметической интенсивностью, вроде сложения двух векторов. На CPU исполняются со скоростью памяти, а на GPU - со скоростью пересылки через PCI-Express. Т.е. медленнее.

1) задачи вроде сортировки, где требуется доступ к случайным данным в случайном порядке: выигрыш на GPU в лучшем случае в разы, да и то в небольшие.

2) Задачи вроде умножения матриц: доступ к памяти линейный, арифметическая интенсивность высокая. На GPU реально получают 70-80% от пиковой (теоретической) производительности, на CPU - 90% т.е. GPU примерно на порядок быстрее.

3) Задачи с интенсивным использованием функций, которых нет на CPU (аппаратных), но есть на GPU: тригонометрия, экспонента, логарифм. 30-40-кратный прирост на GPU - нормальное явление.

4) То же самое, что в предыдущем пункте, но для sin/cos/exp/ на CPU используются не высокоэффективные векторные реализации (вроде SVML), а вот прямо и пишут a = sin(b) да так, что компилятор не векторизует.
Тут прирост в 1000 раз меня совершенно не удивит, но это потому что сравнение (CPU-шный вариант) с совершенно неэффективной реализацией.

В какой класс попадает ваша задача - не знаю.

2. Как я должен понимать 448


2. Как я должен понимать 448 ядер значит ли это, что я могу одновременно считать 448 потоков?
Подробности тут: http://ru.wikipedia.org/wiki/SIMD. Вы можете одновременно использовать 448 потоков, но не в том смысле, в котором вы привыкли при работе с центральным процессором. Говоря простым языком - вы не можете запустить 448 приложений и каждому отдать по одному CUDA ядру, но вы можете превратить обычные циклы в последовательный код, используя в качестве индексов номера потоков. Таким образом циклическая операция превращается в большое кол-во последовательных операций, выполняемых одновременно.

Смотря что за ядра. Для ферми, одно ядро (SP) одновременно может "выполнять" два потока.


Я понимаю, что прямо сравнивать производительность CPU и GPU не совсем корректно из-за принципиальной разницы в архитектуре, но все же вернусь к этому вопросу и постараюсь изложить свой случай более правильно. Грубо говоря, у меня есть задача, требующая больших вычислений и состоящая из некоторого числа итераций. На каждой итерации задачу довольно быстро можно разделить на почти полностью независимые подзадачи (их будет где-то 60-80). Кроме того, решение подзадач также можно частично распараллелить (если коммуникация между параллельными блоками будет достаточно быстрой).

Нужно понимать, что переход к параллельности, это не какая-то добродетель, а вынужденная мера - потому что по-другому не получается.
Для современных GPU, нужно не просто произвести распараллеливание алгоритма, но также необходимо чтобы эти параллельные нити выполняли *одинаковую* (ну почти) работу. Потом, есть много мест, в которых можно похоронить всю производительность, например - доступ к памяти.
Преимущество GPU над современными CPU (с RAM'ом) по основным показателям - GFlop/s, Memory Bandwidth - примерно на порядок. Не стоит ожидать большего ускорения. Тем более, чтобы получить этот порядок разницы (по сравнению с оптимальной CPU версией), нужно приложить намного больше усилий, чем для оптимизации CPU версии. Также для определённого класса задач, получить этот порядок разницы невозможно в принципе.
Да, в некоторых местах пишут о 1000x ускорении, но это скорее говорит о том, что версия программы для CPU была крайне не оптимальна, или железо было древним.

Вот вы говорите, что считать "действительно много" - а вы уверены что обычные CPU вам не подойдут, т.е. будут считать очень долго(дольше допустимых пределов)? На чём основана эта уверенность? Вы проводили оценку объёмов необходимых вычислений и сравнивали её с мощностями CPU?

И почему именно Tesla? На чём основан этот выбор?
Так как вы не собираетесь строить кластер, то единственным плюсом для вас по сравнению с GTX'ами, по большому счёту является большее количество double GFlop's-ов. А у вас есть вообще эти double precision floating point в ваших задачах? И если есть, то почему не карточки AMD? У них с double GFlop's-ами всё и так не плохо.
То есть скорей всего, вы просто повелись на рекламу, типа "Tesla - для расчётов".
И почему Quadro?
Ладно - мне всё равно, хотите вливать деньги в индустрию - вперёд, мне же лучше будет.

Здравствуйте, J0hn! Моя цель,

Здравствуйте, J0hn! Моя цель, все же, решить быстро и эффективно мою задачу, а не вливать деньги в индустрию . Как я уже писал, речь идет о докторской диссертации, и я пытаюсь учесть все возможный нюансы и проблемы, а здесь за советом.
В моем случае, к сожалению, переход к параллельным вычислениям действительно вынужденная мера. Как я уже писал, моя задача оптимизация фабрик полупроводников, задача NP-сложная в строгом смысле. Вместе з увеличениям моделей сложность возрастает экспоненциально, а модели приходиться рассматривать довольно большие, чтобы хоть немного приблизиться к реальным фабрикам полупроводников. Потенциал для оптимизации очень хороший и чем интеллектуальнее эвристики я использую, тем лучшие результаты, но дело иногда доходит к абсурду, когда, скажем, вычисления для симуляции одного дня на фабрике занимают даже больше 24 часов при использовании однопоточной процессорной реализации. Мне же нужно симулировать 200-300 дней, делать много экспериментов с разными параметрами, так что параллельные вычисления мой единственный выход, и сейчас моя задача продумать грамотно дизайн этих вычислений.
Использовать кластер я пробовал. У меня был доступ к линукс-кластеру, где я проводил некоторые эксперименты. Но проблема в том, что вынуждено центральный нод кластера з программным обеспечениям для симуляции это Windows-машина. Для коммуникации и передачи данных пришлось использовать SSH и SCP протоколы, из-за этого возникал довольно большой overhead при параллельных вычислениях. Windows-кластера у меня нет, да и проблемы з общими данными и коммуникацией там, наверно, будут те же. Так что, доступ к памяти, я надеюсь, для меня будет скорее большим преимуществом, а не способом похоронить прирост производительности. Вот и думаю, как так и сделать.
На счет почти одинаковой роботы для параллельных нитей, не могли бы вы, пожалуйста, немного детальнее объяснить, что вы имеете в виду?
Выбор Tesla по сравнению с AMD из-за доступной и простой среды разработки. Да и перед тем как принимать такое решение, я перечитал множество статей про задачи, подобные моей. И некоторым уже получалось использовать GPU Computing на базе CUDA и получать даже очень хорошие результаты. Поэтому я и сделал такой выбор, теперь разбираюсь, как реализовать.
На счет double precision floating-point , то у меня все вычисления с числами з плавающей точкой, у меня нет почти целочисленных вычислений. Если я не правильно понял замечание, объясните мне, пожалуйста.
А Quadro, это, по сути, не имеет никакого значения, это самый дешевый Quadro, который мне понадобился только для видео-выхода. Какой поставили, такой и будет. И, простите за любопытство, почему вам же лучше будет из-за вливания денег в индустрию? :-)

Ерунда какая-то, должен при

Ерунда какая-то, должен при сомнениях капчу спрашивать.

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

Добавляю пост J0hn-а, чтобы

Добавляю пост J0hn-а, чтобы продолжить обсуждения.

Потенциал для оптимизации очень хороший и чем интеллектуальнее эвристики я использую, тем лучшие результаты, но дело иногда доходит к абсурду, когда, скажем, вычисления для симуляции одного дня на фабрике занимают даже больше 24 часов при использовании однопоточной процессорной реализации. Мне же нужно симулировать 200-300 дней, делать много экспериментов с разными параметрами, так что параллельные вычисления мой единственный выход, и сейчас моя задача продумать грамотно дизайн этих вычислений
Ок, хорошо - в этом случае действительно на мой взгляд попытка использования GPU целесообразна. Быть может вам придётся использовать и не одну GPU.

Использовать кластер я пробовал. У меня был доступ к линукс-кластеру, где я проводил некоторые эксперименты. Но проблема в том, что вынуждено центральный нод кластера з программным обеспечениям для симуляции это Windows-машина.
Я не понял смысл этих предложений. У вас есть проекты (исходный код+файлы сборки) только для Windows?

Для коммуникации и передачи данных пришлось использовать SSH и SCP протоколы, из-за этого возникал довольно большой overhead при параллельных вычислениях.
Ну всё зависит от объёма коммуникаций и от их структуры (да, я кэп). Для кластеров обычно используется MPI, для которого как я понял обычно работа с сетью достаточно оптимизированная.
Быстрый хинт для SSH/SCP - попробовать выключить сжатие (и если возможно шифрование - на счёт этого не уверен).

Так что, доступ к памяти, я надеюсь, для меня будет скорее большим преимуществом, а не способом похоронить прирост производительности
Я говорил о другом. А именно о том, что без продуманного использования памяти (которой на GPU несколько видов), получить значения мощности близкие хотя бы к 70% от пика - невозможно. Более того, для некоторых задач это невозможно в принципе.

Я вам советую "откинуться на спинку кресла" и посмотреть видео лекций Борескова: http://www.intuit.ru/video/59/ - там всего четыре часа. Информация там немного устаревшая, так как вышло новое железо - но в общем даёт неплохое поверхностное представление о технологии, и подводных камнях.

На счет почти одинаковой роботы для параллельных нитей, не могли бы вы, пожалуйста, немного детальнее объяснить, что вы имеете в виду?
Я имел ввиду то, что очень желательно, чтобы нити выполняли один и тот же код, причём находились на одних и тех же ветках выполнения.
То есть допустим есть задача суммирования двух векторов, псевдокод для GPU, для одной из возможных реализаций будет иметь вид:

  1. void threadCode(T *vecA,T *vecB,T *vecC)
  2. {
  3.     int i=getThreadID();
  4.     vecC[i]=vecA[i]+vecB[i];
  5. }

Где threadCode - это код который будет выполняться в одной нити.
Всё это конечно очень грубо, и ветвления возможны, и даже запуск совершенно разных кодов на одной GPU. Но опять же, желательно, чтобы все нити выполняли один и тот же код - иначе производительность сильно просядет.

Выбор Tesla по сравнению с AMD из-за доступной и простой среды разработки.
Да, у NVidia среда разработки намного лучше. Она намного лучше подходит для обучения.
Но тут несколько нюансов. Double GFlop's у AMD лучше, по крайней мере если сравнивать с GTX'ами.
Между Tesla и GTX'ами существенной разницей для описанной вами ситуации является опять же скорость Double GFlop's - у Tesla больше. Но, например Memory Bandwidth соответствующих моделей меньше у Tesla (даже при отключённом ECC), также я думаю что Single GFlop's у Tesla может быть меньше. Ещё не маловажный фактор это цена(особенно важно если использовать несколько карт).

На счет double precision floating-point , то у меня все вычисления с числами з плавающей точкой, у меня нет почти целочисленных вычислений. Если я не правильно понял замечание, объясните мне, пожалуйста.
Какие именно у вас числа с плавающей точкой? 32бита или 64бита?

И, простите за любопытство, почему вам же лучше будет из-за вливания денег в индустрию? :-)
Не, ну во-первых, от этого будет лучше любому IT'шнику. Например где бы было сейчас это GPGPU без вливаний средств геймеров?
Во-вторых я специализируюсь на визуализации и вычислениях/обработке данных (научных) (и стараюсь работать только в этих направлениях) - поэтому для меня развитие GPU вдвойне полезно.

P.S.:
To lexa: мне кажется на этот сайт напрашивается небольшой FAQ - так как некоторый Q, действительно FA.

Но тут несколько нюансов.

Забыл еще, хотя это самое важное:

Важный плюс NVidia заключается в куда большей распространенности (они в маркетинг и поддержку вложили гораздо больше). В результате, там всего больше:
- публикаций "как мы ускорили нашу задачу во много раз"
- готовых библиотек, как от NVidia, так и от сторонних разработчиков
- литературы

Как раз средства разработки почти одинаковые: OpenCL-отладчик у AMD появился, а все остальное и вовсе почти одинаковое. Ну может профайлер у NVidia получше, но и то - несильно.

Но тут несколько нюансов. Double GFlop's у AMD лучше, по крайней мере если сравнивать с GTX'ами.

Реальность такова, что эти гигафлопсы из AMD "легко" достать только программируя "графический" т.е. поточный шейдер. С OpenCL там ситуация заметно хуже и HD5870 на одном и том же OpenCL коде или несколько проигрывает NVidia GTX480 или немного выигрывает. Но не в два раза, как по формальным флопсам получается.

To lexa: мне кажется на этот сайт напрашивается небольшой FAQ - так как некоторый Q, действительно FA.
Да, идея правильная, хотя начать бы со списка этих Q, которые FA......

Ок, хорошо - в этом случае

Ок, хорошо - в этом случае действительно на мой взгляд попытка использования GPU целесообразна. Быть может вам придётся использовать и не одну GPU.
Пока что количество GPU ограничено количеством PCI-Ex, да и еще один Tesla будет денег стоит, система и так уже в кругленькую сумму обошлась. Посмотрим, как удастся загрузить и раскрыть потенциал одной Tesla, а там видно будет. Кроме того, как один из возможных будущих способов дополнительного повышения производительности, интересует идея Heterogeneous Computing. На мой взгляд, было бы интересно использовать также CPU. Но здесь надо будет очень аккуратно с памятью работать и минимизировать обмен данными между оперативной памятью и памятью GPU. Если есть какие-то мысли по этому поводу, буду благодарен.
Я не понял смысл этих предложений. У вас есть проекты (исходный код+файлы сборки) только для Windows?
Эх. Это печальная история. Проблема в том, что симуляция, сама по себе, довольно сложный процесс. Поэтому я вынужден использовать коммерческий симулятор, который есть только под Windows. У симулятора есть API, который позволяет прикрутить свои библиотеки, написанные на С++ (довольна большая часть кода уже есть). Все новые фичи приходиться реализовывать в этих библиотеках, учитывая особенности этого API. Отсюда много своих нюансов и проблем (например, невозможность нормального использования MPI с Linux-кластером). Но здесь это немного не по теме, от кластера решил отказаться в пользу CUDA. Вернёмся к ней.
Я вам советую "откинуться на спинку кресла" и посмотреть видео лекций Борескова:
Спасибо, у меня есть уже ети лекции, как раз вот на выходных собираюсь посмотреть. Пожалуй, лучше я сначала посмотрю, и может некоторые вопросы отпадут сами собой.
Какие именно у вас числа с плавающей точкой? 32бита или 64бита?
В основном использую double, то есть 8 байт. Но я не совсем понял, к чему это. Если сравнивать, например, умножение двух double и двух float, то на CPU понадобиться одинаковое время, насколько я знаю. На GPU по-другому?

В основном использую double,

В основном использую double, то есть 8 байт. Но я не совсем понял, к чему это. Если сравнивать, например, умножение двух double и двух float, то на CPU понадобиться одинаковое время, насколько я знаю. На GPU по-другому?

На CPU потребуется одинаковое время если вы сопроцессор (X87) используете. Но его уже никто не использует, используют SIMD (SSE, AVX). И на SIMD все просто - грубо говоря две векторные операции за такт, вектора - 128 бит. Т.е. или 4 double операции или 8 float за такт (на AVX вектора длиннее, а вот операций за такт пока меньше, поэтому получается хоть и быстрее, но не в разы, а принцип тот же).
Это не говоря о том, что на одно и то же количество данных нужно (для double) вдвое больше памяти, соответственно вдвое больше memory bandwidth при пересылке.

На GPU все не настолько прямолинейно:
AMD: HD5xxx: 5 float-юнитов объединяются, чтобы посчитать одно double. HD6xxx - 4 юнита. Соответственно, производительность на double: 1/5 или 1/4 от float.
NVidia Tesla (новые 2050, 2070, 2075): 1/2 производительности double относительно float. Это на простых вычислениях, а на sin/cos/exp - подозреваю что все сложнее.
NVidia Geforce GTX 4xx/5xx: 1/4 производительности double относительно float.
Предыдущие поколения NVidia. Я уже забыл и могу ошибиться, но по-моему 1/4 и 1/8 производительности на double относительно float для Tesla/Geforce

Для Geforce и AMD реальность еще сложнее: так как производительность вычислений double меньше чем 1/2 от float, а данных - ровно вдвое больше, то те алгоритмы, которые для float являются memory limited (по bandwidth или еше чему) - для double могут таковыми оказаться. Поэтому во многих случаях Tesla не вдвое быстрее чем Geforce на double. Язык сломаешь, пока объяснишь.....

"но дело иногда доходит к

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

А не пробовали для начала на четыре-шесть потоков разделить? Современные CPU - многоядерные ж.