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

[v567]

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

Некорректное сравнение по ряду причин:
- разные версии Linux, Mono, ZedGraph;
- разное железо пк;
- разные приложения с разной загрузкой графической системы.

Результаты работы теста с ZedGraph в режиме профайлера
(mono --profile=default:stat test.exe):

Результаты работы теста SharpGears в режиме профайлера
(mono --profile=default:stat SharpGears.exe):

Как видно из этих примеров, разный уровень загрузки графической системы даёт разную загрузку разделяемой библиотеки libgdiplus.so (test.exe - 58%, SharpGears - 65%).

Кому интересно, ниже представлены результаты работы теста с ZedGraph в режиме профайлера в более полном виде (mono --profile test.exe):

[kamre]

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

Вроде же XP умеет полупрозрачные окошки? Вон, можно даже через JavaFX запустить: http://www.javafx.com/samples/SwirlingSquares/index.html
Что имеется ввиду под композитом?

[v567]

Кстати еще один факт, говорящий не впользу того, что Xorg криво рисует, так это то, что под VMWARE(а рисуется тоже самое) прорисывается быстрей => отрисовка реализация моно под линукс кака.

Шутки ради поставил vmware workstation 6.5.2 под windows. Создал виртуальную машину с OpenSUSE 11.1 В результате тест с ZedGraph стал выполняться 400 сек (с чистой загрузкой OpenSUSE выполнялся 360 сек). Основную программу даже тестировать не стал - уж больно грустно и долго скрипел винт.

[v567]

В настоящее время жду появления ubuntu 9.04, где должен вроде как присутствовать mono 2.0.

Дождался. Поставил ubuntu 9.04. Лучше бы не ставил
Mono 2.2 вышла в январе, 2.4 - 1 апреля. Релиз убунты 9.04 состоялся 23 апреля. Т.е. Canonical знала о существовании и Mono 2.4 и Mono 2.2 Однако вопреки всякой логики ubuntu 9.04 имеет корявую Mono 2.0.1:

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

mono -V
Mono JIT compiler version 2.0.1 (tarball)
Copyright (C) 2002-2008 Novell, Inc and Contributors. www.mono-project.com
    TLS:           __thread
    GC:            Included Boehm (with typed GC)
    SIGSEGV:       altstack
    Notifications: epoll
    Architecture:  x86
    Disabled:      none

При этом даже имеющаяся Mono 2.0.1 криво поставлена (GTK'шные приложения запускаются, а winform'овские нет):

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

mono test.exe

** (test.exe:3627): WARNING **: The following assembly referenced from /home/v567/test.exe could not be loaded:
     Assembly:   System.Windows.Forms    (assemblyref_index=2)
     Version:    2.0.0.0
     Public Key: b77a5c561934e089
The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/home/v567/).

** (test.exe:3627): WARNING **: Could not load file or assembly 'System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies.

** (test.exe:3627): WARNING **: Missing method EnableVisualStyles in assembly /home/v567/test.exe,
type System.Windows.Forms.Application

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. File name: 'System.Windows.Forms, Version=2.0.0.0, Culture=neutral,  PublicKeyToken=b77a5c561934e089'

В репозитариях debian'а в настоящее время имеется лишь кое-как работающая версия Mono 2.0.1. Судя по-всему, Canonical не стала тяготиться раздумьями о своих пользователях и слямзила mono'вские deb-пакеты имеенно оттуда. И это при том, что исходники Mono 2.4 общедоступны и их можно взять в любой момент, например отсюда:
http://ftp.novell.com/pub/mono/sources-stable/

Наверное Canonical предпочла свалить проблемы установки Mono 2.4 из исходников на плечи своих пользователей, нежели заняться этим самой. Что-ж придется помучиться. Появлюсь и отпишу результаты теперь нескоро.

[pcodr]

При этом даже имеющаяся Mono 2.0.1 криво поставлена (GTK'шные приложения запускаются, а winform'овские нет):

apt-get install libmono-winforms2.0-cil
Делать вам чтоли нечего кроме как менять дистрибутивы один за другим? Как будто это что-то изменит относительно mono и вашей программы.

[v567]

Наверное Canonical предпочла свалить проблемы установки Mono 2.4 из исходников на плечи своих пользователей, нежели заняться этим самой. Что-ж придется помучиться. Появлюсь и отпишу результаты теперь нескоро.

Вот вроде и все
Сравнил работу тестов в ubuntu 9.04 и в opensuse 11.1. Ради чистоты эксперимента ни на одной из ОС проприетарных дров не ставил. Тесты запускал без дополнительных настроек ОС. Результаты работы в XP (mono) / OpenSUSE (gnome 2.24.1) / Ubuntu (gnome 2.26.1):
1. JPoints.jar - 2.8сек/6.5сек/3.24сек
2. SharpGears.exe - 56fps/21fps/26fps
3. test.exe (с zedgraph) - 7.7сек/578сек/3995сек
Сразу же вернул сусю обратно.

Делать вам чтоли нечего кроме как менять дистрибутивы один за другим? Как будто это что-то изменит относительно mono и вашей программы.

Практика - критерий истины. Зато теперь знаю, что лучше суси с mono никто не работает. Да и ставить под неё проще. Репозитарии всегда содержат последние версии моны.

[kamre]

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

Кстати, поставил недавно на тот же комп win7 "на посмотреть", в ней композит точно есть. И количество fps в тестах практически не изменилось по сравнению с winXP. Так что падение производительности графики почти в 2 раза в X-ах при включении композита еще одно подтверждение корявости X-ов.

Вообщем печально как-то все с X-ами, похоже они всегда будут тормозить по сравнению с графикой в windows.

[Olegator]

Вообщем печально как-то все с X-ами, похоже они всегда будут тормозить по сравнению с графикой в windows.

так выяснили же что проблема в ZedGraph, при чём тут Х? Да они работают медленнее, но не на столько как думалось изначально.

[v567]

так выяснили же что проблема в ZedGraph, при чём тут Х? Да они работают медленнее, но не на столько как думалось изначально.

