181–190 of 359 posts
It's not exactly a threat. Amazon use cortex A72 in their CPUs and there's no way they can replace most Intel CPUs with that. The performance isn't there.
Earlier quoted context omitted.
Allegedly, Apple hates GPLv3.
You would hate it too if you had to open source the entirety of your OS or application because a GPLv3 COPYING file was floating about in there.
Earlier quoted context omitted.
Intel has always been a process first, design second company. The company was founded by physicists and chemists. Their process has always been the best in the world until just recently. So they had a particular advantage, and exploited the heck out of it, but now the potency of that advantage is largely gone?
I don't know what country you're in but in cricket there's a concept of innings and scoring runs. There's this dude who averaged nearly a 100 in every innings, most others average 50. Now think of the situation as him scoring a few knots. Is he old and retiring? Or is this just a slump in form? Nobody knows! I worked for a design team and we were proud of our material engineers.
Earlier quoted context omitted.
The idea that Intel is “RISC under the hood” is too simplistic. Instructions get decoded and some end up looking like RISC instructions, but there is so much macro- and micro-op fusion going on, as well as reordering, etc, that it is nothing like a RISC machine. (The whole argument is kind of pointless anyway.)
With all the optimizations going on, high performance RISC designs don't look like RISC designs anymore either. The ISA has very little to do with whatever the execution units actually see or execute.
Just yesterday, I was trying to explain to my partner (who isn't a programmer) why I think open source software and hardware is so important. My argument is that without enough core components in the industry standard tech stack being open source, the more likely companies who develop solutions will restrict user freedom. For example, Apple has been able to own nearly their entire iDevice stack from manufacturing to…
If there is a security issue in the iPhone everybody knows who owns the problem. If there are scammy apps in the iOS App Store - and there actually are - everyone knows who has the power and responsibility to clean that up.
Just yesterday, I was trying to explain to my partner (who isn't a programmer) why I think open source software and hardware is so important. My argument is that without enough core components in the industry standard tech stack being open source, the more likely companies who develop solutions will restrict user freedom. For example, Apple has been able to own nearly their entire iDevice stack from manufacturing to…
Google itself has admitted that Android itself is a mess by lieu of the fact that they open sourced it in the first place.
Good thing Apple kept everything proprietary. There’s at least one Technology Stack I can place my trust on.
Earlier quoted context omitted.
Intel chips are RISC under the hood these days (for a long while - decade or more). They're CISC at the ASM layer before the instructions are decoded and dispatched by the microcode.
Possibly stupid questions from someone completely ignorant about hardware: If they didn’t care about backwards compatibility, would it be possible for them to release versions of their CPUs with _only_ the microcode layer? If yes, would a sufficiently good compiler be able to generate faster code for such a platform than for x86? Alternatively, could Intel theoretically implement a new, non-x86 ASM layer that would d…
The microcode is the CPU firmware that turns x86 (or whatever) instructions into micro-ops. In theory if you knew about all the internals of your CPU you could upload your own microcode that would run some custom ISA (which could be straight micro-ops I guess).
> If yes, would a sufficiently good compiler be able to generate faster code for such a platform than for x86?
The most important concern for modern code performance is cache efficiency, so x86-style instruction sets actually lead to better performance than a vanilla RISC-style one (the complex instructions act as a de facto compression mechanism) - compare ARM Thumb.
Instruction sets that are more efficient than x86 are certainly possible, especially if you allowed the compiler to come up with a custom instruction set for your particular program and microcode to implement it. (It'd be like a slightly more efficient version of how the high-performance K programming language works: interpreted, but by an interpreter designed to be small enough to fit into L1 cache). But we're talking about a small difference; existing processors are designed to implement x86 efficiently, and there's been a huge amount of compiler work put into producing efficient x86.
Earlier quoted context omitted.
A node is a combination of manufacturing capabilities and design components that are manufacturable in that process. They're typically named after an arbitrary dimension of a silicon feature, for example 14nm or 10nm. Your higher level design options are dictated by what you can produce at that "node" (with those masking methods/transistor pitches/sizes/electrical and thermal properties).
Would a pixel be a good analogy? It's the smallest thing you can make on your chip and that defines all the rest of your design.
What is missing from this analogy is the degree of layering / 3d structures that is possible. You might couple that to RGB v RGBY but I'm not really sure.
Earlier quoted context omitted.
CISC is still an asset rather than a liability, though, as it means you can fit more code into cache.
I don't think that's an advantage these days. The bottleneck seems to be decoding instructions, and that's easier to parallelize if instructions are fixed width. Case in point: The big cores on Apple's A11 and A12 SoCs can decode 7 instructions per cycle. Intel's Skylake can do 5. Intel CPUs also have μop caches because decoding x86 is so expensive.
(yes, I'm aware there's no high performance risc-v core available (yet) comparable to x86-64 or power, or even the higher end arm ones)
Earlier quoted context omitted.
My personal suspicion is that the integrated approach can eventually be a liability. If you have an integrated process/design house, process can count on design to work around its shortcomings and failures. By contrast, if you are process only, and multiple firms make designs for the process, you have to make your process robust, which means that your process staff is ready and has good practices down when it's time…
It turns out that the effect is typically exactly the opposite. Design and process are already coupled where a given process will have design rules that must be adhered to to achieve a successfully manufacturable design. Intel only has to support their own designs so can have very strict design rules. Fabs like TSMC have to be more lenient in what they allow from their customers so have looser design rules that resul…