The bolded part is something that was nagging at me when I first read Digital Foundry's article. Why should games improve the pop-in issue and load times? Don't original X360 games always count on 512MB and nothing more, so it shouldn't make a difference if you have 8GB of available memory now? Why should the X360 executable look for more memory and if it is a yes, use it? Could it be due to development kits?
if a game has strict, pre-allocated budgets, then it probably will always allocate the same amount of memory.
But even on consoles it might make sense nowadays to allocate bigger memory chunks from the OS, as the OS can re-combine memory pages into one block of virtual memory space (that's what an OS does, right?
)
So if a game wants to stream in a texture or a new sound file, it could try to allocate some memory from the OS, on X360 this might fail as it reaches the memory limit and the Game would free some old resources and try again. On XBOne the allocation might succeed and then a game might as well use 2GB of space. This might be risky at times, as some internal structures might run with assumptions e.g. "we cannot fit more than 1024 textures into memory anyway", that's where MS has probably to hand tune the VM for every game, but beyond this, the increased memory budget might really help with streaming even on engine side.
And as
3dilettante said, it's rather straight forward to translate opcodes from one ISA to another. It's what emulators do on runtime, but instead of executing the instruction, you'd store the emulation code. I've written my tiny C++ to MIPS to C# to .Net converted that way. The idea is based on
http://nestedvm.ibex.org/ and it actually shows how simple the idea is.
non optimized code will probably run faster on x86 than on the XBox CPU. When the PS3 came out (which is similar on CPU core side), there were benchmarks with PPU vs X86 and most of the time vanilla c++ code run on PPU as fast as it would run on an 700MHz - 1300MHz x86 core2 (you might still find those results in google). Modern Jaguar cores @ 1.86GHz might be a good match for vanilla PowerPC code. On top the X360 run two thread per core, which effectivelly means 1.6GHz and that's even less raw MHz power, eh?
yet Altivec code was always famous to wipe the floor with the SSE code, not only does it support multiply-add, but also tons of registers and operates non destructive on more registers per op. If you give your code some altivec love, you can really gain a lot performance.
I think, if developers optimized for altivec, they've optimized the parts that were really time critical (e.g. some physics or AI raycast). Hence those hard to emulate altivec ops will be issued when it's most critical (e.g. combat) and that would hurt emulation twice.
Yet I'm really impressed with what MS has pulled out of the box.
