101–110 of 196 posts
Earlier quoted context omitted.
> 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...
The Swiss watch industry isn't what it was. Most people I know don't wear a watch.
Earlier quoted context omitted.
Doesn't Apple use TSMC manufacturing?
Yes, and they are the only ones on TSMC 5nm currently.
I can tell you some companies were not too pleased about that.
Earlier quoted context omitted.
> The reality is that the reasons these chips are fast are either unknown or boring. I suspect that these will one out as we play around with them more, but we don’t have the details right now. I disagree, I think we have plenty of information. This is what happens when a huge proportion of your die isn't doing instruction decoding. x86/amd64 are old and crufty. Lessons have been learned, and had been learned for som…
This is what happens when a huge proportion of your die isn't doing instruction decoding. That's a misconception. Yes, decoding x86 is somewhat more complicated, as far as I'm aware that's mostly because instruction length differs at a byte granularity. Still, the area dedicated to it simply isn't that large on those huge out of order designs. I'm sure the instruction encoding plays some role, but I suspect what we'r…
Earlier quoted context omitted.
The Swiss watch industry isn't what it was. Most people I know don't wear a watch.
Wait, where did the goal posts go. Has anyone seen them? I swear they were here a minute ago.
> 4/ So Apple simply cheated. They added Intel's memory-ordering to their CPU. When running translated x86 code, they switch the mode of the CPU to conform to Intel's memory ordering. Uh, no. Implementing TSO in a highly performant way is not "cheating", it's a difficult engineering feat. And no, TSO is not some fancy Intel thingy. It's a standard memory model.
To add to this: The POWER7 through POWER9 processors from IBM implement an equivalent to this called "SAO", or "Strong Access Ordering Mode". To quote an IBM engineer: > Currently, power has a weaker memory model than x86. Implementing a stronger memory model allows an emulator to more efficiently translate x86 code into power code, resulting in faster code execution. What's interesting is IBM publishes pretty detail…
Earlier quoted context omitted.
Yes, and they are the only ones on TSMC 5nm currently.
That's because apple bought the entire 5nm production capacity/runs for basically for the entire last quarter of 2020. I can tell you some companies were not too pleased about that.
Finally a company has the guts to move us from the straitjacket of x86. I hope this is just the beginning of much needed innovation in CPU architecture. Due to the MS/Intel duopoly we had to suffer x86 for decades with few real options.
Earlier quoted context omitted.
I think the M1 macs are the first really significant product that Apple has introduced since Steve Job's death.
Apple Watch put a Unix computer with a 16-hour battery life, an LTE modem & multiple health sensors on my wrist. I’d count that as significant.
Having fun with writing CLI apps and daemons for the watch?
Plus POSIX support in IoT like devices exists since ages.
It’s important to note that most of the things mentioned here are just “tricks”: they’re fun to discover and talk about, but they really only end up being minor wins in practice. TSO is great…if you are trying to make a simpler Rosetta (it’s not even necessary on the M1, although I think Apple is still using it for convenience; I’m still trying to find out where). The JavaScript instruction speeds up…one specific rou…
> The reality is that the reasons these chips are fast are either unknown or boring. I suspect that these will one out as we play around with them more, but we don’t have the details right now. I disagree, I think we have plenty of information. This is what happens when a huge proportion of your die isn't doing instruction decoding. x86/amd64 are old and crufty. Lessons have been learned, and had been learned for som…
Dunno why people would keep thinking this is a good idea, but if someone wants to try eating it with a new VLIW design yet again, I’m always down for some popcorn.
Dynamically finding ILP at instruction dispatch time is always going to be smarter than a compiler trying to guess at compile time. IMO, it’s worth the area. Even if you assume the compiler gets it right and finds tons of ILP, it’ll get it wrong for the next hardware rev when your core inevitably changes and you have to break apart your VLIW instructions and get ILP back dynamically anyway. To say nothing of shared pipelines in an SMT processor, where VLIW basically runs counter to SMT and the only way to know which units are going to be available on a specific cycle is during runtime.
> and they're going to succeed this time.
I don’t see any reason why VLIW would succeed more in future attempts than in past attempts.
> 4/ So Apple simply cheated. They added Intel's memory-ordering to their CPU. When running translated x86 code, they switch the mode of the CPU to conform to Intel's memory ordering. Uh, no. Implementing TSO in a highly performant way is not "cheating", it's a difficult engineering feat. And no, TSO is not some fancy Intel thingy. It's a standard memory model.
To add to this: The POWER7 through POWER9 processors from IBM implement an equivalent to this called "SAO", or "Strong Access Ordering Mode". To quote an IBM engineer: > Currently, power has a weaker memory model than x86. Implementing a stronger memory model allows an emulator to more efficiently translate x86 code into power code, resulting in faster code execution. What's interesting is IBM publishes pretty detail…