OK, apenas para fazer alguns buracos nesse discurso que você vinculou:
- "C # depende de um intérprete" Just In Time "" - errado - é um compilador JIT . Depois que um método é JITted uma vez , o código compilado é reutilizado para cada chamada. O código compilado é muito próximo do código nativo pré-compilado.
- "CPU Xenon é um processador" no local " - ele quer dizer" em ordem "? - E: "A CPU do Xenon não tem previsão de ramificação" . Ele implica que isso significa que a compilação JIT produz naturalmente código incorreto que deve ser reordenado pela CPU e causa muitas ramificações - o que é um absurdo absoluto . O mesmo conselho de desempenho para executar nesta arquitetura de CPU se aplica a C ++ e C #.
- "[JIT] requer liberação constante no 360" - errado, o código compilado pode ser mantido em cache como qualquer código compilado normalmente. (Se ele significa descarga de tubulação, veja o ponto acima.)
- "genéricos usam [...] geração de código" - os genéricos são JITted como todo o resto e, como todo o resto, o código JITted é rápido. Não há penalidade de desempenho pelo uso de genéricos.
- "todos os bits sensuais da linguagem [...] exigem previsão de ramificação ..." - como isso também não se aplica ao C ++? - "... ou [...] geração de código no local" - ele quer dizer JITting? Eu mencionei que é rápido? (Não vou entrar em todos os lugares em que o CLR da área de trabalho usa a geração real de código - um recurso não suportado pelo Xbox 360!)
- "[O C # não possui] as grandes bibliotecas [do C ++]" - exceto, digamos, o próprio XNA? E muito mais . (Ainda assim, este é um ponto bastante justo.)
O XNA no Xbox 360 é executado em uma versão modificada do .NET Compact Framework CLR. Não tenho dúvidas de que não está de acordo com o padrão da versão para desktop. O JITter provavelmente não é tão bom - mas também não acho que seja ruim . Estou surpreso que ele não tenha mencionado o coletor de lixo, o que é terrível comparado ao CLR da área de trabalho.
(Claro - você não deve bater o coletor de lixo em um jogo desenvolvido profissionalmente de qualquer maneira , assim como você deve ter cuidado com atribuições em qualquer jogo de nível profissional.)
(Para uma discussão técnica real do .NET Compact Framework, talvez comece com esta série de artigos: Visão geral , JIT Compiler e GC e heap .)
A maneira como ele é totalmente inespecífico sobre sua terminologia dificulta o entendimento do que ele quer dizer. Ou ele está no modo de máximo discurso retórico ou não sabe do que está falando.
Agora que nós temos que fora do caminho, aqui estão algumas coisas que você não deixar escapar usando XNA no 360, ao invés de ir nativa :
- Acesso à unidade SIMD / Vector para realizar cálculos de ponto flutuante da CPU muito, muito rápidos
- Capacidade de usar código de idioma nativo que provavelmente será um pouco mais rápido que C #
- Capacidade de ficar um pouco mais preguiçoso com a maneira como você aloca memória
- Os jogos XBLIG têm acesso a apenas 4 dos 6 núcleos (mas ainda temos todas as 3 CPUs, e eles também não são núcleos completos, para não perdermos muito) - não tenho certeza se isso se aplica a XNA não XBLIG jogos
- Acesso total ao DirectX para realizar truques gráficos realmente obscuros
Também vale ressaltar que essas são apenas restrições do lado da CPU. Você ainda tem acesso totalmente gratuito em execução na GPU.
Descrevi essas coisas nesta resposta para o que é efetivamente a mesma pergunta que essa. Como mencionei nessa resposta, o XNA é absolutamente adequado para o desenvolvimento "profissional" .
As únicas razões que você evitaria é que você não pode contratar talentos em C #, licenciar mecanismos em C # e reutilizar o código C # existente da mesma maneira que pode com a base existente de conhecimento em C ++. Ou porque você também pode ter como alvo uma plataforma que não suporta C #.
Obviamente, para muitos de nós que não somos desenvolvedores "profissionais", o XNA é a nossa única opção de entrar no Xbox 360, fazendo questão de argumentar.
Para responder suas outras perguntas:
Nada no C # impede você de usar abordagens orientadas a dados essencialmente exatamente da mesma maneira que você as usaria no C ++.
O C # carece da capacidade de alinhar automaticamente o código no tempo de compilação e (sem precisar verificar) tenho certeza de que o JITter do CLR compacto não pode incorporar métodos (o CLR da área de trabalho). Portanto, para código crítico de desempenho, talvez seja necessário alinhar manualmente em C #, onde o C ++ fornece assistência.
Provavelmente, uma razão maior pela qual você não vê frequentemente coisas intensivas em matemática da CPU, como detecção de colisão e simulações de fluidos em C #, é a falta de acesso à unidade vetorial (como mencionado acima).