All these are issues listed have been known. What surprised us all that Apple could make on the first attempt a processor that beats the Intel and AMD by 60% on first try! They also include encryption, video codecs, etc.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Developer Delves Into Reasons Why Apple's M1 Chip is So Fast
- Thread starter MacRumors
- Start date
- Sort by reaction score
Nope, there are already examples out in the wild where people have virtualized windows 10 ARM on M1 Macs:
Apple M1 Mac Running Windows 10 ARM Is Embarrassing For Surface Pro X
It seems that Apple's M1 Silicon isn't yet done amazing people, even those from outside of Apple's circles. The processor's benchmarks have already been covered…
www.slashgear.com
I really hope any app can tap into some of the extra processors in these chips. Maybe apple can make xcode take care of this kind of optimization? This time next year should be a great time to be a brand new apple hardware user in that many many more apps may be optimized for the M1 by then. The apps on the same chips should get faster over time, thats just great.
It's even less of an issue with so much transitioning to web based applications too. It's not perfect for everything but its getting better by the day.
I absolutely CANNOT wait to see what the Mac Pro becomes. If it's not priced like the Intel variant, I'm in!
the CPU cores are RISC (based on an ARM instruction set).
The other more specialized tasks are not handled by the CPU cores at all.
RISC vs. CISC is mostly an not that important difference: the M1 uses microcode in the end just like an x86 CPU.
But there is one important advantage the AMD instruction set has over the x86 one:
Like the article itself explains: the absense of variable length instructions make it super easy to do parralel decoding of the instructions inside the CPU allowing for massive improvements in out of order execution. That's where the M1 single core speed comes from in the end. Something that's simply not easy to do with an x86 instruction set (if possible at all - AMD saying the limit of what's possible is at is at 4 parallel instruction decoders while the M1 in it's least complex form already does 8 tells a lot of what we might see when apple pushes this further in a next iteration).
Last edited:
That's exactly how it works: the developer uses an API (Like Metal for the graphics): the library then takes care of getting it done either in hardware if there is that, or using a general purpose CPU core if there is none. For the application it's almost fully irrelevant: it gets done, and how fast depends on the hardware present in the machine.
Last edited:
You’re assuming everyone spends their time on Macrumors, so they’ll know how much faster the M1 Macs are compared to their intel counterparts. The average buyer on eBay probably just cares about it being a Mac in the first place.
I wonder what's holding apple back from releasing the M1 to the PC market. It would be a real kick to the balls to both Intel and AMD.
More instructions doesn’t mean more complex instructions.
The difference between RISC and CISC isn’t the number of instructions, it’s the complexity of instructions. So, unlike CISC, RISC processors generally:
1) have fixed instruction lengths
2) only allow memory access via load/store instructions and not through other instructions
3) have larger register files
4) have simpler addressing modes (i.e. no “store R0 in [R1] offset by [R2]” type stuff)
5) have most ALU instructions (other than multiplies and divides) execute in a single pipe stage
6) do not encode instructions in such a manner so as to require a state machine for decoding
It’s actually very common for RISC CPUs to have MORE instructions than x86 or other CISC processors.
what’s holding them back is that are not a component supply company. They make money selling finished products, not by selling parts to their competitors who can then use them to compete with apple.
*rolls eyes*
Who says the M1 uses microcode? I don’t see any microcode ROMs or microcode sequencers in the floor plan. I’ve designed many RISC chips and none of them used microcode.
Why would they? The whole purpose to make the M1 is to be able to control and integrate it all and not be dependent on partners like Intel that prove to be unreliable (at best).
They also don't sell A14s ...
There's no need to sell the best component you have when you also sell it integrated into a final product. Let those end users that want the M1 buy the whole product, that's where the profit margins are.
moreover they'd have to divulge way more than they want to their competitors if they were to sell the M1.
The original article at https://erik-engheim.medium.com/why-is-apples-m1-chip-so-fast-3262b158cba2
Not this many and not on the SoC level as Apple has implemented it. The discrete and separate 56001 DSP in the NeXTcube and station comes to mind first.
Juli Clover is an absolutely excellent technical writer. She's got a rare ability to take an extremely complicated concept -- such as this revolutionary new SoC CPU -- and make it readily understandable by everyone. This article is no exception; I've been reading everything I can find about the M1 and she just managed to teach me a whole bunch of new stuff in the third-last paragraph. We're all fortunate to have Juli and her writing skills here for us at a time when the entire Apple landscape is changing fast.
With macs stubbornly stuck at 8% market share for the last two decades - Intel has nothing to worry about. And AMD has never been and never would end up in a Mac any way. People are pretty much set in their ways. Camp Windows or Camp Mac.
Where does it say that? The word “microcode” comes up only once, and not with respect to M1.
Are you confusing micro-ops with microcode? These are two very different things. Micro-ops, in this context, are merely re-encoded versions of the ISA instructions. There is a 1:1 relationship, unlike microcode, where one ISA instruction is broken into numerous microcode instructions.
I have not been this excited about owning a new "Unix RISC workstation" since my SGI Indigo2 Max Impact.
The powerful RISC Unix workstations with exotic co-processors are back.
The powerful RISC Unix workstations with exotic co-processors are back.
Yes, apps can tap into all of the processing circuitry. That’s what it’s for.
I have not been this excited about owning a new "Unix RISC workstation" since my SGI Indigo2 Max Impact.
The powerful RISC Unix workstations with exotic co-processors are back.
The 1990’s were a golden age of awesome risc machines. Purple SGI MIPS boxes, DEC Alphas, pizza-box Sun SPARC boxes, boring ol‘ IBM RS-6000’s, HP PA-RISC, ...
A lot of cpu architects had a lot of fun back then
We had some lovely Pyramid RISC computers back in the 80’s (a Pyramid 90x and a 98x). They were fabulous, oh so fast (compared to the MicroVaxes they replaced), and ran a Unix that could appear largely BSD or largely AT&T with a simple per-user “universe” command (using conditional symbolic links). Those gave me an enduring respect for RISC systems. Sadly, by the next generation they’d stopped their own processor development and switched to MIPS RISC chips, which were rather pedestrian. From there we went to HP (PA-RISC), and those lasted quite a while.
So, yeah, RISC has been a terrific - and thoroughly useful - technology for quite a while.
I don’t think so. Before M1 I would have considered a used Mac to save some money. Now, I’d rather pony up more money for a base new system with multiples in performance, warranty and future integration and support. While that’s just me I suspect that will bear out in the consumer market. It may take a while but it’s coming.