Как раз то с библиотекой ZedGraph и нет проблем
В MS-Windows проблем с её использованием нет вообще, поскольку графический интерфейс адекватен. ZedGraph, конечно, значительно нагружает графическую 2D подсистему ОС в силу заложенного в ней функционала, например:
- масштабируемости графиков;
- возможности ведения серий разнородных данных;
- возможности обработки событий (клик по нанесенным данным, прокрутка графиков, события при изменении серий и т.д.);
- прочих многочисленных возможностей.
Но на то и существуют графические интерфейсы оконных систем, чтобы их нагружали. А вот они в свою очередь должны нагружать видеокарту, а не процессор (как это имеет место в случае с Xlib'ом в Linux).

Можно конечно и самому сделать подобие ZedGraph'а, но это потребует значительного времени и в итоге врядли получится что-то лучше хотя бы по той простой причине, что народ трудился над библиотекой несколько лет. Возможности ZedGraph очень схожи с компонентом TChart в Delphi. Для того, чтобы сложность TChart была более понятна могу добавить, что ни одно IDE (будь то последние Visual Studio 2008, Sharp Develop 3.0 или MonoDevelop 2.0 (если брать Linux)) для платформы .NET не имеет на данный момент реализации TChart в виде стандартного компонента.
Поэтому народ вовсю кует деньги, предлагая платные компонеты для VS:
- контора Software FX Corporate предлагает ChartFX (http://eu.softwarefx.com);
- контора Perpetuum Software предлагает Chart ModelKit (http://www.perpetuumsoft.com);
- есть и другие интересные решения, но за плату.
Из опенсорсного могу отметить ZedGraph и NPlot. ZedGraph на мой взгляд получше.

Поэтому как здесь и было выяснено медленную работу WinForm-приложений .NET в Linux определяют две составляющие: тормознутость X Window System (предположительно библиотека Xlib) и сыроватость проекта Mono (предположительно библиотека libgdiplus).

[v567]

И я не поленился и зашел на MSDN где ангельским по белому написано.
Приложения базирующиеся на Microsoft Win32 API не могут получить прямой доступ к видеокарте (или иному оборудованию). Вместо этого используется GDI+ взаимодействующий с драйверами устройств от имени приложений. Я согласен с Вами, что не используется directx и opengl, просто выполняется прямая работа с драйвером. А теперь вернувшись к linux gdi посмотрите как он работает и имеет ли он возможность работы с драйвером видеокарты. Отсюда и скорость.

Но на то и существуют графические интерфейсы оконных систем, чтобы их нагружали. А вот они в свою очередь должны нагружать видеокарту, а не процессор (как это имеет место в случае с Xlib'ом в Linux).

Все оказалось не так просто. Сравнил ещё раз работу в Windows и Linux тестов, упоминающихся в данной теме. Посмотрел загрузку процессора в обеих ОС. Для Windows загрузка максимальна и составляет во всех случаях почти 100%. Для Linux загрузка процессора несколько интереснее:
1. test.exe (с ZedGraph): mono - 8%, X - 83% (всего 91%).
2. SharpGears.exe: mono - 40%, X - 52% (всего 92%).
3. gr_test.exe: mono - 53%, X - 40% (всего 93%).
Как ни странно, но несмотря на использование более сложной графики в тесте SharpGeras, тест с ZedGraph грузит X-ы сильнее. Но не в этом суть.
Интересно другое. А именно то, что в обеих ОС при отрисовке графики необоснованно сильно задействован процессор. Полез в инет. Как оказалось GDI+ (библиотека графического пользовательского интерфейса для .NET) в настоящее время не использует аппаратное ускорение, а его использование планируется в будущем. И это безобразие творится в целях обеспечения большей аппаратной независимости и кроссплатформенности. Всё прёт через процессор. Осюда его бешенная загрузка при работе .NET-приложений.
Раз GDI+ использует процессор, то медленная работа .NET-приложений в Linux в сравнении с MS-Windows выглядит ещё более нелогичной.

[kamre]

Посмотрел загрузку процессора в обеих ОС. Для Windows загрузка максимальна и составляет во всех случаях почти 100%. Для Linux загрузка процессора несколько интереснее ... Интересно другое. А именно то, что в обеих ОС при отрисовке графики необоснованно сильно задействован процессор.

По крайней мере для тестов с точками и sharpgears смысл именно в максимальной нагрузке системы, как CPU так и GPU. Так что 100% загрузка процессора здесь и должна быть. А в реальном приложении зачастую нет смысла выжимать максимальное количество fps из компьютера, поэтому для графики вроде sharpgears можно ограничить fps до максимально поддерживаемого монитором (вроде 60fps) или даже еще меньше, при этом и загрузка процессора будет уже гораздо ниже (в windows по крайней мере, т.к. в linux там только до 36 fps дотягивает и ему это не поможет).

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

Для качественной графики со сглаживанием большая часть операций в GDI+/Java2D/Cairo/Qt render делается на CPU, т.к. доверить ее видеокарте и получить качественный результат весьма сложно: http://homepage.mac.com/arekkusu/bugs/invariance/HWAA.html Хотя и без сглаживания GDI+ также не очень быстрая: у меня где-то до 250 fps выдает на sharpgears, в то время как Java2D direct3d pipeline уже показывает на этом тесте до 500 fps. Быстрая графика со сглаживанием поддерживается в Qt opengl pipeline на современных видеокартах, качество практически такое же как у Qt render и до 900fps на тесте qgears2.

Раз GDI+ использует процессор, то медленная работа .NET-приложений в Linux в сравнении с MS-Windows выглядит ещё более нелогичной.

Видимо в Linux через X-ы даже примитивные операции с картинками вроде блиттинга и блендинга работают томознее чем в Windows, да и Cairo с оберткой libgdiplus также медленее рисуют чем GDI+ в Windows.

[v567]

Я мог бы понять столь значительную загрузку центрального процессора, если бы использовалась крутейшая 3D графика, от которой к примеру видеокарта захлебывалась бы при обсчете вершин полигонов в процессе создания геометрии объектов (хотя по моему глубокому убеждению даже эта задача является задачей видеокарты). Но в данном случае речь идёт об операциях с графическими примитивами. Если взять SharpGears, то и в нём используются несложные графические операции, не говоря уже о совсем примитивных операциях в тестах с точками. В них сглаживания даже близко нет (например тест c ZedGraph). И такой чудесный результат - 100% загрузка центрального процессора. Чем же он интересно занят? Просчетом в какое место вонзить следующую точку?
Ради интереса достал старый добрый Delphi 6.0 и слепил аналогию теста с ZedGraph, только теперь уже с использованием TChart'а:
код -

исходники -

Результат аналогичный - 100% загрузка процессора. Ужас. Какой из тестов данной темы не запустишь - загрузка CPU 100%. Придется искать ПК с Win'98, где использовалась GDI без плюсов, и там проверить работу теста с TChart.


Закончим с лирикой и вернемся к теме.
В процессе обсуждения темы были получены противоречивые результаты:

Так оно вообще "аццки" тормозит и больше 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!!!

Ещё раз посмотрел в профайле работу тестов (test.exe с ZedGraph и SharpGears) в MS-Windows и Linux.
MS-Windows (mono --profile test.exe > test_win.txt):

Linux (mono --profile test.exe > test_lin.txt):

MS-Windows (mono --profile sharpgears.exe > sharp_win.txt):

Linux (mono --profile SharpGears.exe > sharp_lin.txt):

test_win.txt:

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

Time(ms) Count   P/call(ms) Method name
########################
 9914.255    1799    5.511   System.Windows.Forms.Control::Refresh()
        1260  70 % System.Windows.Forms.Control::Refresh()
         500  27 % Test.TestForm::Tm()
########################
 9884.213     506   19.534   System.Windows.Forms.XplatUI::UpdateWindow(intptr)
         502  99 % System.Windows.Forms.Control::Refresh()
########################
 9874.198     506   19.514   System.Windows.Forms.XplatUIWin32::UpdateWindow(intptr)
         506  100 % System.Windows.Forms.XplatUI::UpdateWindow(intptr)
########################
 9874.198     506   19.514   System.Windows.Forms.XplatUIWin32::Win32UpdateWindow(intptr)
         506  100 % System.Windows.Forms.XplatUIWin32::UpdateWindow(intptr)


########################
 19948.684    1173   17.007   System.Windows.Forms.XplatUIWin32::InternalWndProc(intptr,Msg,intptr,intptr)
         501  42 % System.Windows.Forms.XplatUIWin32::Win32UpdateWindow(intptr)
         241  20 % System.Windows.Forms.XplatUIWin32::Win32GetMessage(MSG&,intptr,int,int)
         134  11 % System.Windows.Forms.XplatUIWin32::Win32DispatchMessage(MSG&)
 ########################
 19948.684    1173   17.007   System.Windows.Forms.NativeWindow::WndProc(intptr,Msg,intptr,intptr)
        1173  100 % System.Windows.Forms.XplatUIWin32::InternalWndProc(intptr,Msg,intptr,intptr)
########################
 19948.684    1167   17.094   .ControlNativeWindow::WndProc(Message&)
        1167  100 % System.Windows.Forms.NativeWindow::WndProc(intptr,Msg,intptr,intptr)
########################
 19948.684    1167   17.094   .ControlWindowTarget::OnMessage(Message&)
        1167  100 % .ControlNativeWindow::WndProc(Message&)

Получим:
1). Tm() -> Control::Refresh -> XplatUI::UpdateWindow -> XplatUIWin32::UpdateWindow -> XplatUIWin32::Win32UpdateWindow
2). XplatUIWin32::Win32UpdateWindow -> XplatUIWin32::InternalWndProc -> NativeWindow::WndProc -> ControlWindowTarget::OnMessage


test_lin.txt:

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

Time(ms) Count   P/call(ms) Method name
########################
 502527,899    1801  279,027   System.Windows.Forms.Control::Refresh()
  Callers (with count) that contribute at least for 1%:
        1260  69 % System.Windows.Forms.Control::Refresh()
         500  27 % Test.TestForm::Tm()
########################
 502504,858     508  989,183   System.Windows.Forms.XplatUI::UpdateWindow(intptr)
         504  99 % System.Windows.Forms.Control::Refresh()
########################
 502502,880     508  989,179   System.Windows.Forms.XplatUIX11::UpdateWindow(intptr)
         508  100 % System.Windows.Forms.XplatUI::UpdateWindow(intptr)


########################
 503021,459     563  893,466   System.Windows.Forms.XplatUIX11::SendMessage(intptr,Msg,intptr,intptr)
         507  90 % System.Windows.Forms.XplatUIX11::UpdateWindow(intptr)
          13   2 % System.Windows.Forms.XplatUIX11::CreateWindow(CreateParams)
           9   1 % System.Windows.Forms.XplatUIX11::GetMessage(object,MSG&,intptr,int,int)
########################
 1009427,130    1282  787,385   System.Windows.Forms.NativeWindow::WndProc(intptr,Msg,intptr,intptr)
         563  43 % System.Windows.Forms.XplatUIX11::SendMessage(intptr,Msg,intptr,intptr)
         546  42 % System.Windows.Forms.XplatUIX11::DispatchMessage(MSG&)
          83   6 % System.Windows.Forms.XplatUIX11::GetMessage(object,MSG&,intptr,int,int)
########################
 1009384,710     875  1153,583   .ControlNativeWindow::WndProc(Message&)
         875  100 % System.Windows.Forms.NativeWindow::WndProc(intptr,Msg,intptr,intptr)
########################
 1009376,983     875  1153,574   .ControlWindowTarget::OnMessage(Message&)
         875  100 % .ControlNativeWindow::WndProc(Message&)

Получим:
1). Tm() -> Control::Refresh -> XplatUI::UpdateWindow -> XplatUIX11::UpdateWindow
2). XplatUIX11::UpdateWindow -> XplatUIX11::SendMessage -> NativeWindow::WndProc -> ControlNativeWindow::WndProc -> ControlWindowTarget::OnMessage

