mjsabby

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.

I got it at 39, still have it, you'll be fine.

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.

Can you elaborate “never rely on countermeasures”. What are you referring to?

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.

Thanks for the suggestion, I've modified the graphic.

It's in milliseconds. I'm going to update the post and add that note, but omitting values was a business decision, sorry.

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.

Current: Windows Server 2016 + http.sys + homegrown managed layer replacement for System.Web.

Near future: Windows Server 2019 + http.sys + ASP.NET Core

Medium future: Windows Server 2019 + Kestrel + ASP.NET Core

Folks, adding mscorlib binary compatibility is not going to boil the ocean or alter the "Core"-ness of .NET Core.

I implore you to take a look at this pull request:

https://github.com/dotnet/coreclr/pull/4874

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.

ETW2JSON: https://github.com/ETWTools/ETW2JSON

ETW2SQLite: https://github.com/ETWTools/ETW2SQLite

The motivation for these tools is to make Windows system instrumentation data more accessible.

This wiki page details what LLILC will be doing to get GC Support as required by the CoreCLR:

https://github.com/dotnet/llilc/blob/master/Documentation/ll...

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.

Have a look at the FAQ: https://github.com/dotnet/llilc/wiki/LLILC-FAQ

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.

LLILC is absolutely interested in upstreaming and in fact, at least one big change (prelim COFF support for MCJIT) is already upstreamed (http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-...) in addition to a few smaller ones.

Diffing upstream with http://github.com/Microsoft/llvm will let you track what Microsoft is currently doing in its repo.

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.

Mailing list post: http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084459...

And also check out LLVMSharp -- http://www.llvmsharp.org which gives LLVM access to .NET

Disclaimer: I'm involved in both projects.