С# и Xna - революция в игросторении.
 

Люди почему вы прогаете на всяких Delphi и ВизуалБарсиках? Ладно я понимаю тех кто на С++ прогает. Надо смотреть в будушие. Вот как выйдет Singularity(Ну или её потомок) чего будете делать? Если вы думаете что там будет P-code(родной Visual Basic(Который не .NET)) - нет не будет. А вдруг вы думаете что там будет native код(Delphi, C++,...) - нет она будет написана целиком и полностью на C#. И только несколько мегабайт остального кода, да и то не объектно ориентированого(это через p/Invoke, или его потомок). Язык C# очень элегантен - даже у криворукого программера получится красивый код. Язык C# быстрей чем Delphi и даже С++(Если кто несогласен я вам расскажу много нового :) ). В нем нет утечек памяти, есть возможность пользоватся указателями, референс типы заместо тех же поинтеров - это делает vс# быстрой - лёгкой - безопасной средой разработки. Xna это надстройка над DirectX 9.0. Она очень легкая и быстродействующая. В ней есть конвейр-контента(!). Ну может сейчас её использовать не стоит - ибо она только бета. Но в рождество будет всё ок.

Что значит "лёгкая и быстродейсвующая"? Молодой человек, XNA ещё очееень далеко до Direct3D 10 и OpenGL 2.0. Может просто С++ выучить не могите? м?

Всё. Холивар. С++ намного быстрее. На 35%. Это не моя цифра - это microsoft. Учи матчасть %)

Судя по вашей речи - вы не имеете никакого отношения к программерам. "С++ медленнее С#" - бред! Код исполняемый в интерпритаторе не может быть впринципе быстрее бинарного.

О, да! Еще один "великий программер" пришел всех учить!
Fulcrum абсолютно прав. Добавлю, что я пробовал писать 3D игру на C#. Результат - проект закрылcя в самом начале. К счастью. Так что я имею представление о быстродействии этого чуда. C# - это язык для написания, возможно, офисных программ, но ни в коем случае не требовательных к ресурсам приложений. Отсутствие заботы о памяти - не достоинство, а недостаток. Из него, а также из использования байт-кода, вытекает жутко медленная скорость работы, а также потребление лишней этой самой памяти - ведь объекты удаляются не сразу, а когда до них дойдет функция очистки. А за это время может еще понадобится наплодить объектов... Да и не будем забывать, что все функции в C# виртуальные! Кроме того, пиша программы на C#, Вы ставите себя в зависимость от Framework'. Если там вдруг будет глюк (что у Майкрософта не редкость) - все, программа накрылась медным тазом.
Если у Вас код на C# оказался быстрее кода на C++... Уж не знаю, что Вы такое сделали, что так могло получится... Бесконечный цикл, что ли, пытались выполнить :sml:. Может, просвятите?
Сейчас долго думал, и все же пришел к выводу, что для обучения программированию C# тоже не очень подходит. То же отсутствие заботы о памяти может здорово навредить программисту, если он после C# возьмется осваивать, например, C++...

P.S. А автору темы рекомендую попробовать Prolog или Mercury. Вот уж действительно дружественные к программисту языки! Все подчинено логике, задачи поиска реализуются элементарно, да и все остальные тоже. А если кто-то напишет 3D игру на одном из этих языков (и она будет выдавать больше пары FPS), то напишите мне - любопытно будет посмотреть на это чудо!

Судя по вашей речи - вы не имеете никакого отношения к программерам. "С++ медленнее С#" - бред! Код исполняемый в интерпритаторе не может быть впринципе быстрее бинарного.

Так похоже вы ничего не знаете о платформе .NET.
я сказал же (Если кто несогласен я вам расскажу много нового)
вот начнем.

C#(.NET вообщем) это не ИНТЕРПРЕТИРУЕМАЯ а компилирумая в оптимизизированый к конкретному процесору и памяти, код прямо на машине клиента(Конечного юзера) среда. Есть два вида компиляции.

1) JIT - just-in-time это значит что вся програма компилируется во время выполнения. Вот это и есть ваши "На 35%". Я использую только для дебага.