Различия:
XplatUIWin32::Win32UpdateWindow -> XplatUIWin32::InternalWndProc -> NativeWindow::WndProc
XplatUIX11::UpdateWindow -> XplatUIX11::SendMessage -> NativeWindow::WndProc

Прямой вызов процедуры InternalWndProc эффективнее, чем отправка SendMessage'а оконной системе X Window. Метод SendMessage отправляет сообщение окну и управление не возвращается до обработки данного сообщения. Вероятно этим и объясняется повышенная тормознутость в работе теста с ZedGraph в Linux.

С тестом SharpGears дело обстоит несколько иначе. Метод SendMessage в Linux практически не используется. Обработка идёт не прямой перерисовкой (Refresh), а заменой обработчика onPaint. Поэтому цепочки вызывов схожи как в Linux, так и в MS-Windows. Явных отличий нет.
Можно предположить, что тормознутость SharpGears в MS-Windows (под mono) связана с кривой реализацией операций с векторными примитивами. Так в отрывках ниже метод GdipFillPath выполняется в Linux в 2.3 раза быстрее (3.365 / 1.455), чем в MS-Windows (под mono). Поскольку SharpGears в MS-Windows под .NET отрабатывает намного быстрее, чем в Linux, то иначе как кривым использованием библиотеки GDI+ со стороны mono объяснить нельзя.

sharp_win.txt:

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

Time(ms) Count   P/call(ms) Method name
########################
 26347.906    7830    3.365   System.Drawing.GDIPlus::GdipFillPath(intptr,intptr,intptr)
        7830  100 % System.Drawing.Graphics::FillPath(Brush,GraphicsPath)
########################
 19167.529    3915    4.896   System.Drawing.GDIPlus::GdipDrawPath(intptr,intptr,intptr)
        3915  100 % System.Drawing.Graphics::DrawPath(Pen,GraphicsPath)
########################
 6559.433   26535    0.247   System.Drawing.GDIPlus::GdipFillEllipse(intptr,intptr,single,single,single,single)
       26535  100 % System.Drawing.Graphics::FillEllipse(Brush,single,single,single,single)
