Проблемы работы программ в среде mono в linux

[Warlornhor]

Тест написанный на Java работает примерно также быстро как и QT вариант, с AA---6сек, без AA---3сек. Проблема определенно не в X'ах (IMHO), все таки .NET приложения (или как там правильно их назвать) будут работать быстро только под виндовсом, возможно это интересный коммерческий ход.

[kamre]

Тест написанный на Java работает примерно также быстро как и QT вариант, с AA---6сек, без AA---3сек.

У меня примерно такие же результаты как в Qt, более подробно напишу как до дома доберусь уже и потестирую в Win/Lin.
А меняются результаты, если под линуксом запускать java вариант так:

Код: Выделить всё

java -Dsun.java2d.opengl=True -jar jpoints.jar

?

[Warlornhor]

Тест написанный на Java работает примерно также быстро как и QT вариант, с AA---6сек, без AA---3сек.

У меня примерно такие же результаты как в Qt, более подробно напишу как до дома доберусь уже и потестирую в Win/Lin.
А меняются результаты, если под линуксом запускать java вариант так:

Код: Выделить всё

java -Dsun.java2d.opengl=True -jar jpoints.jar

?

Нет, не меняются.

[v567]

Тест написанный на Java работает примерно также быстро как и QT вариант, с AA---6сек, без AA---3сек. Проблема определенно не в X'ах (IMHO), все таки .NET приложения (или как там правильно их назвать) будут работать быстро только под виндовсом, возможно это интересный коммерческий ход.

Взял тест на JAVA, изменив строку:

