Arm is not any better than x86 when it comes to instructions. There’s a reason we stuck to x86 for a very long time. Arm is great because of its power efficiency.
That power efficiency is a direct result of the instructions. Namely smaller chips due to the reduced instructions set, in contrast to x86’s (legacy bearing) complex instruction set.
It’s really not, x86 (CISC) CPUs could be just as efficient as arm (RISC) CPUs since instruction sets (despite popular consensus) don’t really influence performance or efficiency.
It’s just that the x86 CPU oligopoly had little interest in producing power efficient CPUs while arm chip manufacturers were mostly making chips for phones and embedded devices making them focus on power efficiency instead of relentlessly maximizing performance. I expect the next few generations of intel and AMD x86 based laptop CPUs to approach the power efficiency Apple and Qualcomm have to offer.
All else being equal, a complex decoding pipeline does reduce the efficiency of a processor. It’s likely not the most important aspect, but eventually there will be a point where it does become an issue once larger efficiency problems are addressed.
yeah, but you could improve the not ideal encoding with a relatively simple update, no need to throw out all the tools, great compatibility, and working binaries that intel and amd already have.
Well, not exactly. You have to remove instructions at some point. That’s what Intel’s x86-S is supposed to be. You lose some backwards compatibility but they’re chosen to have the least impact on most users.
Yes I understand that and agree, but the reason x86 dominated is because of those QoL instructions that x86 has. On arm you need to write more code to do the same thing x86 does, OTOH, if you don’t need to write a complex application, that isn’t a bad thing.
You don’t need to write more code. It’s just that code compiles to more explicit/numerous machine instructions. A difference in architecture is only really relevant if you’re writing assembly or something like it.
Sorry, I should have been more specific. I am talking about assembly code. I will again state that I am pro-arm, and wish I was posting this from an arm laptop running a distro.
Arm is better because there are more than three companies who can design and manufacture one.
Edit: And only one of the three x86 manufacturers are worth a damn, and it ain’t Intel.
Edit2: On further checking, VIA sold its CPU design division (Centaur) to Intel in 2021. VIA now makes things like SBCs, some with Intel, some ARM. So there’s only two x86 manufacturers around anymore.
We stuck to x86 forever because backwards compatibility and because nobody had anything better. Now manufacturers do have something better, and it’s fast enough that emulation is good enough for backwards compatibility.
Arm is not any better than x86 when it comes to instructions. There’s a reason we stuck to x86 for a very long time. Arm is great because of its power efficiency.
That power efficiency is a direct result of the instructions. Namely smaller chips due to the reduced instructions set, in contrast to x86’s (legacy bearing) complex instruction set.
It’s really not, x86 (CISC) CPUs could be just as efficient as arm (RISC) CPUs since instruction sets (despite popular consensus) don’t really influence performance or efficiency. It’s just that the x86 CPU oligopoly had little interest in producing power efficient CPUs while arm chip manufacturers were mostly making chips for phones and embedded devices making them focus on power efficiency instead of relentlessly maximizing performance. I expect the next few generations of intel and AMD x86 based laptop CPUs to approach the power efficiency Apple and Qualcomm have to offer.
All else being equal, a complex decoding pipeline does reduce the efficiency of a processor. It’s likely not the most important aspect, but eventually there will be a point where it does become an issue once larger efficiency problems are addressed.
yeah, but you could improve the not ideal encoding with a relatively simple update, no need to throw out all the tools, great compatibility, and working binaries that intel and amd already have.
its also not the isa’s fault
Well, not exactly. You have to remove instructions at some point. That’s what Intel’s x86-S is supposed to be. You lose some backwards compatibility but they’re chosen to have the least impact on most users.
Would this actually improve efficiency though or just reduce the manufacturing and development cost?
Instruction decoding takes space and power. If there are fewer, smaller transistors dedicated to the task it will take less space and power.
Yes I understand that and agree, but the reason x86 dominated is because of those QoL instructions that x86 has. On arm you need to write more code to do the same thing x86 does, OTOH, if you don’t need to write a complex application, that isn’t a bad thing.
You don’t need to write more code. It’s just that code compiles to more explicit/numerous machine instructions. A difference in architecture is only really relevant if you’re writing assembly or something like it.
Sorry, I should have been more specific. I am talking about assembly code. I will again state that I am pro-arm, and wish I was posting this from an arm laptop running a distro.
Arm is better because there are more than three companies who can design and manufacture one.
Edit: And only one of the three x86 manufacturers are worth a damn, and it ain’t Intel.
Edit2: On further checking, VIA sold its CPU design division (Centaur) to Intel in 2021. VIA now makes things like SBCs, some with Intel, some ARM. So there’s only two x86 manufacturers around anymore.
Three? VIA?
Yes, everyone forgets them. Mostly for good reasons.
Do they (or whatever’s left of them) have a license to x86_64, or is it just x86?
They have x86_64 models.
We stuck to x86 forever because backwards compatibility and because nobody had anything better. Now manufacturers do have something better, and it’s fast enough that emulation is good enough for backwards compatibility.
Acorn computers would like to say that’s not 100% correct.