########################
 2363.397    5220    0.453   System.Drawing.GDIPlus::GdipDrawEllipse(intptr,intptr,single,single,single,single)
        5220  100 % System.Drawing.Graphics::DrawEllipse(Pen,single,single,single,single)
########################
 4336.249     871    4.978   System.Drawing.GDIPlus::GdipFillRectangleI(intptr,intptr,int,int,int,int)
         871  100 % System.Drawing.Graphics::FillRectangle(Brush,int,int,int,int)

sharp_lin.txt:

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

Time(ms) Count   P/call(ms) Method name
########################
 21370,793   14688    1,455   System.Drawing.GDIPlus::GdipFillPath(intptr,intptr,intptr)
       14688  100 % System.Drawing.Graphics::FillPath(Brush,GraphicsPath)
########################
 10092,740    7344    1,374   System.Drawing.GDIPlus::GdipDrawPath(intptr,intptr,intptr)
        7344  100 % System.Drawing.Graphics::DrawPath(Pen,GraphicsPath)
########################
 5762,369   49776    0,116   System.Drawing.GDIPlus::GdipFillEllipse(intptr,intptr,single,single,single,single)
       49776  100 % System.Drawing.Graphics::FillEllipse(Brush,single,single,single,single)
########################
 4049,272    9792    0,414   System.Drawing.GDIPlus::GdipDrawEllipse(intptr,intptr,single,single,single,single)
        9792  100 % System.Drawing.Graphics::DrawEllipse(Pen,single,single,single,single)
########################
  48,426    1632    0,030   System.Drawing.GDIPlus::GdipFillRectangleI(intptr,intptr,int,int,int,int)
        1632  100 % System.Drawing.Graphics::FillRectangle(Brush,int,int,int,int)

Кто что думает по этому поводу?

[v567]

Кто что думает по этому поводу?

Раз "по этому поводу" никто ничего уже не думает, тогда позволю себе высказать ещё ряд моментов...
Посмотрим на выделение времени процедурам трех тестов (c ZedGrap, без него, SharpGears).

test (XP, 8сек):

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

########################
 Время, мс   вызовы  время,мс(на один вызов)
 19948.684    1173   17.007   System.Windows.Forms.NativeWindow::WndProc
        1173  100 % System.Windows.Forms.XplatUIWin32::InternalWndProc
########################
 19948.684    1173   17.007   System.Windows.Forms.XplatUIWin32::InternalWndProc
         501  42 % System.Windows.Forms.XplatUIWin32::Win32UpdateWindow
         241  20 % System.Windows.Forms.XplatUIWin32::Win32GetMessage
         134  11 % System.Windows.Forms.XplatUIWin32::Win32DispatchMessage

test (OpenSUSE, 494сек, CPU: mono - 8%, X - 83%):

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

########################
 Время, мс   вызовы  время,мс(на один вызов)
 1009427,130  1282  787,385   System.Windows.Forms.NativeWindow::WndProc
         563  43 % System.Windows.Forms.XplatUIX11::SendMessage
         546  42 % System.Windows.Forms.XplatUIX11::DispatchMessage
          83   6 % System.Windows.Forms.XplatUIX11::GetMessage

XP: UpdateWindow - 19мс; GetMessage - 35мс; DispatchMessage - 74мс
OpenSUSE: SendMessage - 893мс; DispatchMessage - 546мс; GetMessage - 14мс


test1 (XP, 13сек):

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

########################
 Время, мс   вызовы  время,мс(на один вызов)
 17755.529    1166   15.228   System.Windows.Forms.NativeWindow::WndProc
        1166  100 % System.Windows.Forms.XplatUIWin32::InternalWndProc
########################
 17755.529    1166   15.228   System.Windows.Forms.XplatUIWin32::InternalWndProc
         458  39 % System.Windows.Forms.XplatUIWin32::Win32GetMessage
         255  21 % System.Windows.Forms.XplatUIWin32::Win32DispatchMessage
         150  12 % System.Windows.Forms.XplatUIWin32::Win32UpdateWindow

test1 (OpenSUSE, 75сек, CPU: mono - 40%, X - 54%):

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

########################
 Время, мс   вызовы  время,мс(на один вызов)
 62649,443    1115   56,188   System.Windows.Forms.NativeWindow::WndProc
         691  61 % System.Windows.Forms.XplatUIX11::DispatchMessage
         194  17 % System.Windows.Forms.XplatUIX11::SendMessage
         159  14 % System.Windows.Forms.XplatUIX11::GetMessage

XP: GetMessage - 26мс; DispatchMessage - 67мс; UpdateWindow - 0.4мс
OpenSUSE: DispatchMessage - 90мс; SendMessage - 2мс; GetMessage - 12мс


SharpGears (XP, 7fps):

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

########################
 Время, мс   вызовы  время,мс(на один вызов)
 60797.424     612   99.342   System.Windows.Forms.NativeWindow::WndProc
         612  100 % System.Windows.Forms.XplatUIWin32::InternalWndProc
########################
 60797.424     612   99.342   System.Windows.Forms.XplatUIWin32::InternalWndProc
         471  76 % System.Windows.Forms.XplatUIWin32::Win32DispatchMessage
          55   8 % System.Windows.Forms.XplatUIWin32::Win32GetMessage

SharpGears (OpenSUSE, 14fps, CPU: mono - 40%, X - 52%):

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

########################
 Время, мс   вызовы  время,мс(на один вызов)
 53503,165     874   61,216   System.Windows.Forms.NativeWindow::WndProc
         832  95 % System.Windows.Forms.XplatUIX11::DispatchMessage
          20   2 % System.Windows.Forms.XplatUIX11::SendMessage

XP: DispatchMessage - 126мс; GetMessage - 0.04мс
OpenSUSE : DispatchMessage - 64мс; SendMessage - 3мс

Назначение функций:
GetMessage - извлекает (с удалением) сообщение из очереди сообщений.
DispatchMessage - передает сообщение оконной процедуре для его обработки.
SendMessage - отправляет сообщение оконной процедуре, соответствующей данному окну, ждет завершения обработки оконной
процедуры и возвращает результат обработки.
UpdateWindow - посылает сообщние wm_Paint оконной процедуре данного окна, если область обновления окна непуста.

Работа классической WinForm программы упрощенно выглядит так:

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

RegisterClass()                          // регистрируем класс
CreateWindow()                           // создаем окно
ShowWindow()                             // показываем окно
UpdateWindow()                           // посылаем WM_PAINT оконной процедуре

// цикл обработки сообщений
while (true)
{
   GetMessage(MSG)                       // ожидаем и получаем сообщение
   if (MSG.message == WM_QUIT) break()   // выходим из цикла при получении WM_QUIT (выход из программы)
   TranslateMessage(MSG)                 // преобразуем символьные сообщения (при необходимости)
   DispatchMessage(MSG)                  // обрабатываем сообщение
}