if (Math.abs(sm) < 15.0 * Math.PI) {

на:

if (Math.abs(sm) < 30.0 * Math.PI) {

для того, чтобы увеличить общее время выполнения теста. Сглаживание не включал.
Результаты:
XP - 8.8 сек, OpenSUSE 11.1 - 19.9 сек.
Больше, чем в два раза.

Вам, Warlornhor, как бы уже неоднократно говорили, что все тесты (.NET, JAVA, QT) идут не в пользу X Window. Пора бы уже признать, что X Window уже давно состарилась и её пора переработать для того, чтобы linux мог развиваться.

А насчет .NET думаю, что это скорее досадная ошибка, чем какие-то злодейские происки.

[kamre]

Поставил я значит новейшую openSUSE и видеодрайвера через single click с wiki на новый компьютер (Intel E8400 Nvidia 9800gtx+). Прогнал тесты и вот такие результаты получились:

тест с отрисовкой точек (время в секундах):

Код: Выделить всё

           OpenSuse  WinXP
Qt NoAA      3.8      1.2
Qt AA       10.5      2.3
GLQt NoAA    2.0      1.0
GLQt AA      1.8      1.0
Java NoAA    1.4      1.8
Java AA      2.5      2.6

Т.к. в линуксе по умолчанию не включена вертикальная синхронизация для opengl, то я ее и в винде также выключил при тестировании. И в висте она также должна быть включена по умолчанию. Так что тот товарищ выше, тестировавший на висте, по вполне понятным причинам получил такой медленный результат.

тест qgears2 (результаты в FPS):

Код: Выделить всё

           OpenSuse  WinXP
image         87      145
render        43      160
opengl       600      850

Этот тест уже гораздо сложнее чем тест с точками, здесь много разных графических операций используется. И сразу заметно, что в линуксе графика работает хуже.
Но самый фэил в этих результатах это то, что в линуксе Qt render (отрисовка непосредственно через X по протоколу) в 2 раза уступает Qt image (рендеринг полность на CPU и блиттинг картинки). Вот это и есть кривая архитектура X-ов. Такого быть не должно, т.к. при Qt render задействуются ресурсы видеокарты (хотя и не на полную мощь как через opengl). Еще можно заметить, что даже блиттинг картинок в X-ах работает раза в полтора медленее, чем в WinXP (предполагаем, что gcc в openSUSE не хуже MSVC2008 и рендеринг картинки на CPU примерно одинаковое время занимает).

[Full Null]

Если можно, то укажите скорость работы теста (с ZedGraph) как в linux, так и в windows, а также характеристики Ваших ПК и версию Mono и Linux (например так, как это сделано у меня). Это позволит провести хоть какое-то сравнение.

282 сек, причём заметил, что первая часть графика прорисовывалась намного быстрее, дальше всё медленнее и медленнее...
Intel core2duo 1.86Ghz, 4Gb RAM, NVIDIA 8800GT (driver 180.51), kernel 2.6.30-rc3, Mono 2.4, Arch Linux x86_64
В windows проверить нет возможности

И еще одна просьба: укажите был ли Mono установлен по умолчанию или пришлось его ставить. Если пришлось ставить, то каким образом (по сети или на дисках болтался).

Ставил, из репозитория archlinux

[v567]

282 сек, причём заметил, что первая часть графика прорисовывалась намного быстрее, дальше всё медленнее и медленнее...
Intel core2duo 1.86Ghz, 4Gb RAM, NVIDIA 8800GT (driver 180.51), kernel 2.6.30-rc3, Mono 2.4, Arch Linux x86_64
В windows проверить нет возможности

И на том спасибо.
А по поводу замедления ранее уже говорилось:

По аналогии со стандартным компонентом Delphi TChart, ZedGraph имеет очень неприятное свойство: с каждым наносимым элементом (точка, линия и прочее) время перерисовки графика в целом увеличивается. Таким образом, чем больше нанесено элементов - тем больше время перерисовки.

Теперь об обращении на go-mono.com/forums.

Отправил сообщение с проблемами на go-mono.com/forums.

Некто Carlos Alberto переработал мое сообщение в виде "bug report" и отправил в службу novell:
https://bugzilla.novell.com/show_bug.cgi?id=498963
Там оно в настоящее и покоится мирным сном. Учитывая его номер "498963", есть опасения, что разрешится "отчет о жуке" весьма не скоро.

Ещё нацарапал письмецо всем разработчикам библиотеки libgdiplus, которых насчитывалось 10 человек (во главе с Мигелем). Вдруг ответят.

[v567]

Ещё нацарапал письмецо всем разработчикам библиотеки libgdiplus, которых насчитывалось 10 человек (во главе с Мигелем). Вдруг ответят.

Первым ответил сам Мигель:

Hello,
I ran the code in the profiler and it showed that 50% of the time is spent on our implementation of libgdiplus. I have not ran this with a native profiler to identify why it is so slow, you might want to do that.
Miguel

То есть, он запустил test.exe (тот, что с ZedGraph) и установил, что 50% времени отъедается их бибилиотекой libgdiplus. Ну а дальше, мол, мучайся сам.

[kamre]

Переписал тест "Fancy Gears" на .NET, т.е. теперь есть все три варианта Qt/Java/.NET Под виндой у меня .NET быстрее Java, но медленее Qt работает. Хотя там разброс в FPS не сильно большой, примерно 95-105-120. Попозже потестирую в mono под openSUSE и доложу результаты.

Сборку вроде под 2.0 сделал, но если что там и исходники есть.

[kamre]

Потестировал под mono в openSUSE (из репозитория ставил). Итоговые результаты (Frames Per Second):

Код: Выделить всё

           OpenSuse   WinXP
Qt image       87      145
Qt render      43      160
Qt opengl     600      850
Java           78      115
Java opengl   109      110
Mono/.NET      36      125

Моноподелие в линуксе тормозит зверски, отрисовывается все с рывками. Ну и кроссплатформенность Mono на лицо (Java себе такого не позволяет с графикой):

[v567]

Под виндой у меня .NET быстрее Java, но медленее Qt работает. Хотя там разброс в FPS не сильно большой, примерно 95-105-120.

Так и должно быть. В настоящее время скорость приложения под .NET выше чем под JAVA. Но разумеется будет ниже чем с использованием Qt. Код с использованием Qt компилится под каждую ось отдельно и содержит выполнимые инструкции. Ну а .NET и JAVA приходится использовать промежуточные инструкции, чтоб приложение работало без перекомпиляции на любой оси. На получение выполнимого кода средами .NET или JAVA естественно затрачивается дополнительное время.

[v567]

А под mono в XP не пробовали?

[kamre]

А под mono в XP не пробовали?

Попробовал вот это:

Код: Выделить всё

Mono JIT compiler version 2.4 (tarball)
Copyright (C) 2002-2008 Novell, Inc and Contributors. www.mono-project.com
        TLS:           normal
        GC:            Included Boehm (with typed GC)
        SIGSEGV:       normal
        Notification:  Thread + polling
        Architecture:  x86
        Disabled:      none

Так оно вообще "аццки" тормозит и больше 11 FPS не показывает. Хотя рисует все правильно, без косяков как в линуксе.
Запускал в "Mono-2.4 Command Prompt" через "mono SharpGears.exe".

[v567]

Так оно вообще "аццки" тормозит и больше 11 FPS не показывает.
Запускал в "Mono-2.4 Command Prompt" через "mono SharpGears.exe".

Там по-другому никак не запустить, только через командную строку.
Удивительно другое. Получается, что mono на Вашем пк показал результаты: в xp 11 fps, а в opensuse 36 fps. Т.е. mono в opensuse отработал в 3 раза шустрее, чем в xp.
Мой же тест (с zedgraph) показал другие результаты для mono: в xp 7.7 сек, в opensuse 494.2 сек. Т.е. mono в opensuse отработал в 64 раза медленнее, чем в xp!!!
Следовательно, получены противоречивые данные.
Сейчас на мобилке. Как доберусь до компа посмотрю Ваш тест на своем пк.

[v567]

Результаты на моем компе:
1. XP .Net Framework 2.0 - 56 fps
2. XP mono 2.4 - 7 fps
3. OpenSUSE 11.1 mono 2.4 - 14 fps
В этом тесте задействуются графические области и операции с ними: изменение размеров, повороты, перемещения и т.д.
До сих пор не понятно почему мой тест с zedgraph показывал совершенно иные результаты. Очевидно mono одни графические операции выполняет быстрее в windows, чем в linux, другие наоборот. Возможно linux в операциях с графическими областями все же выручает использование cairo.
Остается признать, что в настоящее время проект mono хоть и работает без глюков, но его производительность заставляет желать намного лучшего (не знаю как в mac, но в win и в lin точно). Думаю в новых версиях все изменится к лучшему, проект еще молодой.
Стабильно пока работает .Net Framework, но он существует только для windows.

[yaleks]

Стабильно пока работает .Net Framework, но он существует только для windows.

Очень многозначительный вывод. Вы ещё WINE/ReactOS по сравнению с XP потестируйте.
Есть оригинальные разработчики, и есть реализация сторонним коллективом (по неполным/ошибочным спецификациям), которому доступно меньше информации и работать они начали позже.

Если вас что-то не устраивает, то ждите когда полностью запустят хотя-бы Paint.NET и начнут заниматься оптимизацией производительности. Или проверьте насколько хорошо работает http://appdb.winehq.org/objectManager.php?...on&iId=2586

[kamre]

До сих пор не понятно почему мой тест с zedgraph показывал совершенно иные результаты. Очевидно mono одни графические операции выполняет быстрее в windows, чем в linux, другие наоборот. Возможно linux в операциях с графическими областями все же выручает использование cairo.

Все-таки у вас в том тесте похоже только целочисленные координаты для отрисовки графики используются и достаточно примитивные операции. С другой стороны совершенно непонятно, что могло помешать разработчикам Mono нормально использовать GDI+ под виндой для отрисовки векторной графики (как это сам .NET делает) кроме "кривизны рук".

Остается признать, что в настоящее время проект mono хоть и работает без глюков, но его производительность заставляет желать намного лучшего (не знаю как в mac, но в win и в lin точно).

Да где уж там без глюков, вы вон выше посмотрите как он отрисовывает под линуксом. Такое ощущение что они вообще не тестировали отрисовку векторной графики на совместимость с .NET. А вот 36 fps под линуксом вполне объясняется тем, что сам Mono дает небольшой overhead (по сравнению с 43 fps в Qt render) и все упирается в корявые X-ы, из-за которых все так и тормозит.

[fynjy]

sharpGears 10-12 fps (описание тачки выше).

v567 Из кроссплатформенного здесь только mono, .Net никогда не будет кроссплатформенным (ну если считать различные версии версии винды различными платформами, только). Насчёт графики в вашем zedgraph: при добавлении точки к графику, в идеале, должна отрисовываться только эта самая точка и больше ничего (при условии что размер окна не изменился и никакая область окна не была затёрта другим приложением). Для чего я вас просил сделать примитивный тест? Надо было оценить скорость отрисовки отдельной точки. Дело в том, что если точка при изменении графика в zedgraph отрисовывается на порядки дольше примитива это означает, что библиотека при рисовании выполняет огромное количество никому не нужных действий. Я не ставлю под вопрос насыщенность библиотеки функциями, да оно может быть очень функционально, но реализация графического вывода, скорее всего, не учитывает существование тормозных устройств (вот она замечательная кроссплатформенность аля винда). Вы можете сколь угодно долго плакаться о дерьмовой реализации графики в иксах, но ваша прога от этого быстрее работать не будет. Пути три: или вы помогаете mono (речь о .Net не идёт, поскольку кроссплатформенным он не будет никогда, да и закрыто), или допиливаете zedgraph в плане отрисовки графики (благо сырцы открыты), или вы просто забиваете на это дело мотивируя тем, что продать прогу под линь не удаться поскольку целевая аудитория использующая данную ось слишком мала да и работает тормозно (тогда собственно где обещанная, спрашивает начальство, кроссплатформенность? Но я думаю вопрос можно как нибудь замять, мотивируя тем что кроссплатформенность от микрософт всего лишь маркетинговый ход и включает только разные версии виндовс, а мы млин попались...).

[mikluxo]

Minor development
# X server backtraces could potentially be more useful. glibc's backtrace() isn't great. Maybe fork() gdb? Maybe link against libelf and walk the the symbols ourselves?
#

XAA is lacking. See ExaStatus for status on the replacement.
# Input properties are a lovely hammer, but they need some standardization for things like pointer acceleration.
# X server protocol dispatch is still handwritten. We should generate it from xcb-proto instead.
# Extend shadow to be something you can have per-drawable instead of per-screen.
# Loader: Remove the abstraction from the loader (hw/xfree86/loader) so it's just a simple libdl wrapper with the same API, and punt it up to the DIX, so all DDXes can use it.
#

Remove statics: Make MAXSCREENS and MAXFORMATS run-time configurable, ditto MAXCLIENTS. ajax started a patch for MAXFORMATS, bother him about it.
# Code removal: Remove anything that's unused and/or bad.
# Port the int10 code to libx86. mjg59 and vignatti had started on this (from opposite ends).
# Build the "X server awesome scheduler":

* What we want is simple: a preemptive scheduler with priorities (real-time scheduler) to deal with multiple clients and with a special care for input events.

One interesting thing to considerer is that the issue of long-lived requests is mostly a thing of the past. PolyLines are not that common, fonts are mostly client side, and OpenGL is usually client-side as well due to DRI. Moreover, clients can block each other. Just try to execute a x11perf -getimagexy500 plus play a video to see. x11perf eats all the X process. Isn't wiser to give a tiny quantum here for each client? The funny thing is that -dumbSched gives a better result than with the _smart_ scheduler :) So simultaneous client requests aren't dealt by smart scheduler at all. This is quite interesting for those who is trying to start in the X world because it doesn't touch much of the graphics oddities :)

http://www.x.org/wiki/ToDo
http://en.wikipedia.org/wiki/XFree86_Accel...on_Architecture

Ну иксы зря скидывать со счетов. Вроде XAA собираются улучшать(ссылки выше). Хотя да, моно еще несколько сыроват.

[yaleks]

Ну иксы зря скидывать со счетов. Вроде XAA собираются улучшать(ссылки выше). Хотя да, моно еще несколько сыроват.

XAA мёртв. http://www.opennet.ru/opennews/art.shtml?num=21518

[mikluxo]

XAA мёртв. http://www.opennet.ru/opennews/art.shtml?num=21518

Мда, не внимательно прочитал. Там на EXA хотят поменять.
Не знаю как у Вас ребята, а у меня
mono SharpGears.exe под линем
100 frames 16867.77ms = 5.93 FPS
после того, как в /etc/xorg.conf добавил

Код: Выделить всё

Option "AccelMethod" "XAA"

в принципе так же при

Код: Выделить всё

Option "AccelMethod" "EXA"

стало быстрее рисоваться(без глюков, почти)
100 fr 12218.65 ms = 8.93 FPS
Сейчас попробую с .dll

[kamre]

стало быстрее рисоваться(без глюков, почти)
100 fr 12218.65 ms = 8.93 FPS

Что у вас за железо?

Я еще на EeePC901 в WinXP запустил .NET вариант - 30 fps. И это на каком-то нетбуке со слабым железом. В то время как Mono в линукс на не самой плохой видеокарте (NVIDIA 9800gtx+) с драйверами от производителя и процессором куда быстрее чем Intel Atom показывает 36 fps и рисует криво.

Кто там у нас специалист по "засчитыванию сливов"? Засчитывайте уже

[v567]

Очень многозначительный вывод.

Спасибо.

Вы ещё WINE/ReactOS по сравнению с XP потестируйте.

Не относится к теме и мне неинтересно.

Есть оригинальные разработчики, и есть реализация сторонним коллективом (по неполным/ошибочным спецификациям), которому доступно меньше информации и работать они начали позже.

Хотел бы согласиться, но как посещаю mono-project.com, так читаю следующее:

Run your applications...
.NET .Winforms
.ASP.NET .GTK
on all the platforms
.Linux .Mac .Windows

"Сторонний коллектив" как бы сам заявляет, что работает все и под все.

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

Этим и занимаюсь за неимением выбора.

Или проверьте насколько хорошо работает...

Проверю как-нибудь.

[mikluxo]

Я еще на EeePC901 в WinXP запустил .NET вариант - 30 fps. И это на каком-то нетбуке со слабым железом. В то время как Mono в линукс на не самой плохой видеокарте (NVIDIA 9800gtx+) с драйверами от производителя и процессором куда быстрее чем Intel Atom показывает 36 fps и рисует криво.

Могли бы и выше посмотреть
Intel Celeron 1.7 GeForce 4 MX 440 AGP 8 1024 + 256 MB.

Кто там у нас специалист по "засчитыванию сливов"? Засчитывайте уже

Это типа намек?

[upd]
1931 сек против 22** с копейками. Все равно не очень.

[v567]

Для fynjy.
Помочь mono могу только морально (проект неплохой). В Zedgraph лезть глупо, поскольку библиотека постоянно развивается и версии выходят одна за одной (получим в будущем несовместимость). Программа не для продажи.

[yaleks]

Мда, не внимательно прочитал. Там на EXA хотят поменять.

Уже даже не так если вам нужна быстрая 2D графика под Linux, то kernel 2.6.30, Xorg 1.6 и драйвера с поддержкой UXA (пока intel) будет то что нужно.
Nvidia предлагает 3D графику и с 2D там не всё хорошо (по крайней мере пока не завершится полный переход на отрисовку всего через OpenGL). Отчасти это реализуется cairo+glitz, но косяки в реализации GDI+ это конечно не убъёт.

[TuxWare]

Код: Выделить всё

           OpenSuse   WinXP
Qt render      43      160

Ничего не меняет, но все же на XP нет композита, потому с composite disable будет 80 вместо 43.

[fynjy]

v567, у каждого свой путь. Лично я не люблю чего либо ждать... Ну в общем, удачи...

[v567]

у каждого свой путь. Лично я не люблю чего либо ждать... Ну в общем, удачи...

Вы наверное философ, fynjy.

Но вернёмся к делам земным. Покопался в инете. Нашел интересную ссылку:
http://www.gotmono.com/cgi-bin/yabb/YaBB.pl?num=1169984052/0


Там значится следующее послание:

Jaakko YaBB Newbies
Performance issues when using ZedGraph in Mono. Jan 28th, 2007, 3:34am


Hello!
ZedGraph is a good charting class library for .NET. ZedGraph's website is http://zedgraph.org/.
ZedGraph is also mentioned in http://www.mono-project.com/Libraries#ZedGraph
I'm trying to use ZedGraph in Mono, but I have found out that performance is really poor. Execution time of my test program is about 20 seconds, while it's less than second in native Windows environment.
I have noticed same slowness with ZedGraph 4.5 and 5.0 (.NET 1 and .NET 2 versions) and with Mono 1.1.17.1 (Ubuntu x86 installation) and 1.2.2.1 (VMWare image from Mono-project).
My test program created this example chart: http://zedgraph.org/wiki/index.php?title=Multi-Y_Demo.
Sample programs in Mono's VMWare-image are fairly fast, so the Mono is working generally very well. The ZedGraph.DLL I was using was compiled binary from the ZedGraph project.
I ran Mono in profiling mode and noticed that most of the time is spent in /usr/lib/libgdiplus.so (85%).
Is this GDI+ library extremely slow? Is this ZedGraph slowness known issue? Am I doing something wrong? How on earth I could speed my ZedGraph&Mono?

В переводе примерно следующее:

ZedGraph - хорошая библиотека классов для графиков в .NET. Её сайт: http://zedgraph.org, она также упоминается на http://www.mono-project.com/Libraries#ZedGraph
Я пробовал использовать ZedGraph в Mono, но я обнаружил, что её выполнение действительно плохое. Время выполнения моей тестовой программы около 20 сек, в то время как в среде windows она выполняется меньше секунды. Я обратил внимание на аналогичную тормознутость с ZedGraph версий 4.5 и 5.0 (версии .NET 1 и .NET 2) и с Mono 1.1.17.1 (с установленной ubuntu x86) и 1.2.2.1 (образ VMWare из Mono-project). Моя тестовая программа создала этот пример графика:
http://zedgraph.org/wiki/index.php?title=Multi-Y_Demo.
Примеры программ в Mono в образах VMWare довольно быстрые, поэтому Mono работает очень хорошо. Я использовал ZedGraph.dll, которая была скомпилина в бинарник из проекта ZedGraph.
Я запускал Mono в режиме profiling и обратил внимание, что наибольшее время затрачивается /usr/lib/libgdiplus.so (85%).
Эта библиотека GDI+ крайне медленная? Это ZedGraph приводит к столь медленному результату? Я делаю что-то неправильно? Каким образом я мог бы ускорить мой ZedGraph и Mono?

Вопрос был задан на форуме gotmono 28 января 2007 года. Ответ до сих пор не последовал. Комментарии, как говорится, излишни. Бедный Jaakko наверное до сих пор так и не подозревает, что ни он, ни ZedGraph тут как бы не причем. Виноваты тормознутость X Window + сыроватость Mono.


А по той ссылке, которую он указал (http://www.mono-project.com/Libraries) о ZedGraph пишется следующее:

ZedGraph is a set of classes, written in C#, for creating 2D line and bar graphs of arbitrary datasets. The classes provide a high degree of flexibility -- almost every aspect of the graph can be user-modified. At the same time, usage of the classes is kept simple by providing default values for all of the graph attributes. The classes include code for choosing appropriate scale ranges and step sizes based on the range of data values being plotted. ZedGraph also includes a UserControl interface, allowing drag and drop editing within the Visual Studio forms editor, plus access from other languages such as C++ and VB. ZedGraph is licensed under the LGPL.

Т.е. поётся следующая песня:

ZedGraph - набор классов на C# для создания линий 2D и диаграмм произвольных данных. Классы обеспечивают высокую степень гибкости - почти каждый элемент графика может быть модифицирован юзером. В то же самое время, использование классов сохраняет простоту, обеспечивая значения по умлочанию для всех графических атрибутов. Классы включают код для выбора подходящих масштабных областей и размеров шага основанных на диапазонах значений данных, наносимых на график.
ZedGraph также включает интерфейс UserControl, допускающий drag and drop, редактируемый редактором форм Visual Studio + доступ из других языков (таких как C++ и VB). ZedGraph лицензирован под LGPL.

Так что, Ximina'у в купе с Novell'ом давным давно известна библиотека ZedGraph.

[yaleks]

Так что, Ximina'у в купе с Novell'ом давным давно известна библиотека ZedGraph.

Сравните с Проблемы работы программ в среде mono в linux . 85% -> 50% -- прогресс налицо.