Я хотел разобрать максимально простой пример, который при этом будет легко читаться в ассемблере. Мне кажется сложное складывается из простого.
Проанализировать более сложный алгоритм в ассемблере разумеется тоже реально, но его реализация на каждом из языков будет вызывать много спорных моментов (почему использована именно эта библиотека, почему использован именно этот тип, этот вид оптимизации и т.п.)
Ведь даже в моем примитивном примере пришлось рассмотреть альтернативные контейнеры и некоторые элементы оптимизации. В более сложном алгоритме, количество подобных вариаций думаю должно быть существенно больше, чтобы выполнить более менее объективное сравнения, это требует многократно больше времени.
Мне кажется анализировать элементы сложного проще, чем сложное целиком.
И кстати, попытка анализа чуть более сложных алгоритмов есть в статье Head-to-head benchmark: C++ vs .NET, на которую я ссылаюсь в своей статье.
В тесте, я попробовал просто обнести сортировку блоком unsafe {… }, и этого не хватило чтобы убрать проверки, вероятно без фиксирования указателей (как и указано в вашем примере) данный метод не работает.
После же того как я зафиксировал items проверки ушли и код items[j] = items[i]; скомпилировался без дополнительных call-ов (таких как в статье), однако же его все-равно получилось многовато кода.
Я попробовал вместо грида в тесте использовать с ListView с GridView в нем. Без дополнительных темплейтов редактирования. Написать пример получилось быстро.
Но вот работал он ничуть не быстрее обычного грида WPF, FPS на скроллинге был ровно такой же…
Получается достаточно дорого для разработки в ListView поддерживать редактирование шаблонами…
Хотя если в гриде все колонки шаблонные, то разница по разработке не сильно большая.
Надо пробовать, на сколько это может поднять производительность.
Как понимаю, основной недостаток ListView + GridView в невозможности полноценного inline edit.
Был бы рад, если бы кто-нибудь написал подобное сравнение для контролов ListView в разных библиотеках и возможно других стандартных контролов. Гриды же были выбраны мной, как наиболее универсальные контролы представления (и редактирования) табличных данных.
Ранее я пробовал ставить фиксированные размеры WPF гридам. Эффекта от этого не было. Грид вызывает измерение размера ячеек даже тогда, когда причины для измерений нет… то есть нет ни ресайза, ни изменения колонок — только скроллинг.
В CListView не хватает возможности стандартного редактирования ячеек, там, на сколько мне известно, можно редактировать только первую колонку, это существенно сужает его применение для задач представления данных, где данные нужно еще и редактировать.
Да и в целом CListView плохо умеет работать с ячейками отдельно т.е. для него есть «первая» ячейка, а есть остальные. Конечно бывает этого и хватает.
Иными словами, на гриде можно решать практический любую задачу представления и редактирования табличных данных, а на ListView только часть этих задач, из-за меньшей универсальности CListView был выбран именно грид для тестов.
( и конечно если сравнивать листы, то их надо сравнивать уже с листами, а это совсем другое сравнение)
В статье я рассматривал этап уже не стартовый этап, и даже не менял размеры колонок.
Я просто скролил контент.
И кстати ранее тоже профайлил WPF грид во время скролла (в комментах к предыдущей статье я это разбирал). Вот например мой скриншот профайлинга во время скролла
http://s30.postimg.org/4lvgfhrnl/Measure.png
Большинство времени тратится на MeasureCore, даже тогда когда никакие размеры ни грида ни колонок не меняются, виртуализация проблему не лечит.
Выглядит такая логика не эффективной конечно т.е. можно сказать что проблема в реализации грида.
Я наконец таки его запустил так, чтобы он работал быстро.
Возиться пришлось не меньше чем с FLTK: создать модель представления и использовать кастомный рендер текста и фиксированный размер грида. Кроме того пришлось отказаться от биндингов данных.
Но все же fastwpfgrid показал производительность примерно равную производительности грида FLTK.
Конечно это очень хороший результат, хотя грид и не дешев в использовании.
Жалко что грид пока слишком молодой (4 месяца и 231 скачка) для использования в продакшине.
Еще более жалко что стандартный грид WPF не дает и половины производительности этого грида…
Проблема в том, что на сколько мне известно в MFC нету контрола грид. (Например CListView это никак не грид)
Сравнивать же сторонние, и зачастую платные, контролы для MFC — наряду со стандартными контролами для других библиотек выглядит очень неравноценным сравнением.
В FLTK неплохо интегрирована поддержка OpenGL, и некоторые контролы с префиксом Fl_Gl_ рендерятся через OpenGL, однако на сколько я понял, многие другие контролы, рендерятся стандартными средствами системы (Windows, Linux или MacOS)
Попробовал использовать FastGridControl в своем примере вместо стандартного грида. Я просто подставил другой грид в свой тест и грид на системе с 4.5.1 все заработало.
Производительность была ровно такой-же как и и обычного грида WPF. (да похоже это и был обычный WPF грид)
Видимо в приложенных примерах с гридом делается еще что-то, причем со стороны приложения, что его использует.
В примере, которые лежит в репозитории видно что еще создаются дополнительные модели и некий свой TextRenderPanel контрол (очень странно почему все это делается не внутри грида, а снаружи)
Похоже повозиться тут надо не меньше чем с FLTK. Но все еще не теряю надежды запустить данный грид, так, чтобы он работал быстро, однако похоже для этого надо будет потратить немало времени.
Конкретно этой библиотеке похоже уже 3 года, и вполне возможно, что она достаточно «провереная». Хотя конечно код вроде этого, немного пугает с точки зрения использования в С#
// Win32 memory copy function
//[DllImport(«ntdll.dll»)]
[DllImport(«msvcrt.dll», EntryPoint = «memcpy», CallingConvention = CallingConvention.Cdecl, SetLastError = false)]
public static extern unsafe void* memcpy(
void* dst,
void* src,
int count);
В любом случае грид заметно быстрее стандартного. Надо его проверить с тестовыми данными.
К сожалению сейчас не могу проверить. Грид не совместим с vs2010 и .net framework 4.0
(даже не получается перестроить грид из исходников без более свежей студии и 4.5.1, а на этой машине не могу его сносить 4.0 так на ней иногда как требуется строить приложения совместимые с XP, для которой нет 4.5.1)
Попробую проверить на более свежем framework позже. По исходникам могу сказать что в реализации грида много unmanaged кода, и приложеный пример (который в бинарном виде запускается даже на 4.0) работает в два раза быстрее стандартного грида WPF, однако же в примере 100 колонок и 1000 строк, что отличается от тестовой конфигурации.
Кроме того опасения вызывает то, что контрол fastgrid достаточно «молодой», появился только в Mar 24, 2015, есть риск столкнуться с багами при использованиии в продакшине…
Я попробую его чуть позже, когда будет доступна ситема, где нет необходимости в 4.0 фреймворке.
Qt использовался тот который оказался под рукой (5.2.1 вышел в 2014 году).
Вполне возможно более свежие Qt покажут результат лучше.
Если выложите пример на QML или результаты этого же теста собранного под более свежим Qt — будет очень полезно.
Проанализировать более сложный алгоритм в ассемблере разумеется тоже реально, но его реализация на каждом из языков будет вызывать много спорных моментов (почему использована именно эта библиотека, почему использован именно этот тип, этот вид оптимизации и т.п.)
Ведь даже в моем примитивном примере пришлось рассмотреть альтернативные контейнеры и некоторые элементы оптимизации. В более сложном алгоритме, количество подобных вариаций думаю должно быть существенно больше, чтобы выполнить более менее объективное сравнения, это требует многократно больше времени.
Мне кажется анализировать элементы сложного проще, чем сложное целиком.
И кстати, попытка анализа чуть более сложных алгоритмов есть в статье Head-to-head benchmark: C++ vs .NET, на которую я ссылаюсь в своей статье.
После же того как я зафиксировал items проверки ушли и код items[j] = items[i]; скомпилировался без дополнительных call-ов (таких как в статье), однако же его все-равно получилось многовато кода.
items[j] = items[i];
00000105 mov eax,dword ptr [ebp-34h]
00000108 mov dword ptr [ebp-6Ch],eax
0000010b mov eax,dword ptr [ebp-6Ch]
0000010e mov edx,dword ptr [ebp-44h]
00000111 mov ecx,dword ptr [ebp-34h]
00000114 mov dword ptr [ebp-70h],ecx
00000117 mov ecx,dword ptr [ebp-70h]
0000011a mov ebx,dword ptr [ebp-40h]
0000011d mov ecx,dword ptr [ecx+ebx*4]
00000120 mov dword ptr [eax+edx*4],ecx
Но вот работал он ничуть не быстрее обычного грида WPF, FPS на скроллинге был ровно такой же…
Хотя если в гриде все колонки шаблонные, то разница по разработке не сильно большая.
Надо пробовать, на сколько это может поднять производительность.
Был бы рад, если бы кто-нибудь написал подобное сравнение для контролов ListView в разных библиотеках и возможно других стандартных контролов. Гриды же были выбраны мной, как наиболее универсальные контролы представления (и редактирования) табличных данных.
Да и в целом CListView плохо умеет работать с ячейками отдельно т.е. для него есть «первая» ячейка, а есть остальные. Конечно бывает этого и хватает.
Иными словами, на гриде можно решать практический любую задачу представления и редактирования табличных данных, а на ListView только часть этих задач, из-за меньшей универсальности CListView был выбран именно грид для тестов.
( и конечно если сравнивать листы, то их надо сравнивать уже с листами, а это совсем другое сравнение)
Я просто скролил контент.
И кстати ранее тоже профайлил WPF грид во время скролла (в комментах к предыдущей статье я это разбирал). Вот например мой скриншот профайлинга во время скролла
http://s30.postimg.org/4lvgfhrnl/Measure.png
Большинство времени тратится на MeasureCore, даже тогда когда никакие размеры ни грида ни колонок не меняются, виртуализация проблему не лечит.
Выглядит такая логика не эффективной конечно т.е. можно сказать что проблема в реализации грида.
Возиться пришлось не меньше чем с FLTK: создать модель представления и использовать кастомный рендер текста и фиксированный размер грида. Кроме того пришлось отказаться от биндингов данных.
Но все же fastwpfgrid показал производительность примерно равную производительности грида FLTK.
Конечно это очень хороший результат, хотя грид и не дешев в использовании.
Жалко что грид пока слишком молодой (4 месяца и 231 скачка) для использования в продакшине.
Еще более жалко что стандартный грид WPF не дает и половины производительности этого грида…
Сравнивать же сторонние, и зачастую платные, контролы для MFC — наряду со стандартными контролами для других библиотек выглядит очень неравноценным сравнением.
Производительность была ровно такой-же как и и обычного грида WPF. (да похоже это и был обычный WPF грид)
Видимо в приложенных примерах с гридом делается еще что-то, причем со стороны приложения, что его использует.
В примере, которые лежит в репозитории видно что еще создаются дополнительные модели и некий свой TextRenderPanel контрол (очень странно почему все это делается не внутри грида, а снаружи)
Похоже повозиться тут надо не меньше чем с FLTK. Но все еще не теряю надежды запустить данный грид, так, чтобы он работал быстро, однако похоже для этого надо будет потратить немало времени.
// Win32 memory copy function
//[DllImport(«ntdll.dll»)]
[DllImport(«msvcrt.dll», EntryPoint = «memcpy», CallingConvention = CallingConvention.Cdecl, SetLastError = false)]
public static extern unsafe void* memcpy(
void* dst,
void* src,
int count);
В любом случае грид заметно быстрее стандартного. Надо его проверить с тестовыми данными.
(даже не получается перестроить грид из исходников без более свежей студии и 4.5.1, а на этой машине не могу его сносить 4.0 так на ней иногда как требуется строить приложения совместимые с XP, для которой нет 4.5.1)
Попробую проверить на более свежем framework позже. По исходникам могу сказать что в реализации грида много unmanaged кода, и приложеный пример (который в бинарном виде запускается даже на 4.0) работает в два раза быстрее стандартного грида WPF, однако же в примере 100 колонок и 1000 строк, что отличается от тестовой конфигурации.
Кроме того опасения вызывает то, что контрол fastgrid достаточно «молодой», появился только в Mar 24, 2015, есть риск столкнуться с багами при использованиии в продакшине…
Я попробую его чуть позже, когда будет доступна ситема, где нет необходимости в 4.0 фреймворке.
Вполне возможно более свежие Qt покажут результат лучше.
Если выложите пример на QML или результаты этого же теста собранного под более свежим Qt — будет очень полезно.