Ряд спорных предположений:
1. Наибольшее время затрачивается программой на многократный вызов функций оконной системы (Forms::WndProc).
2. Время затрачиваемое обработкой данного вызова является определяющей составляющей быстродействия программы.
3. Если окно успевает отрисовывать "как надо", то функции GetMessage и DispatchMessage должны преобладать в плане выделения им времени выполнения программы.
4. X Window имеет определенный "потолок" в использовании процессорного времени (в данных примерах не более 52%), с превышением которого программа (активно нагружающая X-ы) не успевает своевременно обрабатывать сообщения.
5. Преобладание функций SendMessage для программ, работающих под управлением mono в Linux, указывает на значительные задержки в отрисовке элементов окна.

И последнее.
Реакция на внешние события окон test и test1 в Linux и Windows различна. Если в Windows размеры окон данных тестов не меняются до окончания их работы, то в Linux их изменение возможно (измененные поля окон при этом не перерисовываются).

[loop]

Заинтересовался, т.к. столкнулся с аналогичными проблемами при переводе ПО винды под линукс. Внимательно прочёл тему, но не увидел способов решения данной проблемы: много рассуждений о тормозах графики в линукс, глубинного погружения в работу тестов в отладочных режимах. Но нет ответов как ускорить работу в линукс. Перелопачивание кода, как тут предлагалось, с помощью других кроссплатформенных инструментов проблематично. Поэтому вопрос к народу кто разбирается. Существует ли всё-таки в линукс возможность нормальной работы с приложениями .NET или проект Мигеля тупиковая ветвь эволюции?

[v567]

Внимательно прочёл тему, но не увидел способов решения данной проблемы...

Если внимательно прочесть тему станет ясно, что .NET приложения в Linux работают медленно из-за двух составляющих: торомознутости X Window и недостаточной проработки проекта Mono.

Существует ли всё-таки в линукс возможность нормальной работы с приложениями .NET ... ?

Наверное следует немного подождать выхода следующих версий X-ов и Mono. Надеюсь, что в них разработчики уделят больше внимания вопросам быстродействия своих продуктов.

... или проект Мигеля тупиковая ветвь эволюции?

Думаю у проекта Mono есть будущее. Возможно лет через 5 большинство программ в Linux будет работать с помощью среды Mono.

[kamre]

Я мог бы понять столь значительную загрузку центрального процессора, если бы использовалась крутейшая 3D графика, от которой к примеру видеокарта захлебывалась бы при обсчете вершин полигонов в процессе создания геометрии объектов (хотя по моему глубокому убеждению даже эта задача является задачей видеокарты). Но в данном случае речь идёт об операциях с графическими примитивами. Если взять SharpGears, то и в нём используются несложные графические операции, не говоря уже о совсем примитивных операциях в тестах с точками. В них сглаживания даже близко нет (например тест c ZedGraph). И такой чудесный результат - 100% загрузка центрального процессора. Чем же он интересно занят? Просчетом в какое место вонзить следующую точку?

Хотите рисовать много точек и очень быстро - легко, но тогда придется работать с низкоуровневыми API для отрисовки вроде OpenGL. Вот пример на QGLWidget с отрисовкой 10 тыс. точек и анимацией примерно 50 кадров в секунду:

Можно двигать мышкой зажав правую кнопку и зумиться через колесико. При этом ничего не тормозит и на WinXP использование процессора вообще около нуля, CPU тратится только на расчет координат и переброску этих чисел в конвейер OpenGL. На openSUSE 11.1 уже под 15-20 % CPU usage, но это похоже из-за кривой поддержки композита и включенных эффектов в kwin.

[v567]

Хотите рисовать много точек и очень быстро - легко, но тогда придется работать с низкоуровневыми API для отрисовки вроде OpenGL.

Возможности OpenGL (впрочем как и DirectX) мне известны. Бибилиотека OpenGL использовалась в паре модулей (всего их штук 20) в первоначальном комплексе, разработанным на Delphi 6.0. Модули отвечали за отображение информации на фоне Земли с возможностью детализации (что-то типа Google Earth).

Поскольку платформа Win32 начала процесс отмирания, а Microsoft упорно пропихивает .NET, встал вопросо будущем комплекса. Вопрос о использовании QT даже не поднимался. Выбор шел между C# (для .NET) и JAVA. Оптимальным оказалось использование .NET. Программы не яве работали медленнее. Это и понятно, поскольку результирующий байт-код программы работает под управлением ява-машины, т.е. является интерпретируемым. И напротив CIL-код .NET программ с помощью JIT-компилятора преобразуется в выполнимый код и помещаетсяв кэш по правилам целевой ОС.

Первоначально вопрос об использовании Linux не ставился. С появлением Mono 2.0 всплыл вопрос о портировании .NET комплекса в Linux. Комплекс под .NET пришлось править, чтобы он заработал в Mono. Разработка пары модулей на OpenGL была отложена "на потом", поскольку они не являлись основными в работе, а использование реализаций OpenGL в .NET и в Mono вызывало несовместимость. Быстродействие комплекса под .NET по понятным причинам было ниже, чем аналога под Win32, однако было терпимым. Скорость работы комплекса под Mono в Linux оказалась слишком медленной

Учитывая то, что комплекс под .NET разрабатывался около года, вопрос об использовании других средств разработки отпадает. Будет использоваться MS-Windows. Работа в Linux будет отложена до лучших времен: выхода более производительных версий оконных систем и среды Mono.

Поэтому проблема как бы и не в точках. Примитивный тест с ZedGraph лишь пример медленной работы .NET программы в Linux. Простоты ради были выбраны точки. В комплексе под .NET графика намного сложнее, а использование возможностей ZedGraph шире. При этом основная часть комплекса не графическая, а расчетная. Графика - лишь средство визуализации расчетов.

[kamre]

Поскольку платформа Win32 начала процесс отмирания, а Microsoft упорно пропихивает .NET, встал вопросо будущем комплекса. Вопрос о использовании QT даже не поднимался. Выбор шел между C# (для .NET) и JAVA.

Странно немного, что вопрос о Java поднимался, а о переходе с unmanaged платформы Delphi на unmanaged платформу Qt, работающую в разных ОС, не поднимался. Наверное, лицензия на Qt раньше не позволяла даже рассматривать такие варианты. Хотя, конечно, это смотря для чего переход был нужен. Видимо кросплатформенность была далеко не главным критерием при выборе, как и производительность.

Если уж "платформа Win32 начала процесс отмирания", то тогда можно и о WinForms забыть и начинать уже на WPF делать приложения. Его сейчас MS активно продвигает, и приложения вроде AutoCAD уже переходят на WPF для создания интерфейса. Правда про Mono тогда вообще можно забыть, они вообще не собираются эту технологию поддерживать, только небольшую часть ввиде Moonlight.

