GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-12-18) - page 1 of 10
 
___________________________________________________________________
A Look at the Internals of 'Tiered JIT Compilation' in .NET Core
37 points by matthewwarren
http://www.mattwarren.org/2017/12/15/How-does-.NET-JIT-a-method-...
___________________________________________________________________
 
polskibus - 1 hours ago
I heard so many times that JVM is much better than CLR, especially
in the JIT area (Hotspot?).If it's true, do the new .NET Core
internals, allow .NET Core to beat JVM? If not, are there any
additional steps planned to beat JVM at last?.NET ecosystem is much
smaller than Java's (for instance  all the Apache projects) and
Linux + .NET Core happened too late to make up for it in my
opinion. Hopefully, at least performance can be the point that can
turn other people attention back towards C#/.NET.
 
  matthewwarren - 1 hours ago
  > If it's true, do the new .NET Core internals, allow .NET Core
  to beat JVM?I'm hoping that 'Tiered Compilation' will help, but
  it's early days. We will have to wait until it is 'officially' in
  .NET Core before it can be properly tested
 
  benaadams - 30 minutes ago
  The JVM jit _has_ to do a lot more for performance.Lack of value
  types means greater allocation by default - so it needs escape
  analysis to avoid it.Type erasure for generic types means
  speculative optimisation and deoptimisation steps for
  types.etcDoesn't mean the .NET Jit can't improve in these areas
  (e.g. now its doing devirtualization for .NET Core 2.1, and
  escape analysis would be great) - but it does start in a better
  place.
 
  chrisseaton - 1 hours ago
  > I heard so many times that JVM is much better than CLR,
  especially in the JIT area (Hotspot?).I wouldn't disagree with
  this (I work at Oracle on VM research), but I've been told by
  other people that Microsoft or at least the .NET just generally
  prefer a simpler approach, without profiling, dynamic
  compilation, deoptimisation, and other complexity the approach
  used by the JVM brings. It's much more what-you-see-is-what-you-
  get from their JIT, rather than the mind-binding things the JVM
  manages to do with some code, and maybe that makes life easier
  for their use cases.I'm not sure they want to add the same kind
  of complexity that the JVM has, even if it did bring them some
  better performance. But as I say that's second hand
  conversations.
 
    sreque - 31 minutes ago
    I definitely agree with this stance, and would say that
    languages like C# and golang have a weaker runtime but try to
    make up for it in other ways, often surpassing Java in certain
    areas. For instance, both languages have stack-allocated types
    to help stress the GC less. C# also has a much better native
    interop story than Java, as well as the unsafe keyword.At the
    end of the day, if you want amazing performance in Java, you
    have to write C-like code in Java, and that often involves
    things like managing your own offheap memory, sticking with
    arrays of numbers, etc. Java's biggest areas for improvement in
    the performance arena are going to come allowing for stack-
    allocated types, fully-continugous arrays, less overhead when
    calling native code, and providing official APIs for the other
    things you can currently do with sun.misc.Unsafe.
 
    matthewwarren - 29 minutes ago
    > but I've been told by other people that Microsoft or at least
    the .NET just generally prefer a simpler approach, without
    profiling, dynamic compilation, deoptimisation, and other
    complexity the approach used by the JVM brings. It's much more
    what-you-see-is-what-you-get from their JIT, rather than the
    mind-binding things the JVM manages to do with some code, and
    maybe that makes life easier for their use cases.Interesting,
    it's clear after a bit of research that this is the case (i.e.
    .NET JIT simpler that Hotspot), but it had never occurred to me
    that it was a conscious decisionI'd always thought that the
    .NET was just playing catch-up and/or didn't need to do all the
    things that Hotspot does. (for instance .NET has value types or
    'stucts' so some optimisations are not needed because the
    programmer can just use them instead of classes, if they need
    the perf boost)
 
  [deleted]