Re: Linux and FreeBSD

From

Constantin Stefanov (2:5020/400)

To

Slawa Olhovchenkov (2:5054/37.63)

Date

2005-05-31T12:50:56Z

Area

RU.UNIX.BSD

From: Constantin Stefanov <cstef@mail.ru>

Slawa Olhovchenkov wrote:
>  >> А это не учитывается?
>  CS> А такие скачки просто нельзя учесть. Ведь прикладную программу пишут на
>  CS> уровне выше ethernet - обычно MPI. Там еще оверхеда накрутят (сначала
>  CS> сам MPI, потом TCP, IP, и только потом ethernet). И какой будет размер
>  CS> этих заголовков, зависит как минимум от реализации MPI, а она не
>  CS> единственная. Вот и получится, что такие провалы учесть просто нельзя.
> 
> Да ладно, насколько я издали вижу этих расчетчиков -- они учитывают и
> выравнивание на параграф и попадание в кэши. Условная компиляция на оптимальный
> размер пакета не такая и сложная вещь на этом фоне.
Нет, кончено, не очень сложная. Но: выравнивание на размер параграфа и 
т.п. определяется кодом самой расчетной системы. А оверхед в пакетах 
определяется той реализацией MPI, с которой задачу будет линковать 
конечный пользователь. А в момент написания программы (да и компиляции 
порой) версия этой библиотеки просто неизвестна. А если даже 
пользователь и будет компилировать программу, в стандарте MPI на 
заложено механизма получения такой информации.

>  CS> Итого. Использование другого интерконнекта дает вполне себе ощутимый
>  CS> рост эффективности вычислительной установки (до 20%), особенно заметный
>  CS> на больших установках. Это при том, что модельная задача имеет неплохие
>  CS> коммуникационные свойства.
>  CS> Вот тебе и первое приближение ответа.
> 
> Теперь делаем второе приближение -- смотрим на системы с myrinet. Видим
> эффективность порядка 61%. Рабочая гипотеза: важна не технология, а скорость
> передачи (10 у infi, 2 у мури и 1 у GE. Систем с 2xGE слишком мало, а с 10GE
> вообще нету).
Да, на LinPack (той самой тестовой задаче) это в большой степени так - у 
нее хорошие коммуникационные свойства. Есть другие классы задач, где 
бегает много мелких пакетиков, и где пропускная способность отходит на 
второй план - там важны именно задержки. И тут мы получим совсем другие 
соотношения.

> К сожалению мне не удалось найти систем, построенных на аналогичном
> оборудовании. Возможно еще и собственно построитель играет роль (кривые-прямые
> руки АКА систематическая ошибка).
> 
> Кстати, на скоростях 10G начинает сказываться проблема с попускной способностью
> PCI-X.
Именно поэтому компания mellanox (производитель существенной части 
оборудования InfiniBand приводит в качестве пиковых результаты, 
полученные на PCI Express). Кстати, на 10G Ethernet точно также упрешься 
в это ограничение.

-- 
Константин Стефанов
--- ifmail v.2.15dev5.3
 * Origin: Demos online service (2:5020/400)
SEEN-BY: 46/50 50/203 520 400/814 450/159 186 247 1024 451/30 461/43 132 640
SEEN-BY: 469/999 550/196 4616/3 4625/8 4627/10 4635/4 4652/15 5000/76 5000
SEEN-BY: 5006/1 5007/1 5010/70 5011/13 5015/10 5019/31 5020/52 118 154 175 194
SEEN-BY: 5020/400 545 549 604 715 758 830 937 1057 1523 1604 1630 1922 2020
SEEN-BY: 5020/2142 2238 2450 2590 4441 5021/29 5022/128 5025/3 750 5026/45
SEEN-BY: 5027/16 5029/32 5030/49 115 473 500 556 966 1063 1900 5031/70 72
SEEN-BY: 5034/13 5035/3 38 5036/1 34 5042/13 5049/1 50 97 5051/15 5054/1 4 8 9
SEEN-BY: 5054/28 35 36 37 63 66 67 70 75 81 84 85 5055/95 5057/1 5060/88
SEEN-BY: 5061/15 120 5062/1 10 5063/3 5066/18 5067/2 5069/7 5070/1222 5074/9
SEEN-BY: 5075/5 35 5079/23 5080/80 1003 5081/2 5082/6 5083/21 5085/13 5090/108
SEEN-BY: 5095/20 5096/18 6000/12 254 6001/3 10

PATH: 5020/400 4441 545 5054/1 37