2) AOT - Ahead-of-time это значит что прога компилируется прямо в нейтивный код во время устоновки. Времени занимает не очень много.Для увесистой проги это секунд 10 на pIII 800 MHz.

"Судя по вашей речи - вы не имеете никакого отношения к программерам."

Я прогаю уже 2 года на уже 4 языках и остановил свой выбор на C#.


Итог - сам учи матчасть


Про бесконечный цикл спасиб :) . Я же написал что этот байт код компилируется в найтив в стартапе (AOT). И значит никакого байт кода. Ну если только метаданные да и только если вас вдруг приспичит юзать
System.Reflection

Два года???? :lol:
О, ну тогда не нам, жалким ламерам, программирующим по восемь лет, Вас учить! Не подскажите, какой институт окончили, или Вы еще в школе?
А теперь о том, почему C# в принципе не может быть быстрее кода на C++:
1) Уборка памяти: как может код, который постоянно обходит все объекты и проверяет, не достигло ли количество ссылок на них 0, может быть быстрее кода, этого не делающего?
2) Как может код, компилирующийся во время выполнения (почти интерпритация!) может быть быстрее кода, этого не делающего?
3) Как может код, в котором все функции виртуальные, быстрее кода, в котором это не так?
4) Да, и еще вопрос вдогонку: как вообще может программа, использующая куда больше библиотек, чем c-шная, быть быстрее ее?

Ну два года я просидел по 12 часов в день за клавой.

1) Ну почему так сразу, ты слыхал про такую штуку как оптимизация.
Для .NET она тоже сушествует. Надо соблюдать её и всё будет ок.

2) Ты слыхал про утилиту ngen.exe? NativeGENERATOR переводится. Она делает очень быстрые native'ные файлы. Хотите сравнить две анологичные проги на C# и на С++ - ок я могу это устроить. Да и ктомуже если вы не поняли я хочу подметить что С# код оптимизируется под машину юзера - он будет использовать(Я имею ввиду код) проц на полную. Он учитывает начиная от разрядности до дополнительного набора инструкций. А теперь про С++. Интересно можно ли на С++ сделать такойже оптимизированый код как на С#. Мне интересно кто это будет делать на конечной машине - млжет юзер или святой дух?

3) Ты хоть понял что сам сказал :) ?

ЗЫ. Возраст и образование не имеет значения - слыхали про 16 летнего подростка который выпустил свой LiveCD Linux дистрибутив.
ЗЫЫ. С++ я знаю, но не имею большого опыта
ЗЫЫЫ. Вы сказали что XNA очень далеко до DirectX 10 и OpenGL 2.0. Да до ОпенЖеЛе 2.0 ему еше очень далеко - не думаю что
Microsoft опустится до такого :). А что касается DirectX 10 то я вам напомню что Xna строится на DirectX

Да ну? В таком случае, эта оптимизация должна не просто сводить количество дополнительных действий к нулю, а делать его отрицательным!
О! Оптимизирующийся под машину юзера код. Смешно :lol: . Во-первых, мне крайне интересно, что он вообще может использовать, кроме количества ядер процессора. А использование количества ядер процессора требует распараллеливание. А распараллеливание - штука черезвычайно сложная, на должном уровне ее только человек может сделать. Набор интструкций, кстати, у современных процессоров почти одинаков. И еще мне интересно, откуда эта утилита будет узнавать о выходе новых процессоров - получается, что она устареет сразу после своего выхода. А ведь на ее переписывание при появленнии новой модели тоже время нужно. Кстати, откуда эта утилита будет знать, а нужна ли вообще юзеру такая "оптимизация"? К примеру, хочу ли я, чтобы архивирующийся WinRAR жрал ресурсы с обоих ядер моего двухядерника, или я на втором проце в кваку поиграть хочу? Так что такая утилита должна быть не просто "умной" - она должна чуть ли не сильным AI быть! Что-то я не слышал про получение первой премии Тьюрига...
Про использовании разрядности процессора: оно приносит пользу только в специфических задачах, и их вполне можно изначально скомпилить в двух вариантах. К тому же я не совсем понимаю, как вообще можно написать, например, сетевое приложение, не зная, сколько в каком типе бит у тебя будет. Будешь слать по сети вроде 32-х битное число, а оно - опа! - 64-х битным станет. А откуда компилятору знать, что в нем у тебя не может быть числа, больше чем 1000000, чисто по конструкции программы?
Оптимизация кода на машине юзера теряет смысл хотя бы потому, что ее конфигурация не постоянна. Регулярно меняются драйверы, устройства, ОС, наконец! Такая программа перед каждым запуском должна перекомпилироваться, да и во время работы тоже, потому что постоянно меняется окружение, другие программы и т.п., и это много на что влияет. Да, C++-код оптимизироваться на машине юзера не может, но его, во-первых, можно изначально скомпилировать под различные конфигурации, и ставить юзеру в зависимотсти от его конфигурации соответствующий экзешник, а во-вторых, такую оптимизацию на должном уровне написать практически невозможно по причинам, указаным выше.
Кстати, оптимизация C++ - программ во многом базируется на вещах, с которыми в C# играться нельзя - например, на адресной арифметике.
А ты хоть знаешь, что такое виртуальная функция? Судя по всему, нет.
Возраст - да. Образование - нет. Гении всегда есть, но их мало, и не надо приводить единичные примеры. И на вопрос об образовании ты не ответил.

