Опять про многопроцессорность....(сорри если уже )

[StreLOCK 0]

Суть такова...

UG NX 1.0

При обновлении чертежа на одной машине (Р4 2,8 МГц 1 ГБ памяти) обновление вида заняло 12 минут.

При обновлении этого-же вида на другой машине (Два Xeon`а 2,66 Мгц 2 Гб памяти,Hyper Treading включен, параметр UGII_SMP_ENABLE выставлен в 1) времени заняло 18 минут.

То бишь вместо предполагаемого прироста получили наоборот падение скорости.

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

В доках это официально заявлено, что дает прирост производительности при данном типе операций, но на деле не видно

Изменено 15 марта 2005 пользователем StreLOCK

[mr.Karapuz 2]

To: StreLOCK

1. Гипертрейдинг это не многопроцессорность. Это видимость двух процессоров (понт...).

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

Вывод: если ты уже озадачил проц какой либо задачей... усё больше никак того же самого не влезет. Более того на распределение расчетов по блокам на их идентификацию тоже требуются ресурсы, а так как CAD не относится к потоковым данным, то и тип задач постоянно меняется от сюда понижение производительности что то около 15% (читал на каком то сайте непомню где(просто поверьте)).

2. Пробовал вообще ставить два проца физически, результат тот же, на них пробовал ставить Гипертр. итого было 4 проца (вирт.) прироста теже -15%. Так что ИМХО HT непоможет CADу как ни крути.

[FFF 0]

To: StreLOCK

1. Гипертрейдинг это не многопроцессорность. Это видимость двух процессоров (понт...).

<{POST_SNAPBACK}>

НО StreLOCK говорил(а) именно о ДВУХ процессорах

Два Xeon`а 2,66 Мгц 2 Гб памяти,Hyper Treading включен

Что касается сути вопроса.

Так кроме наличия технических средств (ДВУХ и более процессоров) и сама программа должна быть заточена под многопроцессорность. чтобы она могла распараллеливать процессы. тогда операционная система может запустить эти процессы на разных процессорах. И тогда эти процессы выполняются одновременно, обеспечивая выигрыш времени. Но не всегда удается распараллелить. Поэтому выигрыш от многопроцессорности зависит от конкретной программы.

[StreLOCK 0]

НО StreLOCK говорил(а) именно о ДВУХ процессорах

Два Xeon`а 2,66 Мгц 2 Гб памяти,Hyper Treading включен

Что касается сути вопроса.

Так кроме наличия технических средств (ДВУХ и более процессоров) и сама программа должна быть заточена под многопроцессорность. чтобы она могла распараллеливать процессы. тогда операционная система может запустить эти процессы на разных процессорах. И тогда эти процессы выполняются одновременно, обеспечивая выигрыш времени. Но не всегда удается распараллелить. Поэтому выигрыш от многопроцессорности зависит от конкретной программы.

<{POST_SNAPBACK}>

Процов именно, два, а с НТ их стает четыре, но толку ноль что НТ, что без него одни и те же 18 минут, хотя UG официально заявляет что держит многопроцессорность, и во время обсчета исправно грузит все процы что есть хоть два (без НТ), хоть четрые (со включенным НТ).

[niki 0]

Судя по инфе с ugs.com заточены под SMP следующие операции :

1. Booleans. This can have a 0-15% improvement on modeling update.

The improvement really depends on the part.

2. Hidden Line Rendering. This has a 5-15% improvement on both

generating a modeling HLR representation (MB3->Display->Hidden Line),

and bringing up a Hidden line view on a drawing. Bringing up a single

Hidden line view on a drawing shows the most improvement.

3. Mass Properties. This will have a 20-40% improvement. The

algorithm is well suited to multiprocessors, unfortunately is not a

commonly used function.

4. Silhouette generation. This will have a 5-10% improvement in

generation a display with silhouettes turned on.

Regardzzz ...

[mif 1]

Шобы 2 проца заработали для одной проги конечно нужно чтобы об этом АДЕКВАТНО позаботились программеры писавшие эту прогу. Вобще мне, с точки зрения программера, эта задачка представляется не очень простой. Это нужно реализовать по крайней мере 2 алгоритма для каждой операции, которую имеет смысл распределять: обычный алгоритм, и алгоритм распараллеливания задачи, или просто алгоритм с двухпоточного выполнения задачи... и желательно с эффективным распределением. И, скорее всего, далекго не все можно распаралелить. Многие алгоритмы по сути своей последовательны. Отсюда выходит, что теоретически, в том же самом UG, могут оказаться распределенными лишь некоторые операции, причем эффективность распределения может кабелиться от 0 до 90%, а большая часть задач, я думаю, от 0 до 30%. Насколько операцию "обновления вида" реально распределить (и насколько актуальна такая попытка) судить знающим UG и, конечно программерам в первую очередь.

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

А ксеоны видимо проигрывают из-за частоты шины. Тот проц что 2,8ГГц нибось с 800 МHz шиной. Таким образом прослеживается почти прямая зависимость эффективности выполнения данной операции от пропускной способности шины проца, и, видимо, пропускной способности памяти .

[Nikolas 0]

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

[mr.Karapuz 2]

Вообще у меня впечатления от ксеонов только отрицательные . Соотношение цена производительность просто никакое. Домашний AMD 3,2 хеон просто в клочья рвет.