Сравнение скорости Fluent на 1-2-3-4 ядрах и 32 и 64 битах.

[Игорь (Москва) 1]

Добрый день!

Разжился четырехядерным компом - решил поэкспериментировать.

Итак. Начальные условия.

Intel Core2Quad 2.4 ГГц

RAM 4Гб

Fluent 6.3.26

Задача: Ступенчатое концевое уплотнение турбины. 2D.

Level Cells Faces Nodes Partitions

0 167037 338133 171052 1

16 cell zones, 169 face zones.

Поставил на комп Win XP, Win XP x64, Vista x64.

На Win XP х64, 64-х битный Флюент почему-то не запустился. Выдал сразу же ошибку. На Висте - все ОК.

Засчекал время расчета 100 итераций (мин:сек), потому что неизвестно сколько нужно для сходимости - не моя задача.

Кол-во ядер | Vista 64 | Win XP 32

-------------------------------------------

1 | 4:50 | 5:10

2 | 2:53 | 2:55

3 | 2:08 | 2:13

4 | 1:52 | 1:56

______________________________

Таким образом видим, что использование 4-х ядер ускоряет процесс в 2.6 раз, трех в 2.27, двух - в 1.68.

Далее попробовал разогнать процессор - .

Частота, ГГц | Vista 64, 4 ядра.

---------------------------

2.4 | 1:52

3.0 | 1:44

3.13 | 1:39

___________________

Выводы и фантазии.

1. Два ядра гораздо лучше одного. А три существенно лучше двух. (Привет фирме АМД с их Phenom X3!)

2. 64-х битность заметно улучшает погоду тольrо на одноядерниках - надо учесть тем, кто не пересел на Core2.

3. Частота. 30% рост частоты приводит к уменьшению времени счета на 13%. Так что многоядерность нам важней чем частота.

Перспективы.

Любопытно посмотреть как что изменится при более тяжелых задачах, на больших сетках.

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

Вроде бы все.

Приветствуются комментарии, дололнения и т.п... :)

Изменено 26 января 2008 пользователем Игорь (Москва)

[digger 0]

64-битность нужна не для скорости а для больших задач (>4 ГБ, хотя это от бедности - на ядро эффективнее порядка 0.5ГБ).

Как изменится и т.п. - см. <noindex>http://www.fluent.com/software/fluent/fl5bench/index.htm</noindex> и <noindex>http://www.fluent.com/software/fluent/fl5bench/new.htm</noindex>

[Игорь (Москва) 1]

Да.... с 64-х битностью это разумеется основное. Правда у меня пока нет таких задач - поэтому сейчас был интересен именно скоростной аспект. И хотелось именно самому пощупать - ведь те машины которые описаны на сайте Флюента обычному человеку малодоступны. А сейчас уже нечто почти суперкомпьютерное :) можно собрать и у себя на столе.

Было описание интересной системы - четыре платы с двухядерными АМД закреплены на одной стойке. Соединены гигабитным ethernet. Получилась шустрая вещь. И наращиваемая. И ДЕШЕВАЯ!

С уважением,

Игорь

[a_schelyaev 366]

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

Где-то в сети валялись тесты по параллельной эфективности вычислений на камнях от Интела и АМД.

Оптерон с ростом количества ядер выше двух Зеона на лопатки кладет именно по указанной выше причине.

Поэтому пока на интелах лучше иметь два двухядерных компа. Это будет куда лучше, чем один четырехядерный.

Или на одной материнке два гнезда иметь, но только если они там не на одной шине сидят, как это у интела всегда раньше было.

[Ara 0]

Перспективы.

Любопытно посмотреть как что изменится при более тяжелых задачах, на больших сетках.

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

Чем больше размерность сетки, тем меньше (в процентах от общего количества) ячеек приходится на границы декомпозиционных блоков, тем эффективнее распараллеливание. Имеется даже некое исследование на эту тему. Я исследовал в том числе и свой код таким образом. Более того, во-первых, ядро можно считать отдельным процессором. Пробовал запускать задачу как на разных ядрах, так и на физически разных процессорах в пределах одного узла. Время счета не отличается. Во-вторых, на сетках высокой размерности передача данных занимает незначительное время по сравнению с объемом вычислений, то есть возможно использование низкоскоростной сети (Gigabit Ethernet) между узлами. В-третьих, значительное время занимает подготовка пересылок, ее имеет смысл посадить на отдельный процессор.

[Lektor 0]

Таким образом видим, что использование 4-х ядер ускоряет процесс в 2.6 раз, трех в 2.27, двух - в 1.68.

........

Приветствуются комментарии, дололнения и т.п... :)

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

При расчете на 2-х и более ядрах, затрачивается дополнительное кол-во итераций на сшивку решения.

К примеру если у меня на одном ядре сходимость 10-3 достигалась за 104 итерации, то на двух уже за 125, при этом выйгрыш по времени достигал 1.6

По поводу мнения Ara, передача данных и счет - операции чисто последовательные, поэтому чем больше пересылок, тем больше общее время задачи.