Набор интструкций, кстати, у современных процессоров почти одинаков. И еще мне интересно, откуда эта утилита будет узнавать о выходе новых процессоров - получается, что она устареет сразу после своего выхода.

Чет ты гониш. Я же не сказал что под конкретную модель подстраивается. Эт происходит так:

Win32: я загружаю ехе, тут флаги клр есть.
CLR: это флаги джита
JIT: нашли самого левого. О юзера 32 risc проц есть SSE,SSE2,MMX,3DNOW! итд. Буду оптимизить под нехо.

"Набор интструкций, кстати, у современных процессоров почти одинаков."

не спорю - а как насчет расширений? Как об этом узнает прога на С++?

"Оптимизация кода на машине юзера теряет смысл хотя бы потому, что ее конфигурация не постоянна. Регулярно меняются драйверы, устройства, ОС, наконец!"

Драйверы тут не причем, устройства тоже, и вообще что мешает сделать так что-бы при изменении конфигурации, прога меняла свою нативный образ? Да и почему ты не упомянул статический C++? :)

"Такая программа перед каждым запуском должна перекомпилироваться, да и во время работы тоже, потому что постоянно меняется окружение, другие программы"

Другие программы - нет, дригие либы - да. Только есть одно но - либы в .net на много отличаются от с++.

"а, C++-код оптимизироваться не может, но его, во-первых, можно изначально скомпилировать под различные конфигурации, и ставить юзеру в зависимотсти от его конфигурации соответствующий экзешник, а во-вторых, такую оптимизацию на должном уровне написать практически невозможно по причинам, указаным выше."

Вот вот оптимизироватся неможет... Хош сказать что ты должен сделать
столько версий что-бы удолетворяло обсолютно всем конфигурациям?

Да и ктому же про конфигурации. Где ещё как не .net ты можеш одну прогу запускать как на Linux так и на Windows. Да и ктомуже как ты будеш давать всем свои "разные конфигурации" разным пользователям если твоя прога распростроняется посредством диска. Кстати ты смотрел на размер ексешника .NET? Так вот посмотрите.

"А ты хоть знаешь, что такое виртуальная функция? Судя по всему, нет."

- Судя по всему, нет - это судя по чему?

В .NET не так всё "виртулизировано" :) как кажется.

"Кстати, оптимизация C++ - программ во многом базируется на вещах, с которыми в C# играться нельзя - например, на адресной арифметике."

В С# можно игратся с адресной арфмитикой. Читай доки

Во-первых, пользуйся цитатой! Невозможно понять, где цитата, а где ответ на нее!
Эти расширения есть почти на каждом современном проце. Что же касается различий - их использование можно зашить в DLL библиотеки, так как они узкоспециализированны. По той же причине не надо оптимизировать C++-программу под все возможные конфигурации - достаточно скомпилить несколько вариантов DLL-библиотек. Для того их и придумывали.

