2 ms·

Quick note: the magic "help JS function" is literally just a double->int conversion that uses the x86 sentinel values and rounding modes. The effect on JS is th

by olliej 6y ago

Quick note: the magic "help JS function" is literally just a double->int conversion that uses the x86 sentinel values and rounding modes. The effect on JS is that it removes a set of branches following ((int)someDouble) that are needed to match the x86 semantics that JS mandates. The instruction is not magically faster than x86. In fact more or less by definition it's just doing what x86 does. I am tired of people bringing up that instruction as though it's magically making JS faster compared to intel. At best it's a leveling the playing field instruction. Implementing TSO isn't "cheating", it's hard work that other companies aren't willing to do. Ref counting isn't magically faster than other GC methods - there's arguments that it is slower - it does however use much less memory than pretty much any other GC scheme, hence the lower memory needs on iOS vs Android.

normaljoe 6y ago
RC vs GC really depends on workload/memory and the volatility of the allocate to deallocate timeframe. I think the better argument here is that iOS and MacOS use RC in the underlying objc libs. Having a CPU that works better around that makes sense to increase performance for those particular OSes.
- olliej 6y ago
  Oh I didn’t mean to distract from the improvements to refcounting - it sounds very much like they’ve significantly improved the perf of uncontended atomic increment vs Intel which is obviously a win on iOS and OS X as objc and Swift both inline refcounting - I think on windows/COM it is through a virtual call? In which case improving the increment itself seems like it would not be a huge win. As far as perf the general argument is that dropping the need for refcounting saves time, and that removal also helps caching due to reduced per-object size. That said I’m not sure if those comparisons are comparing to generational or moving collectors (which are the low latency collectors) because those start needing write barriers.

by olliej 6y ago

normaljoe 6y ago

RC vs GC really depends on workload/memory and the volatility of the allocate to deallocate timeframe. I think the better argument here is that iOS and MacOS use RC in the underlying objc libs. Having a CPU that works better around that makes sense to increase performance for those particular OSes.

olliej 6y ago
Oh I didn’t mean to distract from the improvements to refcounting - it sounds very much like they’ve significantly improved the perf of uncontended atomic increment vs Intel which is obviously a win on iOS and OS X as objc and Swift both inline refcounting - I think on windows/COM it is through a virtual call? In which case improving the increment itself seems like it would not be a huge win. As far as perf the general argument is that dropping the need for refcounting saves time, and that removal also helps caching due to reduced per-object size. That said I’m not sure if those comparisons are comparing to generational or moving collectors (which are the low latency collectors) because those start needing write barriers.