Вывод по приведенным таблицам и графикам:
64х битная версия от 32х битной мало чем отличается, но в среднем потребляет заметно больше памяти
(что вполне логично, как минимум в силу большего размера указателей)
То есть простой вывод: Хотите экономить память — ставьте 32 битный браузер.
Но автор конечно вопрос сравнения раскрыл не полностью, в том числе и относительно других особенностей использования 32 битных и 64 битных браузеров.
Правильно ли я понимаю, что переход к схеме аренды означает переход от модели
«когда новая версия продукта является действительно новой», к модели
«когда новая версия продукта является maintenance релизом, и по сути не имеет существенных изменений»
И если да, то связано ли это со сворачиванием разработки продукта?
Я могу ошибаться в своих предположениях, просто высказываю общее ощущение от переходов к модели ренты(в других случаях) и пытаюсь понять на сколько оно неверно.
В качестве ответа на 2 и 3 самому себе:
Похоже обычные десктопные приложения нельзя построить с .NET Native, а построить можно только приложения для Windows Store. Так ли это?
Хотелось бы поблагодарить автора за статью и особенно пример на .NET Native, а также задать несколько вопросов:
1. Удалось ли понять за счет чего .NET Native несколько медленнее С++, не получалось ли сравнить disassembly?
2. Есть ли возможность использовать .NET Native с .Net Framework 4.0 (чтобы «разогнать» энтерпрайс, которому необходима поддержка XP:( )
3. Какие видятся причины для того чтобы не переходить на .NET Native с обычного managed С#?
Так или иначе количество строк и столбцов в статье написано точно и исходный код выложен.
Альтернативных гридов для WPF, из более менее зрелых библиотек к сожалению не нашлось. Те что попадались были либо достаточно сырыми opensource либо тормозили не меньше стандартного.
Если знаете быстрый грид для WPF, напишите пожалуйста, ну а если не знаете, то к чему ваш посыл?
Я разобрал производительность компонента с функциональностью DataGrid, это важное уточнение, так как при реализации практических задач нам важен функционал компонента.
Сравнение показало, что датагрид WPF, является одним из худших по производительности, причем на столько что при загрузке данными ентерпрайз уровня дает лишь 12 FPS на железе близком к топовому, а на железе по проще вообще еле шевелится.
Мне кажется знание этого очень полезно разработчикам, решившим использовать WPF датагрид для отображения тяжелых данных. Мне бы такое знание могло бы помочь года три-четыре назад, но к сожалению попадалась только реклама того, наскольо это хороший контрол…
Поэтому я и делюсь этим знанием, я хочу чтобы мир стал лучше либо за счет того что микрософт наконец таки оптимизирует свой контрол, либо за счет того что контролом не будут пользоваться там, где он не способен справляеться с задачей.
И мне кажется, что не я один хочу этого, потому что по результатам опроса, приведенного в статье, большинство ожидает хотя бы 30 FPS от приложений.
Вопрос итератор какого из циклов за какой индекс массива будет отвечать и наличия другого кода.
cache miss, по идее должен возникать когда будет обращение к элементам массива находящимся друг от друга на расстоянии больше, чем размер кэша. То есть вложенным должен поидее быть итератор, который отвечает за итерацию по «колонкам»(с точки зрения расположения в памяти) двухмерного массива.
И другой вопрос в том как именно данный пример сравнивает С++ и C#?
Кто-то из них способен избежать эффекта cache miss?
Даже если добавить j=0, не ясно как foreach(int imemJ in items)
может стать тождественным for (int j = i; j < ITEMS_COUNT; j++)
пока идея не совсем понятна…
Я очень четко поставил себе задачу — оценить накладные расходы на «управление кодом» путем сравнения решений на С++ и С#. И как мне кажется оценку удалось получить вполне показательную.
Я буду очень рад, если вы приведете ее опровержение или же напишите сравнение по методикам которые считаете верными, мы их сможем обсудить и сделать выводы.
Приведенный вами код, не выглядит рабочим и как я понимаю, он должен увеличить j свыше размерности массива а потом скорее всего свалиться с выходом за рамки массива.
Да и выложенный цикл у вас должен быть не полным перебором, а перебором начиная с i…
С вектором была разница в зависимости от платформы (на новых разницы не было). Возможно повлияли какие-то размеры кэша или же просто различные оптимизации в аппаратной реализации процессора…
1. Я был бы очень рад увидеть результаты тестирования с .Net Native относительно С++. Хотелось бы оперировать результатами чтобы делать выводы относительно эффктивности.
2. Получается мой тест оценивает цену этой проверки с точки зрения производительности, разве это не полезно? И разумеется когда я выполняю доступ к элементу, я не всегда хочу выполнять проверку. Поэтому да — проверка в ряде случаев чистый overhead, не нужный для решения задачи.
Кстати, очень интересно, останется ли проверка в .Net Native?
3. Я хотел посмотреть на работу «не последовательного» доступа к элементам. Поэтому решил использовать алгоритм сортировки… Конечно есть и другие варианты такого доступа, но этот вариант мне показался одним из наиболее простых для восприятия и понятных.
Я конечно же делал несколько тестов, в результате отклонения были до 3-5%. Думаю это отклонение и вызвано наличием промахов по кэшу, и прочих случайных событий. Мне кажется принять его за погрешность измерений достаточно для того чтобы считать результатами достоверными, но с погрешностью.
Также я думаю что промахи по кэшу и прочие условно случайных событий для С++ и для С# будут примерно одинаковыми.
1. Согласен, но что мешает сравнивать результат компиляции? Ведь без компиляции язык не может быть выполнен, а нас интересует именно время выполнения.
2. С точки зрения решения прикладной задачи items[i] и в C++ и в C# значат одно и тоже — доступ к элементу массива. В чем вы видите разницу?
3. Я пытался. Но моя задача была не максимально быстро отсортировать массив, а максимально быстро прочитать\записать элемент массива. (в исходниках кстати есть и пример максимально быстрой сортировки, в которой С++ тоже был быстрее, но тут мы не меряем скорость сортировки)
4. Тут уже нужны конкретные примеры. Пока в статье есть только один пример с unsafe кодом, который показал схожую с С++ производительность доступа к элементам массива.
Я искренне надеюсь что данная статья способна принести пользу многим программистам.
Не знаю, возможно мне просто показался этот термин более лаконичным… я и правда часто использую его когда говорю о выделении памяти или других ресурсов…
Все-таки думаю что у С++ очень неплохие перспективы в свете падения темпов роста производительности процессоров.
64х битная версия от 32х битной мало чем отличается, но в среднем потребляет заметно больше памяти
(что вполне логично, как минимум в силу большего размера указателей)
То есть простой вывод: Хотите экономить память — ставьте 32 битный браузер.
Но автор конечно вопрос сравнения раскрыл не полностью, в том числе и относительно других особенностей использования 32 битных и 64 битных браузеров.
«когда новая версия продукта является действительно новой», к модели
«когда новая версия продукта является maintenance релизом, и по сути не имеет существенных изменений»
И если да, то связано ли это со сворачиванием разработки продукта?
Я могу ошибаться в своих предположениях, просто высказываю общее ощущение от переходов к модели ренты(в других случаях) и пытаюсь понять на сколько оно неверно.
Похоже обычные десктопные приложения нельзя построить с .NET Native, а построить можно только приложения для Windows Store. Так ли это?
1. Удалось ли понять за счет чего .NET Native несколько медленнее С++, не получалось ли сравнить disassembly?
2. Есть ли возможность использовать .NET Native с .Net Framework 4.0 (чтобы «разогнать» энтерпрайс, которому необходима поддержка XP:( )
3. Какие видятся причины для того чтобы не переходить на .NET Native с обычного managed С#?
Почему эффект cache miss будет разным для С++ и С# при работе с данными одинакового вида и использовании одинакового алгоритма обработки?
Альтернативных гридов для WPF, из более менее зрелых библиотек к сожалению не нашлось. Те что попадались были либо достаточно сырыми opensource либо тормозили не меньше стандартного.
Если знаете быстрый грид для WPF, напишите пожалуйста, ну а если не знаете, то к чему ваш посыл?
Сравнение показало, что датагрид WPF, является одним из худших по производительности, причем на столько что при загрузке данными ентерпрайз уровня дает лишь 12 FPS на железе близком к топовому, а на железе по проще вообще еле шевелится.
Мне кажется знание этого очень полезно разработчикам, решившим использовать WPF датагрид для отображения тяжелых данных. Мне бы такое знание могло бы помочь года три-четыре назад, но к сожалению попадалась только реклама того, наскольо это хороший контрол…
Поэтому я и делюсь этим знанием, я хочу чтобы мир стал лучше либо за счет того что микрософт наконец таки оптимизирует свой контрол, либо за счет того что контролом не будут пользоваться там, где он не способен справляеться с задачей.
И мне кажется, что не я один хочу этого, потому что по результатам опроса, приведенного в статье, большинство ожидает хотя бы 30 FPS от приложений.
cache miss, по идее должен возникать когда будет обращение к элементам массива находящимся друг от друга на расстоянии больше, чем размер кэша. То есть вложенным должен поидее быть итератор, который отвечает за итерацию по «колонкам»(с точки зрения расположения в памяти) двухмерного массива.
И другой вопрос в том как именно данный пример сравнивает С++ и C#?
Кто-то из них способен избежать эффекта cache miss?
foreach(int imemJ in items)
может стать тождественным
for (int j = i; j < ITEMS_COUNT; j++)
пока идея не совсем понятна…
Я буду очень рад, если вы приведете ее опровержение или же напишите сравнение по методикам которые считаете верными, мы их сможем обсудить и сделать выводы.
Да и выложенный цикл у вас должен быть не полным перебором, а перебором начиная с i…
http://www.filedropper.com/performance
Продублирую ссылку еще раз.
С вектором была разница в зависимости от платформы (на новых разницы не было). Возможно повлияли какие-то размеры кэша или же просто различные оптимизации в аппаратной реализации процессора…
2. Получается мой тест оценивает цену этой проверки с точки зрения производительности, разве это не полезно? И разумеется когда я выполняю доступ к элементу, я не всегда хочу выполнять проверку. Поэтому да — проверка в ряде случаев чистый overhead, не нужный для решения задачи.
Кстати, очень интересно, останется ли проверка в .Net Native?
3. Я хотел посмотреть на работу «не последовательного» доступа к элементам. Поэтому решил использовать алгоритм сортировки… Конечно есть и другие варианты такого доступа, но этот вариант мне показался одним из наиболее простых для восприятия и понятных.
Также я думаю что промахи по кэшу и прочие условно случайных событий для С++ и для С# будут примерно одинаковыми.
Но в целом я соглашусь с вами, в русской языке этот термин чаще используется в несколько других целях.
2. С точки зрения решения прикладной задачи items[i] и в C++ и в C# значат одно и тоже — доступ к элементу массива. В чем вы видите разницу?
3. Я пытался. Но моя задача была не максимально быстро отсортировать массив, а максимально быстро прочитать\записать элемент массива. (в исходниках кстати есть и пример максимально быстрой сортировки, в которой С++ тоже был быстрее, но тут мы не меряем скорость сортировки)
4. Тут уже нужны конкретные примеры. Пока в статье есть только один пример с unsafe кодом, который показал схожую с С++ производительность доступа к элементам массива.
Я искренне надеюсь что данная статья способна принести пользу многим программистам.
http://dic.academic.ru/dic.nsf/dic_fwords/3506/АЛЛОКАЦИЯ
http://dic.academic.ru/dic.nsf/business/605/Аллокация
Не знаю, возможно мне просто показался этот термин более лаконичным… я и правда часто использую его когда говорю о выделении памяти или других ресурсов…