Сравнение двух реализаций дотнета: Win7 64bit vs Mono 32bit

[Губанов Сергей Юрьевич]

Некоторые программы запущенные под 32 разрядной Mono 2.6.7 могут работать до пяти раз медленнее чем запущенные под 64 разрядной микрософтовской реализации в Windows 7

 

[Губанов Сергей Юрьевич]

Сейчас закончил измерение скорости работы узла логики нашей телефонной станции на Mono 64bit.

AMD.Linux.Mono = AMD Opteron 6172, 2100 MHz, 4*12=48 ядер. Debian, Mono 2.10.8.1 64bit(--with-large-heap=yes)

Intel.Windows = Intel Core i7 2600K, 3800 MHz, 4 ядра. Windows 7, Microsoft.Net 64bit

На 1'000'000 абонентах наша телефонная станция запущенная на Intel.Windows быстрее чем на AMD.Linux.Mono в 215 раз (4300 звонков в секунду против 20 звонков в секунду).

Mono - говно!

Пробовал сборщик мусора --gc=sgen, так с ним Mono ещё медленнее.

[Peter Almazov]

Может, AMD говно? 

[valexey_u]

На 1'000'000 абонентах наша телефонная станция запущенная на Intel.Windows быстрее чем на AMD.Linux.Mono в 215 раз (4300 звонков в секунду против 20 звонков в секунду).

Mono - говно!

Пробовал сборщик мусора --gc=sgen, так с ним Mono ещё медленнее.

Либо вы в качестве девелоперской платформы имеете не mono, а .net, а в качестве компилятора и среды разработки, не компилятор моновский, а MSVS. Cоответственно невольная заточка идет именно под специфику .net'а а не mono ;-)

Какой-нибудь ISO/IEC 23271:2012, насколько я понимаю, обещает корректность исполнения, а не быстродействие. Если нужна скорость, то всегда нужно пилить под конкретную реализацию VM (постоянно) под конкретной ОС и на конкретной архитектуре процессора/памяти. Иначе можно ВНЕЗАПНО обнаружить что на целевой платформе быстродействие ниже ожидаемого на порядки.
Это справедливо в общем то для любых языков.

[Губанов Сергей Юрьевич]

Может, AMD говно? 

Да, в данном случае процессор AMD медленнее Intel примерно в 4 раза. Остальные 54 раза - Mono.

[valexey_u]

Может, AMD говно? 

Да, в данном случае процессор AMD медленнее Intel примерно в 4 раза. Остальные 54 раза - Mono.

А точно не линукс? ;-) И точно не из за какого-нибудь кеша?
Где именно просадка производительности?

То есть это может быть тормозная VM, это может быть кривость сгенеренного jit'ом кода (кстати, а у вас там точно не в режиме интерпретации все работает?) для конкретно amd, это может быть тормозная реализация одной из стандартных библиотек, это может быть проблема с тем, что у вас из за чего-то часто дергается syscall который исполняется ясное дело ме-едленно да еще и инвалидирует процессорный кеш.

Причем в разных ОС грабли с медленными стандартными функциями разложены в разных местах. Одна и та же функция из стандартной либе на одной системе может дергать syscall, а на другой (или в другой реализации) обходиться без syscall'а вообще.

Тонкостей уйма. Но все можно конечно свести к простым двум исходам:
1) monoLinuxAmd говно.
2) ваше прога говно (хорошая работа под виндузами не доказывает что оно не говно). :-)

Кстати, как ваша прога работает под monoWindowsIntel?

[Губанов Сергей Юрьевич]

Cоответственно невольная заточка идет именно под специфику .net'а а не mono ;-)

Заточка IL кода? Это как?

[valexey_u]

Cоответственно невольная заточка идет именно под специфику .net'а а не mono ;-)

Заточка IL кода? Это как?

А это легко. Оптимизации проведенные компилятором в IL могут привести к тому, что jit VM не сможет провести свои оптимизации, ибо IL-код уже не подпадает под нужные паттерны. Поэтому желательно чтобы компилятор и VM были от одного и того же вендора.

[Губанов Сергей Юрьевич]

А точно не линукс? ;-) И точно не из за какого-нибудь кеша? Где именно просадка производительности?

А везде ровным слоем. Когда просадка производительности идёт везде ровным слоем это обычно означает просадку в сборщике мусора. Он в случайные моменты времени останавливает программу и в среднем замедляются все процедуры. При миллионе абонентов очень много объектов в памяти. Микрософтовский сборщик мусора с ними ещё справляется, а моновский - уже нет.

Кстати, при 3'000'000 абонентах разница в производительности стремится к бесконечности. Программа под Mono только и делает, что собирает мусор (останавливается на 8-12 секунд).

[Губанов Сергей Юрьевич]

В моне есть такая фича, она может вместо своего jit компилятора использовать кодогенератор LLVM:

http://www.mono-project.com/Mono_LLVM

Начать копать в этом направлении что ли...

Хотя, если затык в мусоре, то едва ли не поможет.

[valexey_u]

А точно не линукс? ;-) И точно не из за какого-нибудь кеша? Где именно просадка производительности?

А везде ровным слоем. Когда просадка производительности идёт везде ровным слоем это обычно означает просадку в сборщике мусора.

Или в промахах кеша, или в тормозном VM или в тормозном сгенерированном jit'ом коде :-) Но если нагрузка зависит не линейно от числа абонентов, то это скорее всего что-то с менеджментом памяти таки. Но не обязательно GC.

Кстати, при 3'000'000 абонентах разница в производительности стремится к бесконечности. Программа под Mono только и делает, что собирает мусор (останавливается на 8-12 секунд).

Линух точно не начинает свопиться? Ибо в случае свопинга в линуксах становится сразу о-очень печально (в нормальном состоянии, пока ОЗУ не кончилось, линукс свопиться не будет, у них с виндой разные политики на этот счет).

[Губанов Сергей Юрьевич]

то едва ли не поможет.

то едва ли поможет

[Geniepro]

ДотНет тоже та ещё какашка. Буквально сегодня обнаружил, что одна и та же простенькая программка с 7-ю потоками по разному нагружает процессор -- на винде-хр или 7 нагрузка низкая, а на винде сервере 2003 -- до 99% подскакивает...

[Губанов Сергей Юрьевич]

на винде-хр или 7 нагрузка низкая, а на винде сервере 2003 -- до 99% подскакивает

А скорость работы программы выше?

Наверное на сервере запускается серверный-очень-многопоточный сборщик мусора (если есть, скажем, 48 ядер, то это актуально), а на десктопе GC десктопный-малопоточный.

[Geniepro]

на винде-хр или 7 нагрузка низкая, а на винде сервере 2003 -- до 99% подскакивает

А скорость работы программы выше?

Наверное на сервере запускается серверный-очень-многопоточный сборщик мусора (если есть, скажем, 48 ядер, то это актуально), а на десктопе GC десктопный-малопоточный.

Скорость работы у неё замерять бессмысленно, так как она единственное что делает -- скачивает в несколько потоков по низкоскоростному интернет-каналу файлики с 7 компов. И вообще она тестовая -- проверяет надёжность WiMAX-интернет канала.
По идее она вообще не должна оказывать никакой нагрузки, так что нипанятно что она так нагружает процессор...