То есть оптимизация идет только под процессор? И не важно, как и чем он забит помимо программы?
Как я уже говорил, такую оптимизацию сделать нереально хотя бы потому, что эта задача почти приравнивается к искуственному интеллекту. Такие ходы, как при оптимизации на C++, ни одна автоматическая система не повторит.
Только если в сторону тормознутости. Не забывай, .NET исполняется Framework'ом, а Framework на чем написан? На C++ или другом полностью компилируемом языке. И как могут его либы быть качественнее C'шных?
Как уже писал выше, достаточно использовать разные библиотеки. Кстати, такую систему вполне реально реализовать в отрыве от C# для C++.
Размер екзешника такой как раз потому, что программа на C# тормознутие программы на C++ и требует выполнения байт-кода Framework'ом. Касательно Framework на Linux: многое, доступное под Windows, под ним работать не будет. К тому же, если программа пишется грамотно на C++, то она будет компилироваться как под Linux, так и под Windows, почти без изменений в коде.
Интересно, как это - при наличии только виртуальных функций "не все виртулизировано"?
Да, и тут еще один вопросец назрел:
Программа на C# компилируется в байт-код. Даже если он будет у юзера на машине компилироваться в двоичный код, все равно юзеру ты даешь байт-код. А теперь внимание, вопрос:
Что мешает юзеру оказаться хакером, перегнать твой байт-код назад в C# (по ассемблерному коду код на C++ восстановить практически нереально, а по байт-коду код на исходном языке - элементарно) и посмотреть в нем все твои программистские секреты, отключить любую самую хитрую регистрационную систему и защиту от копирования, да и просто найти твои ошибки, наконец? И использовать все это в своих грязных целях, бесповоротно запоров твою программу? Взломав компьютеры всех юзеров, ею пользующихся? За пару часов написав кряк? Вставив в нее вирус? Так что программа в байт-коде - мечта хакера. Не нужно часами копаться в ассемблере и ловить прерывания! Пара секунд - и программа предстает перед ним в своем исходном виде, готовая к любому вмешательству!

Итог: программа на C# медленне программы на C++ хотя бы в силу своей конструкции. Оптимизация не может ничего дать, кроме незначительного выигрыша, из-за сложности самой задачи. Программа на C# практически элементарно взламывается и модифицируется (и я не говорю уже про Framework - т.е. систему с закрытыми исходниками - от которого все зависит! Если в нем будет закладка, баг, дыра - конец всем C#-программам!
Вывод: ты можешь быть прав только в случае, если Майкрософт заставит всех писать только под .NET, и не найдется никого, решившегося реализовать похожие возможности для C++ (для которого они реализуются проще). Надеюсь, что этого не случится.
Да ладно? В языке без возможности работы с памятью? Мы точно об одном и том же говорим?

Оптимизация зависит от памяти, от проца, и не много от ОС. Там оптимизация зависит какбы от контрольных точек.
Допустим тебе надо перемножить флоаты. Если SSE будет то код будет вместе с этими SSE.
А теперь скажи на чем написан твой C++ компилятор :)
Ладно можно но сложнее чем для С#
а ты слашал про Obfuscator'ы?
[quote]Вывод: ты можешь быть прав только в случае, если Майкрософт заставит всех писать только под .NET, и не найдется никого, решившегося реализовать похожие возможности для C++ (для которого они реализуются проще). Надеюсь, что этого не случится.[/qoute]
Ты хоть слышал про Singularity - нет? почитай. Про баг в .net framework, это странно но ещё не одного бага с framework'ом небыло.
Да ты уверен? А про unsafe код не слыхал, или вот это не видел.
using System;
namespace Knott.Benchmark
{
internal unsafe class Program
{
private unsafe static void Main(string[] args) {
DataHolder holder = new DataHolder();
for (int i = 0; i < 128 / 4; i += 4) {
DataStruct str = new DataStruct();
str.Offset = i;
str.Location = holder.Array;
str.Data = i * 10;
}
}
}
public unsafe struct DataHolder
{
public fixed byte Array[128];
}
public struct DataStruct
{
public int Offset;
public unsafe void* Location;
public unsafe int Data {
get { int* dataLocation = (int*)((byte*)Location + Offset); return *dataLocation; }
set { int* dataLocation = (int*)((byte*)Location + Offset); *dataLocation = value; }
}
}
}
Я не уверен что этот код работет правильно - но дело в том что поинтеры там есть.

