Oberon space
General Category => Общий раздел => Тема начата: Губанов Сергей Юрьевич от Май 03, 2012, 03:28:23 pm
-
Некоторые программы запущенные под 32 разрядной Mono 2.6.7 могут работать до пяти раз медленнее чем запущенные под 64 разрядной микрософтовской реализации в Windows 7
:o :o :o
(http://sergeygubanov.narod.ru/Windows_7_64bit_vs_Linux_Mono_2.6.7_32bit.png)
-
Сейчас закончил измерение скорости работы узла логики нашей телефонной станции на 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 ещё медленнее.
-
Может, AMD говно? ;)
-
На 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.
-
Может, AMD говно? ;)
Да, в данном случае процессор AMD медленнее Intel примерно в 4 раза. Остальные 54 раза - Mono.
А точно не линукс? ;-) И точно не из за какого-нибудь кеша?
Где именно просадка производительности?
То есть это может быть тормозная VM, это может быть кривость сгенеренного jit'ом кода (кстати, а у вас там точно не в режиме интерпретации все работает?) для конкретно amd, это может быть тормозная реализация одной из стандартных библиотек, это может быть проблема с тем, что у вас из за чего-то часто дергается syscall который исполняется ясное дело ме-едленно да еще и инвалидирует процессорный кеш.
Причем в разных ОС грабли с медленными стандартными функциями разложены в разных местах. Одна и та же функция из стандартной либе на одной системе может дергать syscall, а на другой (или в другой реализации) обходиться без syscall'а вообще.
Тонкостей уйма. Но все можно конечно свести к простым двум исходам:
1) monoLinuxAmd говно.
2) ваше прога говно (хорошая работа под виндузами не доказывает что оно не говно). :-)
Кстати, как ваша прога работает под monoWindowsIntel?
-
Cоответственно невольная заточка идет именно под специфику .net'а а не mono ;-)
Заточка IL кода? Это как?
-
Cоответственно невольная заточка идет именно под специфику .net'а а не mono ;-)
Заточка IL кода? Это как?
А это легко. Оптимизации проведенные компилятором в IL могут привести к тому, что jit VM не сможет провести свои оптимизации, ибо IL-код уже не подпадает под нужные паттерны. Поэтому желательно чтобы компилятор и VM были от одного и того же вендора.
-
А точно не линукс? ;-) И точно не из за какого-нибудь кеша? Где именно просадка производительности?
А везде ровным слоем. Когда просадка производительности идёт везде ровным слоем это обычно означает просадку в сборщике мусора. Он в случайные моменты времени останавливает программу и в среднем замедляются все процедуры. При миллионе абонентов очень много объектов в памяти. Микрософтовский сборщик мусора с ними ещё справляется, а моновский - уже нет.
Кстати, при 3'000'000 абонентах разница в производительности стремится к бесконечности. Программа под Mono только и делает, что собирает мусор (останавливается на 8-12 секунд).
-
В моне есть такая фича, она может вместо своего jit компилятора использовать кодогенератор LLVM:
http://www.mono-project.com/Mono_LLVM
Начать копать в этом направлении что ли...
Хотя, если затык в мусоре, то едва ли не поможет.
-
А точно не линукс? ;-) И точно не из за какого-нибудь кеша? Где именно просадка производительности?
А везде ровным слоем. Когда просадка производительности идёт везде ровным слоем это обычно означает просадку в сборщике мусора.
Или в промахах кеша, или в тормозном VM или в тормозном сгенерированном jit'ом коде :-) Но если нагрузка зависит не линейно от числа абонентов, то это скорее всего что-то с менеджментом памяти таки. Но не обязательно GC.
Кстати, при 3'000'000 абонентах разница в производительности стремится к бесконечности. Программа под Mono только и делает, что собирает мусор (останавливается на 8-12 секунд).
Линух точно не начинает свопиться? Ибо в случае свопинга в линуксах становится сразу о-очень печально (в нормальном состоянии, пока ОЗУ не кончилось, линукс свопиться не будет, у них с виндой разные политики на этот счет).
-
то едва ли не поможет.
то едва ли поможет
-
ДотНет тоже та ещё какашка. Буквально сегодня обнаружил, что одна и та же простенькая программка с 7-ю потоками по разному нагружает процессор -- на винде-хр или 7 нагрузка низкая, а на винде сервере 2003 -- до 99% подскакивает...
-
на винде-хр или 7 нагрузка низкая, а на винде сервере 2003 -- до 99% подскакивает
А скорость работы программы выше?
Наверное на сервере запускается серверный-очень-многопоточный сборщик мусора (если есть, скажем, 48 ядер, то это актуально), а на десктопе GC десктопный-малопоточный.
-
на винде-хр или 7 нагрузка низкая, а на винде сервере 2003 -- до 99% подскакивает
А скорость работы программы выше?
Наверное на сервере запускается серверный-очень-многопоточный сборщик мусора (если есть, скажем, 48 ядер, то это актуально), а на десктопе GC десктопный-малопоточный.
Скорость работы у неё замерять бессмысленно, так как она единственное что делает -- скачивает в несколько потоков по низкоскоростному интернет-каналу файлики с 7 компов. И вообще она тестовая -- проверяет надёжность WiMAX-интернет канала.
По идее она вообще не должна оказывать никакой нагрузки, так что нипанятно что она так нагружает процессор...
-
Пробовал Mono 3.0.1, 3.0.2. Там какой-то странный баг. Через TCP сокет на 127.0.0.1 сообщения пролазят примерно 4 раза в секунду. То есть блокирующая socket.Receive срабатывает так редко. Хотя с отправляющей стороны сокетный буфер заполнен.
Вернулся обратно на Mono 2.10.8.1 компилировал её с разными флагами, пробовал
./configure --with-large-heap=yes --enable-optimized=yes --enable-parallel-mark=yes
В результате добился того, что и в Mono 2.10.8.1 блокирующий socket.Receive тоже стал работать медленно. Почему не ясно. Как вернуть всё назад не знаю. Пробовал make uninstall, пробовал aptitude purge ~imono, затем ставил "чистую" - не помогает. :'(
-
А вам там обязательно использовать Моно? Может ну его нафиг? )
-
А вам там обязательно использовать Моно? Может ну его нафиг? )
Я тоже за Windows, осталось убедить клиентов. Фактор 54 выглядит убедительно...
-
В результате добился того, что и в Mono 2.10.8.1 блокирующий socket.Receive тоже стал работать медленно.
Получается, что каким-то макаром Mono запорола операционку. Блокирующий socket.Send/Receive выпоняется не чаще чем пару раз в секунду. Стирание-переустановка Mono не помогает :'( :'( :'(
-
А вам там обязательно использовать Моно? Может ну его нафиг? )
Я тоже за Windows, осталось убедить клиентов. Фактор 54 выглядит убедительно...
Не, клиенты скажут -- перепишите на С++ )))
-
Не, клиенты скажут -- перепишите на С++ )))
А в этом смысле. Ну это без меня. Я тогда на C# другую работу найду. Кстати, там 543 тысячи строчек C#, что, как бы, долго переписывать.
-
Кстати, там 543 тысячи строчек C#, что, как бы, долго переписывать.
:o Это что за монстр?
-
Не, клиенты скажут -- перепишите на С++ )))
А в этом смысле. Ну это без меня. Я тогда на C# другую работу найду. Кстати, там 543 тысячи строчек C#, что, как бы, долго переписывать.
Да там после переписки, наверное, будет 50к ;)
-
Не, клиенты скажут -- перепишите на С++ )))
А в этом смысле. Ну это без меня. Я тогда на C# другую работу найду. Кстати, там 543 тысячи строчек C#, что, как бы, долго переписывать.
Да там после переписки, наверное, будет 50к ;)
Особенно на C++. Например на плюсах не придется заморачиваться с ручным управлением памятью ;-)
-
:o Это что за монстр?
Это модуль логики пятого класса платформы РТУ (Российский Телефонный Узел) http://www.mfisoft.ru/products/voip/rtu
-
Например на плюсах не придется заморачиваться с ручным управлением памятью ;-)
Вне контекста звучит сногсшибательно, типа чёрное - это белое (для того кто не знает как я намучился прячя объекты от сборщика мусора).