Maybe Samsung will manage an Apple M1 competitor.
More difficult, however, would probably be selling it - I would imagine some HPC clusters would love it, for example, but for consumer products Apple can charge through the roof because their customers are used to paying pretty high prices for (sometimes better, sometimes worse) hardware. Apple's vertical integration also means they basically don't have to bother building an acceptable ecosystem around their new chipset - there's basically no documentation or vTune-style performance tools. It's also partly a question of priorities, but AMD still lag behind Intel even after decades in the game.
Apple just went with an 8-wide decoder, surprising a bunch of people. There's not much difference between 4-wide and 8-wide, aside from Apple deciding that such a wide single-core unit was worthwhile.
Not that Apple will tell us how many units it has
It's actually well known how wide the M1 is.
You can measure the ROB pretty accurately but the execution units have to be used to be measured.
uOps are already decoded by definition
Intel and AMD both perform decodes in parallel, but not as wide as M1, but having such a large and complex decoder costs silicon and power. Taking RISC-V as an example, a fixed width frontend is a project for a student, a modern x86 decoder is probably millions to write and verify.
I bet both Intel and AMD aren't exactly in love with x86 at the moment
I must be missing something, because it looks pretty simple as a segmented sum problem to me.
A good example of parallel segmented sum is bishop / rook (aka sliding pieces) movement.
https://www.chessprogramming.org/Kogge-Stone_Algorithm
This segmented sum / prefix sum / Kogge Stone is taught in carry sum adder class at the undergrad level. Sure, it's non obvious that it applies to parallel decoding but id expect this sort of thing to be a student exercise at the masters level.
A master's project might be to write a decoder, possibly to verify (prove - everything in a CPU has to be formally verified or generated from some other formally verified tool) it.
As proof I raise that many disassemblers, which run as software and are therefore much easier to write, still disagree and struggle with x86
https://en.wikipedia.org/wiki/Prefix_sum
In particular, this arrangement: https://en.wikipedia.org/wiki/Prefix_sum#/media/File:Hillis-...
Now "add" (or +) is associative. But it also works for *, min, max, and even weird stuff like "Can the Bishop move here" or "Can the Rook move here". So the goal is to find an associative operator that you apply byte-per-byte.
------
Okay, a brief detour. It seems obvious to me that a finite-state machine can decode x86 byte-by-byte. FSM is the "obvious" sequential algorithm that determines whether the byte is the start-of-instruction, or the middle-of-instruction, as well as what instruction it is by the end.
Remember: we're just trying to make a FSM decode ONE instruction right now. That's pretty obvious how to do that. (Alternatively, imagine a RegEx that can parse an instruction from the bytestream when given the start-of-instruction. All Regular-expressions have a finite-state-machine representation).
Hillis / Steele proved that finite-state machines are associative operators (!!!), and therefore can be used in parallel-prefix sum arrangements. (http://uenics.evansville.edu/~mr56/ece757/DataParallelAlgori...)
The page number is 1176:
> Since this composition operation is associative, we may compute the automaton state after every character in a string as follows:
> 1. Replace every character in the string with the array representation of its state-to-state function.
> 2. Perform a parallel-prefix operation. The combining function is the composition of arrays as described above. The net effect is that, after this step, every character c of the original string has been replaced by an array representing the state- to-state function for that prefix of the original string that ends at (and includes) c.
> 3. Use the initial automaton state (N in our example) to index into all these arrays. Now every character has been replaced by the state the automaton would have after that character.
In short: computing the "state" of a sequential FSM applied across its inputs can be EASILY performed in parallel through the prefix-sum model.
Any finite state machine can be converted into parallel prefix form through this mechanism.
"Work Efficient" Parallel Prefix arrangement is O(log(n)) depth and O(n) total elements, which means that parallel decoding to any width (ie: 8-way decoder, 16-way decoder, or even 1024-way decoder) is LINEAR in terms of power-consumption and O(log(n)) with respect to time.
The layout for work-efficient Parallel Prefix is: https://en.wikipedia.org/wiki/Prefix_sum#/media/File:Prefix_...
I'm not sure x86 decoding is oh-so-simple, because if you bring in memory the alignment is not guaranteed so you don't even know where the instruction starts let alone where it ends. An x86 instruction can theoretically have an unbounded number of prefixes, meaningful only after decoding something after that - maybe you can do it with a FSM but an enormous one.
All in all this doesn't sound like a master's project in the slightest, because remember I said design and verify not just build a never-used-again toy.
There have been probably hundreds of millions of dollars spent on this over the years, and they're basically stuck on the current width and multiple pipeline stages.
All x86 instructions are strongly bounded by 15 byte lengths, otherwise processors throw an exception.
I just searched StackOverflow: https://stackoverflow.com/questions/23788236/get-size-of-ass...
Just as I expected: finite-state machine used to decode. Now write a FSM-compiler (which is an undergrad-level project), to automatically parallelize the implementation.
The parallelization step is probably Master's level, but a very advanced undergrad student can probably accomplish it: since all the individual elements are undergrad projects (Kogge-stone applied to associative operators, finite-state machine compiler / regular expressions)
The overall process is also documented by Intel in their Opcode map: https://www.intel.com/content/dam/www/public/us/en/documents...
As a FSM, verification is simple. Just generate all x86 instructions (there are a finite number of them after all), and ensure your FSM properly goes through all of them.
You have to verify it decodes invalid instructions as a fault which means testing the entire search space.
Hypothetically you could use a bounded model check but you need to test roughly 10^36 combinations which is still thousands of years if you can do a 1000 billion billion a second. You need a formal proof of the operation too.
You don't need to do an exhaustive check of the 2^8^15 all 15-byte combinations. You just check all state-transitions of the state machine.
Or to put it another way: you don't need to test all 2^8^15 byte combinations. You just need to check all invalid-instructions that have ONE invalid byte, to prove the attributes of the finite-state-machine.
This has been the case for, eh, decades now? To me it's almost a joke how many times Intel has tried to replace ia32 with a modernized replacement and miserably failed to make any headway.
I suppose Intel doesn't want to try competing with the legion of architecturally similar RISC cores and would rather "go big" with ideas like Itanium/i860/i960/iAPX. It's funny to imagine, but maybe one day they'd release a RISC-V implementing processor. Can't imagine them licensing the rights to ARM, and going with Power or MIPS also seems out of character.
Only for programs that depend heavily on just-in-time compilation for Java, JavaScript etc. Apple must fall-back to interpretation of the x86 instructions, being then much slower.
Also the outperforming of AMD/Intel has been somewhat exaggerated. Apple M1 is faster in single-thread than any old Intel or AMD, but it is slower than any new Zen 3 CPU and it will be slower than the top models of Intel Tiger Lake H and Intel Rocket Lake. In multi-thread M1 is easily beaten by many processors.
On Christmas I have upgraded the CPU in one of my computers with a Ryzen 9 5900X, so I could verify that in the single-thread benchmarks that I could run on my computer, the values matched those published elsewhere for Zen 3 and they also exceeded the highest of the values published for Apple M1, by e.g. from 3% to 4% in Geekbench 5, until 24% in gmpbench.
When the M2 comes out with a big heatsink and fan, it is going to be extremely competitive. Although AMD might be on 5nm by then.
The M1 has a maximum power consumption of 15.1w (13.8w + 1.3w) so for the high powered cores that is 3.45w/core and a miniscule amount for the low power cores. A mac mini tops out at around 20w during 8-core CPU benchmarks. While a 5950X PC will draw around 96w at the wall when idle.
I know a Ryzen desktop CPU probably won't necessarily draw its entire TDP but it is not in the same league as an low powered CPU such as the M1 or the latest Ryzen mobile CPUs in terms of power consumption.
The 5990X is at 4.37W/core at its maximum power consumption - 280W/64 cores. This is from full TDP, which yes it very rarely touches, and when it does it's crunching way more numbers than most benchmarks use.
The M1 core is not that far away. A single core can boost up to 15W or more. The reason why laptops catch up to desktops in single core benchmarks is because their single core power budget is almost exactly the same but every time people act as if there is still a 4x energy efficiency gain left to be exploited when there isn't.
Idle power is a matter of how integrated your system is. The M1 is highly integrated so it will consume less power just like any other integrated SoC. When people buy desktops they want to get as far away from an integrated system as possible.
The documentation is depressingly more detailed that what Apple bless you with. I always get the feeling that Apple create for the same reason a pretentious chef cooks, you're merely proof of my greatness.
But let's see what they are up to.
What is genuinely so bad about Linux these days? Although I like playing with low-level stuff, I derive zero pleasure from OS-fettling and I just stuck Mint on my laptop - it's been basically perfect apart from a problem with the dual-boot setup which I think is an SSD problem waiting to explode.
Half the time I read these complaints, I either see people who actually already have neck beards in denial, or people who are expecting Linux or Windows to be identical to macOS.
Desktop Linux is developed by people who love CLI. It's not built by people that try to address problems of common mundane people off the street.
I'd rather use Windows than Linux for daily driver. Atleast UI will not freak out like in Ubuntu.
Half the time I read people saying have you tried Linux Desktop, I either see people who are tasteless and love being nerdy with tmux environment, or people who are expecting others to be like themselves.
As Linus Torvalds would plainly put "Desktop Linux sucks. It is the worst piece of shit attempt at Desktop OS". :-)
Look at the direction modern Gnome goes. They have the money from Red Hat and Canonical. BTW systemd too was developed by salaried employees of Red Hat. Money makes things happen, but not always the nicest things.
There's now, what, 3 forks of RHEL? People are free to do what they want, of course, but this doesn't help Linux at all.
For all its faults, systemd was a major step forward for a system to "just work".
I get far more UI freakouts in Windows.
Most of the glitchy stuff I've seen like you describe is either nvidia+nouveu driver, or AMD's GPUs.
Our operating system in an outlet for so many cultures — privacy minded, seeking freedom or free, people who hack and patch, etc, etc. And your first instinct is to take it away, make it another Windows/macOs for you who don't even run Linux.
I feel sorry for people who tried to help you, that's you who expect others to be like yourself.
Linux gives me the system I want — functional understood minimalist retro style [1]. And I am not alone [2], these are not tasteless, that's my home. Get off my lawn!
I shopped around for Linux distributions and finally settled on Pop!_OS. I loved it. No fiddling needed and the user experience is the closest to MacOS I have gotten.