Оптимальным оказалось использование .NET. Программы не яве работали медленнее. Это и понятно, поскольку результирующий байт-код программы работает под управлением ява-машины, т.е. является интерпретируемым. И напротив CIL-код .NET программ с помощью JIT-компилятора преобразуется в выполнимый код и помещаетсяв кэш по правилам целевой ОС.

Ну совсем-то сказки про интерпретируемую Java рассказывать не нужно, есть там HotSpot давно уже, и вполне прилично работает. А вот в кэш нельзя вроде помещать, поэтому и стартуют Java приложения весьма не быстро (это даже на тесте с точками было заметно, там отрисовка заметно ускоряется через небольшой промежуток времени после старта).

[yaleks]

Выбор шел между C# (для .NET) и JAVA. Оптимальным оказалось использование .NET. Программы не яве работали медленнее. Это и понятно, поскольку результирующий байт-код программы работает под управлением ява-машины, т.е. является интерпретируемым. И напротив CIL-код .NET программ с помощью JIT-компилятора преобразуется в выполнимый код и помещаетсяв кэш по правилам целевой ОС.

Сейчас Java тоже с JIT работает (с версии 1.6 точно), так что тут вы не правы. Ранние версии да, такой возможности не имели.
Но Java, в отличии от .NET имеет реальную кроссплатформенность, а не гипотетическую.

[v567]

Ну совсем-то сказки про интерпретируемую Java рассказывать не нужно, есть там HotSpot давно уже, и вполне прилично работает.

Сейчас Java тоже с JIT работает (с версии 1.6 точно), так что тут вы не правы. Ранние версии да, такой возможности не имели.

Выбор между .NET и Java производился несколько лет назад.
А насчет Ваших замечаний по поводу JIT могу предложить прочесть пару книжек ниже. Автор очень даже известный и уважаемый.

Герберт Шилдт. Полный справочник по JAVA. Java SE 6 Edition. 7-е издание.
Магия Java: байт-код. стр.40-41

Байт-код - это в высшей степени оптимизированный набор инструкций, предназначенных для исполнения системой времени выполнения Java, называемой виртуальной машиной Java. Собственно говоря, первоначально версия JVM разрабатывалась в качестве интерпретатора байт-кода. Это может вызывать определенное удивление, поскольку по соображениям обеспечения максимальной производительности многие современные языки призваны создавать исполняемый код.
Однако то, что Java-программа интерпретируется машиной JVM, помогает решать основные проблемы, связанные с программами, предназначенными для Web.
То, что Java-программа выполняется машиной JVM, способствует также повышению ее безопасности. Поскольку машина JVM управляет выполнением программы, она может изолировать программу и воспрепятствовать порождению ею побочных эффектов вне данной системы. В общем случае, когда программа компилируется в промежуточную форму, а затем интерпретируется виртуальной машиной, она выполняется медленнее, чем если бы она была скомпилирована в исполняемый код. Однако при использовании языка Java различие в производительности не слишком велико. Поскольку байт-код в высокой степени оптимизирован, его применение позволяет машине JVM выполнять программы значительно быстрее, чем можно было ожидать.
Хотя язык Java был задуман в качестве интерпретируемого языка, ничто не препятствует Java выполнять компиляцию байт-кода во внутренний код "на лету" для повышения производительности. Поэтому вскоре после появления Java компания Sun начала поставлять свою технологию HotSpot. Эта технология предоставляет оперативный (Just-In-Time - JIT) компилятор байт-кода. Когда JIT-компилятор является составной частью JVM, избранные фрагменты байт-кода один за другим компилируются в исполняемый код в реальном времени, по соответствующим запросам.
Важно понимать, что одновременная компиляция всей Java-программы в исполняемый код нецелесообразна, поскольку Java выполняет различные проверки, которые могут быть осуществлены только во время выполнения. Вместо этого во время выполнения JIT-компилятор компилирует код по мере необходимости. Более того, компилируются не все фрагменты байт-кода, а только те, которым компиляция принесет выгоду. Остальной код просто интерпретируется.

Герберт Шилдт. Полный справочник по C#. 2004 г
Функционирование системы CLR. стр. 28

Система CLR управляет выполнением .NET-кода. Вот как это происходит. В результате компиляции C#-программы получается не исполнимый код, а файл, который содержит специальный псевдокод, именуемый промежуточным языком MSIL. MSIL определяет переносимость инструкций, которые не зависят от типа процессора. По сути, MSIL определяет переносимость ассемблера. И хотя концептуально MSIL подобен байт-коду Java, это не одно и то же.
Цель CLR-системы - при выполнении программы перевести ее промежуточный код в исполняемый. Таким образом, программа, подвергнутая MSIL-компиляции, может быть выполнена в любой среде, для которой реализована CLR-система. Код, написанный на промежуточном языке Microsoft, переводится в исполняемый с помощью JIT-компилятора.
Этот процесс работает следующим образом. При выполнении .NET-программы CLR-система активизирует JIT-компилятор, который преобразует MSIL-код в ее "родной" код на требуемой основе, поскольку необходимо сохранить каждую часть программы. Таким образом, C#-программа в действительности выполняется в виде "родного" кода, несмотря на то, что превоначально была скомпилирована в MSIL-код.
Это значит, что программа будет выполнена практически так же быстро, как если бы она с самого начала была скомпилирована с получением "родного" кода, но с "добавлением" преемуществ переносимости от преобразования в MSIL-код.

На мой взгляд разница очевидна. На всякий случай нужное подчеркнуто
Вот поэтому JAVA до сих пор и остался интерпретируемым.
Хотя положительные сдвиги (очевидно с оглядкой на .NET) в JAVA уже начались

Но Java, в отличии от .NET имеет реальную кроссплатформенность, а не гипотетическую.

Насчет кроссплатформенности думаю у .NET (к которому между прочим относится и Mono) ещё все впереди. Возможно появятся и другие проекты типа Mono, поскольку спецификации .NET открыты.

Странно немного, что вопрос о Java поднимался, а о переходе с unmanaged платформы Delphi на unmanaged платформу Qt, работающую в разных ОС, не поднимался. Наверное, лицензия на Qt раньше не позволяла даже рассматривать такие варианты. Хотя, конечно, это смотря для чего переход был нужен. Видимо кросплатформенность была далеко не главным критерием при выборе, как и производительность.

Однако сам факт того, что исходный код необходимо компилить под каждую ось отдельно заставляет думать о слегка натянутом определении кроссплатформенности. Кроссплатформенность на уровне выполнения и кроссплатформенность на уровне компиляции как бы не однои тоже. Вот когда Qt Software со своим продуктом Qt позволит делать то, что делает .Net или Java, тогда и можно будет всерьез говорить об её супер-пупер кроссплатформенности.

