Ok, disclaimer first: it's Friday, I've had a few, I'm going to try to minimise the drunken tangentrambles but who knows.
Rightso...
<snip>
First off, just so I don't get some "aha! SSE only exists on PC" type gotcha-ing, I'm going to start saying SIMD (single instruction, multiple data). SSE is a kind of SIMD, there's a newer PC one called AVX, on the 360 it was Altivec... all variants of the same idea - several numbers side by side in one wide register, and you can do the same operation on all of them in a single instruction.
What Derek's link above doesn't mention is that you tend to wrap all these weird types and unpronouncable intrinsics into a more user friendly, multi-platform friendly container, so if you need to, say, get the Y component out of it, you call a thing called "GetY" and it gives you the right thing. What it's doing at a hardware level, though, is shuffling the components around so Y is at the start, or is all of them, and it's taken a whole operation that could have done four of something else.
So how does a coding standard matter for this? Well, take these two apparently identical operations (yeah someone probably wouldn't do exactly this, but hopefully you see the point):
Code:
1) Vec C = A + B
2) Vec C = Vec( A.GetX + B.GetX, A.GetY + B.GetY, A.GetZ + B.GetZ)
Option 1 is one operation. Option 2 takes six swizzles, three adds, and maybe some more swizzles and masks packing them together at the end. It's also the kind of code that's easier to write when you're trying to think about a problem rather than ideal vectorisation. This is where I talk about fanaticism, and where Frontier shines, IMO, because not only did they design a really idiot-proof vector library, but they have a general attitude that if you try to work around the interface design and start writing sloppy code, someone comes to your desk and kicks your butt for it. This kind of sloppiness naturally creeps in, but Frontier's general culture is one where you get called out even on apparently harmless deviations from the standard, so the standard stays strong. So there you go - fanatical cleanliness, miles of well-build explicitly 32-bit SIMD code, well worth sticking in 32-bit and working around the pain it causes.
So CryTek didn't do the things above. Obviously they've put out some groundbreaking tech over the years, but "fanatical cleanliness" isn't exactly their watchword. Watchphrase. I asked a guy who used to work there why there wasn't an explicit SIMD vector library like wot I was used to, and he said they'd trialled one, but because the original interface had funnelled people into Option 2 style code instead of Option 1, it actually ran much slower and they abandoned it. Modern compilers are still smart enough, though, that if it can work out what you're doing - do four adds in roughly the same place, say - it'll try to reorder the instructions so they were already side-by-side, and so on. In many cases it'll probably even out-perform because it saw stuff you didn't, and switching to 64-bit probably breaks a few less things.
Now for the hedge - this started as an off-the-cuff comment. I've not profiled either codebase at either precision, I'm not even sure
how you'd test them side by side. Don't trust anyone who claims to be certain when they don't have the profile data to back it up.
So yeah, Regel, I hope that answered your question. dsmart, I hope I've not walked into some quibble about your precise definition of "coding standard". Jools, I hope I didn't arm anyone. Frontier, you're only fanatics in a good way, mostly.