>Чтение нежатого видео с диска.
Тут упремся в железо без вариантов. Если есть возможность видео лучше пожать.
>Сканирование большого объема фотографий в поисках нужного тега.
Есть смысл построить индекс на теги. Или хотябы испрользовать SSD, на HDD это будет работать более-менее быстро только на втором поиске, когда он прокэшируется.
>HDD 80МБ в секунду? Да вы оптимист, реально для HDD рассчитывать на 10мб в секунду в лучшем случае.
У меня HDD без проблем выдает 80МБ в секунду. Мне сложно представить где взять HDD, который выдаст только 10мб в секунду. Если только по USB 1.1 его подключить :)
>Чем это было обосновано?
В обоих случаях ASP.NET приложения были слишком ориентированы на исползование в Windows окружениии под IE.
И когда доля Windows и IE в целевом сегменте начала резко падать, оказалось не рентабельным делать эти приложения работающими на остальных браузерах, включая мобильные платформы.
То есть можно сказать что развитие мобильных платформ явилось причиной по которой данные приложения потеряли свою долю на рынке.
>Как вообще на C++ решается если кто-то начинает перетирать память ваших переменных случайным образом (из-за ошибки в указателе, итераторе и т.п.), а кол-во нового кода слишком велико чтобы его как-то вручную проверить за обозримое время?
Отладка под gflags, с page heap флагами позволят поймать большинство таких проблем
>Тогда почему сейчас, по вашим словам, мало хороших и удобных веб-фреймворков на C++? Раз все так изменилось?
Фреймворки уже написаны по большей части и пока они справляются, оптимизировать их нет нужды. Поэтому и вкладываться в оптимизацию на C++ пока нету резона.
Запрос на оптимизацию такого рода, видимо еще не созрел.
>контрол от DevExpress
У DevExpress медленно работали Tabbed groups, Grid, Property Grid
Чего там в Дойче я не знаю, но у меня тормозит именно WPF, например у моем обычном wpf датагриде нет никаких ObservableCollection, но как только там появляется больше 1000-2000 элементов он начинает тормозить.
Я его профайлил — тормозит обход дерева визуальных элементов и многократные вызовы Measure.Я незнаю зачем так часто и в таком количестве мерить ячейки грида, но я знаю что мой код в этом процессе не вызывался.
>Ты хоть представляешь как сделать так, чтобы приложение на C++ не тупило пока получает данные по сети. Причем кроссплатформенно?
Элементарно. Используй потоки они кросплатформенны (#include )
>Только это не асинхронный код ;)
Чем же он не асинхронный? И какой-же он тогда? синхронный?
>Неужели нельзя было сделать изоляцию? Очевидно, что можно — почему не сделали?
Если реализовывать изоляцию, то она сделает из С++ кода управляемый код, и все возможные преимущества будут съедены этой «изоляцией», т.е. издержки производительности от изоляции сведут на нет ее смысл.
>Это типовые задачи для программирования вообще — и вы говорите, что они решаются на C++ дороже, чем на других языках? Вы уверены?
Я говорю что они раньше, 15 лет назад, решались заметно дороже. Сейчас ситуация другая, 15 лет назад даже boost-а не было…
>Или в чем-то совершенно другом — например, в том, что предполагаемые преимущества от использования C++ не оправдывают всего связанного с ним геморроя?
Да. На тот момент совокупное решение было именно таким. Но с того момента прошло немало времени, мир несколько изменился. Часть С++ гемороя ушла, а фаза галопирующего роста IT направления подходит(а может и подошла) к концу. Вполне возможно что все это вызовет переоценку приоритетов.
>Теоретически ты глядя на код на языке X можешь написать аналогичный на языке Y. А вот Xamarin делает это практически, конвертируя .NET в код для iOS.
Если конвертировать до компиляции, то да, это реально, но я бы не стал называть .net приложением, то что получится в результате этой конвертации. И я не уверен что конверсия кода до компиляции это очень эффективный подход…
>если переписать android приложение на C++, то оно будет быстрее работать?
Если в приложении есть участки критичные к производительности то их перепись на С++ ускорит приложение.
>нет в C++ средств делать асинхронный код
Это ложь. В С++ можно создавать потоки и запускать в них асинхронно все что вам нужно.
>С чего вы взяли что у WPF низкая производительность?
Из собственной практики, я даже примеры привел.
>На нем например пишется софт для трейдеров в Дойче Банке ЕМНИП?
Я очень сильно этому удивился. Может это попил какой-то…
>Telerik
Вполне возможно он заметно быстрее DevExpress, но базовую тормозню WPF он вряд-ли уберет.
>Если вы сталкивались с посредственными результатами — не означает, что .Net медленный
Не подскажите альтернативную UI библиотеку под .net без проблем с производительностью?
>Вся конверсия выполняется при компиляции
Ведь неправда же. Это невозможно реализовать, ведь на этапе компиляции еще нет данных для конверсии, они появляются только в рантайме. Вы же не с константными параметрами вызовы делаете.
>Тока почему-то все пишут на жабе.
Кому нужно по-быстрому написать, а производительность приложения не критична — пишут. Их большинство возможно, но никак уж не «все».
По библиотекам насчет Qt поддерживаю — решает все эти задачи.
По второму пункту еще могу предложить Boost.Asio.
А типизированный доступ к базам данных есть даже в древнейшем odbc (хотя конкретно для него пул для асинхронного запуска придется написать руками :( )
Насчет поиска в google, я как вы наверное догадались искал, просто читать всю выборку в поисках особенностей построения и дебага достаточно долго. Поэтому и задал вам вопросы, как человеку вероятно использующего данную технологию.
Односложных ответов мне бы хватило, что сэкономило бы немного и вашего время и моего времени, но тут ваше право.
>И? Причем тут выводы о быстродействии .Net на основе левой либы?
Я видел и другие библиотеки .net, которые не поразили меня своей производительностью.
Например возьмем WPF, вы тоже скажете что это пример говнокода?
Если нет, то почему у нее такая низкая производительность?
Попробуйте создать какой-нибудь форматированный датагрид с тысячей-другой элементов. Навигация по ячейкам этого грида будет идти крайней медленно, вы можете шаманить с отключением и включением виртуализации, но сильно это не поможет отзывчивость приложения будет никакой.
Или например WPF рибон, в каком-нибудь автокаде или вашем приложении. Почему переключение между табами идет так долго?
А если взять какую-нибудь библиотеку WPF контролов, например DevExpress, то там с производительностью все будет еще раза в 2 хуже.
Вы можете сказать что C# в этом не виноват, что .net в этом тоже не виноват.
Хорошо, а кто тогда виноват в столь низкой производительности WPF?
>В iOS идет напрямую (внезапно!)
Прямо без конверсий типы .net ложатся на типы iOS?
>В Android код обращается к java-либам, так же как любое приложение на android.
На самом деле модули Android NDK могут делать вызовы напрямую, без Java
>Тогда откуда уверенность что это вообще куча, а не кучка?
Скажем так. Практический под любую _общую_ задачу (например задачу уровня реализованных в .net) мне удавалось найти библиотеку на С++ с помощью google :)
Конечно я не все задачи пробовал, но если вы найдете общую задачу для которой нет библиотек на С++, но есть на С# было бы о ней очень интересно узнать.
>Вы не думали что просто через одно место написана?
Никакой другой .Net библиотеки решающей ту же задачу я не нашел. Вообще.
>Вот небольшой пример — Debunking C# vs C++ Performance
Это же чистая синтетика в вакууме, работающая сама с собой.
В реальных же задачах нужно достаточно часто работать с системой, где и случаются основные провалы у С# на маршалинге
>.Net Native.
Интересно. Пара глупых вопросов по нему: как его потом дебажить? И можно ли заставить студию строить прямо в него, а не в IL?
>В общем можете почитать достаточно подробные ответы на SO — C++ performance vs. Java/C#
Кажется читал как-то, но ссылка хорошая, спасибо.
Изоляция ОС от прикладных приложений конечно есть, но вот изоляция внутри прикладного приложения уже отсутсвует, а веб сервер это прикладное приложение, пусть даже и сервис. И завалить его из кода выполняемого на сервере можно. (хотя думаю что при должном старании можно завалить и iis из asp.net кода, но вероятность написания такого кода для стандартных задач невысока)
С другой стороны можно просто перезапустить сервер чтобы обойти проблему… возможно она не такая страшная.
Возможно еще роль в распространении PHP (и других managed сред) для Web сыграло отсутствие для С++ библиотек, которые позволяют быстро решать задачи web разработки,
на момент роста Web-а. То есть 15 лет назад, задачи парсинга, работы с XML и регулярными выражениями на С++ решались существенно дороже, особенно если говорить о кросплатформенном решении, а не использовании
За 15 лет конечно библиотек решающих все эти задачи стало намного больше, но ниша уже была занята, возможно дело в этом…
Тут упремся в железо без вариантов. Если есть возможность видео лучше пожать.
>Сканирование большого объема фотографий в поисках нужного тега.
Есть смысл построить индекс на теги. Или хотябы испрользовать SSD, на HDD это будет работать более-менее быстро только на втором поиске, когда он прокэшируется.
У меня HDD без проблем выдает 80МБ в секунду. Мне сложно представить где взять HDD, который выдаст только 10мб в секунду. Если только по USB 1.1 его подключить :)
В обоих случаях ASP.NET приложения были слишком ориентированы на исползование в Windows окружениии под IE.
И когда доля Windows и IE в целевом сегменте начала резко падать, оказалось не рентабельным делать эти приложения работающими на остальных браузерах, включая мобильные платформы.
То есть можно сказать что развитие мобильных платформ явилось причиной по которой данные приложения потеряли свою долю на рынке.
Но основная причина, действительно в том что в вебе С++ пока не нужен.
Отладка под gflags, с page heap флагами позволят поймать большинство таких проблем
msdn.microsoft.com/en-us/library/windows/hardware/ff549557(v=vs.85).aspx
Фреймворки уже написаны по большей части и пока они справляются, оптимизировать их нет нужды. Поэтому и вкладываться в оптимизацию на C++ пока нету резона.
Запрос на оптимизацию такого рода, видимо еще не созрел.
У DevExpress медленно работали Tabbed groups, Grid, Property Grid
Чего там в Дойче я не знаю, но у меня тормозит именно WPF, например у моем обычном wpf датагриде нет никаких ObservableCollection, но как только там появляется больше 1000-2000 элементов он начинает тормозить.
Я его профайлил — тормозит обход дерева визуальных элементов и многократные вызовы Measure.Я незнаю зачем так часто и в таком количестве мерить ячейки грида, но я знаю что мой код в этом процессе не вызывался.
>Ты хоть представляешь как сделать так, чтобы приложение на C++ не тупило пока получает данные по сети. Причем кроссплатформенно?
Элементарно. Используй потоки они кросплатформенны (#include )
>Только это не асинхронный код ;)
Чем же он не асинхронный? И какой-же он тогда? синхронный?
Если реализовывать изоляцию, то она сделает из С++ кода управляемый код, и все возможные преимущества будут съедены этой «изоляцией», т.е. издержки производительности от изоляции сведут на нет ее смысл.
>Это типовые задачи для программирования вообще — и вы говорите, что они решаются на C++ дороже, чем на других языках? Вы уверены?
Я говорю что они раньше, 15 лет назад, решались заметно дороже. Сейчас ситуация другая, 15 лет назад даже boost-а не было…
>Или в чем-то совершенно другом — например, в том, что предполагаемые преимущества от использования C++ не оправдывают всего связанного с ним геморроя?
Да. На тот момент совокупное решение было именно таким. Но с того момента прошло немало времени, мир несколько изменился. Часть С++ гемороя ушла, а фаза галопирующего роста IT направления подходит(а может и подошла) к концу. Вполне возможно что все это вызовет переоценку приоритетов.
Если конвертировать до компиляции, то да, это реально, но я бы не стал называть .net приложением, то что получится в результате этой конвертации. И я не уверен что конверсия кода до компиляции это очень эффективный подход…
>если переписать android приложение на C++, то оно будет быстрее работать?
Если в приложении есть участки критичные к производительности то их перепись на С++ ускорит приложение.
>нет в C++ средств делать асинхронный код
Это ложь. В С++ можно создавать потоки и запускать в них асинхронно все что вам нужно.
Из собственной практики, я даже примеры привел.
>На нем например пишется софт для трейдеров в Дойче Банке ЕМНИП?
Я очень сильно этому удивился. Может это попил какой-то…
>Telerik
Вполне возможно он заметно быстрее DevExpress, но базовую тормозню WPF он вряд-ли уберет.
>Если вы сталкивались с посредственными результатами — не означает, что .Net медленный
Не подскажите альтернативную UI библиотеку под .net без проблем с производительностью?
Ведь неправда же. Это невозможно реализовать, ведь на этапе компиляции еще нет данных для конверсии, они появляются только в рантайме. Вы же не с константными параметрами вызовы делаете.
>Тока почему-то все пишут на жабе.
Кому нужно по-быстрому написать, а производительность приложения не критична — пишут. Их большинство возможно, но никак уж не «все».
По библиотекам насчет Qt поддерживаю — решает все эти задачи.
По второму пункту еще могу предложить Boost.Asio.
А типизированный доступ к базам данных есть даже в древнейшем odbc (хотя конкретно для него пул для асинхронного запуска придется написать руками :( )
Односложных ответов мне бы хватило, что сэкономило бы немного и вашего время и моего времени, но тут ваше право.
>И? Причем тут выводы о быстродействии .Net на основе левой либы?
Я видел и другие библиотеки .net, которые не поразили меня своей производительностью.
Например возьмем WPF, вы тоже скажете что это пример говнокода?
Если нет, то почему у нее такая низкая производительность?
Попробуйте создать какой-нибудь форматированный датагрид с тысячей-другой элементов. Навигация по ячейкам этого грида будет идти крайней медленно, вы можете шаманить с отключением и включением виртуализации, но сильно это не поможет отзывчивость приложения будет никакой.
Или например WPF рибон, в каком-нибудь автокаде или вашем приложении. Почему переключение между табами идет так долго?
А если взять какую-нибудь библиотеку WPF контролов, например DevExpress, то там с производительностью все будет еще раза в 2 хуже.
Вы можете сказать что C# в этом не виноват, что .net в этом тоже не виноват.
Хорошо, а кто тогда виноват в столь низкой производительности WPF?
Прямо без конверсий типы .net ложатся на типы iOS?
>В Android код обращается к java-либам, так же как любое приложение на android.
На самом деле модули Android NDK могут делать вызовы напрямую, без Java
>Тогда откуда уверенность что это вообще куча, а не кучка?
Скажем так. Практический под любую _общую_ задачу (например задачу уровня реализованных в .net) мне удавалось найти библиотеку на С++ с помощью google :)
Конечно я не все задачи пробовал, но если вы найдете общую задачу для которой нет библиотек на С++, но есть на С# было бы о ней очень интересно узнать.
Для С++ вызов того же winapi не отличается от родного вызова, то есть может быть написан без конверсий вообще, вот собственно и весь черный ход)
Никакой другой .Net библиотеки решающей ту же задачу я не нашел. Вообще.
>Вот небольшой пример — Debunking C# vs C++ Performance
Это же чистая синтетика в вакууме, работающая сама с собой.
В реальных же задачах нужно достаточно часто работать с системой, где и случаются основные провалы у С# на маршалинге
>.Net Native.
Интересно. Пара глупых вопросов по нему: как его потом дебажить? И можно ли заставить студию строить прямо в него, а не в IL?
>В общем можете почитать достаточно подробные ответы на SO — C++ performance vs. Java/C#
Кажется читал как-то, но ссылка хорошая, спасибо.
С другой стороны можно просто перезапустить сервер чтобы обойти проблему… возможно она не такая страшная.
Возможно еще роль в распространении PHP (и других managed сред) для Web сыграло отсутствие для С++ библиотек, которые позволяют быстро решать задачи web разработки,
на момент роста Web-а. То есть 15 лет назад, задачи парсинга, работы с XML и регулярными выражениями на С++ решались существенно дороже, особенно если говорить о кросплатформенном решении, а не использовании
За 15 лет конечно библиотек решающих все эти задачи стало намного больше, но ниша уже была занята, возможно дело в этом…