Если уж "платформа Win32 начала процесс отмирания", то тогда можно и о WinForms забыть и начинать уже на WPF делать приложения. Его сейчас MS активно продвигает, и приложения вроде AutoCAD уже переходят на WPF для создания интерфейса. Правда про Mono тогда вообще можно забыть, они вообще не собираются эту технологию поддерживать, только небольшую часть ввиде Moonlight.

Комплекс начинал разрабатываться на VS 2005. WPF появился к концу 2006. А потом уже вышел Mono 2.0, и на www.mono-project.com/WPF было прописано:

Mono project does not have plans to implement Windows Presentation Foundation APIs as part of the project.

Потому пока и нет желания перебираться на WPF, хотя такие задумки есть. С точки зрения быстродействия WPF получше WinForm (с её GDI&GDI+). Есть уже аппаратное ускорение 2D и 3D графики.

Споры о достоинствах и недостатках .NET, Java и Qt несколько далеки от темы. Желательно высказываться ближе к теме для решения вопросов как же все-таки ускорить работу .NET-приложений в среде Mono в Linux.

[v567]

Как оказалось "рефакторизация и оптимизация" теста с ZedGraph (как советовал один товарищ) возможны. Как ни странно, но идея созрела здесь: http://jenyay.net/Programming/ZedGraph#queue

Используя всего лишь навсего один дополнительный поток удалось разогнать тест с ZedGraph до непостижимой для .NET скорости работы, в результате время работы составило 0.8 сек (ранее 2.5 сек). Но это опять таки, в .NET под Windows.

Остальные результаты указаны здесь:


Однако, несмотря на все оптимизации, скорость работы в Linux, как основной программы, так и теста с ZedGraph, по-прежнему в несколько раз медленнее, чем в Windows. К тому же в Linux из-за торможения графики прорисовка идет не поточечно, а покучечно.

Ждёмс выхода следующих версий mono и opensuse.

Обновленный тест c ZedGraph (выполнимый код):

Обновленный тест с ZedGraph (исходник):

[TuxWare]

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

Вроде же XP умеет полупрозрачные окошки? Вон, можно даже через JavaFX запустить: http://www.javafx.com/samples/SwirlingSquares/index.html
Что имеется ввиду под композитом?

Сам вошел в ступор, потому не смог ответить. Полупрозрачные окошки - чушь. Возьмите в виндовс окно в котором фигачит DirectX или OpenGl и это окно сделайте прозрачным!! Вот это и есть композит.

[TuxWare]

Ждёмс выхода следующих версий mono и opensuse.

ждите и даже обождитесь - не поможет

[yaleks]

Однако, несмотря на все оптимизации, скорость работы в Linux, как основной программы, так и теста с ZedGraph, по-прежнему в несколько раз медленнее, чем в Windows. К тому же в Linux из-за торможения графики прорисовка идет не поточечно, а покучечно.

Ждёмс выхода следующих версий mono и opensuse.

Мне видится проблема с threads. Я запускаю ваш новый вариант под mono-2.4.2 (gentoo amd64) и он довольно шустро рисует синусоиду. Но таймер видимо замирает на отметке 0.1-0.8 сек (в зависимости от запуска).

[v567]

Мне видится проблема с threads. Я запускаю ваш новый вариант под mono-2.4.2 (gentoo amd64) и он довольно шустро рисует синусоиду. Но таймер видимо замирает на отметке 0.1-0.8 сек (в зависимости от запуска).

Могу ошибаться но выход mono 2.4.2 (в котором намечено исправление ошибок версии 2.4) запланирован на июль 2009 г.
Можно поподробнее что значит таймер "замирает"? Из ваших слов лично я понял что тест начинает работать и через 0.1-0.8 сек виснет так и не доработав до конца. Это так или ваши слова нужно понимать иначе? Просто у меня на разных пк и под mono (linux) и под .net (windows) он отрабатывает нормально.

[yaleks]

Можно поподробнее что значит таймер "замирает"? Из ваших слов лично я понял что тест начинает работать и через 0.1-0.8 сек виснет так и не доработав до конца. Это так или ваши слова нужно понимать иначе? Просто у меня на разных пк и под mono (linux) и под .net (windows) он отрабатывает нормально.

Это значит можно заметить 0.1, потом 0.9.. рисует действительно рывками. Система 64 битная, core2 (2 ядра).
Что является признаком завершения теста?
Посмотрел сорцы, вы используете какой-то самопальный таймер? В mono нет нормального таймера?

Вот http://www.mono-project.com/Release_Notes_Mono_2.4.2 всё выпущено.

[v567]

Вот http://www.mono-project.com/Release_Notes_Mono_2.4.2 всё выпущено.

Действительно, на http://www.mono-project.com/Main_Page есть упоминание о том, что mono 2.4.2 вышел. Репозитарии OpenSuse 11.1 http://download.opensuse.org/repositories/.../openSUSE_11.1/ уже содержит mono 2.4.2. Что ж попробуем, поработаем

Что является признаком завершения теста?

Признаками завершения теста является вывод синусоиды от левой до правой границ окна и остановка вывода текущего времени выполнения.

Это значит можно заметить 0.1, потом 0.9.. рисует действительно рывками. Система 64 битная, core2 (2 ядра).
Посмотрел сорцы, вы используете какой-то самопальный таймер? В mono нет нормального таймера?

Как в .NET, так и в mono есть таймеры. Но тест их не использует, поскольку любой таймер работает с определенной дискретностью и не подходит к условиям работы теста. Напоминаю, что целью данного теста является максимально быстрый поточечный вывод (т.е. расчитали точку -> добавили в серию -> отобразили на графике) в графическом виде для того, чтобы сравнить скорость работы теста в windows и linux.

Предыдущий тест работал так: после нажатия кнопки в методе обработки нажатия этой кнопки циклически произодилось вычисление координат и отрисовка текущей точки синусоиды на графике.
В новом тесте вместо таймера для ускорения вывода используется дополнительный (второй) поток.
Смысл использования доп. потока указан здесь: http://jenyay.net/Programming/ZedGraph#queue, он заключается в следующем.

Отрисовку точки после вычисления ее координат нужно производить максимально быстро. Поэтому ранее использовался метод Refresh. Оптимально, если бы ZedGraph сам рисовал точку сразу же после ее добавления в серию (как TChart), но ZedGraph этого не делает. Refresh же, судя по всему, перерисовывает всю область графики вместо отрисовки одной вновь появившейся точки. Для отрисовки непосредственно вновь воявившихся изменений в ZedGraph (и в .NET в целом) правильно было бы использовать метод Invalidate. Но как удалось выяснить Invalidate работает весьма своеобразно: отрисовка изменений производится не сразу, а после завершения выполнения текущего потока (из которого был вызван Invalidate). В принципе, Invalidat'ом возможно сразу же произвести отрисовку, но для этого после Invalidate нужно вызвать метод Update. Однако использование связки Invalidate + Update по быстродействию ничем не лучше, чем использование Refresh'а (по этой причине в предыдущем тесте использовался Refresh).
Дабы разрешить эту параноидальную проблему был введен второй поток. Его задача заключается в том, чтобы сразу же вернуть управление основному потоку. Т.е. выполнить все капризы Invalidate: основной поток вызывает Invalidate и сразу же заканчивает свою работу для того, чтобы Invalidate нарисовал эту точку; второй же поток, определив, что основной поток закончил свою работу, сразу же возвращает ему управления и т.д. В перерыве после вызыва основным потоком Invalidate и возвратом основному потоку управления мистическим образом производится обновление экрана.