Ась? о_О Чики - пуки. Бубль - гум. OpenGL теперь оказывается ламерский продукт. Надо известить моего закодычного дружбана Джонни. Который Кармак. А то этот ламер совсем обнаглел - использует понимаешь ли опенгл... Ты парень чего "того"? Самый быстрый апи называть опущением? о_О

pokibor в отличие от тебя программист и высказывает факты, а ты нахватался зивини меня дешёвых статей с сомнительных сайтов и пытаешься до всех донести...

Значит он медленнее директа по определению. Вотттактавот.

Я и говрю: все это сводится к написанным под тот или иной вариант функциям. Так на любом языке писать можно. И получится, кстати, быстрее, потому как там будет все с умом сделано под конкретный случай, а не под общий, как тут.
Это ты к чему? Ты утверждал, что C#'е либы быстрее C'шных. Я опроверг это. Ты мне в ответ какой-то глупый вопрос задал. C++'е компиляторы пишутся, как ни странно, на том же C++. Также как, например, Паскаль: спера был написан его компилятор (на чем-то, от Паскаля отличном), потом переписан на самом Паскале и скомпилирован этим компилятором - это обычная практика - писать компилятор на самом языке. Но вот для C# она не проходит, т.к. он компилирует в промежуточный код... То есть компилятор C#, конечно, можно переписать на C#, а вот .NET - бессмысленно. И потому либы .NET в приципе не могут быть быстрее C'шных.
Не-а. Проще. Так как имеем дело с ассемлерными инструкциями, а не с байт-кодом. Ассемблер - самый простой язык, на нем писать медленнее, а не труднее...
Не забывай, у нас этот байт-код будет компилировать FrameWork. Соответственно, как бы там все не было запутано, оно в равной мере отразится как на хакере, так и на Framework, причем в равной мере. Возможно, Obfuscator'ы замедлят появление дизассемблера, но ненадолго. А ведь их применение еще более замедляет выполнение кода.
Читал. И мне смешно. Это с какой же скоростью это чудо будет работать? Да не особо быстрый Windows по сравнению с этой ОС будет как заяц по сравнению с черепахой! Microsoft опять пытается выехать на своем монополизме на рынке ОС, но вовсе не факт, что у нее получится. Во-первых, подходит Google со своей бесплатной осью, которая базируется на Windows, а не начинает все с чистого листа, во-вторых, вряд ли пользователи, если они не дураки, захотят замедлить свой комп и сделать его уязвимым для хакерских атак (байт-код!) непонятно ради чего, в-третьих это чудо выйдет непонятно когда. Похоже, что ты начитался рекламных статеек от Майкрософта и начинаешь кричать всем, что "давайте поддержим дядю Билли!", хотя его за такие дела пора заставить на ассемблере программировать для стиральных машин! :sml:
Это не значит, что их там нет. Впрочем, с такой открытостью кода проще искать баги в программах, чем в Framework.
Слыхал. Только смысла в нем? Его использование превращает язык в C++ с чуть другим синтаксисом и более тормознутым выполнением. И все. Ты, помнится, отсутствие необходимости работы с памятью выводил в преимущесива. Вот и не противоречь себе же.
Работает - не работает - не важно. Важно то, что с их использованием язык перестает быть собой и становится очевидно хуже C++. Так что их в расчет не берем.

Я да я знаю. Не ты мне сказал что Framework написан на С++. А ведь C++ компилятор тоже написан на С++. И в чем разница?

Да на асм писать легко, но это-же дело вкуса. Например мне нравится IL Asm.

Так если не ошибаюсь Dotfuscator был разработан припомоши МС.Надо его юзать.



Эх читать до конца никто не учил? Этот код будет компилироватся во время установки. Да это займёт время. Компилятор называется Bartok.

А ты читай http://blogs.zdnet.com/Murphy/index.php?p=459

Да не хрена - байт-код байт-код читай выше

Это точно.

Да приводил, и я не противоречю себе. Необходимости нет - возможность есть.

А в делфи тоже есть поинтеры. :)

