Is it possible to inline asm ?
It’s definitely possible, but I think the real question is why would you want to? There are very few cases where a human will write more optimised code than the C++ compiler is able to generate.
I have a huge bunch of asm code that runs around 3 to 5 times faster than native C++, which takes advantage of things like SSE, SSE2, MMX.
Sometimes, it is better to do it yourself and tell the compiler to back off. Although in most cases this is totally true that modern day compilers are really great optimizer.
You won’t be able to use inline assembly directly for any Windows 64bit builds as the MS compiler doesn’t allow it; you can however use intrinsics to access things like SSE instructions however.
Okay cool, thanks 
Yes, VC++ does not support assembly *inlining *for x64 builds. Intrinsics and separated assembly modules are of course supported.
Clang support is in the works for Windows iirc, so it should be possible there.
Assembler code can be “assembled/compiled” then imported as a dll at runtime or dynamically with any 64bit VCP module; the offset here is that the assembler code will be either a dll or external executable imported or fired up by the instantiated system process thread. This is a valid alternative to nesting assembler within native C++ code with little overhead consumed by external calls (generally incurred due to the stack calling convention/operation).
C++ is constantly getting optimized and faster all the time, but not as fast as C and certainly not as fast as assembler. File sizes of C++, C and assembler range from largest to smallest respectively and size is relevant to speed; the purpose of C++ is constituent to standardized, ready-made “objects” and was supposed to do so in an easily readable format (syntax) and has been getting better, but could learn from C# as the run-time interpreted grammar draws heavily upon C&C++ in its grammar design. Most of C++ “bloat” is policy related for concurrency considering stability and accessibility (security) using stuff like public & private access methods. Ultimately, there are always opportunities for optimization so don’t kid yourself and C++ is a valid grammar that compiles natively where as C# is essentially a “word document” type or compressed archive with a manifest, resource and code component files read by the .Net framework. I like C# more than C++, but do not hate C++ by any measure as both have unique purposes by design.
In closing, to change from C++ to C# (regarding UE) would require a complete re-write and may not be suitable and with clang coming down the road file sizes are slated to shrink in size at all levels including C++ & C; before any comments are made I have tested clang against MVC & C++ compilers and GCC and there is no contest --clang wins. Microsoft Visual C compiler is real close to clang though --real close. Microsoft Visual Studio is going to completely support clang and may even convert to clang entirely in a financially strategic move lowering cost shifting to the open source sector. Clarifying on the subject of intrinsics, the term merely indicates/references in-built support plain and simple where the only term that matters is why said intrinsics. MS might be slowing development of the compiler in a move toward supporting clang or any other reason --it’s all conjecture as motivations & goals change daily.
Anyway, really don’t fancy C++, but do admire and appreciate the Unreal brand, if C++ is their call I’m standing behind them and accept C++ with open arms. C++ does offer functionality similar to assembler considering the memory stack, etcetera in the standard template library of the language.
Albeit, this thread is slightly aged --this argument is over a decade old and a common debate that will never go away hence my input. Hope my input has shed a tad of light on the matter without all the theory stuff. Take care.