Теперь о "замирании" и о "threads".
У меня тоже новый тест показывал чередующиеся времена выполнения: нечетные прогоны теста - меньшее, четные - большее. Тут скорее дело не в потоках, в особенностях работы CLR системы в средах как .NET, так и mono: первый проход работает нормально (т.е. быстро), следующий тормозит, и т.д. с чередованием. Суть не в этом. Достаточно ограничиться показателями быстрого результата.

А вот с "рывками" в linux дело обстоит гораздо печальнее. На мой взгляд проблема вот в чем:
mono не успевает обработать предудыщий Invalidate, как основной поток вызывает уже следующий Invalidate. В результате вывод осуществляется рывками. Но даже в отрисовке точек блоками ("рывками") скорость выполнения теста намного медленнее, чем под windows (см. таблицу). Как уже было сказано проблема заключается в графической подсистеме linux, а точнее в X-ах.

[fynjy]

Разрывы в рисовании --- это скорее всего из-за клиент серверной архитектуры иксов, связанной с буферизацией запросов. То есть вы отправляете иксам несколько запросов и они через некоторое время рисуются пачкой. Для улучшения быстродействия попробуйте инвалидатить только то место куда была нарисована точка (возможно для этого потребуется окунуться в сырцы ZedGraph). Если есть возможность отслеживать завершение выполнения запросов, то можно попробовать собирать запросы (например делать несколько Invalidate за раз).

Ещё посмотрите есть ли возможность создать графический контекст из openGL или XVideo и отправлять туда запросы на отрисовку (если получится, пробуйте определять ось в рантайме и соответсвенно куда рисовать). Я не думаю, что положение с иксами в лине в ближайшие несколько лет улучшиться. Тем кому нужен скоростной вывод видео всегда юзают XVideo или openGL (2D это ведь всего лишь подмножество 3D). Я не знаю есть ли привязки для XVideo и openGL для C# и насколько хорошо они реализованы. Если вдруг не получится их заюзать, то то что Вы сейчас сделали --- это, наверное, максимум (возможно можно что-то подкрутить, но это уже не существенно).

Результаты для последнего теста с моего ноута (mono 2.4.2) составили от 0,3 до 14 секунд (это цифра которая была нарисована около кнопки на момент достижения синусоиды правого края)

[yaleks]

mono не успевает обработать предудыщий Invalidate, как основной поток вызывает уже следующий Invalidate. В результате вывод осуществляется рывками. Но даже в отрисовке точек блоками ("рывками") скорость выполнения теста намного медленнее, чем под windows (см. таблицу). Как уже было сказано проблема заключается в графической подсистеме linux, а точнее в X-ах.

Проблема именно в mono и иксы совершенно ни при чём.
Иначе бы не работала ни одна игрушка под linux (их много и 2D и 3D и все работают шустро и без тормозов).

Раз вы говорите, что в ZedGraph есть проблемы с sync, то и копать надо в том направлении.

[v567]

Разрывы в рисовании --- это скорее всего из-за клиент серверной архитектуры иксов, связанной с буферизацией запросов. То есть вы отправляете иксам несколько запросов и они через некоторое время рисуются пачкой.

Просто-напросто X-ы не в состоянии с необходимой скоростью обработать запросы на отрисовку Invalidate, потому и идет буферизация.

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

Пробовал инвалидить области - бесполезно, скорость не меняется.
Собирать запросы даже не думаю, поскольку цель теста не обойти проблему быстродействия графики в linux, а наглядно ее показать (в сравнении с windows), ну и по возможности решить.
Основная программа работает по таймеру и производит вывод на график блоками, однако скорость её работы в linux намного медленнее, чем в windows.

Ещё посмотрите есть ли возможность создать графический контекст из openGL или XVideo и отправлять туда запросы на отрисовку (если получится, пробуйте определять ось в рантайме и соответсвенно куда рисовать). Я не думаю, что положение с иксами в лине в ближайшие несколько лет улучшиться. Тем кому нужен скоростной вывод видео всегда юзают XVideo или openGL (2D это ведь всего лишь подмножество 3D). Я не знаю есть ли привязки для XVideo и openGL для C# и насколько хорошо они реализованы. Если вдруг не получится их заюзать, то то что Вы сейчас сделали --- это, наверное, максимум (возможно можно что-то подкрутить, но это уже не существенно).

Про OpenGL уже неоднократно говорилось:
Проблемы работы программ в среде mono в linux
В .net и mono нет единого стандарта на использование OpenGL, хотя возможности работы с OpenGL есть (например, Tao для mono, или XNA для .net).
И по большому счету дело не в громких названиях (типа OpenGL, DirectX и прочий хлам), а в том насколько используются ресурсы видеокарты. К сожалению X-ы в linux ресурсы видеокарты используют слабо.

Проблема именно в mono и иксы совершенно ни при чём.
Иначе бы не работала ни одна игрушка под linux (их много и 2D и 3D и все работают шустро и без тормозов).

В этой теме уже было неоднократно доказано, что тормоза 2D графики в linux связаны именно с кривой реализацией X-ов. Почитайте тему еще раз, ну или хотя бы прочтите вот эти несколько сообщений:
Проблемы работы программ в среде mono в linux
Проблемы работы программ в среде mono в linux
Проблемы работы программ в среде mono в linux
Обратите внимание на результаты тестов, использующих JAVA и QT. Скорость вывода графики в linux по меньшей мере в раза 2 медленне, чем в windows.
Хотя кривость mono отрицать уже тоже невозможно
Но как бы там ни было, если бы X-ы работали шустрее, чем оконная система MS-Windows, думаю результаты сравнения работы .net (mono) в linux и windows были бы совершенно иными. Честно говоря, я не понимаю, почему столь кривая архитектура как X-ы просуществовала столь значительное время и до сих пор живет.

Раз вы говорите, что в ZedGraph есть проблемы с sync, то и копать надо в том направлении.

ZedGraph тут не при чем. Если его не использовать результаты работы net-приложений в linux тоже вызывают тихую грусть:
Проблемы работы программ в среде mono в linux