Ты что-то уже совсем потерял нить нашей дискуссии. Это ты вообще к чему? Я все упомянутые примеры приводил в доказательство того, что C# в приницпе не может работать быстрее C++, ты какой-то оффтоп начал писать.
И чем это поможет? Опять никаких противоречий со сказанным мною нет. Как замедлял работу, так и будет замедлять. Как код был прост ко взлому хакерами, так и останется.
Никогда не поверю, что Micro$oft, известная своей любовью к закрытым исходникам, будет поставлять ОС пусть даже в байт-коде! А если и вправду будет, то ой как хакеры порадуются! :lol:
"Вы все еще не в белом? Тогда мы идем к Вам!" - вот что-то вроде этого. Больше походит на громкое реламное сообщение.
Вот именно что читай выше - как не запутай байт-код, он байт-кодом останется. Так что - ломаем, братцы! А написаная таким образом система будет медленной потому, что C# медленнее C++, чего ты так и не опроверг.
Опять бессмысленные сообщения. В компилируемых в двоичный код языках ссылки и адресная арифметика - основа динамичекого выделения памяти, в C# - абсолютно чуждый элемент, использование которого начисто убивает смысл C#.

P.S. Хотя, если все сказанное Knott и представителями мелкомягких правда, похоже, Microsoft отказалась от изначальной идеи Windows в пользу Linux! Ведь если не брать в рассмотрение язык - действительно получается система с практически открытыми исходниками, которую компилирует сам пользователь. И по сути единственным слабым местом становится как раз медлительность языка (что, впрочем, скорее реверанс в сторону неопытных программистов), причем оно вполне может быть преодолено поставкой с сисемой, кроме компилятора C#, нормального компилятора C++ в двоичный код (а какая разница - из байт-кода или из исходного компилировать программу)? Вот только, похоже, при обновлении чего-то в компьютере (а то и просто при появлении нового драйвера) систему придется перекомпилять заново (а как еще - она же "оптимизируется" как-то. Правда, непонятно, как.)...
Впрочем, в любом случае профессиональные программы как на C/C++ писались, так и будут продолжать писаться. Ибо в них обычно задействуются такие ресурсы, что малейшее замедление из-за сомнительных достоинств смерти подобно.
В общем, на революцию (а тем более в игростроении - отрасли, в которой конкуренция по ресурсам наиболее жесткая) не тянет. Совмещение идей Java и Linux - еще куда ни шло, но не более.

Вот письмо, присланное в нашу студенческую рассылку человеком по имени Алексей Лебедев. Отличный ответ на приведенное в начале этой темы высказывание:
Жаль, что Knott покинул форум. Было бы очень интересно узнать, что он может возразить Страуструпу...

Знаю С++ 8лет, а С# 4,5 года, спор о производительности ваш для меня кажется странным. В больших проектах типа 1С:Бухгалтерия и т.п. написанных на ++ все равно используется автоматическая уборка мусора и быстродействие этих языков выравнивается. С# ускоряет разработку программ за счет простоты. О быстродействии могу сказать что в ближайшем будущем процессоры будут использовать НЕ команды Assembler в нынешнем виде, а микрокоманды которые не учитывают специфику расположения регистров и т.д. то есть будет использоваться высокоуровневый ассемблер типа MSIL. Microsoft ввела Framework ещё и потому, что ей проще стабилизировать 20 мегабайт кода Framework, чем 600 MB dll-библиотек которые используются сейчас в Windows сейчас. Мой вывод: Framework имеет будущее, он наверняка будет перенесён и на другие операционные системы (уже есть MONO Framework), и программисту не нужно будет задумываться под какую ОС он пишет программу, в перспективе код MSIL или подобный ему будет поддерживаться процессором НАПРЯМУЮ.

ага, тогда или фрэймворк, или виндоус ;) Им двоим тесно в 1 системе

Прашол гот.... С тех пор йа много понил/узнал/прочёл...

НУ ТИПЕРЬ КТО НА МИНЯ?????

... кроме учебника по русскому языку.
Использование подобного диалекта Вас не красит как профессионала, а именно таким Вы себя стараетесь выставить.

Эм... на Вас по-прежнему Страуструп, тремя постами выше. Знаете, кто это? Впрочем, в любом случае можете попробовать ему возражать.

Ну что, друзья, подождем еще годик? :lol: