[HN Gopher] Ask HN: Can competitors catch up to Apple Silicon?
___________________________________________________________________
Ask HN: Can competitors catch up to Apple Silicon?
The Apple M1 Ultra SoC chip achieves 87% of the performance of the
Intel 12900K and Nvidia RTX 3090 combined while only consuming 34%
of the power. The entire M1 Ultra chip draws 225W at full load and
11w at idle. Forget the Nvidia card and the other PC components,
the 12900K alone can draw 250W and the Ryzen 5950X 140W. This is a
seismic shift. Can Intel and the other players like AMD and Nvidia
catch up to this peformace per watt that Apple has on their hands?
Author : carlycue
Score : 123 points
Date : 2022-07-04 10:39 UTC (12 hours ago)
| pjmlp wrote:
| Given that whatever Apple has is not going into 80% of the
| desktop market, 60% of the mobile market, 100% of game consoles,
| or 100% of the server market, it matters much less than some
| Apple afficionados make out of it.
| philistine wrote:
| When Apple can make a game console for half the price with the
| same GPU power as the competition, which is something that
| could happen in ten years, Microsoft and PlayStation are going
| to sweat and pay very close attention to what Apple is doing.
| sys_64738 wrote:
| Well if the initial M2 machines are anything to go by then x86
| really has nothing to worry about. Apple will damage the
| reputation of their systems by themselves.
| [deleted]
| fxtentacle wrote:
| For many years, AMD GPUs were cheaper and equally or more
| performant than NVIDIA GPUs. Did that stop NVIDIAs lead in AI
| training? No, software support is the key component.
|
| It's the same with Apple's M1. I don't know anyone who is using
| it. People need obscure x64 instructions and CUDA. And that means
| you buy AMD CPU + NVIDIA GPU as the cheapest high-performance
| combination.
|
| Also, I expect that the 5nm process is responsible for a large
| part of the power savings in the M1. So I would expect an AMD CPU
| on TSMCs 5nm to be pretty close in terms of performance per watt.
| It's just that the mainstream market isn't willing to pay the
| premium price for 5nm yet. So AMD produces "good enough" at a
| price that people are happy to pay, which means they need to hold
| off on going 5nm for now.
| SaulJLH wrote:
| "For many years, AMD GPUs were cheaper and equally or more
| performant than NVIDIA GPUs. Did that stop NVIDIAs lead in AI
| training? No, software support is the key component. It's the
| same with Apple's M1. I don't know anyone who is using it.
| People need obscure x64 instructions and CUDA. And that means
| you buy AMD CPU + NVIDIA GPU as the cheapest high-performance
| combination."
|
| Riiight, but, OP isn't necessarily talking purely from an AI/ML
| use case.
| fxtentacle wrote:
| Well if you don't need the high performance, then I'd expect
| people will go for a cheap CPU, meaning no M1 Ultra.
| pclmulqdq wrote:
| ML training isn't the only application of high performance
| computing. Apple is making video editing machines - which
| is why they have the mix of cores that they do. Simulations
| are also high-performance computing applications.
| PaulDavisThe1st wrote:
| > Apple is making video editing machines - which is why
| they have the mix of cores that they do.
|
| Nope. They have that mix because they've decided to
| prioritize power consumption reduction (I suspect because
| they sell way, way more laptops that desktops/servers).
| It's actually a PITA for developers (you have to ensure
| that your compute-heavy threads are always on the
| performance cores), and conceptually confusing for users
| if they ever have to confront it. For pure performance,
| with no concern for power consumption, there are faster
| solutions.
| tambourine_man wrote:
| Software changes much faster these days. We are all dealing
| with high abstraction layers and legacy x86/64 and even CUDA
| can be replaced without much disruption in most cases.
|
| If it's proven that Apple can consistently provide better
| performance per watt per dollar and have enough chips available
| that people can actually buy, I think they can stand a chance
| to gain the AI market.
| fxtentacle wrote:
| "even CUDA can be replaced without much disruption in most
| cases"
|
| Tell that to AMD who's been missing out on the very lucrative
| government data-center market because they can't replace CUDA
| well enough. BTW, PyTorch and TensorFlow still ship without
| AMD support despite AMD's ROCm being around for 6 years now.
| pca006132 wrote:
| iirc there are comments saying that ROCm is not very mature
| yet. I wish OpenCL can evolve to compete with CUDA
| tambourine_man wrote:
| Is that more an indictment of ROCm immaturity or of
| PyTorch/TensorFlow unwillingness to support it?
| pclmulqdq wrote:
| ROCm is pretty mature, but harder to support than CUDA.
| Its BLAS library works well. PyTorch and TensorFlow are
| likely getting a lot more help from Nvidia than from AMD
| on compatibility. The ROCm ecosystem is a lot smaller,
| too, so there are many fewer examples to copy.
|
| Still, if you want to do floating point math with high
| performance for a lot cheaper than Nvidia, investing the
| time in ROCm is probably worth it.
| fxtentacle wrote:
| I believe ROCm isn't usable yet.
|
| I don't know anyone who successfully trained a state of
| the art neural network on anything that was not NVIDIA.
| AMD keeps offering their own forks of PyTorch and
| TensorFlow, but last time I checked they were years
| outdated, and nobody uses them. So either
| PyTorch/TensorFlow are secretly sponsored by NVIDIA, or
| AMD's and Apple's CUDA replacements aren't mature enough
| yet. Given how many bugs there still are in CUDA despite
| them being around for a long time,
|
| I'd guess that building a GPU-capable BLAS library is
| just a lot more work than one would think. I mean I also
| always wonder why CUDA comes with 400 MB of GPU shaders
| ... but apparently they need that to cover every edge
| case in a fast way.
|
| FYI, this is the ROCm "getting started" guide:
| https://github.com/RadeonOpenCompute/ROCm-
| docker/blob/master...
|
| NVIDIA has a GUI installer for CUDA.
| pclmulqdq wrote:
| It is the former, that Nvidia effectively sponsors ML
| libraries. If you're training a neural network, and you
| are hiring expensive ML people, you're likely just going
| to pay the Nvidia tax than work on ROCm support.
|
| My use of ROCm for signal processing has been pretty nice
| so far, and I think the ROCm BLAS library is up to par
| now.
| paulmd wrote:
| > It's the same with Apple's M1. I don't know anyone who is
| using it.
|
| "I can't believe Nixon won. I don't know anyone who voted for
| him."
|
| Yes, a misquotation, but still. The Java/JVM world has dived
| into it. Java is all JVM code and it's platform-independent,
| and unlike, say, Python, the Java world never dived that
| heavily into native-interface code that tied them to a specific
| instruction set, they built a faster JVM instead of going out
| to native code. M1 is so good you can get better performance on
| a M1 MBA with significantly longer battery life compared to an
| i9 MBP of the previous generation.
|
| Same for average users who don't do any of the developer things
| - HN itself is a bubble and most users don't know or care the
| uarch is different at all, they just know a base-tier M1 feels
| better than an i9, and they're right.
|
| > So I would expect an AMD CPU on TSMCs 5nm to be pretty close
| in terms of performance per watt. It's just that the mainstream
| market isn't willing to pay the premium price for 5nm yet
|
| Apple and AMD are going to be on the same node this year.
| MomoXenosaga wrote:
| He who is first will later be last
|
| Bob Dylan
| WithinReason wrote:
| And the first one now will later be last - Bob Dylan
|
| The last will be first, and the first last - Matthew 20:16
| jacknews wrote:
| I hope so, but I'm also sure.
|
| Technology is created by people, and I believe a big chunk of
| Apple's silicon team left last year.
|
| So I hope we will see good performance from non-vertically
| integrated cpus soon. ie companies offering devices using a
| Qualcom or whatever cpu, which can run windows, linux, etc, not
| just tied into the Apple ecosystem.
| TruthWillHurt wrote:
| leguminous wrote:
| Intel's stated TDPs are not accurate representations of how
| much power a chip actually uses. You can see in some of these
| Blender benchmarks the 12900k hitting >230W average:
|
| https://www.tomshardware.com/reviews/intel-core-i9-12900k-an...
|
| It's very workload-dependent, so it's difficult to say how much
| power a chip will draw in general. It's clear that Intel is
| still a bit of an energy hog, though.
| nottorp wrote:
| - both Intel and AMD lie about TDP now, Intel much more than
| AMD
|
| - 225 W is for the M1 Ultra Mac Studio, whole system power
| consumption - that includes powering the TB peripherals if
| they exist
|
| - Intel numbers are just the CPU (not even including the
| chipset) and will only happen if you don't cool it enough and
| it has to throttle
|
| So yes, I'd rather have a M1 (probably a Pro would be enough)
| on my desk than an i9 under it. But I am weird and like cool
| and quiet, not larger numbers.
| datavirtue wrote:
| The first thing I did with my M1 MBP was fire up my game of
| choice for the last twelve years. It performed adequately, and
| respectably, but the performance is not equal to my Nvidia
| 1060/70. Still, I shut off my modern i5+Nvidia desktop that day
| and haven't turned it on since.
|
| MBP is too damn fast (holy shit the build times!!) and too damn
| quiet to go back. The M1 put the i5 in a headlock and had it
| begging for mercy without the slightest bit of effort.
| bee_rider wrote:
| One of Apple's major advantages, I think, is that they don't
| use very many shitty components. Meanwhile, OEMs always cheap
| out on components that don't produce the numbers that
| consumers understand -- hard drive? memory? Who cares! Here's
| the core count and clock frequency.
| yxhuvud wrote:
| Apple will stay in the lead as long as they pay TSMC for a
| virtual monopoly on the smallest die sizes. How it will look when
| that situation changes is anyones guess. Apple is likely to
| continue to use the least electricity as they have spent a lot of
| effort on that, but other than that is impossible to say.
| sausagefeet wrote:
| Intel is investing in RISC-V[0] as well as working on its own
| chips.
|
| But this kind of question is not new. 10-20 years ago nobody
| would be thinking ARM could catch up to Intel. But also, is your
| question just about laptops and mobile devices? I don't see Apple
| taking on server markets, where the power per watt is perhaps
| less important. Finally, lots of people will be using non-Apple
| hardware for a long time (think anyone who isn't in Engineering
| at a company, they will probably be on a Windows system), which
| means there is guaranteed revenue for these other folks to
| compete, and possibly, catch up.
|
| [0] https://www.zdnet.com/article/intel-invests-in-open-
| source-r...
| bayindirh wrote:
| > I don't see Apple taking on server markets, where the power
| per watt is perhaps less important.
|
| While, as an HPC admin, I don't expect to see any Apple branded
| XServes in our system room for a long time (if ever), or their
| silicon on any other system, many HPC and data center operators
| would love to have servers with better performance per watt,
| because cooling these systems is a pain.
|
| Everybody is moving to direct liquid cooling systems beyond a
| specific performance point, and this is not making things
| simpler.
| mouzogu wrote:
| And yet slack still takes 30 seconds to select and load a chat.
| sharikous wrote:
| The M1 is packed to the brim with top of the class technology
| (lower node, big ROB, big caches, fast buses, very complex
| prefetching and branch prediction...) and has the advantage that
| it was basically wrote from scratch during a decade or so from
| simple mobile level processors to full grade CPU, but it is not
| magic. Competitors can certainly catch up in some years
|
| A lot of their best engineers left and joined the competition and
| a whole lot depends on them. The second thing that needs to
| happen is a serious restructuring of existing processors, to the
| point of rewriting parts from scratch. It will take some time but
| there are companies with the budget and the know how to do it.
| naillo wrote:
| Considering that no one with an apple M1 chip is gaming or
| training ML with it, I'm not even sure what it means that these
| are supposedly better. What are people even using the extra
| performance for? Keeping thousands of tabs open simultaneously?
| zimpenfish wrote:
| > Considering that no one with an apple M1 chip is gaming or
| training ML with it,
|
| Anecdatum of one: I use my M1 chip for gaming (predominantly
| Minecraft with smatterings of Cities Skyline, Rocket League,
| etc.)
|
| (I have trained MLs using the Metal version of Torch, too, but
| generally only tiny textgenrnn things for fun.)
| Joeri wrote:
| Audio and video production, and web and app development.
|
| I don't think many people are switching from linux and windows
| (although I switched from a linux thinkpad to m1 air), but
| those upgrading from intel macs to m1 macs are seeing huge
| jumps.
| maccard wrote:
| We use it for compilation. The M1 Mac Pro we use is about 50%
| quicker than the i7 we had before it for an end to end compile
| of our project.
| amelius wrote:
| Compilation is just fast for me. A 100% increase in speed
| won't make a real difference. (Except when I compile an
| entire project from scratch, which I almost never do.)
| maccard wrote:
| I work on a medium sized project. A full rebuild is about
| 25 minutes on the M1 Mac and was about 55 minutes on the i7
| Mac mini we used before. The "normal" build (what most
| developers have to face semi-regularly) is about 15 minutes
| on the Intel and about 4 on the M1. (I checked our CI
| numbers and can't explain the discrepancy sorry but I would
| guess the M1 Mac is quicker linking and the link time
| dominates).
|
| Our CI does clean builds once a week, and the other builds
| somewhat regularly. Reducing the feedback loop by 10
| minutes for a developers post merge check is a huge win
| IMO.
| bluescrn wrote:
| Performance isn't everything.
|
| Even if the comparisons to the RTX3090 were legit, all that power
| is still 'trapped' inside a Mac.
|
| As the main reasons to have that level of power are gaming and
| VR, you'd be probably be better off having a bit less performance
| but on a Windows machine.
| PeterStuer wrote:
| And then you try gaming and it is comparable to a Ryzen 7 4800H
| (45W)/ Nvidia GTX 1650ti (50W).
| hajile wrote:
| The biggest problem has been Metal and incompatibilities. Metal
| 3 brings most of the important things they've been missing.
| We're already seeing companies like crossover working on this
| to make a lot of additional games work on their hardware.
|
| The second issue is dev relationships. The real AMD/Nvidia
| advantage over other GPU makers is that they pay huge amounts
| of money to optimize games to the point that their drivers will
| detect a game and then completely replace huge sections of the
| game with optimized versions they wrote. These relationships
| take a lot of time to establish and maintain.
|
| In any case, supply chain rumors strongly indicate Apple
| launching a very expensive VR headset in 2023 (which also
| matches up well with games that would be delivered after a
| half-billion dollar investment into their gaming subscription
| service around 2019). There are also rumors of Apple making an
| offer to buy EA games.
|
| Apple makes more money from games than every other major game
| company put together. They have a huge interest in moving
| further this direction going forward. I don't see any way they
| don't just throw large amounts of money into this problem until
| it goes away.
| Retric wrote:
| Several versions of M1 and M2 GPU's but M1 8-Core GPU (15W)
| being roughly equivalent to low end 50W GPU's makes me want to
| see what Apple could do with a discrete graphics card.
|
| 10+ times M2 performance as a discrete 200W card with dedicated
| memory and 100ish cores could be really compelling depending on
| the price point. That's RTX 3090 territory, but much easier to
| cool etc.
| rubatuga wrote:
| You are so wrong about achieving 87% of rtx 3090 power.
| dclusin wrote:
| Apples hardware is proprietary and they don't offer or probably
| plan to offer server chips. I think what would make these stats
| more interesting is if we saw a shift in the thin client vs. fat
| client debate back to fat clients. Perhaps these changes will
| bring us into that era?
|
| Amazons arm-based offerings are pretty interesting as are the
| other non-x86 initiatives. But I don't see x86 going away in my
| day job any time soon.
| incrudible wrote:
| The GPU is not that fast. It is at heart a mobile architecture
| that excels when the application takes that into account.
| Otherwise, it is mediocre. It is also worth noting that
| performance does not scale linearly with power. You can often get
| something like 75% of the performance at 50% of the power.
| fortran77 wrote:
| Of course. It's not a seismic shift; it has some advantages in
| some dimensions.
| uniqueuid wrote:
| The picture you're painting is far too simple.
|
| There are many metrics that play a role for different
| applications. A modern Nvidia card is magnitudes faster than any
| CPU and the M1 GPUs. A Nvidia A100 card has HBM memory with
| ~2TB/s bandwidth.
|
| On the other hand, there are areas where a ~5GHz intel CPU is
| competitive, or even older server chips with AVX can compete.
|
| So let's see what happens when Intel and AMD step to smaller
| processes and switch to much faster memory (ddr5 as apple has
| done). Maybe the gap is large in energy consumption, but not in
| total performance.
| daneel_w wrote:
| _> So let 's see what happens when Intel and AMD step to
| smaller processes and switch to much faster memory (ddr5 as
| apple has done). Maybe the gap is large in energy consumption,
| but not in total performance._
|
| There are 18 months worth of benchmarks from the Apple M1 that
| show that the gap really _is_ large in total performance, and
| the "standard" M1 doesn't use DDR5, it uses the same DDR4
| memory everything else uses. The observed performance gap is
| larger than what we can see happen between DDR4 and DDR5, and
| larger than what is expected to happen for AMD's and Intel's
| x86 between 7 and 5 nm.
| pclmulqdq wrote:
| Apple uses LPDDR RAM which is a very different protocol. It
| is actually faster than DDR, and this may be a big part of
| the performance difference.
|
| For obvious reasons, desktop CPUs cannot use LPDDR RAM,
| because you can't put it in DIMM form.
| daneel_w wrote:
| Are you really sure about that? I thought LPDDR is all
| about low power consumption - running at half the frequency
| but making up for it by twice the bus width, ending up at
| same performance but with an emphasis on the LOW POWER part
| of its name.
|
| Add.: or maybe I got it the wrong way around; smaller bus
| width but same performance due often being clocked faster.
| Either way I cannot find anything suggesting LPDDR offers
| practically faster performance on memory-bound operations
| than the DDR equivalent, but I'd love to see some tech
| details and numbers explaining how it works.
| pclmulqdq wrote:
| LPDDR used to be about power consumption. It is not any
| more. DDR uses a lot of power for I/O and SERDES links to
| maintain a modular form factor, and LPDDR uses a lot less
| power by having worse signal integrity and lower swings.
|
| They run the memory cells and the I/O faster, and as of
| LPDDR4 it is now significantly faster than the DDR memory
| products available.
| wmf wrote:
| In Apple's case, it's the same width (M1/2) or much wider
| (Pro/Max/Ultra) and also clocked faster (6400 vs. 4800).
| uniqueuid wrote:
| Yeah I was imprecise there, the M2 is using LPDDR5. So I'm
| expecting Apple to stick with that for future macs of this
| generation.
|
| The gap between M1/M2 is pronounced in laptops but you can
| get faster (and hotter) multicore CPUs. Single-core is also
| not the same gap that it was because Rocket Lake has caught
| up and Zen3 had less of a gap to begin with.
| daneel_w wrote:
| And M2 benchmarks aren't even out yet. The topic will be
| yet more interesting in the coming months.
| uniqueuid wrote:
| They are absolutely out, because the M2 MBP is publicly
| available.
|
| https://browser.geekbench.com/v5/cpu/15482594
| fxtentacle wrote:
| Oh so the M2 is a lot slower than Samsung phones?
|
| Samsung Galaxy S20 FE 5G = 2147483647 multi-core score
| https://browser.geekbench.com/v5/cpu/15129294
|
| But only 8928 multi-core for the new M2.
|
| Or maybe that page is kinda unreliable?
| sph wrote:
| That number is 2^31-1, the maximum number representable
| as a signed 32bit integer.
|
| Sounds like someone managed to push their fake Geekbench
| score.
|
| "Text compression: 22.8 TB/s". How long does the battery
| last though?
| fxtentacle wrote:
| Yes, that's what I wanted to say. Geekbench scores aren't
| that trustworthy.
| danaris wrote:
| "You _can_ post obviously absurd scores " does not
| logically lead to the conclusion "therefore none of the
| scores can be trusted."
| fxtentacle wrote:
| "You can post obviously absurd scores" makes it more
| difficult to believe a very good score for a very new
| device that has mostly been criticized in reviews:
| https://www.digitaltrends.com/computing/m2-macbook-pro-
| perfo...
| devoutsalsa wrote:
| Regardless of how fast the phone is, it's gonna throttle
| way down under any heavy load, unless you keep it super
| cool.
| fxtentacle wrote:
| They probably dipped it in liquid nitrogen during testing
| ;)
| daneel_w wrote:
| My point is that benchmarking as a whole need a bit of
| time to mature with the help of real and diverse usage.
| Not just two weeks of GeekBench.
| [deleted]
| FireBeyond wrote:
| Very simple. There's also several articles discussing that how
| certain M2 configurations are actually lower performance than
| the M1, so this is hardly a done race.
| rob74 wrote:
| Both Intel and AMD have the major disadvantage of having (or,
| let's say, wanting) to maintain x86 backward compatibility -
| which means not only staying compatible with the almost 45 year
| old CISC instruction set of the Intel 8086, but also with the
| whole line of CPUs that came after it. All this ballast makes
| it harder for them to build an energy-efficient CPU.
|
| By contrast, Apple was able to just create a new CPU based on
| the much more modern ARM architecture, and switch to it like
| they have already done two times before (from 68k to PowerPC
| and then to x86), because they control the whole Macintosh
| platform. Compare that to Microsoft's largely unsuccessful
| attempt of selling ARM-based Windows machines.
| dtech wrote:
| This argument goes back 30 years. As far as I know, not a
| hardware engineer, it's not that much of an issue since the
| only complicated thing is the decoder, and then it's
| microcode and not an issue.
|
| The TSO memory guarantee X86 is probably the exception, since
| Apple supports it on their M1s too for emulation.
| rbanffy wrote:
| > Compare that to Microsoft's largely unsuccessful attempt of
| selling ARM-based Windows machines.
|
| Microsoft failed at that multiple times in the past. Windows
| NT was initially available for multiple architectures, but
| that mostly ended with Windows 2000. Itanium got support
| until Server 2008 but non-server software support was very
| limited. Some Windows NT releases had a "workstation" label
| but application support, even from Microsoft, was between
| halfhearted and non-existent and the availability of some
| programs (such as Office) was almost a secret (I remember it
| existing for PPC, but never heard anything for MIPS or
| Alpha).
| CoastalCoder wrote:
| IMHO a major enabler for this is LLVM.
|
| I think it's significantly reduced the time / cost /
| difficulty in rolling out a new instruction set architecture.
| cowtools wrote:
| Are the GCC cross-compilers for ARM64 not sufficient? We're
| not talking about some niche, new architecture here like
| RISCV or WASM.
| pdpi wrote:
| Rolling out a new architecture isn't just about getting
| your own tools out, it's about enabling the rest of the
| ecosystem to come along for the ride.
|
| LLVM is specifically meant to be a compiler backend that
| you write languages frontends against. It sort of solves
| the expression problem for programming languages, and
| there's a whole range of production-ready compilers out
| there using it. When they add support for an
| architecture, every one of those languages also gets a
| large part of the work to support it done for them.
| gary_0 wrote:
| I think it goes beyond LLVM, it's software in general. 20
| years ago, software was locked into a particular
| architecture because proprietary compilers and binary blobs
| were the norm, and vendors still ruled their platforms with
| an iron fist. But nowadays, open source libraries and
| compilers are a lot more standard, and a lot of
| hardware/software is cross-platform so switching is easier.
| Linux is mainstream and gives you support for dozens of
| architectures for free.
|
| Also, CPU technology (outside of tiny embedded chips) is a
| lot more uniform with fewer weird variations or cost-
| cutting shortcuts, and transistors are ridiculously cheap.
| You can assume 32/64-bit, little-endian, twos-complement
| math, IEEE-754 floats, etc.
| saagarjha wrote:
| Having to support x86 is definitely not a "major"
| disadvantage.
| hajile wrote:
| The X2 cores in 8cx gen3 get similar performance to Zen 2
| U-series chips while using 7-10w instead of 15-50w.
|
| How many more ARM chips have to get equivalent performance
| at a tiny fraction of the power before people will finally
| start considering that either AMD and Intel hire the most
| incompetent people out there or that ISA actually matters?
| kaba0 wrote:
| Do we know whether that x86 backward compatibility is all
| that problematic? If I'm not mistaken, it is only used as a
| "public API" even in current CPUs, and on a microcode level
| it doesn't have as much relevance.
| pclmulqdq wrote:
| Backwards compatibility costs a tremendous amount of
| silicon to handle the micro-decoding. The more problematic
| aspect is things like the segment registers from 16-bit
| x86, which can give you a 4-operand LEA, and other such
| nonsense. Sure, these operands can be microcoded, but that
| leaves a lot of performance on the table when a modern
| program wants to use an old instruction (SETcc comes to
| mind for branch elimination).
| dmitrygr wrote:
| For example: Decode. One of the things Apple CPUs keep
| being praised for is how wide they are. To be wide
| effectively and keep your execution units busy, you need a
| wide decoder. With aarch64 it is easy. Every instruction is
| 4 bytes on a 4 byte boundary. Want a 4-wide decoder? Ingest
| 16 bytes and copy-and-paste the same decoder 4 times.
|
| X86 instructions are variable-length: 1-15 bytes. And you
| do not know how long any instruction is until you read
| almost every byte of it (there is no length byte up front -
| it is just a list of prefixes). Thus to make a 4-wide
| decoder you need to ingest up to 60 bytes, and your decoder
| cannot start on instruction #2 till it finds the end of #
| 1. (Or guess, and rewind as needed). Much harder and a
| rather long dependency chain for decoder #4 to even get
| started.
|
| Now say you want to go wider: 8-wide.
|
| Arm64: copy and paste same decoders again. Done
|
| X86: Now you need to ingest 120 bytes, and find even more
| boundaries, each depending on the previous - an even longer
| dependency chain. Decoder #8 cannot start till #1 - #7 are
| almost done. A mess nobody has managed to solve yet.
| jcranmer wrote:
| That would be a dumb way to build a decoder. Which is why
| that's not how it works on x86 processors.
|
| What an x86 processor does is fetch an entire cacheline
| of instructions at once. Working out which byte
| corresponds to instructions is a straightforward state
| machine--and state machines can be parallelized as
| reduction tree, because function application is
| associative! (This is usually described as "x86
| processors start decoding, in parallel, every byte as if
| it were the start of a new instruction.) My guess for x86
| is that resolving instruction length takes a single
| cycle, a single stage of the instruction decode pipeline.
|
| It's actually hard to come up with x86 instructions that
| are 15 bytes long. Your typical general-purpose
| instruction is going to max out around 4 bytes (REX +
| other prefix + opcode + ModR/M byte), and even that's a
| little long. A "complex" memory instruction that moves a
| 4-byte constant into a register + constant offset will
| manage 12 bytes, but that's really the limit of practical
| instruction. So there's no point building a decoder
| capable of ingesting that many extra-long instructions a
| cycle because it is so synthetic a use case.
|
| Sure, you could design a better compressed ISA for
| decoding than x86, but the impact of its complexity on
| processors is _vastly_ oversold. Just look at how much
| die space the x86 decoders actually take up to see how
| little of an impact it has.
| dmitrygr wrote:
| > fetch an entire cacheline of instructions at once
|
| And how many instructions fit into it? Are you going to
| feed an 8-wide decoder with a single 64B cacheline?
| Especially with no promises that any instruction starts
| or ends on that boundary?
|
| > It's actually hard to come up with x86 instructions
| that are 15 bytes long.
|
| Something as simple and trivial as loading a 64-bit
| immediate into a register is a 10-byte instruction in
| x86... So for you to feed an 8-wide decoder even with
| such simple things as that, you're already at TWO cache
| lines ingested per cycle (80 bytes)... good luck with
| that...
|
| I hear intel is hiring. Their current top of the line
| decoder is IIRC 5-wide. I am sure they'd like to hear
| your ideas as to how easy it is to decode x86 8-way
| jcranmer wrote:
| > Something as simple and trivial as loading a 64-bit
| immediate into a register is a 10-byte instruction in
| x86...
|
| It will only take a 10 byte instruction if you can't
| zero- or sign-extend from a 32-bit immediate. Of course,
| if you were on ARM or most RISC processors, such an
| immediate likely requires at least two instructions
| anyways.
|
| From paging through an objdump output of a large program,
| I'd hazard that average instruction size is about 4
| bytes, maybe a touch shy of that. After all, instructions
| like "add rax, rbx" is going to be 3 bytes (two if you're
| only using 32-bit registers!).
|
| > Their current top of the line decoder is IIRC 5-wide.
|
| Looking at wikichip for the block diagram [1], that's 5
| instructions per 16-byte window.
|
| [1] https://en.wikichip.org/wiki/intel/microarchitectures
| /skylak...
| gary_0 wrote:
| And those bytes matter when most Intel CPU cores have
| only a few dozen KB of L1I cache. Interestingly, the M1
| and M2 performance cores have a whopping 192KB of L1
| instruction cache.
| pclmulqdq wrote:
| ARM instructions aren't as compact as their x86
| counterparts, so they need a big cache to get similar
| performance on cache-bound applications.
| hajile wrote:
| ARM aarch64 instructions are around 12-15% bigger
| overall, but cache sizes are much larger than that. Most
| likely that is so they can power the massive reorder
| buffer and deal with having code for tons of branches
| handy.
| gary_0 wrote:
| AFAIK, AArch64 instructions are roughly 2x longer than
| x64's average, but that's 3x as much cache as a
| comparable Intel core.
| kaba0 wrote:
| Isn't it in part due to business reasons, namely that
| Apple is _not_ a CPU vendor, it doesn't have to turn a
| profit on chips so it can allow much larger die sizes and
| thus larger cache sizes as well. Is there something
| inherent in ARM here I'm missing?
| abc_lisper wrote:
| Excellent answer. I learnt something today!
| pizlonator wrote:
| The other answer was awesome but here's another one: Number
| of registers.
|
| Of course internally the CPU has some huge number of
| registers. But it matters how many registers the machine
| code can speak of, and arm64 has 32 while x86 has 16.
| Consequently, x86 machine code has more cases of data flow
| obscured by spills to the stack. In a very sophisticated
| cpu, that might mean more decoding work to try to
| reconstruct the original data flow, or more likely (what'll
| probably happen in most cpus), those spills will limit how
| wide the cpu can go.
|
| I don't know what limits you more in practice - the smaller
| number of registers or the variable length instructions.
| X86 throws at least one more limiter just for good measure:
| the TSO memory model, which causes memory effects to have
| dependencies between them in cases where they wouldn't on
| arm.
| erichocean wrote:
| > _X86 throws at least one more limiter just for good
| measure: the TSO memory model, which causes memory
| effects to have dependencies between them in cases where
| they wouldn't on arm._
|
| Apple's M1 supports TSO (on ARM, obviously).
| scheme271 wrote:
| Isn't that only used to support x86 emulation (i.e. apps
| for the older macs)?
| philistine wrote:
| Yea, and that emulation is fast as all hell !
| Asooka wrote:
| But you can run x86 software on the M1 at almost native speed
| through a software translator. Isn't that proof enough that
| the instruction set itself isn't what's holding back the
| hardware?
| fooker wrote:
| Most of the translation is done ahead of time, not
| something you pay for while running.
| mrandish wrote:
| > staying compatible with the almost 45 year old CISC
| instruction set
|
| It's easy to take for granted how unusual it was the WinTel
| hegemony happened at all. As a fan of the breathtaking
| diversity of classic 80s desktop computing (Amiga, Atari,
| C64, Spectrum, MSX, etc), I lamented the steamroller of
| WinTel beige-box homogenization as it paved over so many
| divergent evolutionary branches. Yet the fact I can _still_
| install and run mass market consumer software products
| released in the mid-90s on Windows 11.
|
| Yes, a high price was paid in both silicon and OS software to
| sustain such extraordinary backward compatibility - and is
| still being paid. While the utility of running circa-Win 95
| software today in minimal, it's pretty amazing and I think
| the underlying stability in APIs, user interfaces and
| peripheral interfaces had under-appreciated positive impacts
| on the rapid prolife ation of desktop computing across
| society. Remember that the landline phone and cable companies
| initially envisioned the "home computer" to a be little more
| than a dumb terminal consumers would rent like a telephone
| handset. We're fortunate that vision failed when the
| commoditization of PCs allowed the home "internet terminal"
| to be a full user-owned and controlled computer with
| significant local processing and storage.
| CamperBob2 wrote:
| An underrepresented point of view, certainly. As a software
| developer at a small game publisher, our idea of hell was a
| dozen incompatible platforms, none of which had a decisive
| advantage over the others, few of which could be ignored if
| the company were to prosper, and all of which were _just_
| different enough to tie up resources for porting that were
| badly needed for product development.
|
| Wintel made a lot of good things possible that simply could
| never have happened in a fragmented market.
| alberth wrote:
| > Apple was able to just create a new CPU based on the _much
| more modern_ ARM architecture
|
| Is that accurate?
|
| x86 launched in 1978. (64bit in 2003).
|
| ARM launched in 1985. (64bit in 2011).
|
| https://en.m.wikipedia.org/wiki/X86
|
| https://en.m.wikipedia.org/wiki/ARM_architecture_family
| phoe-krk wrote:
| You should not consider the dates that support for these
| initial revisions had started, you should consider the
| dates it had been dropped. For x86, it's "never", unlike
| for modern ARM (see sibling comment).
| alberth wrote:
| ARM only officially dropped 32bit support last year.
|
| https://m.gsmarena.com/arm_will_drop_32bit_support_in_the
| _bi...
| NobodyNada wrote:
| ..."in big Cortex-A cores."
|
| ARM designs both the architecture specification and some
| reference designs. 32-bit support has been an optional
| part of the specification since ARMv8 in 2011.
|
| The article you link is saying that ARM's Cortex-A
| reference designs will no longer include 32-bit support,
| which has nothing to do with Apple since Apple uses their
| own custom designs. Apple dropped 32 bit support in their
| own designs in (IIRC) 2016.
| doublepg23 wrote:
| afaik the last remaining 32 bit Apple SoC is in the Apple
| Watch Series 3.
| dmitrygr wrote:
| X86-64 INCLUDES all the legacy cruft of x86-32 and x86-16
| and is thus 44 years old. Aarch64 in Apple chips doesn't
| include A32 and is thus 11 years old. It is indeed a large
| age difference.
| agsnu wrote:
| Apple was also the first vendor to ship an ARMv8-A
| compatible chip; I'm sure there have been reports that
| they heavily influenced the design of AArch64 but I can't
| dig them out right now.
| NobodyNada wrote:
| To back this up, here's a Twitter thread from an Apple
| engineer:
| https://twitter.com/stuntpants/status/1346470705446092811
|
| > arm64 is the Apple ISA, it was designed to enable
| Apple's microarchitecture plans. There's a reason Apple's
| first 64 bit core (Cyclone) was years ahead of everyone
| else, and it isn't just caches.
|
| > Arm64 didn't appear out of nowhere, Apple contracted
| ARM to design a new ISA for its purposes. When Apple
| began selling iPhones containing arm64 chips, ARM hadn't
| even finished their own core design to license to others.
|
| > ARM designed a standard that serves its clients and
| gets feedback from them on ISA evolution. In 2010 few
| cared about a 64-bit ARM core. Samsung & Qualcomm, the
| biggest mobile vendors, were certainly caught unaware by
| it when Apple shipped in 2013.
|
| > Apple planned to go super-wide with low clocks, highly
| OoO, highly speculative. They needed an ISA to enable
| that, which ARM provided.
|
| > M1 performance is not so because of the ARM ISA, the
| ARM ISA is so because of Apple core performance plans a
| decade ago.
| alberth wrote:
| But ARMv8-A is backward compatible.
| dmitrygr wrote:
| Armv8 aarch32 (32-bit) support is optional and hasn't
| existed in Apple CPUs for years... (according to jail
| breakers and public SDK info). Aarch32 is a separate mode
| so dropping it is easy. In x86 you cannot drop 32bit
| because... it is part of the 64-bit mode and needed.
| hajile wrote:
| Apple dropped support years ago and the last couple ARM
| chip designs finally dropped support too.
|
| A715 in particular made it's decoder 20+% wider while
| reducing die area by 75% all due to eliminating 32-bit
| support.
| yxhuvud wrote:
| How about waiting until the competitors is actually on the
| same process node size until declaring the x86 baggage to
| costly? Most of all, Apple is currently in the lead because
| they threw money on TSMC to get a virtual monopoly on the
| smallest node size. How much of that which will remain once
| the competitors are comparable is an unknown at this point.
| mromanuk wrote:
| Comparing currently available CPUs on the market is pretty
| fair.
| kaba0 wrote:
| Sure, but would you go as far to claim that X phone is so
| much better in battery, Y has no chance of catching up,
| when X just put a twice as big battery in their phone?
|
| Like we just don't know how much node size alone matters
| in the picture (or in the analogy, whether the
| improvement is only due to the bigger capacity battery vs
| better energy management at other places)
| mromanuk wrote:
| > Like we just don't know how much node size alone
| matters in the picture (or in the analogy, whether the
| improvement is only due to the bigger capacity battery vs
| better energy management at other places)
|
| Yes, that's what interesting about this, how did they
| achieved the performance gap
| yxhuvud wrote:
| That is definitely true, but you can't reach any
| conclusion on the cost of the x86 baggage by comparing
| different process nodes. It has way too much influence on
| the end result to be ignored.
|
| In a few months we will have both AMD and Apple on the
| same size, so we will finally get some idea of how the
| baggage compare then. It won't be a long situation, Apple
| will relatively soon after release a new on a smaller
| size again.
| hajile wrote:
| A13 and Zen 2 were both made in TSMC N7 fabs, but the
| performance per watt differences were still enormous.
| philistine wrote:
| You have had the same fab processes for years on phone
| chips and Apple was winning every year. The fact the chip
| is in the chassis of a computer does not suddenly change
| the game in favour of AMD.
| throwaway5959 wrote:
| What if Apple maintains a lead in process mode though? 3 nm
| while Intel is at 5, 2 nm while Intel is at 3, etc. I'm
| glad they have competition from more than just AMD and wish
| all three the best.
| yxhuvud wrote:
| Apple may maintain the lead, but it is done by throwing
| money at TSMC, not by having better technology by
| themselves. I'd prefer a situation where the TSMC let all
| of them have some access to the better node sizes as that
| would let the company with the better tech sell more.
| throwaway5959 wrote:
| I don't see why the distinction would matter to the
| people it should matter the most to, Apple's customers.
| yxhuvud wrote:
| I was responding to a claim that Apple would keep their
| lead due to x86 baggage. It matters for the truthiness
| for that claim, it doesn't matter for how much stuff
| Apple will sell.
| hnlmorg wrote:
| > much more modern ARM architecture
|
| ARM is nearly as old as x86 and has had just as many
| evolutions in architecture as x86.
| johnklos wrote:
| But ARM didn't start out as a shitpile of attempted
| backwards compatibility with an 8 bit CPU. The i8086 was
| made as an evolution of the i8080.
| ido wrote:
| And it's also not really "nearly as old" considering how
| fast stuff developed in the early day - the first ARM
| CPUs launched in 1986, and the i8086 in 1978 - 8 years
| earlier.
| hnlmorg wrote:
| That still doesn't make ARM "modern".
| johnklos wrote:
| No. The design made it modern.
|
| Look at the m68000 (1979) compared with the i8086 (1978).
| The m68k was 32 bits from the beginning, so while moving
| from the m68000 to the m68020 did add some instructions,
| there were no "special modes" for "backwards
| compatibility". All binaries that run on the m68000 can
| directly on the m68020.
|
| Add an MMU and optionally an FPU to an m68020 (1984) or
| just use an m68030 (1987), and you have a fully modern
| system that can run modern software in 2022.
|
| The i80386 (1985) is 32 bits and much more modern than
| the i8086, but real mode and 386 mode are completely
| different. Even with this modernization, Intel didn't
| bother with atomic operations, which is why neither Linux
| nor the BSDs support the original i80386. To run modern
| software, you'd need an i80486 (1989).
| NobodyNada wrote:
| Yeah, the processor world changed a LOT in those 8 years.
| Specifically, Berkley RISC and MIPS were developed, which
| ARM was based on.
|
| In today's world of "tick-tock-tock-tock-tock-tock" it's
| easy to forget just how fast the semiconductor industry
| was moving during the 70's-80's. Just about every
| processor sold introduced a completely new architecture
| wmf wrote:
| Classic ARM mode has been removed. Only ARMv8 is supported
| now.
| hnlmorg wrote:
| The existence of 8086 instructions doesn't slow AMD64
| instructions.
| wmf wrote:
| It kinda does make the critical path in the decoder
| slower.
| qeternity wrote:
| > magnitudes faster
|
| No...
| fxtentacle wrote:
| 100+ vs <20 TFLOPS
| danaris wrote:
| ...which is _one_ order of magnitude.
| xhkkffbf wrote:
| Not if you use base 2. And sometimes I like to use base
| 1.00001 for a grand effect.
| uniqueuid wrote:
| https://en.wikipedia.org/wiki/FLOPS
|
| Intel Rocket Lake FP64: 32 Flops per core per cycle at 8
| cores and 5GHz
|
| Nvidia Ampere: 1/32 Flops per core per cycle at 2048 cores
| and ~2 GHz
|
| Even though there are more architectural differences, there
| IS a difference in orders of magnitude ... for the things
| that you can do on a GPU (SIMD).
| qeternity wrote:
| > here IS a difference in orders of magnitude
|
| No, that is a single order of magnitude.
| bhouston wrote:
| This is because FP64 is emulated on the NVIDIA Ampere as it
| is missing dedicated FP64 hardware. This is not a fair
| comparison.
|
| FP32 is 64x faster on NVIDIA Ampere than FP64 per:
| https://www.nvidia.com/content/PDF/nvidia-ampere-
| ga-102-gpu-...
|
| Ampere has 60 TFLOPs of Performance on its top GPU, the
| Hopper per:
| https://en.wikipedia.org/wiki/Ampere_(microarchitecture).
| Which is roughly 50% to 100% faster than Rocket Lake
| depending and that doesn't account for the
| parallelism/memory benefits that comes with the GPU
| architecture.
| hajile wrote:
| Let's analyze 3 real cores.
|
| A100 has 6912 cores (excluding tensor as they don't do
| 32-bit float math). Each core does 2 (32-bit) floats per
| cycle and runs at 1410MHz peak frequency. It is 826mm^2
| and has an official 300w TDP. This yields 19491.84
| GFLOPS.
|
| Threadripper (Zen 3) has 64 cores. Each core does 32
| (32-bit) floats per cycle and runs at 4300MHz. It has 8
| CPU chiplets (80.7mm^2 each) and one IO die (416mm^2) for
| a total area of 1061.6mm^2. This chip yields 8806.4
| GFLOPS.
|
| Alder Lake has 8 P-cores and 8 E-cores. If you have an
| unlocked chip with AVX-512, that yields 64 (32-bit)
| floats per cycle running at up to 5.3GHz along with 32
| (32-bit) floats per cycle running at up to 4GHz. Die area
| is around 215.25mm^2 (though much of that die area is
| taken up by the GPU) and it has a TDP of 150w (peak
| 241w). This chip yields 2713.6 GFLOPS for the P-cores and
| 1024 GFLOPS for the E-cores for a total of 3737.6 GFLOPS.
|
| The first thing of note is that orders of magnitude is a
| gross overstatement as there isn't even a single order of
| magnitude of difference between the slowest and fastest
| systems here.
|
| Dividing GFLOPS by die area gives 23.60 GFLOPS/mm^2 for
| the A100, 8.30 GFLOPS/mm^2 for the Threadripper, and
| 17.36 GFLOPS?mm&2 for the Alder Lake. Considering the GPU
| size of the Alder Lake, I suspect that GFLOPS per die
| area actually favors Alder Lake over the A100 (though
| this is also somewhat offset by the presence of tensor
| cores and other non-related stuff in A100).
|
| Also noteworthy is that power is a much weirder metric
| due to how turbos affect all the things. I suspect this
| is where the A100 has a major advantage not to mention
| real GFLOPS dropping off steeply in long-running
| workloads (though this will affect all of these systems
| to greater or lesser degrees).
|
| On the flip side, I should add that branchy code
| dramatically slows down actual performance on a GPU while
| only slowing down a CPU when a misprediction happens (in
| theory this should be only 1-5% of cases).
|
| A more interesting question would be Alpha EV9 with it's
| proposed 1024-bit SIMD unit running at around 2GHz. That
| chip would have delivered 256 GFLOPS of performance per
| core around 2005. Scaling to a modest 32-core chip at
| 4GHz gives a very impressive 16384 GFLOPS while retaining
| all those CPU advantages too.
|
| This leads to the observation that adding large
| SIMD/vector units to a CPU isn't really hard. A small,
| in-order core with very wide vector units running at a
| slower speed to conserve energy seems like an interesting
| idea and several startups are working in this direction
| (not to mention this being the basis of Intel's Larabee
| and later Knight's Corner designs).
| simonh wrote:
| Yes, but the reasons are to do with business and investment as
| much as technology.
|
| Apple utterly dominates the mobile phone CPU landscape, and it's
| hard to see that changing. The reason is that they capture a huge
| slice of the profits in mobile phones. Something like 90%. For a
| while they capture over 100% of profits, because so many of their
| competitors were operating at a loss. This enables them to make
| investments their competitors can't. Also because their
| competitors use commodity chips developed by Cisco and Samsung
| none of the Android vendors can use those chips to differentiate
| their products, which means even for flagship phones the CPU
| isn't a unique selling points, so they can't justify buying super
| premium chips. Without the guaranteed sales, the chip vendors
| can't justify investing in making super premium chips. They've
| been stuck in this rut for almost a decade now, and still not
| found a way out. Success breeds investment, but without
| investment they can't achieve success. It's a negative feedback
| loop, compounded by a prisoner's dilemma.
|
| With desktop and server chips these factors don't apply. Apple
| will never dominate the desktop and server CPU market because
| they've positioned themselves as a niche premium brand. They
| don't even make servers, and the desktops they do make are
| ridiculously high end. They can't go down market without
| eviscerating their margins. There's still huge amounts of money
| to be made in those sectors, so vendors like Intel and AMD can
| afford to put in massive investment in new designs. They may be
| behind now, in some ways, but I don't see any barriers to them
| competing in the near to long term.
| jinto36 wrote:
| * presumably Qualcomm and not Cisco, for mobile SoCs?
| cm277 wrote:
| 100%; the business model side is the major advantage Apple has
| here. Part of that advantage is the sheer size of the market
| compared to desktop/servers. They will sell 10s of times more
| CPUs for iPhones/Macs than anyone will sell for
| servers/desktops. I am less optimistic that anyone else can
| compete, since no one else seems to be able to straddle both
| markets and use scale across both.
| PaulDavisThe1st wrote:
| > Apple utterly dominates the mobile phone CPU landscape,
|
| That seems to be an interesting definition of "dominates". 14%
| of global smartphones from independents. 24% by Apple's claims.
| A curious kind of domination.
| matwood wrote:
| I read that as mobile CPU performance is where Apple
| dominates. And they do. This is why people have been
| wondering for years when Apple would put one of their mobile
| chips (or a derivative) in a laptop.
| dav43 wrote:
| I read "dominates" as has the "dominate share of the profits
| for the industry". Not dominates shipments.
| belltaco wrote:
| By that metric Microsoft utterly dominates the web server
| market.
| zinekeller wrote:
| Yes, but that's not the point here. I don't know what
| Microsoft does with their IIS profits but Apple is
| definitely reinvesting them back into making better
| phones.
| solardev wrote:
| > I don't know what Microsoft does with their IIS profits
|
| That's ok. Microsoft doesn't either ;)
| ClumsyPilot wrote:
| The point is that you've chosen a questionable benchmark
| that is only correct if you adopt a very spwsific point
| of view.
| simonh wrote:
| The thread is about performance and technology, and Apple
| dominates the phone CPU landscape in those areas. I thought
| that was clear as my comment mainly addressed technology and
| the driving forces behind it, but I'm sorry for the
| confusion.
| stevenjgarner wrote:
| I think the @simonh "domination" point is that Apple has
| dominated the mobile phone CPU PROFITABILITY landscape, not
| the SALES landscape, and I for one feel @simonh has a valid
| point.
| zinekeller wrote:
| To emphasise, according to Counterpoint Research as of last
| year (https://www.counterpointresearch.com/global-handset-
| market-o...) Apple is able to maintain 75% of the total
| profits on the phone market, while Samsung only captures
| 13% and others (including Xiaomi and the BBK group)
| capturing the remaining 12% with no single company peaking
| above 5%. Apple could store two-thirds of its profits
| offshore (waiting for an opportunate tax break) while only
| moving a third of that profits into actual use and it will
| still be better than Samsung's position.
|
| (Rant specific to HN: some even are comparing IIS sales.
| Geez, it seems that most here are not willing to understand
| correctly what the GGP's comment pointed out is that Apple
| has a massive R&D budget that is unbeatable.)
| KptMarchewa wrote:
| If you're talking about CPU profitability, then look at
| Qualcomm profits, not Xiaomi.
| fortran77 wrote:
| > That seems to be an interesting definition of "dominates".
| 14% of global smartphones from independents.
|
| Exactly right! It always amazes me to see the bubble some
| people here live in (and that's the best possible
| interpretation of these sort of comments; the worst is that
| it's a coordinated/paid astroturf attempt) We just spec'd
| several new computers here and they're all Xeon/NVidia.
| Nothing else can meet our needs.
| zinekeller wrote:
| I'm sorry but I have to label this as a bad-faith attack.
| "dominates" in this context means being the fastest
| available, not necessarily that most people will buy that.
| It's like saying "the i9/Ryzen 7 dominates" and then
| answering with "most people buys Celerons/Athlons". You need
| to read the context of the conversation: it is about
| performance domination and not usershare domination.
| bmitc wrote:
| The iPhones are not always the fastest and certainly not
| dominating.
| PaulDavisThe1st wrote:
| And yet this subthread is filled with several people who
| have yet a 3rd (maybe even a 4th) interpretation. I don't
| dispute that yours could be the intended one, but let's not
| pretend that it's completely clear.
| philistine wrote:
| Maybe commoditizing and refusing to differentiate your
| products, merely being content to shove the pablum OS everyone
| uses is a mistake?
| pella wrote:
| _" Qualcomm Confirms Nuvia Arm Chips Will Be in PCs by Late
| 2023"_
|
| https://www.tomshardware.com/news/qualcomm-confirms-nuvia-ar...
|
| _" Qualcomm acquired Nuvia in January 2021. The processor
| startup was founded by ex-Apple engineers who wanted to turn
| their talents to Arm-based system-on-chips (SoCs) for servers.
| Just a few months later Qualcomm provided an extensive update on
| its plans for Nuvia-technology SoCs, and it publicly pinned its
| hopes on addressing the always-connected PCs (ACPCs) market with
| a processor that could get in the ring and trade blows with the
| Apple M1. This could be an exciting introduction for the Windows
| ecosystem, if all goes to plan."_
| unix_fan wrote:
| Their problem has never been technology or talent, just the
| fact they care a lot more about the margins they make on those
| chips.
|
| The newest snapdragons have had gimped cashes for years now.
| camillomiller wrote:
| Qualcomm has been "on track" with desktop level chips based on
| their mobile platforms for at least four years. I've tested the
| first Windows on Arm laptop with a series 8 "desktop"
| Snapdragon in 2018. Yet, they still have to ship anything
| meaningful. They lake the vertical integration Apple has, and
| they will never have it. Hard for me to see how competitors
| (Qualcomm + Microsoft + OEMs) are supposed to go after Apple in
| this area, considering how incapable they are at working
| together in a productive way.
| pella wrote:
| > are supposed to go after Apple in this area,
|
| Talent can be poached [1] and Technology can be acquired [2]
|
| [1] "Intel Poaches Head Apple Silicon Architect Who Led
| Transition To Arm And M1 Chips"
| https://hothardware.com/news/intel-poaches-head-apple-
| silico...
|
| [2] https://www.qualcomm.com/news/releases/2021/03/qualcomm-
| comp...
|
| ------
|
| The real problem - Apple is slowing down [3][4]
|
| [3] "Apple CPU Gains Grind To A Halt And The Future Looks Dim
| As The Impact From The CPU Engineer Exodus To Nuvia And Rivos
| Starts To Bleed In"
|
| https://semianalysis.com/apple-cpu-gains-grind-to-a-halt-
| and...
|
| [4] "Apple M2 Die Shot and Architecture Analysis - Big Cost
| Increase And A15 Based IP"
|
| https://semianalysis.com/apple-cpu-gains-grind-to-a-halt-
| and...
|
| details from [3]
|
| _" It appears Apple has not changed the CPU much this
| generation. SemiAnalysis believes that the next generation
| core was delayed out of 2021 into 2022 due to CPU engineer
| resource problems. In 2019, Nuvia was founded and later
| acquired by Qualcomm for $1.4B. Apple's Chief CPU Architect,
| Gerard Williams, as well as over a 100 other Apple engineers
| left to join this firm. More recently, SemiAnalysis broke the
| news about Rivos Inc, a new high performance RISC V startup
| which includes many senior Apple engineers. The brain drain
| continues and impacts will be more apparent as time moves on.
| As Apple once drained resources out of Intel and others
| through the industry, the reverse seems to be happening now.
|
| We believe Apple had to delay the next generation CPU core
| due to all the personnel turnover Apple has been
| experiencing. Instead of a new CPU core, they are using a
| modified version of last year's core. One of these
| modifications is related to the CPU core's MMU. This work was
| being done for the upcoming colloquially named "M1X"
| generation of Mac chips. Part of the reason for this change
| is related to larger memory sizes and virtualization
| features/support. In addition, there may be other small
| changes as well, but we need hardware in the hand to analyze
| that. We also aren't sure if Avalanche and Blizzard are the
| next generation cores or the current modified Firestorm and
| Icestorm cores.
|
| Regardless of the paltry CPU gains and potential core
| architecture delays, Apple is still the leader in performance
| per watt. With Intel design teams starting to get back on
| track, AMD executing almost flawlessly, and Qualcomm coming
| in soon like a hammer with Nuvia cores, we aren't sure if
| this lead will be sustained. The A11 to A12 generation was
| seen as Apple starting to asymptote out on gains with only a
| 15% gain, and the A13 to A14 looked even more weak with 8.3%
| gains, but now with no CPU gains, let's cross our fingers and
| hope the A16 brings a large architectural change."_ source:
| [3]
| matwood wrote:
| Doom and gloom for Apple is a common way to get clicks. The
| M2 in many workloads looks like ~20% increase which is
| certainly not a slowdown for YoY performance. Additionally,
| everyone is alway 2 years out from beating what Apple is
| selling today, ignoring where Apple will be in 2 years.
|
| With that said, of course competitors can catch up with
| what Apple is doing. Doing things you link to is how, and
| it's exactly how competition works. We'll have to wait and
| see what AMD and Qualcom end up actually releasing.
| bee_rider wrote:
| How could we define a slowdown or speedup in YoY
| performance improvements, for the M2? It is the first
| successor.
| paulmd wrote:
| Despite the M1 moniker, Apple has been doing in-house
| silicon for about 7 generations now - they started with
| A7 iirc, and M1 is part of the A14 generation, and M2 is
| part of the A15 generation. M1 is what would have
| traditionally been called an "A14X", meaning wider GPU
| than the phone-sized SOC. So there are basically 8
| generations of YoY comparisons to make.
|
| M2 is not a particularly large jump as these generations
| go, but it's on the same node and it's actually decent in
| that context.
| bee_rider wrote:
| Sure, but since they've moved into an entirely different
| class of device, I don't think the A<n> series
| establishes a very useful baseline. I mean, scaling the
| phone/tablet type chip up to laptop/desktop class must
| have made them bump into some bottlenecks that previously
| looked infinitely wide. Depending on how difficult those
| bottlenecks are to clear, we could see some years with
| quick progress, some years with not so much.
| UncleEntity wrote:
| > More recently, SemiAnalysis broke the news about Rivos
| Inc, a new high performance RISC V startup which includes
| many senior Apple engineers.
|
| I thought that's how it works in Silicon Valley these days,
| people leave the company to create a startup with the
| intent to be acquired once they make enough progress.
|
| If apple were planning a risc-v future then this seems like
| much ado about nothing.
|
| If not they have plenty of cash to throw at the problem
| when it becomes a real issue.
|
| I wouldn't bet against them since they take secrecy _very_
| seriously and everyone is predicting doom and gloom without
| any idea what they're doing behind the curtains.
| hajile wrote:
| 8cx Gen 3 (using ARM X2) performance in early benchmarks puts
| it (for the first time) around Zen 2 in performance while
| using a fraction of the power (anywhere from half to 5x less
| power under load and even better metrics at rest).
|
| Qualcomm got impatient and entered too early causing people
| to write them off.
| grecy wrote:
| > _Late 2023_
|
| > _could get in the ring and trade blows with the Apple M1_
|
| If you're aiming to match something that was on shelves for
| sale in November 20202 in late 2023, you're not really
| competing are you?
| znpy wrote:
| Imho they can as long as they agree to drop some sort if retro-
| compatibility.
|
| Modern cpus being able to run dos software is certainly nice, but
| it's probably preventing intel/amd from performing some
| aggressive restyling and optimisation/refactoring to their isa
| and its implementation in silicon.
|
| Apple on the other hand happily deprecates its own os releases
| and the hardware supported. Software retro-compatibility is then
| achieved in software (rosetta and such)
| gruez wrote:
| >Modern cpus being able to run dos software is certainly nice,
| but it's probably preventing intel/amd from performing some
| aggressive restyling and optimisation/refactoring to their isa
|
| Not really. Most of the legacy instructions are implemented via
| microcode anyways, so the amount of resources dedicated to
| legacy support is minimal.
| mariuolo wrote:
| > Imho they can as long as they agree to drop some sort if
| retro-compatibility.
|
| What's the performance hit/wafer space for that today?
| saagarjha wrote:
| I've heard numbers like 5-10%.
| JohnHaugeland wrote:
| Apple fans sure love pretending other chips are as slow as they
| are
|
| > The Apple M1 Ultra SoC chip achieves 87% of the performance of
| the Intel 12900K and Nvidia RTX 3090
|
| Benchmarks not run by Apple do not support this claim
|
| In reality it is not competitive with chips five years old
| defactoPun wrote:
| Well, I dont think there's need for a personal attack here.
| Even though they might not be 87% faster, they are still quite
| significantly faster for an ultrabook and they do deliver the
| battery life. So I guess the OP's question can be taken as,
| could intel or amd or OEMs achieve the performance to power
| ration soon ?
| PaulDavisThe1st wrote:
| This is precisely the right reformulation of the actual
| question.
|
| Apple's competitors are already ahead of of Apple in terms of
| pure performance. "Catching up" is only a thing if you care
| about the performance/power ratio.
| jmiskovic wrote:
| Yes, but the performance/power is extremely important for
| laptops. As a long time Linux user I'm seriously
| considering migrating to Mac just for the laptop staying
| cool and silent after hours operating on battery.
| philistine wrote:
| Reading this thread, the delusional thinking is thick!
|
| I'm hearing that we need to wait until Intel moves to 5nm to
| really compare. When that means that the whole PC market cedes
| the crown to Apple, who is not slowing down. Apple is on its
| second generation on 5nm and the x86 crowd as yet to show any
| response!
|
| That it's only because Apple is on 5nm that they're competitive.
| Which is crazy, since we can directly compare slightly older
| chips made on a 7nm process and Apple comes out way ahead.
|
| That the competitors like Qualcomm are not optimizing for
| performance. When the reality is much simpler. The benchmarks are
| this bad from Qualcomm because they're optimizing for their
| wallets.
|
| The reality is simple: for a decade, Apple has had the fastest
| phones, and the fastest tablets. Are you PC guys ready to admit
| Apple has the fastest computers?
| mhh__ wrote:
| Your comment is needlessly argumentative. No one is saying they
| aren't good chips.
|
| Also if it isn't the process it arguably makes it easier for
| them to catch up because other than the semi-cultural stuff
| like EDA tooling changing a design is much easier than changing
| a process.
|
| Now they have a real target to hit I expect the gap to close,
| especially if Intel can convert their IDM concept into a real
| battle with TSMC
| breadloaf wrote:
| In general what I see as a massive issue for ARM and big win for
| x86 is standardization (or in case of ARM lack of)
|
| - Can you run ARM system on any ARM processor, or are you limited
| by core architecture, endianness (BE/LE), and RAM addressing,
| forcing you to recompile for specific SoC? I honestly don't know
| what are the exact limitations.
|
| - Can you boot any ARM processor in one specific way like x86
| processor? No you can't. Every ARM processor has its own booting
| mechanism and you basically need to bend your system to it.
|
| This lack of standardization is the reason, why Android phones
| does not have universal Lineage OS, but has build for phone X,
| build for phone Y, build for tablet Z and on the other hand this
| basic standardization is what will keep x86 alive for decades to
| come.
| defactoPun wrote:
| Can there be a software side compensation for this lack of
| standardisation? Because I too don't see any hardware standard
| coming very soon to ARM and I don't think it can even.
|
| But, maybe there can be a build automation which can handle all
| the hassle and minimize the randomness?
| pca006132 wrote:
| I thought user-space applications should be fine? Bootloaders
| that kind of stuff has to deal with low-level interfaces and
| those do differ from SoCs to SoCs.
|
| You can build multiple functions to handle different
| architectures by function multi-versioning[1], not sure if it
| works for embedded though.
|
| [1] https://gcc.gnu.org/onlinedocs/gcc/Function-
| Multiversioning....
| mike_hearn wrote:
| That used to be true, but ARM has been standardizing these
| aspects now for a long time. Modern ARM systems can use ACPI
| for example.
|
| Android phones have different builds because the hardware
| varies a lot, and because the OS is an integrated part of the
| product offering. It's not like the PC space where the hardware
| makers can't compete by better integrating the OS.
| cmrdporcupine wrote:
| Almost nobody actually runs ARM in big-endian. I suspect
| although the ISA is technically capable of endian switch many
| SoCs wouldn't even work in BE.
|
| I seem to recall trying to get uboot and and RPi to boot big
| endian at one point and it was infeasible.
| norman784 wrote:
| I think if x86 get rid of their legacy instructions, they could
| reduce their core size, and a few side effects will be
| performance per watt gains and maybe also performance (smaller
| cores), and if you need the legacy instructions you could just
| emulate, most consumer PCs don't need those.
|
| That's the biggest difference with x86 and ARM, ARM got a lot of
| breaking changes with their versions, while x86 don't (I'm not
| sure if there was any breaking change in the las 20 years at
| least).
| chrisseaton wrote:
| > I think if x86 get rid of their legacy instructions, they
| could reduce their core size
|
| Aren't those legacy instructions already emulated in microcode?
| I don't think they take up much physical footprint.
| kersplody wrote:
| Modern x86 processors use about 10% of their power budget for
| instruction decode (translate variable-length x86 machine
| code into one or more fixed-length microcode instructions and
| remap registers). The primary modern benefit of this setup is
| that the decode logic can optimize code at the cost of power.
|
| If x86 could get rid of the x86 instruction set and compile
| directly to something similar to uOPs, then some power
| reduction use and core area reduction could be achieved, but
| tooling cost would be immense.
| emidln wrote:
| Yes. People bandying about "legacy x86" instructions miss
| this often. This isn't much different, conceptually, from
| Apple's Rosetta, except it's provided in microcode
| automatically rather than a discrete transform you need to
| run once and cache. This is very convenient for broad x86
| backwards compatibility (e.g. I can run a Java 1.4 JVM and
| StarOffice or a libc.so.5 to play Unreal Tournament 2004 just
| fine on my 5900x). Can I run x86 apps, even ones from the
| last couple years on an M1 with no questions asked? Well, we
| abandoned local dockerized development at work because Docker
| for Mac's qemu couldn't hook into Rosetta and qemu alone
| couldn't handle JIT'd instructions from a jvm11[0]. Maybe
| that changes with the new MacOS version and the next version
| of Rosetta (there seems to be a Rosetta that works like
| qemu's binfmt_misc translators for Linux), but it's been
| missing for 2 years so far and caused me to do a bunch of
| work on remote dev capabilities in the meantime.
|
| [0] Let me stop you right there before you suggest I
| recompile 15 years of operating systems, third party
| toolchains, and internal tools for ARM and then rebuild every
| intermediate container just so we can work around Rosetta
| shipping without necessary features. I know that you can ship
| a whole parallel stack of containers with ARM but that's not
| feasible in the slightest for anything but the most trivial
| use cases or entirely greenfield projects.
| UncleEntity wrote:
| Do you really target the Java 1.4 JVM?
| layer8 wrote:
| X86 will always be slower because it has stricter memory
| ordering semantics.
| kersplody wrote:
| Not really an issue under most usage scenarios. x86 suffers
| mostly from the cost and complexity of the decode unit. Once
| decoded instructions are cached, the performance penalty
| mostly disappears.
| erichocean wrote:
| Ordering semantics (TSO) that Apple's M1 implements.
|
| I guess it should be slower too?
| hajile wrote:
| And it is a LOT slower to run rosetta apps instead of
| native ones despite all the silicon thrown into emulation.
|
| If it were as simple as "they are the same once everything
| is decoded", then you'd expect a pre-decoded and pre-
| optimized program to be at least as fast, but it's not.
| layer8 wrote:
| M1 implements TSO as a special mode specifically for x86
| compatibility: https://github.com/saagarjha/TSOEnabler
|
| If TSO didn't have a performance penalty, it wouldn't need
| to be a separate mode. Also, it should be obvious that
| stricter ordering constraints inherently allow less
| parallelism, so lower performance.
| modeless wrote:
| You're looking in the wrong place. The magic comes from TSMC, not
| Apple. Apple's major innovation is in using their unrivaled bank
| account to pay TSMC for exclusivity on their newest fabrication
| technology. As competitors gain access to that TSMC technology
| they will match or beat Apple's performance. And if Intel
| succeeds in reclaiming the fabrication technology lead from TSMC
| (we'll see) then Intel will beat Apple's performance again.
| sliken wrote:
| Er, no, sure it's a contributing factor. But Apple's lead in
| perf/watt is much higher than you can attribute to the process.
|
| Their GPU is similarly impressive, with a minimal TDP it
| handily crushes any other iGPU.
| spoonjim wrote:
| Wrong, the majority of Apple's thermal efficiency comes from
| superior design which in turn comes from the fact that they
| were able to design it from the ground up with no backwards
| compatibility requirements (since they don't have any customers
| of the chip besides themselves).
| rowanG077 wrote:
| This is false. Apples arm chips are compatible with the
| normal arm instruction set. Evidenced by Linux trivially
| running on it.
| mike_hearn wrote:
| With AArch64 yes, but that's a relatively recent 'clean
| break' ISA. It's not an extension of Arm32.
| whynaut wrote:
| Well it's an ARM chip. it's still not backwards
| compatible..
| jjtheblunt wrote:
| that's absurd. fabrication depends on a design, and Apple has
| done years of research into low power performant designs, going
| back to be a cofounder of ARM.
|
| Citation : https://en.wikipedia.org/wiki/Arm_(company)#Founding
| hajile wrote:
| A13 and Zen 2/3 were all on TSMC N7, but A13 still crushes in
| performance per watt by a HUGE margin.
| bearjaws wrote:
| This is just absolutely incorrect.
|
| Design is over half the battle, look at Qualcomm n5 performance
| vs Apple M1 on n5 performance.
|
| It's not even comparable in anyway.
|
| Even AMD 6900U struggles in many regards compared to M1 pro,
| and even more so at performance per watt.
|
| For example Cinebench runs at 118% more power draw on the Ryzen
| at only a 11% multi-core performance advantage.
| modeless wrote:
| Qualcomm chooses low cost over performance on purpose. AMD
| 6900U is still at a process disadvantage compared to M1.
| AMD's comparable chips won't come out for many more months.
| Bud wrote:
| You're still wrong. Design counts. Apple has a huge design
| lead here. There's no way to successfully obscure or
| distract from that fact.
| webmobdev wrote:
| > _This is just absolutely incorrect. Design is over half the
| battle_
|
| Completely agree. There are many ARM SoCs available in the
| market, and Apple's ARM SoCs outperform most of them. Apple
| has also made significant design changes in its SoCs that
| really does differentiate it from current Intel and AMD chips
| and these design changes do give it a performance advantage.
| The unified memory access architecture (I think pioneered by
| SGI), is a good example of one such architectural difference.
| And ofcourse, manufacturing these SoCs on newer node tech
| also allows Apple to pack more transistors in their chip than
| Intel and AMD currently can. Altogether, it is undeniable
| that Apple engineers have created a great piece of hardware
| and a very decent and viable alternative to Intel and AMD
| chips.
|
| But ... _better tech doesn 't always necessarily translate to
| more sales and popular acceptance_. AMD is a great example
| here - despite having better technology than both Intel and
| Apple (on CPUs and GPUs), it still struggles to compete with
| either and is nowhere near the market size or capitalisation
| of either Intel or Apple. However, here we are not talking
| about a product from a new startup or small business but
| Apple - A huge behemoth with a fantastic team of management
| that knows how to sell stuff and make a profit. So it's not
| at all far-fetched to assume that the Apple Silicon chips are
| here for the long term and will continue to be a viable
| competitor to Intel and AMD chips. But how are they
| competing, and what company's vision will win in the long
| term?
|
| Apple's long term business vision is to continue being a
| hardware + software company while evolving & _increasing_ its
| recurrent revenue from _services_ that is tied to monetising
| the personal data of its users. I have no clear idea of
| either Intel 's or AMD's future business visions (which is
| perhaps telling in its own way of how both businesses are
| today), other than that they want to continuing innovating
| and selling the hardware that is their core business (CPU,
| GPU, Fab tech etc.) that is more "open" to integration with
| other systems (software and hardware).
|
| So, keeping those visions in mind, let's compare the pros and
| cons of Apple and AMD / Intel chips.
|
| _Apple Silicon - Pros_ :
|
| 1. Latest tech, innovative design offering better performance
| in some areas. 2. Low power usage, great battery life. 3.
| Cheaper. 4. "Integrated" RAM leading to better performance.
| 5. Highly integrated with Apple ecosystem (Apple hardware +
| software + web services).
|
| _Apple Silicon - Cons_ :
|
| 1. It is not sold as stand alone part. 2. It is a closed box
| system with no hardware literature available to build
| alternative platforms on it. 3. Highly integrated with
| Apple's ecosystem. 4. Has built-in planned obsolescence (CPU
| is soldered, RAM is soldered, bootloader can be locked
| anytime). 5. Low power usage that unnecessarily sacrifices
| performance is undesirable in a _desktop_ computer.
|
| As is evident, the pros and cons of Apple Silicon are tied to
| the business vision of Apple - they believe that the best way
| to make recurrent revenues by selling Apple services, is to
| create a closed-box system and tightly integrated ecosystem
| that forces its users to only use Apple hardware and
| services. Built-in planned obsolescence makes it easier to
| sell new system. Similarly, AMD / Intel's business vision is
| reflected in pros and cons of their product too:
|
| _AMD / Intel CPUs - Pros_:
|
| 1. Good support for multiple OS platforms. 2. Backward
| compatible (x86). 3. More open, better hardware literature on
| their SoC's support creating new platforms. 4. Better
| integration with other hardware allows more flexibility to
| users in building custom hardware. 5. Supports repairability
| (CPUs can be replaced and upgraded more easily in the same
| system, integrated GPU doesn't prevent you from adding and
| using a more powerful GPU etc).
|
| _AMD / Intel CPUs - Cons_:
|
| 1. Lagging in newer tech. 2. Maintaining backward
| compatibility comes at a price - more complexity, limits
| exploring new designs and architectures. 3. Supporting
| multiple platforms can be somewhat limiting as hardware
| performance varies depending on software quality of the
| platform.
|
| -----
|
| As AMD and Intel have shown in the past, both have had better
| tech than the other at some point. It's the same today with
| Apple innovating and currently having better tech than AMD /
| Intel. So it isn't exactly a question of will the better tech
| win. What matters is who can sell their tech better.
| kmlevitt wrote:
| >" 5. Low power usage that unnecessarily sacrifices
| performance is undesirable in a _desktop_ computer."
|
| This is a temporary matter. For notebook computers, Apple
| made the obvious decision to optimize for power usage. But
| in interviews their engineers have signaled that when the
| time comes they will be just as capable of optimizing for
| performance on a future Mac Pro.
| greggsy wrote:
| > increasing its recurrent revenue from services that is
| tied to monetising the personal data of its users.
|
| My understanding is that they're more responsible than
| other services with respect to personal data. Unless I'm
| mistaken, their strategy isn't to monetise and sell data,
| but is instead to sell services that _allow users to
| interact with their own personal data_ , which is
| incredibly rich given the ecosystem that Apple Watch and
| HealthKit offers.
| webmobdev wrote:
| As an Apple user, I see it more cynically now - their
| whole idea of "privacy" has morphed into a strategy to
| prevent their competitors access to the personal data of
| the users, while ensuring they have more invasive access
| to it. This idea is offensive to me. Preventing data
| collection is the first step to user privacy. Once
| BigTech has your data, they can do anything with it in
| the future (despite what they say today) because of the
| lack of appropriate law and regulation to prevent this. I
| see us heading to a dystopian future where BigTech evolve
| into data brokers.
| n7pdx wrote:
| lol this will age well. i remember designing CPUs at intel when
| they had like a ~2.5 gen process lead (literally 4-5 years) and
| the result was still barely better than competition.
|
| what outsiders don't realize is intel management never had to
| deal with competition. they spent their entire careers fighting
| each other in petty internecine political battles. if you think
| intel vs amd is a feud, you haven't seen intel arch/design vs
| intel fabs. and in that kind of environment, loyalists and
| politicians are promoted, not people willing to critically
| inspect your own processes and improve things.
|
| end result: intel has a massive competence gap. in the
| extremely unlikely scenario where intel can regain the process
| lead, they will still be behind the curve on innovation and
| execution.
| jaytaylor wrote:
| I didn't know the word internecine, it's actually really
| useful and relevant in many situations, thank you!
|
| > internecine, adj.:
|
| > destructive to both sides in a conflict.
| jodrellblank wrote:
| I find myself googling "etymology {word}" a lot recently;
| here _inter_ is _between_ like in intercontinental, and
| _necine_ is _death_ like in necrosis.
|
| And _inter_ is apparently the origin of _intel_ , which is
| topical, and suggests _Intelnecine_ , adj: destructive to
| all factions within Intel, or any company with a
| destructive amount of in-fighting.
|
| https://www.etymonline.com/word/internecine
| SilverBirch wrote:
| (Ex-Intel, agree)
|
| What do you think of the new management? Too difficult to
| turn the tanker?
| n7pdx wrote:
| Looks bad. I have two examples to go with:
|
| - The Sapphire Rapids validation catastrophe proves they
| haven't learned a damn thing about high quality first
| silicon even after all these years of getting their asses
| handed to them by AMD/Apple on fast cadence updates.
|
| - Arc, enough said.
|
| Pat Gelsinger made some big moves on his direct reports but
| he doesn't have the time to perform the necessary mass
| purge of the mid/mid-high level management (i.e. the baby
| VP tier). When you run a company with 100k staff you have
| to delegate a lot of things, but the problem is a huge
| amount of the toxic management are still there, hiding in
| nooks and crannies and surviving.
|
| Intel is currently throwing a lot of money around to hire
| people from the companies thrashing them (got a text
| message from a VP a couple months back), I get the feeling
| the Intel immune system will spit them back out upon
| detecting deviance from "the Intel way".
| wmf wrote:
| That's not true. Compare the 8+ Gen 1 (TSMC N4) against A15
| (TSMC N5).
| ac29 wrote:
| Where'd you see benchmarks of 8+ Gen 1? It was only announced
| about a month ago and isnt expected to even start sampling
| until later this quarter.
| wmf wrote:
| Ian Cutress https://www.youtube.com/watch?v=9QZIN8LFE-U
| modeless wrote:
| Qualcomm prioritizes cost over performance and it shows. Look
| at AMD for a performance comparison.
| throw34 wrote:
| But doesn't your statement prove that there are decisions
| and things the user of a node can make which effect the end
| result? Therefore, is not just process node that matters.
| grogenaut wrote:
| I think it states that Qualcomm is not competing with
| apple on the success metrics that this post talks about
| re catching up, so you can't use it as a comparison. No
| idea how fast they could hit those specs up if they
| wanted to (was core to their business)
| modeless wrote:
| Obviously you can choose not to aim for the best possible
| performance in order to reduce costs. But for the
| companies that are competing for the absolute best
| performance at any cost, which doesn't include Qualcomm,
| by far the biggest factor determining that performance is
| the fabrication technology.
| throw34 wrote:
| That's an interesting take given this thread because
| Apple has explicitly stated they don't prioritize
| performance, they prioritize performance per watt, which
| is not the same thing. And that also shows there's a
| whole design space here and just focusing on one
| dimension, process node, is overly simplistic.
| modeless wrote:
| Top end performance is power limited, so optimizing for
| performance per watt is almost the same thing as
| optimizing for performance.
| throw34 wrote:
| I'm not sure what point you're arguing anymore.
|
| I'm arguing against this statement. I don't think it's
| true.
|
| " You're looking in the wrong place. The magic comes from
| TSMC, not Apple."
|
| My point is a good process is necessary but not
| sufficient to make a part competitive with Apple on
| performance per watt. There's a lot of "magic" to go
| around.
| xyzzy_plugh wrote:
| I think the argument is that Apple would have
| significantly less magic were it not for TSMC, which
| seems to be correct regardless of process or design
| (vertical integration).
| spenvo wrote:
| Even there, it looks like Samsung is on track to beat TSMC to
| mass production of 3nm chips:
| https://www.reuters.com/technology/samsung-elec-starts-3-nan...
| nixgeek wrote:
| By this logic, you believe Samsung Exynos will be competitive
| with Apple's A16 when it launches later this year? If it's
| all in the process size - you'd expect this to be true but
| I'm betting A16 will continue the trend of Apple Silicon
| being dramatically superior.
| Bud wrote:
| ...except that Samsung demonstrably lies about every single
| thing relevant to assessing performance, benchmarks, release
| dates, etc.
| wmf wrote:
| Nanometers are fake though. Samsung 3GAE probably has worse
| performance than TSMC N4.
| msbarnett wrote:
| To reach 87% of the perf of a 12900K at a max clock of 3.2 GHz
| versus the 12900K's monstrous 5.2 GHz, the M1 has something
| like a 75% IPC advantage.
|
| Are you seriously claiming that you expect a single node shrink
| from Intel 10nm (roughly equivalent to TSMC 7nm) to Intel 7nm
| (equivalent TSMC 5nm, the M1's node) to give Intel an enormous
| 75% increase in IPC such that they'd be able to compete on
| performance per watt by not having to clock so
| stratospherically high (with the attendant voltage penalties)
| to compensate for their low IPC?
|
| That would be an unprecedented outcome for several node
| shrinks, let alone a single one. It's Apple's super-wide design
| that's the primary factor in the IPC here. To pin it all on a
| single node shrink is magical thinking.
| SilverBirch wrote:
| I'm not claiming that I think the parent's claim is true, but
| Intel _really_ fucked up 10nm, and I mean worse than they
| fucked up the shrink to 14nm which fundamentally changed
| their unit economics.
|
| So let's be clear, it's not like the good old days where
| Intel might get ahead by moving to 65nm earlier. TSMC 5nm is
| competing against Intel 10nm at a point where Intel 10nm
| can't really beat Intel 14nm. I know the actual measurements
| are bullshit (I've got flak for complaining about angstroms
| before) but TSMC 5nm is a long way ahead.
| chrsig wrote:
| I was under the impression that having it all as an SoC was a
| significant benefit by cutting down latency between components.
| wmf wrote:
| Intel, AMD, and Qualcomm have been shipping SoCs for years.
| seabrookmx wrote:
| They don't have the RAM on package though.
| wmf wrote:
| This doesn't matter. I know no one will believe me, but
| there's no benchmark that can show the difference.
| wffurr wrote:
| Isn't the packaging part of what makes the very wide
| memory controllers feasible?
| wmf wrote:
| Not really. GPUs regularly implement 256-bit or wider
| RAM.
| erichocean wrote:
| With insanely high latency relative to a CPU...
| wffurr wrote:
| Don't GPUs also typically have the RAM soldered on you
| the card, effectively "on package"?
| wmf wrote:
| That's my point; Apple's RAM soldered on package is the
| same as PC laptops with RAM soldered on the motherboard.
| Apple has no advantage from that.
| boringg wrote:
| You think Intel can right their ship? That's a fairly large
| order given some of the internal problems that have spilled
| into the public limelight. Takes a lot of energy to change that
| momentum.
| paulmd wrote:
| AMD is going to be on the same node as Apple as of this year -
| Apple is not moving onto N3, they're staying on N5P, and Zen4
| will also be N5P, so we can make iso-node comparisons.
| amelius wrote:
| I agree. And part of the magic comes from ASML.
| lumost wrote:
| I simply don't believe this is true enough to matter. If it
| was a simple case of paying ASML X billions for their
| equipment, then we'd see more TSMC competitors.
|
| It is entirely plausible TSMC co-developed some of ASML's IP
| and has exclusivity - or that the tech to make a working
| process out of ASML machines is intrinsically hard.
| arcticbull wrote:
| 84% of ASMLs entire business is TSMC, Samsung and Intel. It
| does seem like it's ASML or bust.
|
| They're the only ones that make EUV lithography equipment.
| Competitors (Canon, Nikon) tapped out at DUV.
| davidf18 wrote:
| The ASML EUV machines are extremely complicated and rate
| limited by the polishing of the Zeiss mirrors which require
| 9 months to manufacture. Zeiss is in the process of scaling
| up, but in the meantime the EUV machines are very much
| backordered and that supply limitation is partially
| responsible for the slowdown in the release of updated
| nodes. There is an update of the ASML machines which are
| far more complicated that cost twice as much and should be
| part of a fab line in production in 2025.
| freemint wrote:
| To continue the tree of suppliers. Zeiss SMT would be
| nothing without:
|
| HAP GmbH Dresden, MBFZ Toolcraft GmbH, Corning Advanced
| Optics, AGC Inc, RUAG Space, Schmolz + Bickenbach, RORZE
| CORPORATION and GEWO Feinmechanik GmbH
| rowanG077 wrote:
| And those depend on dozens of more companies, and those
| on dozen more. That is until suddenly a one man
| specialist retires his company and the entire chains
| grinds to a halt for months.
| gaudat wrote:
| It sounds fun looking at how deep the rabbit hole goes.
| freemint wrote:
| I was only able to find that out because Zeiss SMT has an
| annual "supplier of the year" award.
| [deleted]
| simonh wrote:
| It's true 5nm definitely gives M1 an edge, but Apple's ARM
| chips have lead the pack by a mile in performance for a long
| time, at comparable nodes. To say all the magic lies with TSMC
| is to claim that with M1 Apple suffered a huge loss is
| leadership position in terms of design, saved only by TSMC. I
| don't see how that's a credible claim.
| sliken wrote:
| Generally agreed, however apple's arm cores have substantial
| advantages over all the other common arm cores. The M1
| maintains great perf/watt (common to arm), but is a very
| competitive core at any power level.
| kurupt213 wrote:
| what's your superpower?
|
| _I'm really rich._
|
| That justice league exchange is what came to mind when I read
| your comment
| pizlonator wrote:
| That's a bold statement.
|
| I don't think we really know how much of the lead is due to
| Apple's design.
|
| I would bet it's more due to fab than design, but the design
| plays a nontrivial role.
| mixmastamyk wrote:
| Just ARM is known to have much better per watt performance
| than intel. Folks are desperate that there be a single
| reason, but that is rarely the case.
|
| The reality is that _multiple factors_ are working in Apple's
| favor. Process, architecture, design, investment, focus,
| OS... firing on all cylinders as they say.
| [deleted]
| b20000 wrote:
| the main issue IMHO is that competitors are not choosing the
| right combination of cores and peripherals when designing SoCs.
| Apple is doing that much better.
|
| for example i am not interested in 2x an A53 and 2x an A72. i
| want an octa core with the fastest A cores available. each time
| when i tried to find that i ended up in the server processor
| world with a price tag to match.
|
| stuff like 4k video decoders and TPUs are of no interest to me.
| yet multiple i2s ports or TDM are missing on typical mobile SoCs.
|
| AMD has some seriously interesting CPUs these days but
| unfortunately it seems hard to get access to parts if you are a
| small time device manufacturer...
| tdsanchez wrote:
| Most of the performance advantage of Apple silicon is that it
| puts CPU, GPU and all memory (that is typically VRAM and DRAM in
| traditional architectures) millimeters from primary DRAM. When
| competing purveyors start do this with their own clever
| packaging, they will start to approach Apple's mips/watt.
|
| Emulation on M1 is outstanding. The spatial locality of main
| memory nullifies emulation penalty. Apple has come close to what
| Transmeta tried to do.
| wmf wrote:
| Nope. There's little or no advantage to 2 mm vs. 20 mm.
| throwaway4good wrote:
| I don't think there is a technical reason why a chip based on the
| x86 ISA could not be just as efficient as one based on Apple's
| ARM-variation.
|
| And AMD (and probably Intel soon) has access to the same process
| technology as Apple so I think it is only a matter of time before
| you will see a catch up.
| cowtools wrote:
| I would imagine that any implementation of x86 would have to
| bear the weight of reverse-compatibility. With reverse
| comparability, the bad design decisions just compound, for
| example complicated stuff like memory synchronization
| https://youtu.be/KeLBd2EJLOU?t=2956
| layer8 wrote:
| Exactly. I wish it wasn't the case, but x86 compatibility
| will always come at a cost, in particular due to memory
| semantics, but also I believe due to its complex ISA
| requiring more silicon.
| throwaway4good wrote:
| It would have been a critical factor if this was circuits
| with a few thousands transistors.
|
| Here is an article on the subject; I am sure you can find
| others:
|
| https://chipsandcheese.com/2021/07/13/arm-or-x86-isa-
| doesnt-...
|
| ARM or x86? ISA Doesn't Matter
| baybal2 wrote:
| The question is "Would they, and do they need it?"
|
| For as long as it can't run Windows, it's not a competitor.
|
| A mass market chip will never survive the yield on such extremely
| large dies.
|
| Most of mass market chips will be many times smaller physically
| to make money.
|
| Apple does not make money on these chips.
| UncleEntity wrote:
| > Apple does not make money on these chips.
|
| You really believe that they treat their hardware as a loss
| leader when they are primarily a hardware company?
| baybal2 wrote:
| user_named wrote:
| Perhaps the competition will instead come from China. Xiaomi,
| OPPO both make their own chipset now.
| jurmous wrote:
| ASML is banned to sell the newest machines to China so I don't
| think it will happen soon.
|
| https://www.reuters.com/technology/asml-still-has-no-licence...
| throwaway4good wrote:
| China has their infamous five year plans and for 2025 they have
| a goal of suppying 70% of their own semiconductor demand.
|
| So it is pretty much given that we will see high-end Chinese
| CPUs by then.
| jurmous wrote:
| Good luck with that if you cannot get the latest chipmaking
| machines from ASML. There is basically no competitor to ASML
| for latest gen chipmaking machines.
|
| https://www.reuters.com/technology/asml-still-has-no-
| licence...
| throwaway4good wrote:
| Yes. This is the heart of the tech war.
|
| On the Chinese side there is nothing short of a Manhattan
| project going on to create a semi-conductor industry that
| is outside US sanction power.
|
| It will be absolutely fascinating to see the result of it.
| datavirtue wrote:
| No worries, next president will just ban them.
| throwaway4good wrote:
| I think they are quite aware of that.
| alberth wrote:
| 1. Apple literally pays billions to TSMC to build a new fab
|
| 2. So Apple gets exclusive rights to those new fabs for the first
| 2 years
|
| 3. As a result, Apple gets access to the latest performance
| benefits of the newest nodes 2 years before anyone else
|
| 4. Additionally, since Apple chips are SoC - EVERYTHING (gpu,
| memory controller, memory, cpu, etc) gets fabbed on thr newest
| highest performing node. This has never been done before because
| even Nvidia latest chips, due to cost, are typically in 4 year
| old nodes, along with memory controllers etc.
|
| You can't underestimate the massive benefit of having the
| _entire_ SoC fabbed on a node that no other company can gain
| access too for 2+ years
| philistine wrote:
| Then why was Apple winning against every other phone chip
| before they got access to 5nm? The M1 is the first time Apple
| has had exclusive access to a node in its decades plus history
| of making chips, and yet it has had the fastest chips for a
| decade.
| 2OEH8eoCRo0 wrote:
| Apple Silicon:
|
| Be node ahead of competition.
|
| Solder memory on-package.
|
| ?????
|
| Profit!
|
| Not that Apple Silicon isn't impressive but I think we ignore the
| shortcomings and take a lot of what other processors do for
| granted.
|
| Silicon often struggles on workloads that don't use some sort of
| hardware acceleration. If you never go off the beaten path it is
| very compelling.
| jl6 wrote:
| If your views on technological progress are informed by the 80s
| and 90s, and you think it is an exponential curve, then it seems
| unlikely that today's leaders will ever be caught.
|
| If your views on technological progress are informed by the 00s
| and 10s, and you think it is an S-curve, then today's leaders
| might never be caught in an absolute sense, but the competitors
| will get arbitrarily close eventually.
| personjerry wrote:
| Past performance is not indicative of future results
| [deleted]
| XCSme wrote:
| > achieves 87% of the performance of the Intel 12900K and Nvidia
| RTX 3090 combined
|
| This sounds insane (not in a good way). A 3090 destroys M1 Ultra
| in tasks like machine learning, 3090 being 5x-10x faster than the
| M1 Ultra.
| XCSme wrote:
| Also, just stumbled upon this recent video[0] taking on the
| Apple marketing/graphs for the M1 ultra and testing their
| claims.
|
| [0]: https://www.youtube.com/watch?v=jCs27cNz6_k
| maccard wrote:
| I dont fall in the "apple has changed the world" camp, but bear
| in mind what you're saying here - the flagship $1500 MSRP GPU
| is less than an order of magnitude quicker than a $2000 (total)
| device, with less than half the power usage. That's a pretty
| impressive feat for a first attempt.
| onepointsixC wrote:
| > the flagship $1500 MSRP GPU is less than an order of
| magnitude quicker than a $2000 (total) device
|
| Could you point out which precise Apple device you are
| thinking of? Mac Studio with an M1 Ultra appear to be $3999
| MSRP, and I was assuming that's the cheapest option for an M1
| Ultra.
| maccard wrote:
| You're right sorry - I accidentally compared the price of
| an M1 Pro instead of an M1 Ultra.
| postalrat wrote:
| It wasn't their first attempt. Apple has been making chips
| for their phones for years.
| marcinzm wrote:
| I mean, the top and bottom GPUs of any generation differ by
| much less than 10x the performance but do differ by 5-10x the
| price. The 3090 is $1500 while the 3050 is $250 so 6x the
| price. The 3090 is only 2-3x the performance of the 3050.
|
| There's large diminishing returns as you push performance to
| the utter maximum.
| XCSme wrote:
| > is less than an order of magnitude quicker than a $2000
| (total) device
|
| Isn't the M1 Ultra Mac studio starting at $3999 MSRP?
|
| Also, enthusiasts are usually willing to pay 2x the price for
| even just 2x the performance.
| XCSme wrote:
| I am not saying their chip isn't impressive, just that they
| are clearly lying/deceiving in their marketing.
| MomoXenosaga wrote:
| But can it run Crysis?
|
| Apple is pretty much a no go for gaming.
| zimpenfish wrote:
| > But can it run Crysis?
|
| Yes?[1]
|
| [1] https://www.paulthetall.com/crysis-for-mac-osx/
| maccard wrote:
| No disagreement on that, but that is a very complicated
| topic. It's not _just_ a hardware problem on Mac, there's
| also the OpenGL/Vulkan/Metal debacle, and lack of audience
| compared to windows for developers to target. There are
| more using steam with windows 7 than steam on Mac [0]
|
| [0] https://store.steampowered.com/hwsurvey/Steam-Hardware-
| Softw...
| 2000UltraDeluxe wrote:
| This isn't the first time there's been a shift in claims to the
| various performance thrones and it certainly won't be the last.
| It might take a while before there's another king on the CPU with
| integrated GPU throne, but someone will catch up eventually.
|
| Back in the 90's, there were more contenders than just AMD and
| Intel. Apple was using PowerPC chips, and on the x86 side there
| were several other competitors. Sure, it's been a bit one-sided
| since Apple went the Intel route, Via faded into obscurity and
| Transmeta went belly-up, but something else re-appearing as a
| viable, competitive platform is neither unprecedented nor
| unexpected.
| hatware wrote:
| Can HN users see there's more nuance to performance than
| marketing jargon?
___________________________________________________________________
(page generated 2022-07-04 23:02 UTC)