Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple CPU tricks: memory reordering, JavaScript support, ref counting

twitter.com

Post reply on HN
Print view View original

151–160 of 196 posts

Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting

#151

Post by normaljoe »

calo_star wrote: post #114
toast0 wrote: post #39

Earlier quoted context omitted.

I think there's a couple things here. x86 defines a pretty strict ordering of memory operations, where ARM is more relaxed; as discussed elsewhere in the thread, this means atomic operations, used for synchronization, will need to wait for pending stores to finish on x86, but not on ARM. The other thing is that the M1 processor seems to be a lot wider than contemporary processors. This means it can (potentially) do m…

Can you elaborate on the "Wider processors are harder to clock faster" part?

Clock is a up volt and down volt. There is a period of time it takes to reach either up or down.

If I have to get the clock to reach 2 cores/units at the same time that is easier then say 4 cores/units. As you increase the clock speed the time to reach all the cores decreases. So if you are wider you would need to reach more cores/units in the same period of time, hence "harder".

EDIT (To make it a little more clear) To make it more clear the voltage change is typically represented in books as a vertical line, but that is not the case it's diagonal and fuzzy. By fuzzy I mean not a straight line but will have some tiny mini downs on the way up.

Different parts of the circuits are going to respond to the up or the down. They are also can vary based on the exact voltage. For example if I have a 5V up one circuit might consider 4.8V to be up and another could be 4.9 or 4.7.

Silicon has improved, but there still is limits of scale based on size, volts and timing.

Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting

#152

Post by dingaling »

GeekyBear wrote: post #75
PopePompus wrote: post #74

Earlier quoted context omitted.

Well, I respectfully disagree. The Apple Watch is a successful product, but it really didn't completely disrupt a large existing industry like the iPhone did. I think it's possible that the M1 will trigger the death of x86 personal computers. If that happens, it won't have been an iPhone-level disruption, but it will be a lot more significant than the watch.

> The Apple Watch is a successful product, but it really didn't completely disrupt a large existing industry For some values of large? >Apple now sells more watches than the entire Swiss watch industry https://www.theverge.com/2020/2/5/21125565/apple-watch-sales...

Casio sells more F-91W digital watches per year than the entire Swiss watch industry, too...

Apple's watch was their usual polished refinement of existing, mainly Chinese, SIM-equipped smartwatch designs. They didn't invent a market segment out of a vacuum.

Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting

#153

Post by pjmlp »

tambourine_man wrote: post #141
pjmlp wrote: post #120

Earlier quoted context omitted.

Intel failed because AMD exists and has a cross license agreement that allowed them to be clever. Without AMD in the picture, Itanium issues would have eventually been sorted out.

There would have been no Intel on IBM compatible PCs without x86 cross licensing, so you could make the point that AMD allowed Intel to thrive.

What? I was there on the early days, that just makes no sense.

Cyrix, VIA and friends were ocean drops, hardly available outside US.

Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting

#154

Post by skywhopper »

apetrovic wrote: post #27

Is there any reference/confirmation for all of this? The fact that the author types "Swift" under quotes and doesn't know that refcount is something inherited from Objective C and the whole OS rely on it makes the rest of claims a bit more gossipy. Also, AFAIK MS translation of x86 -> ARM works different than Rosetta2, so the results aren't just because "Apple added Intel's memory ordering to their CPU" (whatever tha…

While I was also thrown off by the lack of reference to Objective-C, in context I think the author used quotes around “Swift” to make it clear it’s a proper name and that he’s not talking about a “swift (ie fast) programming language”.

Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting

#155

Post by jsheard »

rwmj wrote: post #150

I wonder if TSO "violates" ARM standard conformance in some way? Perhaps not since it makes the memory ordering stronger, and is therefore upwards compatible. Or perhaps Apple doesn't care any more about strictly conforming to ARM's specs, which would be interesting news.

M1 does follow standard ARM memory ordering rules in general, TSO is only enabled for processes running under Rosetta2 emulation

It probably would be legal to enable TSO everywhere as you said, but weaker ordering lets the CPU do more aggressive optimizations

Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting

#156

Post by normaljoe »

olliej wrote: post #52

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 br…

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.

Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting

#157

Post by klelatti »

pjmlp wrote: post #153
tambourine_man wrote: post #141

Earlier quoted context omitted.

There would have been no Intel on IBM compatible PCs without x86 cross licensing, so you could make the point that AMD allowed Intel to thrive.

What? I was there on the early days, that just makes no sense. Cyrix, VIA and friends were ocean drops, hardly available outside US.

Very unlikely that IBM would have used the 8088 without a second source - so literally Intel needed firms like AMD.

Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting

#159

Post by tambourine_man »

klelatti wrote: post #157
pjmlp wrote: post #153

Earlier quoted context omitted.

What? I was there on the early days, that just makes no sense. Cyrix, VIA and friends were ocean drops, hardly available outside US.

Very unlikely that IBM would have used the 8088 without a second source - so literally Intel needed firms like AMD.

Not unlikely, it was a condition.

Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting

#160

Post by lern_too_spel »

skellington wrote: post #88
lern_too_spel wrote: post #83

Earlier quoted context omitted.

Reference counting cannot be faster than naive manual memory management because it does the same thing with the additional overhead of reference counting. Even a very simple generational GC beats naive explicit memory management on most nontrivial workloads given enough memory. https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf

You are misunderstanding this paper deeply. Quoted summary from the paper itself: >>>We use this framework to compare the time-space performance of a range of garbage collectors to explicit memory management with the Lea memory allocator. Comparing runtime, space consumption, and virtual memory footprints over a range of benchmarks, we show that the runtime performance of the best-performing garbage collector is comp…

I understood that part completely. You misunderstood my point, which is that with enough memory, generational GC outperforms naive explicit memory management, which is impossible with reference counting.

> Except under unusual conditions, there is no case where GC is faster than manual.

Their simple generational GC outperforms manual memory management in every single workload in that paper given enough memory, so that statement is clearly false. A production quality GC does so with less memory.

> Well, probably this is because GCs are fast when they have low to no memory pressure. They simply don't need to garbage collect anything.

This is wrong. It's because generational GCs start to look like arena allocators when they have enough memory, with cheap bump allocation and bulk deallocation. On most of their workloads, their simple generational GC already outperforms naive explicit memory management with less than 3x the memory, and this would certainly be better with explicit tuning or a production GC.

Post reply on HN