Мини FAQ <------
Linux SMP в VMWare за 7-мь простых шагов
Установка и настройка клиента в VMWare для счета -bigadv заданий на 8-ми ядерниках, (c) anubias
Использовать только VMWare Player или VirtualBox!

Исходное сообщение:
Подумал, что рационально завести тут на какое-то время - до появления нормального клиента SMP-Win, такую тему.

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

lеad
Я уже всё написал. Ты, для начала, попробуй. Всё работает. Последняя сборка - для больших жаб, конечно, может считать и обычные, но это уже - другая история.

Добавлено спустя 1 минуту 8 секунд:
anubias
Что не получилось?

А тогда какая версия плеера была? Свежий плеер 4 ядра держит безо всяких хитростей. В самом плеере открываешь вирт.машину и ставишь 4 процессора

Добавлено спустя 1 минуту 57 секунд:
Раньше на WS 6.5.х можно было использовать 4 ядра только с помощью модификации файла конфигурации вирт.машины. И работала эта хитрушка только на воркстейшне, а на плеере (без воркстейшна) - нет. Щас всё работает без воркстейшна - проверено.

По-моему, какие-то надуманные проблемы. Lead ситему захламляет любая програмулька, никуда от этого не деться, такая система.

Fergity тогда была 6,но тут проблемы другого характера .
Мне больше нравится последняя сборка в отличие от Нотфреда
1.Автоматическая синхронизация времени.
2.Качает ядро только при первом запуске.
3.Считает сколько сдано жаб не зависмо от количества включений выключений.
4.может работать с 8 потоками на 4 ядрах.
опять темой ошибся один оффтоп.

Добавлено спустя 1 минуту 19 секунд:
Миша не стартовало у меня без WS

А я солидарен с Lead
По-моему - версия вмваре не причём (в первом приближении). Всё зависит от образа. Что чел. туда заложил, то и будет, а сама вирт. машина - это Ось в Оси и что там в ней будет крутиться - ей глубоко наплевать. Она должна обеспечить работу этого чего-то максимально прозрачно от основной Оси.

miklebat, anubias
плеер версии 2.5 снес - поэтому насчет работоспособности не могу сказать, а в версии 3.0 после "исправления" VMX файла по описанию Anubis'a все работает PPD показывает 3000 на частоте X4 @ 2300 (в это же время параллельно считается GPU клиент на 8800GTX)

Добавлено спустя 8 минут 3 секунды:
единственный момент - синхронизация времени меня смущает, ну и общее кол-во задавленных жаб хотелось бы знать

Что-то подкачал ipicture Придется перезалить иллюстрации
Вспомнил, что существует замечательный тест производительности TOC F@H BENCHMARK, спасибо команде Total OverClock
Итак:
Антивирь отключил. И прогнал тест TOC F@H Bench по одному разу в "нативной" семёрке и в виртуалке о восьми ядрах.
Настройки для теста:

• Тест: GROMACS 1 (+)
• Тип теста: производительность
• Число потоков: 8
• Увеличить приоритет: Да
• Без ограничений: Нет

Результаты:
"нативная" семёрка -- 3 386.3 ппд
семёрка в vmware --- 3 145.4 ппд
Итого соотношение производительности: +7.7% / -7.1%

Скриншоты:
#77 ... #77

Fergity
Самое главное, что нет в этом тесте - это SMP заданий. А Linux и VMWare именно для это ставят.

1. По сути СМП - это энное количество тех же громаксов, связанных между собой через интерфейс MPI. Наибольшую долю процессорного времени отнимают именно ядра, а подсистема MPI нагружает процессор крайне мало.
Так что громаксы из TOC F@H Bench похожи на СМП (в первом приближении, как говорит miklebat) и можно ожидать тех же результатов для СМП-клиента - ~7-8%
2. Как видно из моих экспериментов (будет виднее, когда я картинки перезалью ), падение производительности при использовании виртуальной машины разительно отличается для различных заданий: e.g. 5% в PerformanceTest и 15% в CINEBENCH. Это означает, падение производительности будет отличаться и для разных версий расчетных ядер СМП-клиента (как типов ядер: FahCore_a1, FaCore_a2, так и их версий).

Fergity

Она нагружать может мало, а потеря скорости будет большой.
Даже в Mac OSX и Linux Ubintu 9.04 за счет разной реализации MPI скорость различается существенно и не в пользу OSX.

Behc, мне кажется, что дело здесь не в MPI.
Я пытался подсовывать виндовому СМП разные варианты mpiexec:

• родной mpiexec.exe
• http://www.mcs.anl.gov/research/projects/mpich2/
• Intel® MPI Library
• MS-MPI

Особой разницы не почувствал. Впрочем как и сам клиент. Не смотря на то, что бинарный файл mpiexec.exe из состава различных пакетов значительно варьировался по размеру, смп-клиент хавал его за милую душу а ппд сохранялся прежним как мировая константа
Имхо, всё дело в расчетных ядрах FahCore...

Fergity
Не в MPI (неправильно сформулировал), а в межядерном взаимодействии в самой системе.
Ядра a0, a1, a2 под все системы одинаковые, компиляция, возможно, только разная.

Например, a2 под винду нет
Второй пример: виндовый смп-клиент работает только в четыре потока, а линуксовый хоть в 4, хоть в 11... Даже если руками заставить ВинСМП считать в 8 потоков, клиент быстро выплевывает UNKNOWN_ERROR так что разные ядра.

Впервые получаю обрезок бигжабы интересно помрет,али нет

решил попробовать запустить SMP на VW .Система 7 х64
#77
Login ввел а дальше никак.ЧНЯД?

brother225 дальше fah1234 но это не будет отображаться погляди тут внизу страницы.

anubias
спасибо .супер! как все оказалось просто.Даже что-то считать начал #77

brother225
Что за проц?

FreecitizenQ9400@3600,можно еще немного добавить.Сейчас читаю и пытаюсь найти путь для FahSpy.

brother225
через что выходишь в инет?
А проще остановить и запустить заново и в этот раз запомнить IP

Добавлено спустя 22 минуты 10 секунд:
\\10.248.62.220\fah посмоти скрин из первого своего поста.
http://i025...radikal.ru/1001/fe/7b9dd0d5c0df.jpg