As Zir blazer says, you might gain a 10% speedup. If you're lucky.
10% (Actually 15%) was what John Carmack said about an hypothetical 100% ASM Doom engine.
Here is the quote:
Although it has often been theorized that Id uses a lot of assembly language in its development, the main language used is ANSI C. "Assembly language is almost dead," declares Carmack. "Doom has only two assembler routines: one to vertically stretch a column and the other to horizontally texture-map a row. Everything else is in C."
If all of Doom was written in assembler and the programmer could manage the overhead correctly, Carmack theorizes it would only make the game 15% faster. And, although the main raycasting trace in Wolfenstein was written in assembly language, Carmack says he could write Wolfenstein faster in C because of today's better algorithm technology.
...BUT, we're talking about the DOS days, when you were working quite close to the Hardware. Lets not get starter about the abstraction layer upon layer upon layer that you have to deal with now for Hardware access with both Drivers and APIs, everything adding their share to the overhead. If someone tried to port a modern game or engine to ASM and bypassing all the API bloat, then say that it is 2-5 times faster, I wouldn't be surprised.
Also, keep in mind that Doom predates the P5 Pentium, which was the first x86 Processor with dual ALUs (The Quake 1 engine was already Pentium-optimized), and there weren't any extra Instruction Set Extensions. Compilers should have evolved to be much more complex than at that time, which many more choices and assumptions that they must make to produce either compatible or faster code. I think that even if overally they are more efficient, the gap should have increased a lot with the drastically increased choices that can be made to achieve something, allowing a good Assembler programmer to optimize by hand things that someone that doesn't understand the Hardware will never be able to, much less a compiler, which doesn't have the flexibility.
It's a very good attitude, and practical attitude, to have faith in your compiler. Especially if it comes from Intel, or is GCC.
I already stated that GCC had its share of compiler-induced bugs, many related to compiling the Linux Kernel. Since compilers are soo complex, it is obviously that eventually they could introduce bugs into perfectly working code (Which was the case with Linux). Can you blindlessly have faith on it?
And the Intel Compiler... wasn't that
the compiler that specifically looked for the "GenuineIntel" string using CPUID, and if was something else, it decided to not use faster SSE codepaths thus killing AMD Processors performance by forcing them to use legacy x87? Yup, I have faith in that one too.
Looking at one particular profile, the app I have on Android (Nintendo DS emulator) is spending about 65% of its runtime in assembly or assembly-like code for an ARMv7a NEON build.
Oh, ASM for console emulators is absolutely wonderful, and its one, if not, THE reason why I love it soo much. ZSNES was made in ASM and was important during the 90's, because it was extremely fast at a time where you couldn't simply throw a faster Processor to solve the problem. Basically, ZSNES under DOS on a Pentium MMX 166 MHz ran in circles against SNES9x in WXP with a K6-II 500 MHz. Then there was NeoRageX, a Neo Geo emulator, also made in ASM. It could play in my humble K6-II games in real time, which were ridiculous choppy in MAME. Even through accuracy-obsessed folks usually claims that they were rather hacky and messy, it was wonderful to see such performance, they made my computer feel fast, while everything else made me remember that it was an outdated piece of junk, and that because my family had an empty wallet, I had to deal with it.
Finally, no$gba, which was the first emulator capable of running commercial Nintendo DS games, made in ASM. The guy that made it is an ASM genius, and has also several legacy console emulators in ASM, too. Performance wise, they stomp everything else I tried. In all 3 cases, the difference against other emulators was rather dramatic.