I've joined the B70 bandwagon as well, and have started profiling, will keep this thread updated. I suspect if we get enough of us to get even 80% of theoretical perf we'll be in a good spot. I also have two B70s.
Lots of clinics in Vancouver BC fully body MRI scans that are not super expensive. I really do think we should just make MRIs cheap and then get the whole world to do them.
I understand the cost, time, etc. but I still think if we can stop doing other useless stuff as humanity and do this it would be net positive.
My team did this when we moved Bing.com over to .NET Core, but it's internal. I will see if we can make it public. The problem is there are some skeletons in the closest that are irrelevant now (some since NS2.0, more since netcoreapp3.1), so I wonder how informative it will be.
Barring any bugs, the hope is that the code generated on Windows and Linux for the same architecture will be very similar, modulo calling conventions and ABI.
Then you come down to issues like Linux networking vs. Windows networking, Disk I/O differences which are interesting but from a .NET perspective less so in my opinion.
Bing is huge both in codesize and technologies used, but most of it is a flavor of Windows Server 2016 (soon 2019) + http.sys + C# + Razor + TypeScript for Frontend. C#/C++ for middle and lower tiers.
Windows Server 2016. All the improvements in the post that helped us are the same on Linux. I will agree though there's more dogfooding to be done. It's happening slowly but surely.
All this does is changes the "core" library for CoreCLR to be renamed from "mscorlib" to "System.Private.Corelib" -- this has an important function, now the .NET team can add more backward compat features (missing types and methods) to mscorlib for those who want to use it.
If your library or product doesn't want to use it, you don't need to.
.NET Core doesn't become more bloated, it says beautiful and Core.
Andy Ayers from the LLILC team will be presenting this exact topic at the EuroLLVM developer meeting: http://llvm.org/devmtg/2015-04
I imagine the LLVM folks will put the meeting videos up on their website like they have in the past, and it would be an interesting video to watch if you're looking for GC specific details in LLILC.
Q: How does LLILC relate to the .NET Native work?
A: .NET Native provides a broad tool-chain, targeting Windows. The LLILC AOT could be used as the compiler component of .NET Native to target other platforms.
Since LLVM can run on Windows, you could also use it as your AOT compiler for multiple platforms (including Windows) once LLILC gets there.
Having multiple code generators is not mutually exclusive, and this effort does not mean MSFT is ditching any existing AOT (or for that matter JIT) compiler projects.
One of LLILC's major objective is give the community an MSIL frontend for LLVM.
This allows a JIT or an AOT compiler to take any C# program written for the .NET Core class libraries to run on any platform that CoreCLR can be ported to and that LLVM will target.