Здравствуйте, Andrbig, Вы писали:
A>3d игры — во-первых, скорость для них часто критична. Во-вторых, там до черта работы с железом. Quake — очень хороший тест (!) для компа. Нет, это не приклад, это системный тест.
А ты тест того же Квака2 видел перекомпилированного под дотнет? Так вот он очень так хорошо показал, что для 3D-игр дотнет очень даже подходит.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Andrbig, Вы писали:
A>>3d игры — во-первых, скорость для них часто критична. Во-вторых, там до черта работы с железом. Quake — очень хороший тест (!) для компа. Нет, это не приклад, это системный тест.
VD>А ты тест того же Квака2 видел перекомпилированного под дотнет? Так вот он очень так хорошо показал, что для 3D-игр дотнет очень даже подходит.
Не совсем верное следствие. В том-то и дело, что он был перекомпилирован в managed code, а не портирован под .NET. Quake 2 .NET не использует .NET библиотеки (BCL, winforms, etc), не использует managed классы, не использует GC. Это скорее тест возможностей VC++ по компилированию C-кода в IL и тест для голого CLR.
Здравствуйте, alexkro, Вы писали:
A>Не совсем верное следствие. В том-то и дело, что он был перекомпилирован в managed code, а не портирован под .NET. Quake 2 .NET не использует .NET библиотеки (BCL, winforms, etc), не использует managed классы,
И что плохого могут сделать библиотеки фрэймворка?
A> не использует GC.
Слухи о тормозах ЖЦ сильно приувеличены. Не трудно провести эксперемент и убедиться, что система поколений и инкрементальная сборка мусора основанная на ней приводит к тому что процесс сборки мусора проходит очень быстро.
A> Это скорее тест возможностей VC++ по компилированию C-кода в IL и тест для голого CLR.
Весь код был полностью переведен во МСИЛ. Приложение исполнялось под управлением дотнета и компилировалось джитом. В приложениии было винформсовое окно и несколько дотнетных объектов. Что еще нужно?
Не нравится квака покляди примеры написанные на шарпе. Хочень из дайрект-икса, а хочишь найти поиском обсуждение на нашем сайте там была ссылка на движек игры специаьно адаптированный на работу с шарпом. Гдето даже были ссылки на отзывы разработчиков. Они примерно говорили следующее: "Проигрыш в скорости получаемый при использовании Шарпа и дотнета минимален и почти незаметен, при этом простота разработки резко повышается и компенсирует проблемы скорости".
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Во втором фрэймворке обернут и виртуальный режим. К тому же нет проблем написать свой виртуальный грид. Тут АПИ только проиграет.
Ну когда выйдет, тогда и посмотрим Писать-то сейчас приходится.
VD>Опять же во втором фрэймворке обернуты основные функции и не можно легко обойтись без использования ГДИ напрмямую.
Очень рад за них.
VD>Есть менеджед-дебаг-апи. Его более чем достаточно для этих целей. Просто это настолько экзотично, что моло кто о нем знает.
А вот об этом не знал. Можно ссылку?
Mab>>3) Memory mapped files. Часть проекта частично делали на MC++ , часть вообще на unmanaged C++ и подцепляли через pinvoke. VD>Это зачем же нужны MMF если есть МС++?
Э... не понял противопоставления. MMF нужны потому, что исходных данных порядка гигабайта и нужен быстрый доступ и отрисовка.
VD>Ну, и где ты видел обертки над MMF? Можно ссылочку?
Они есть в Caching Application Block.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, alexkro, Вы писали:
A>>Не совсем верное следствие. В том-то и дело, что он был перекомпилирован в managed code, а не портирован под .NET. Quake 2 .NET не использует .NET библиотеки (BCL, winforms, etc), не использует managed классы,
VD>И что плохого могут сделать библиотеки фрэймворка?
В том и дело, что этот тест ничего о них сказать не может.
A>> не использует GC.
VD>Слухи о тормозах ЖЦ сильно приувеличены. Не трудно провести эксперемент и убедиться, что система поколений и инкрементальная сборка мусора основанная на ней приводит к тому что процесс сборки мусора проходит очень быстро.
Я и не говорю, что GC медленный. Просто Quake2.NET его не использует.
A>> Это скорее тест возможностей VC++ по компилированию C-кода в IL и тест для голого CLR.
VD>Весь код был полностью переведен во МСИЛ. Приложение исполнялось под управлением дотнета и компилировалось джитом. В приложениии было винформсовое окно и несколько дотнетных объектов. Что еще нужно?
Несколько окошек и объектов — ничто по сравнению с исходным кодом Quake. Нужно: игра, полностью портированная под .NET, с исходными кодами только на C#. Что-то вроде порта Quake на Java.
VD>Не нравится квака покляди примеры написанные на шарпе.
Я не о том, что мне Quake нравится или нет. А о том, что на основании производительности Quake2 .NET нельзя делать выводы о применимости .NET для написания игр.
>Хочень из дайрект-икса, а хочишь найти поиском обсуждение на нашем сайте там была ссылка на движек игры специаьно адаптированный на работу с шарпом. Гдето даже были ссылки на отзывы разработчиков. Они примерно говорили следующее: "Проигрыш в скорости получаемый при использовании Шарпа и дотнета минимален и почти незаметен, при этом простота разработки резко повышается и компенсирует проблемы скорости".
Здравствуйте, VladD2, Вы писали:
VD>... А когда нибудь глядишь фрэймворк будет восприниматься как основное АПИ и тогда времена Вынь32 пройдут как страшный сон.
2006 год — когда это .NET хозяйство полностью укомплектуется, плюс еще 2 года на откладывание сроков и сервиспаки, обкатку, психологическую ломку итд. С 2008 по 2010 активное промышленное использование и забывание страшного сна Вынь32. Только после 2010 можно полностью забыть про Вынь32, сдать в музей.
Здравствуйте, warhast, Вы писали:
W>Здравствуйте, Andrbig, Вы писали:
A>>3d игры — во-первых, скорость для них часто критична. Во-вторых, там до черта работы с железом. Quake — очень хороший тест (!) для компа. Нет, это не приклад, это системный тест. W>Ха, с железом там работают драйвера да прослойки типа OpenGL или директа. Работает же Quake2 .NET, притом почти со скоростью оригинала (где-то 80% от нее по утверждению "переводчиков").
Так этот перевод сделала совершенно левая контора какая то Vertigo, только чтобы продемонстрировать длину своего девайса. По их словам они просто показали что могут отпортировать С код в С++ без багов и без большой потери производительности. (На MC++ в данном случае).
А если бы все изначально проектировалось в .NET стиле и писалось на С#, то скорее всего Quake , был бы пошустрее и покачественнее чем оригинал на С. (Имеется ввиду разработка за те же бюджет). Откуда бы взялось увеличение производительности?
За счет более правильной архитектуры, упрощения разработки можно было бы более сложные оптимизации провернуть. Сама по себе Quake довольно примитивная программа, не требующая высокой производительности, все 3D движок рисует, остальное довольно примитивные алгоритмы.
Здравствуйте, Kisloid, Вы писали:
K>Неужели будут переписывать весь Win API? Я думаю, что дот нет будет основываться на Вин АПИ еще долгое время =)
Ну максимум до 2010 года. А что вобще такое Win API?
— user32.dll (400килобайт),
— comctl32.dll (500K)
— gdi32.dll (200K)
— еще пару тройку.
Из-за этих козявок столько шума? Дык элементарно их переписать, сложнее программстов отучить их использовать. Сделают альтернативное API вместо них.
А если под Win API доразумеваются все файлы .dll из инсталяшки винды, тогда более тяжелый случай. Полностью винду может и не скоро перепишут.
Здравствуйте, alexkro, Вы писали:
A>Нужно: игра, полностью портированная под .NET, с исходными кодами только на C#. Что-то вроде порта Quake на Java.
Зачем нужно? В чем проблема использовать несколько языков? Там где нужны оптимизации применять МС++/С++. А основной код (особенно прикладнаую логику игры) писать на том же шарпе.
A>Я не о том, что мне Quake нравится или нет. А о том, что на основании производительности Quake2 .NET нельзя делать выводы о применимости .NET для написания игр.
Это ж почему нельзя? Код полностью менеджед. Куча менеджед-мнменеджед переходов. И все прекрасно работает. Вбил себе в голову что ЖЦ это самый главный тормоз... вот только откуда ты это взял?
Еще рез говорю. Посмотри другие примеры. Там и ЖЦ испльзуется. И никаких проблем нет.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mab, Вы писали:
Mab>Ну когда выйдет, тогда и посмотрим Писать-то сейчас приходится.
Он уже доступен. Смотри сколько влезет.
Mab>А вот об этом не знал. Можно ссылку?
Сейчас нет доступа а Интернету (пишу в офлайне) попробуй поискать на МСДН и в гугле. Если неполучится, дерни меня еще раз.
VD>>Ну, и где ты видел обертки над MMF? Можно ссылочку? Mab>Они есть в Caching Application Block.
Т.е. левая внешняя реализация? Ну, а что мешает свою сделать?
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Lloyd, Вы писали:
L>Куда переходит менеджед код, если он полностью менеджед?
А ты думешь, что вся ОС тоже менеджед? Код приложения то менеджед, а вот ввод-вывод пока что весь состоит из вызовов анменеджед-АПИ. Так что менеджед-анменеджед переходов там хватает. И как раз Ку2.нэт доказывает, что они делаются в МС++ очень эффективно. Разница с нэйтив вариантом несколько процентов. И на глаз вообще не видна.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WinterMute, Вы писали:
WM>А вы код VirtualDub видели?
Нет.
WM> Там С++, и то редко встречается, портировать это на Dot.NET бессмысленно.
Возможно... если там один ассемблер. Однако уж больно убог гуи у VD. Думаю, что если бы его делали на дотнете, то он оказался бы по приветливее. Даже в самой оптимизированой программе объем кода требующего ручной оптимизации относительно не велик и его проще выделить в отдельный модуль, а остальное написать просто, быстро и удобно, т.е. на чем-то вроде дотнета.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Он уже доступен. Смотри сколько влезет.
Смотреть -- дело одно, использоваться -- другое. Хорошо, что все это хозяйство будет во FW меньше чем через год, но куда я его воткну _сейчас_, пока релиза нет?
VD>Сейчас нет доступа а Интернету (пишу в офлайне) попробуй поискать на МСДН и в гугле. Если неполучится, дерни меня еще раз.
ОК
VD>Т.е. левая внешняя реализация?
Про сей блок ничего сказать вообще не могу -- не использовал и пока не собираюсь. В целом MS App Blocks -- неплохие примеры для изучения, если концепция устраивает, то при необходимости доводятся до кондиции руками (ну или переписываются вообще с нуля).
Есть, впрочем, и совершенно бессмысленные монстры вроде UI Process.
VD>Ну, а что мешает свою сделать?
Да мне она нафиг не нужна -- у нас MMF-ом нативная часть проекта занимается. А в managed-коде торчат уже заведомо более высокоуровневые фукнции, чем ReadByte. И нет другого выхода, потому что иначе от расходов на маршаллинг все ляжет.
Я лишь ответил на вопрос о том, бывает такое в природе или нет (кстати, откуда такой вопрос вообще возник, я не понял ): VD>Ну, и где ты видел обертки над MMF? Можно ссылочку?
Здравствуйте, VladD2, Вы писали:
VD>А ты думешь, что вся ОС тоже менеджед? Код приложения то менеджед, а вот ввод-вывод пока что весь состоит из вызовов анменеджед-АПИ. Так что менеджед-анменеджед переходов там хватает. И как раз Ку2.нэт доказывает, что они делаются в МС++ очень эффективно. Разница с нэйтив вариантом несколько процентов. И на глаз вообще не видна.
Понятно. Просто обычно "менеджед-анменеджед" говорят о смешанном коде. А это называют интеропом.
VD>Возможно... если там один ассемблер. Однако уж больно убог гуи у VD. Думаю, что если бы его делали на дотнете, то он оказался бы по приветливее. Даже в самой оптимизированой программе объем кода требующего ручной оптимизации относительно не велик и его проще выделить в отдельный модуль, а остальное написать просто, быстро и удобно, т.е. на чем-то вроде дотнета.
Если бы GUI был написан на MFC, или WTL, он тоже был бы приветливее.
