181–190 of 196 posts
Earlier quoted context omitted.
I seem to recall that IBM had second source rights to the 8088 too which presumably made the choice easier.
Fair enough, then I am most likely wrong here.
Feeling a bit nostaligic now as my first job was with IBM selling the original PC to small businesses. Not the hardest job!
Earlier quoted context omitted.
I disagree regarding the importance of this kind of "tricks". You are right in pointing to all the "boring" stuff that is considered state of the art in chip design being the main reason why these chips are impressive. Apple seems to have pulled all the right strings in that regard. But there is a point at which you can't execute the known optimizations any more perfect than you already do - when you're already using…
The point is that in benchmarks these things don’t really show up at all and Apple still leads. The things I mentioned are only useful because of specific usecases, and saying that Apple is ahead because of those is inaccurate. The point is that the tricks are extremely important for Apple, but not in an argument of “why is Apple making fast processors”. Regarding a comparison with AMD: I think we’ll have to see what…
Yeah, you can of course say that each of these is a "specific use case". But which use cases other than running native MacOS apps built on Apple's frameworks, x86 MacOS apps and web applications do you have in mind? I see those covering a lot of what people tend to do with their MacBooks.
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…
> we're also going to see someone give VLIW another shot 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 r…
For example, compilers already model the CPU's pipeline and ILP capacity to inform instruction selection. VLIW designs are an attempt to make that cooperation more explicit, similar in spirit to branch/prefetch hints. Maybe there's still a way to do that well?
And re: microarchitectural changes in the next hardware rev: https://news.ycombinator.com/item?id=25237056
These ideas might ultimately fail, but they seem worth looking in to, at least.
Earlier quoted context omitted.
> we're also going to see someone give VLIW another shot 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 r…
Even if compiler-only ILP is doomed to fail, maybe VLIW optimists are just hoping something useful might come out of everything we've learned? For example, compilers already model the CPU's pipeline and ILP capacity to inform instruction selection. VLIW designs are an attempt to make that cooperation more explicit, similar in spirit to branch/prefetch hints. Maybe there's still a way to do that well? And re: microarc…
I don’t think we’re really learning much by pretending building a new one is a good idea. Or that the last efforts had much value.
No one is saying don’t make progress on compilers. Look around you and you’ll see the things you just referenced already exist in practice in production today. (Among others: compiler/architecture co-design is a well established and fertile area of work. Compiling to intermediate formats which specialize for a device later is in use to some degree in App Store, which keeps programs in an intermediate format and thins binaries down to specific slices on demand for iOS devices, etc.) None of these technologies justify building a new VLIW chip or have frankly much to do with those efforts. The best thing we could learn from the huge amount of effort that’s gone into VLIW architectures is actually learn the lesson that in front of us, demonstrated repeatedly, that unless something substantial changes, VLIW does not produce a better architecture for processor cores and the assumption that it would was wrong.
Earlier quoted context omitted.
> Compilers "failed" because VLIW is fundamentally not a particularly useful idea. I think the problem isn’t just that it’s not particularly useful, but that it’s an actively bad idea. It statically encodes ILP that we get dynamically in chip designs today, which means that ILP can no longer react to changing conditions, like literally any core architecture changes as the underlying hardware evolves (or even on the s…
Adapting to advancing hardware isn't impossible. It's been awhile since I've looked so details are a little hazy, but I know the Mill architecture had an answer to this. I believe they were using effectively two-pass compilation. The first compiled against an abstract version of the architecture, and this is what was distributed. Then this could be further specialized on the user's machine as at that point the limits…
Not sure why anyone thinks that’s an argument for doing it.
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.
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.
Earlier quoted context omitted.
Or for us old [feeling] folks: it’s “cheating” by getting a world map and playing through the puzzles and minibosses we would still encounter... not getting a Game Genie and sliding under Mother Brain. Edit: Lol I know, downvote away, icgaf I haven’t played a game besides minesweeper in months.
I honestly just don't understand what you're trying to say.
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…
Intel tried to be brave with the 432.
And failed.
The 8086 was rushed as a stopgap. It was never intended as a serious design.
Intel tried to be a little brave with the 286.
And failed.
Intel tried to be brave with the i860.
And failed.
Intel tried to be brave with Itanium.
And failed.
In the meantime Intel have made countless of billions with souped up 8086s. And we're stuck with them. Or were.
Earlier quoted context omitted.
The most informative post at the moment for me, with more detailed technical information for those who are interested in what's actually making Apple's M1 CPU fast, based on the article by Anandtech, is much lower on this page, by GeekyBear: https://news.ycombinator.com/item?id=25235214
The AnandTech article is not bad, but I have heard that their tests misrepresent some microarchitectural details that they didn’t manage to guess the underlying design of correctly.
Have you maybe also heard which details could have been misrepresented?
Earlier quoted context omitted.
The AnandTech article is not bad, but I have heard that their tests misrepresent some microarchitectural details that they didn’t manage to guess the underlying design of correctly.
> misrepresent some microarchitectural details Have you maybe also heard which details could have been misrepresented?