Здравствуйте, AndrewVK, Вы писали:
AVK>Фреймворк 1.1, янус в стабильном состоянии, AthlonXP 2.1ГГц. Сборка нулевого поколения 100-130 микросекунд. Сборка в самом тяжелом состоянии — 240 микросекунд.
Ну вот! Это уже вполне разумные величины. Всего-то надо было померить. И никаких Urban Legends про 10 ms.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, AndrewVK, Вы писали:
AVK>Фреймворк 1.1, янус в стабильном состоянии, AthlonXP 2.1ГГц. Сборка нулевого поколения 100-130 микросекунд. Сборка в самом тяжелом состоянии — 240 микросекунд.
А как меряешь?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Вот ссылка на сравнение двух 3D-движков. Ogre — исходный движек писанный на С++. Axiom — C#-порт Ogre.
Transparency, Overlays Off
A - Average: 343.648800 Best: 372.639700 Worst: 271.316500
A - Average: 343.435300 Best: 423.982700 Worst: 267.801300
O - Average: 324.679688 Best: 325.349304 Worst: 0.789266
O - Average: 320.316376 Best: 438.123749 Worst: 0.809061
Что-то тут не так с Worst FPS. Я готов допустить, что при некоторых условиях C# работает даже быстрее. Но чтобы он работал быстрее в 400 раз — не верю, ибо это противоречит законам природы и нарушает причинно-следственные связи . Следовательно, это не просто "порт", это существенная алгоритмическая переработка, позволившая достичь подобных результатов. Возможны так же разные исходные условия (разные видеоадапторы), так же не исключен вариант банальной алгоритмической ошибки (O(N^2) вместо O(N log N)) в исходном движке, исправленной в версии C#. В любом случае, данные тесты являются методологически некорректными.
Так что, внимательней надо быть с выбором сравнительных тестов.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
VD>Ну, проблемы неграмотного кода никто устронять не собирался. Диспоз вообще по идее не должнен генерировать исключений. И уж если ты работаешь с ресурсами в диспозе, то ставь using или try/catch|finally защищающие код.
Гы, а что мешает делать то же самое в С++?
MS>Что-то тут не так с Worst FPS. Я готов допустить, что при некоторых условиях C# работает даже быстрее. Но чтобы он работал быстрее в 400 раз — не верю, ибо это противоречит законам природы и нарушает причинно-следственные связи .
Думаю, просто пофиксили глюки.
MS> Следовательно, это не просто "порт", это существенная алгоритмическая переработка, позволившая достичь подобных результатов.
Естественно. Они над этим и работают.
MS> Возможны так же разные исходные условия (разные видеоадапторы), так же не исключен вариант банальной алгоритмической ошибки (O(N^2) вместо O(N log N)) в исходном движке, исправленной в версии C#. В любом случае, данные тесты являются методологически некорректными.
Какая разница? Тут речь идет о невозможности применения Шарпа в 3D играх. Этот движок хорошо доказывает, что эти слова бред. И что намного больше зависит от качества алгоритмов чем от накладных затрат дотнета. Так что эти тесты как нельзя лучше показывают несостоятельность позиции ПК и его сторонников. А что до "методологически некорректными", они сравнивают две версии одного движка. Естественно на одинаковом железе и при одинаковых условиях (обратное твои домыслы), и делают они это совершенно корректно. То что их алгоритмы лучше не умаляет качества движка.
MS>Так что, внимательней надо быть с выбором сравнительных тестов.
Внимательнее надо быть с чтением тем. Смысл нужно улавливать.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Тут речь идет о невозможности применения Шарпа в 3D играх.
Хм, а разве кто-то это утверждал?
P.S.: А ты знаешь, что объем рынка игр для PC уже сейчас составляет около семи процентов и с каждым годом он неумолимо падает? Ну и о какой конкуренции шарпа с плюсами в компьютерных играх после этого вообще можно говорить? Ну займет он в лучшем случае один процент (хотя и в это слабо верится), а 99% достанется С++'у!!!
Здравствуйте, VladD2, Вы писали:
VD>А что до "методологически некорректными", они сравнивают две версии одного движка. Естественно на одинаковом железе и при одинаковых условиях (обратное твои домыслы), и делают они это совершенно корректно. То что их алгоритмы лучше не умаляет качества движка.
Что-то у тебя с логикой не лады. "Две версии одного движка" никак не могут дать столь существенной разницы при условии идентичности алгоритмической части. Следовательно, используемые алгоритмы существенно отличаются, следовательно, сравнение производительности с точки зрения используемых компиляторов — некорректно. Иными словами, мы должны сравнивать, наколько GC влияет на производительность, а мы сравниваем разные алгоритмы. Так понятней?
Да и вообще, поменьше бы агрессивности.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, prVovik, Вы писали:
V>Здравствуйте, VladD2, Вы писали:
VD>>Тут речь идет о невозможности применения Шарпа в 3D играх. V>Хм, а разве кто-то это утверждал?
Утверждал. Я незнаю, что ты под этим имеш ввиду, но тут ПК вот утверждает, что это делать нельзя, а то что это не только возможно но и удобно утверждает как минимум та игра которая прекрасно наботает будучи написанная на этом самом нжте.
V>P.S.: А ты знаешь, что объем рынка игр для PC уже сейчас составляет около семи процентов и с каждым годом он неумолимо падает?
7% чего?
V> Ну и о какой конкуренции шарпа с плюсами в компьютерных играх после этого вообще можно говорить? Ну займет он в лучшем случае один процент (хотя и в это слабо верится), а 99% достанется С++'у!!!
Ты бы привел хоать какие-то ссылки подтверждающие свои слова. Я вот припоминаю информацию из Игромании... там вроде бы говорилось, что рынок PC-игр постоянно растет. И что миллионы стали срывать даже игры второго эшелона.
К тому, же почти все игры выходящие на ХБоксе выходят и на PC. Так что закат этому рынку не грозит.
Ну, и самое главно — это чистеший офтоп. Размеры рынка неимеют никакого отношения к возможности или невозможности создания игр на том же C#.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, McSeem2, Вы писали:
MS>Что-то у тебя с логикой не лады.
У меня то с ней все впорядке...
MS> "Две версии одного движка" никак не могут дать столь существенной разницы при условии идентичности алгоритмической части.
А зачем нужно "условие идентичности алгоритмической части"? Все и без того более чем можно сравнивать.
Если бы Шарп и дотнет имели какие-то серьезные недостатки, то они стабильно бы были в поной заднице по всем пунктам. Ну, а то что они иногда вырываются вперед очень сильно говорит как раз о том, что в Шарповской версии применены лучшие алгоритмы или контейнеры.
MS> Следовательно, используемые алгоритмы существенно отличаются, следовательно, сравнение производительности с точки зрения используемых компиляторов — некорректно.
Корректно сравнение двух версий. Версия написаная на Шарпе явно в основном лучше. Что несколько странно для портированного продукта.
Ну, а я указываю именно на то, что этот факт четко демонстрирует, что на Шарпе не просто возможно писать 3D игры, но и возможно писать игры как минимум конкурирующие с анменеджед-аналогами.
MS> Иными словами, мы должны сравнивать, наколько GC влияет на производительность, а мы сравниваем разные алгоритмы. Так понятней?
Это самотря какова цель сравнения. Ести мы хотим сравнить проиводительность 100%-но аналогичного кода (что в принципе тяжело из-за использования разных парадигм), то конечно такое сравнение некорректно и нужно делать тесты вроде тех что были в Шустриках
Но если мы хотим сравнить возможность производства конкурентно-способных 3D-игн на дотнете, то это очень подходящий полигон для сравнения. Ну, и 100%-но корректным является сравнение двух продуктов решающих одни и теже задачи, но созданных на базе разных технлогий.
Ты вот лучше задумайся как оказалось так, что вроде как потенциально более медленных код, имеющий единого предка, и написанный вроде как на более медленном средстве и насанный не очень крутыми перцами (если верить мифам о том, что крутые перцы работают только на С/С++) оказался во многих случаях шустрее С++-ного аналога?
Случайность это или закономерность? А может кроме замедления связанного с GC, лишними байтами в структуре объектов и т.п. есть и другие факторы влияющие не возможность создания более быстрого продукта? Может быть среди них есть такие вещи, как простота и чистота дизайна, качество и количество базовых библиотек, модульность, простота отладки и скорость компиляции, ну, и многое другое? И может быть по этим параметрам С++ мягко говоря недотягивает?
MS>Да и вообще, поменьше бы агрессивности.
Я совершенно не агрессивен. Так что если из тебя прет агрессия, не нужно приписывать ее другим.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, prVovik, Вы писали:
VD>>Ну, проблемы неграмотного кода никто устронять не собирался. Диспоз вообще по идее не должнен генерировать исключений.
VD>>И уж если ты работаешь с ресурсами в диспозе, то ставь using или try/catch|finally защищающие код. V>Гы, а что мешает делать то же самое в С++?
Тут вроде бы уже 100 раз это говорили. Теоритически ничего. Практически весь дизайн языка.
Ну, давай еще раз по пунктам:
1. Повторная генерация исключения в диспозе или вообще не приводит к фатальным проблемам, или приводит обычно к потере одного ресурса, так как остальные диспозы вызываются из любого положения. При этом с огромной долей вероятности потерянный ресурсный объек реализует и финалайзер, так что он будет подобран при первой же сборке мусора. Если он не успел попасть в первое поколение, то это вопрос нескольких десятых долей секунды (максимум секунд). В С++ же повтораное генерирование исключений обычно приводит к вылету всейго приложения. Именно по этому при малейшем сборее мы видим AV-диалоги у большинства приложений окружающих нас сегодня.
2. Необходимость ручного контроля в С++ не только за ресурсами ОС, но и за любыми динамически занятыми областями памяти. Это приводит или к ловле ликов и попыткам "окуратного" программирования, или к наклепыванию оберток на каждый чих. Четыре года назад наша контора придерживалась второго подхода, но тем не менее в конце концов пришлось писать нехилую систему отлова утечек памяти и в общемй сложнсоти убить не млао времяни на отладку в общем-то рабочего кода.
3. Отсуствие того же finally.
4. Ненацелленность многих С/С**-библиотек на автоматический контроль ресурсов. Вспомним хотя бы CreateFile или fopen.
Для того чтобы просто не получить кучи проблем, программист должен постоянно придерживаться целой кучи паттернов оберегающих его от граблей, и по стуи избегать тех самых мощьных возможностей С++, коими многие так часто гордятся. В итоге мы получаем ситуацию, ктода для написания одного и того же кода (что с точки зрения функциональности, что с точки зрения производительности) нам требуется соврершенно разный уровень квалификации программиста, совершенно разное время на решение задачи, и совершенно разное количество усилий.
Остается только один вопрос... Нафига козе баян?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Если бы Шарп и дотнет имели какие-то серьезные недостатки, то они стабильно бы были в поной заднице по всем пунктам.
С чего это вдруг такой абсурдный вывод?!
Я могу легко привести примеры кода (разного, но решающего одну и ту же задачу) и доказать, что код на javascript в IE даст фору C++ в 400 или более раз. Что с того? Повторяю — код разный.
VD>Ну, а то что они иногда вырываются вперед очень сильно говорит как раз о том, что в Шарповской версии применены лучшие алгоритмы или контейнеры.
Это говорит лишь о том, что "в Шарповской версии применены лучшие алгоритмы или контейнеры". Иными словами, это ничего не говорит о свойствах самого языка. См. аргумент выше.
Влад, всем уже давно понятно, что C# круче вареных яиц. Я лишь возражаю против подобной постановки вопроса: "С# круче вареных яиц, потому что некие люди решили некую прикладную задачу на нем в 400 раз быстрее, чем она когда-то однажды была решена на C++." См. аргумент выше.
Иными словами, это ничего не говорит ни в пользу C# ни против него. С формальной логикой у тебя все-таки не лады
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, VladD2, Вы писали:
VD>Утверждал. Я незнаю, что ты под этим имеш ввиду, но тут ПК вот утверждает, что это делать нельзя,
Честно говоря, не замечал за ним таких утверждений... Он вроде бы говорил только о применимости конкретно ГЦ, а не платформы вцелом.
И вообще, тот факт, что есть игра на С# сам по себе еще ни о чем не говорит. Потому, что:
1) стратегии — это такой жанр игр, в которых не требуется постоянный высокий фпс. Он может падать хоть до 10, и при этом пользователь не заметит особого дискомфорта. Более показательны в этом смысле были бы, например, шутер, или автосимулятор.
2) мы не знаем, как она работает, а именно — исползуется ли активно там ГЦ во время игрового процесса. Может там "operator new" вызывается только во время загрузки?
V>>P.S.: А ты знаешь, что объем рынка игр для PC уже сейчас составляет около семи процентов и с каждым годом он неумолимо падает? VD>7% чего?
От общего объема рынка компьютерных игр. Ну про 7 процентов я, наверное, загнул , но процентов 10 есть...
VD>Ты бы привел хоать какие-то ссылки подтверждающие свои слова.
А вот со ссылками трабл. Дело в том, что подобная информация стоит много денег . Но кое-что все-таки нашлось:
1)Вот эта картинка: http://www.jiad.org/vol4/no1/chou/chou_files/table1.gif
из статьи http://www.jiad.org/vol4/no1/chou/#AUnified
Ну и общая информация:
2) http://www.gamespot.com/all/news/news_6085583.html
3) http://www.release.ru/soft/newslog/2003/12/17/000820.html?m=comments
VD>Я вот припоминаю информацию из Игромании... там вроде бы говорилось, что рынок PC-игр постоянно растет. И что миллионы стали срывать даже игры второго эшелона.
Ты, наверное, путаешь рынок PC-игр, с рынком игр вообще, который, действительно сильно растет, и обогнал уже, кстати, рынок киноиндустрии!!!
VD>К тому, же почти все игры выходящие на ХБоксе выходят и на PC. Так что закат этому рынку не грозит.
Правильно, но замечу, что, даже, на ХБоксе игры пишутся совсем не на шарпе
VD>Размеры рынка неимеют никакого отношения к возможности или невозможности создания игр на том же C#.
Влад, на С# МОЖНО делать игры, и на VB их тоже делать можно, и, даже, на JScript. Но разговор не об этом...
VladD2,
> VD>>Тут речь идет о невозможности применения Шарпа в 3D играх.
> V> Хм, а разве кто-то это утверждал?
> Утверждал. Я незнаю, что ты под этим имеш ввиду, но тут ПК вот утверждает, что это делать нельзя
Ну что за манера подменять позицию собеседника?.. Этого я не утверждаю и не утверждал. Речь шла о проблемах, которые может вызывать GC. Еще в первом сообщении на эту тему было указано, что проблемы решаемые.
P.S. На этом я данное обсуждение с тобой закачиваю, если, конечно, вдруг, не последует какая-то новая информация.
Posted via RSDN NNTP Server 1.9 delta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, AndrewVK, Вы писали:
AVK>Фреймворк 1.1, янус в стабильном состоянии, AthlonXP 2.1ГГц. Сборка нулевого поколения 100-130 микросекунд. Сборка в самом тяжелом состоянии — 240 микросекунд.
А сколько штук объектов обрабатывается в этом цикле?
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
ГВ>>А сколько штук объектов обрабатывается в этом цикле? AVK> Я ж говорю — реальное работающее приложение в стабильном состоянии.
Тогда этот замер ничем не поможет в оценке произаодительности.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
AVK>Я так понимаю вас не устроит любой тест, не доказывающий что .net это полный отстой?
А что, разве в этом топике был представлен хоть один тест, который что-то доказывал?
Ты сказал, что именно в янусе сборка мусора занимает не много времени. Ну замечательно. Как-бы никто и не спорил, что на .net'e можно писать программы... А тесты то где?
. Следовательно, это не просто "порт", это существенная алгоритмическая переработка, позволившая достичь подобных результатов. Возможны так же разные исходные условия (разные видеоадапторы), так же не исключен вариант банальной алгоритмической ошибки (O(N^2) вместо O(N log N)) в исходном движке, исправленной в версии C#. В любом случае, данные тесты являются методологически некорректными.
, но процентов 10 есть... 
. Но кое-что все-таки нашлось:
Я ж говорю — реальное работающее приложение в стабильном состоянии.