• Guest, The rules for the P & N subforum have been updated to prohibit "ad hominem" or personal attacks against other posters. See the full details in the post "Politics and News Rules & Guidelines."

Solved! ARM Apple High-End CPU - Intel replacement

Richie Rich

Senior member
Jul 28, 2019
438
200
76
There is a first rumor about Intel replacement in Apple products:
  • ARM based high-end CPU
  • 8 cores, no SMT
  • IPC +30% over Cortex A77
  • desktop performance (Core i7/Ryzen R7) with much lower power consumption
  • introduction with new gen MacBook Air in mid 2020 (considering also MacBook PRO and iMac)
  • massive AI accelerator

Source Coreteks:
 
  • Like
Reactions: vspalanki

name99

Senior member
Sep 11, 2010
240
221
116
What an understatement :D And it looks like it doesn't want to die. Yet.


Yes, A13 is competitive against Intel chips but the emulation tax is about 2x. So given that A13 ~= Intel, for emulated x86 programs you'd get half the speed of an equivalent x86 machine. This is one of the reasons they haven't yet switched.

Another reason is that it would prevent the use of Windows on their machines, something some say is very important.
The level of ignorance in this thread would be shocking if it weren't depressing.
Let's state some basics:

(a) History. Apple has never let backward compatibility limit what they do. They are not Intel, they are not Windows. They don't sell perpetual compatibility as a feature. Christ, the big weeping and wailing THIS YEAR (every year there's a big weeping and wailing...) is about Catalina dropping all 32-bit compatibility.
Apple has switched from 68K to PPC to x86 (to ARM on iDevices). They have switched from 32 to 64-bits multiple times. Every one of those transitions was smooth. Most people never even noticed. Of course there is that very particular internet personality who is still whining five years later how some transition killed his cat and ate his dog... Do you want to base your analysis of the future on Mr Grumpy, or on the lived experience on most users?

(b) Why don't most users notice? Because
- most users only use Apple apps. I cannot stress how important this is. Apple apps cover most of what people want, and they are very good. And Apple apps will transition to ARM COMPLETELY when Apple transitions. Apple is not MS, randomly leaving bits and pieces of the OS to rot away and never recompiling them.

- most Apple developers are used to change. If they're not, they're bankrupt. Apple tells them years in advance to adopt some technologies and stop using others, and if they refuse to do so THEIR APPS STOP WORKING. (Which includes, as a side effect, that people stop paying for them...) If you ship a GL app today, you're an idiot. If you ship a Carbon app today, it won't work on Catalina. If you ship a PPC assembly app, well, good luck being part of you little community of three other fanatics living in the past. Apple developers have apps written in high level languages, not assembly. So they retarget by recompiling.

- Apple has long experience in how to allow their developers to easily create fat binaries that run on multiple architectures. They'll have a version of Xcode that does this as appropriate (probably announced at WWDC next year) and any developer that's not actually dead will be shipping fat binaries by the time the consumer ARM Macs ship.

- Apple is used to shipping emulators, JITs, and similar machinery that can handle old binaries. Apple doesn't have much interest in supporting this long-term. But they will provide such support for the first few years. People's old x86-64 apps will work (not as fast as before, but they will work) for a year or so, while people who rely on them find an alternative.

(c) Why is this all true for Apple but not Microsoft? Because, repeat after me kids, APPLE IS NOT MICROSOFT!
I'm not interested in arguing about the values of perpetual compatibility and caution vs perpetual change and risk taking. Both have their place, both attract different personalities. It's just a fact that MS is one, Apple is the other. One consequence is that when Apple makes a change like this, it goes all in. Once Apple has decided on ARM Macs, the entire line will be ARM Macs within a year. Within ~three years the old x86 Macs will stop getting new APIs. After ~five years they'll stop getting OS updates, after ~seven years they'll stop getting Security updates. Meanwhile MS still can't decide 20 years later whether it wants to fully support .NET and CLR or not. It remains wishy-washy about its ARM support.
This has consequences. It means that Apple developers are used to rebuilding every year, whereas many Wintel developers never even bother trying to compile for ARM. It means few Apple users are running code that was compiled more than a year ago --- because such code, even if it's still sorta compatible doesn't work well on the newest devices; and because the kinds of developers who don't update their code frequently don't make any money on Macs.

(d) This may come as a shock to you, but the number of people who actually give a damn about Windows running on their Macs is miniscule. Why would they? Everything they want exists in Mac form. Sure, if you hang out in certain places it sounds like this is a super-important issue --- just like if you hang out in certain places everyone will insist that gaming on Linux is like, totally, the economic foundation of the computer entertainment industry...

(e) For those people who absolutely insist on still running Windows on their Macs, here's another surprise: It's no longer 1995, and we have new technologies!
If you require x86+Windows in the modern world, the way you will get it is through a PC in a thumb drive that will communicate with the host Mac's virtualized IO and screen. Basically what Parallels does today, but with the x86 code running on a thumb PC and communicating via USB-C. Apple probably won't even do the work, they'll just let Parallels or VMWare write the code and drivers for both ends and sell the thumb PCs; all Apple will do is work with them if there are any particular technical issues that come up. Expect to see one or both of them demo-ing such a solution when Apple announces the ARM Macs to consumers.
NO-ONE is going to bother with some sort of hydra chip that either executes both ARM and x86 code, or even that puts an x86 core on the ARM SoC.


There is a constant thread going through the people who say Apple can't do this: they are people who haven't studied the history of Apple, and who don't use Apple products very much. They look at this from the point of view of how it would fall out if MS did this. But, what did I say, kids, APPLE IS NOT MS!
Apple USERS are not MS users -- different expectations, different software on their machines.
Apple DEVELOPERS are not MS developers -- used to change, used to supporting multiple OSs and ISAs.


As for why Apple would do this

(a) performance. Apple ALREADY matches the best performance Intel has in their "standard" cores. Look at the numbers. The phone cores do this under phone constraints (most significantly a current constraint). The iPad cores tend to run 5..10% higher performance partially because the current constraint is not so strict, partially because they have wider memory. Obviously the Mac cores would be at the very least the iPad cores, with that wider memory, and with even less severe current constraints.
Apple does this by IPC, not frequency, and if you insist that frequency matters, all you're showing is your ignorance. Intel built themselves a massive hole (that they now apparently can't get out of) because they obsessed over frequency too much (apparently learning NOTHING from how the same obsession failed with the P4).
The one place Apple still lags Intel in a measurable way, for some tasks, is code that can use wide vectors (ie AVX-512). Presumably Apple will soon (maybe even next year) have SVE which takes care of that.

(b) SMT. Another sure sign of the ignorant.
SMT is a DUD. It gives 25% extra performance (so your 4 cores have the throughput of five cores -- for some types of code) at the cost of enormous validation and security headaches.
There are ways to add SMT-like functionality that are much smarter than SMT (in particular forget the "symmetric" part, have fibers that are user-level controlled, not OS controlled, so they never cross protection boundaries) and I certainly hope that if ARM or Apple ever go down the "SMT-like" path, they do that, not Intel-style SMT.
But for now, the ARM/Apple "answer" to SMT is small cores. If you need extra throughput, use the small cores. An A12X (4 large, small cores) has the throughput of ~5 large cores --- same, effectively as SMT"s 25% boost. Different ways to solve the same problem of optionality --- how do I ship a system that maximizes for all of latency, throughput, AND power? SMT gives you some flexibility for the first two, big.little gives you that same flexibility but for all three.

(c) Control. Look at what Apple has done with control of their own SoC. Obviously continual performance improvements.
Much better security. (Including IO security.)
Continually adding features to GPU, plus adding NPU, plus now adding what's apparently for on-machine learning (AMX).
Other functionality we don't even really know yet (U1).

Against that, with Intel all they get is more of the same, year after year. Intel turnaround times are SO slow. Upgrades appear to have actually stopped. Security remains an on-going issue.

Sure Apple can try to deal with some of this through heroic interventions like adding the T1 then T2 chips to retrofit some security. But god, what a pain!
Look at things like how long Apple wanted to use LPDDR4 in Macs --- but couldn't because Intel. I'm sure at least part of the delay for the new Mac Pros was that Apple kept hoping (or being promised by Intel) that soon Intel would be shipping something with PCIe4. But no, still waiting on that.
 
Last edited:

soresu

Golden Member
Dec 19, 2014
1,411
584
136
Fine you can continue with your misplaced doubt about Apple's ARM chips until the new Macs are released in six months and you're forced to eat your words.
Linus Torvalds may be a crude loudmouth bully in his communication 'style', but he knows his stuff, and software wise he is far more responsible for the current success and stability of Linux than Bill Gates has ever been for Windows - I'd say that Linux is the better for his administration efforts.

If he says that the tests are worthless, I think it's safe to say that they are worthless.

Edit: Apparently he doesn't say they are worthless, but my point about his opinion stands regardless of the words he says - basically he's a disagreeable person, but likely his opinions are worth more than anyone on here, myself included.
 
Last edited:

RasCas99

Junior Member
May 18, 2020
24
52
51
Reading this thread for a long time , still no converters to either side , some folks here even going out of their way to invent crazy propositions that fit their agenda without any basis to stand on , when you read your own post and all it has is "but what if , and imagine that, consider that maybe if " instead of relying on facts that are in front of you , its time to admit your bias or even worse bringing agendas and personal dislike to a company into a technical discussion (happens a LOT around here for Intel/AMD).

It will be great to see the reactions when we have a real system in our hands , my bet here is that ppl will STILL be entrenched in the same opinions they have now.
If reviews/extensive benchmarks say Apple are behind , lets see the Armada say they were wrong !
If the reviews/extensive benchmarks say Apple hit it out of the park , lets see the Nay crowd say they were wrong !

No need to feel bad about being wrong , it happens when you have to pick sides with limited information , but once everything is out in the wild there is no excuse for not changing your stance and brace the reality whatever it might be.

"set reminder for the end of the year".
 
  • Like
Reactions: Gideon and scannall

naukkis

Senior member
Jun 5, 2002
353
183
116
Yes, A13 is competitive against Intel chips but the emulation tax is about 2x. So given that A13 ~= Intel, for emulated x86 programs you'd get half the speed of an equivalent x86 machine. This is one of the reasons they haven't yet switched.
You forgot that you are comparing phone chip against desktop chip. Yes, Apple's phone chip is as fast as best Intel desktop but it's still chip in phone which have something like 4W burst and even lower sustained power budget for whole SOC. Give that same A13 chip more power budget and it will be faster. If whole design is optimized for desktop - or even for laptop performance will be much higher.
 

Thala

Golden Member
Nov 12, 2014
1,065
393
136
What an understatement :D And it looks like it doesn't want to die. Yet.


Yes, A13 is competitive against Intel chips but the emulation tax is about 2x. So given that A13 ~= Intel, for emulated x86 programs you'd get half the speed of an equivalent x86 machine. This is one of the reasons they haven't yet switched.

Another reason is that it would prevent the use of Windows on their machines, something some say is very important.
The emulation tax aside, which is a stop-gap solution, an A13 would easily beat an Intel/AMD chip at the same power budget. As i said, native apps are just a matter of compilation without any actual (or very minimal) code changes.
In any case the notion that you get the same speed of an equivalent Intel machine (say both 15W TDP) is just wrong.

If Boot-Camp continues to exists, you might be able to boot native ARM Windows without bigger issues*. And once you have ARM Windows running you can boot Linux as well via WSL. Thing of course is, unless it is a Qualcomm ARM CPU the drivers will be lacking.
So if you want to run Windows on an ARM SoC your best bet today is a Qualcomm device if you want to have full driver support.

*You need proper implementation of EFI in order to boot Windows.
 
Last edited:

naukkis

Senior member
Jun 5, 2002
353
183
116
According to @Andrei. the iPhone consumes up to 6.3W when running single threaded SPEC 2006. The test that consumes the least is 3.8W. So we have at least 3W per core (I don't know if Andrei isolates CPU power, I think he can't do that). Let's put 4 such chips on a SoC with a GPU and we easily get to 15W.
With performance equal to Intel 4c desktop chips, not laptop.....

Also you can't just push voltage to increase frequency and hope everything will be well. If Apple really want to get to 3 GHz and up they will likely have to leave some IPC on the table by increasing pipeline depth and/or reduce width.
Only if they have critical hotspots in design. And as they could clock their chip to 2.66GHz in phone you estimate that already 3GHz with much greater thermal and power envelope would be a problem?
 

Thala

Golden Member
Nov 12, 2014
1,065
393
136
Nooooo, a massive codebase like Autodesk Maya for example could not simply be just recompiled like so.

The ease of recompilation you speak of sounds more like some sort of as yet unmade machine learning transpiler that has been trained on ISA and ABI semantics for translating between them in a similar fashion to human language translation.

I suggest you have a conversation with any halfway decent emulator coder to find out just how difficult it is to get one running on a new ISA, especially if it was never designed to be ISA cross platform from the beginning (ie program structure ABI abstractions and so forth).
The question of compilation is not related to the size of the code base - at all.
I am also not talking about re-compilation at runtime - just static compilation of the source code.

That's not trivial in all cases (intrinsics, assembly language, assumptions about memory order rules especially when multi-threading), but it's quite often not that difficult.
Let me quickly address the issues you mentioned:

1) intrinsics and assembly - many programs indeed use intrinsics and assembly. However in every case known to me there is a code path available without intrinsics and assembly. The modification typically consists of enabling the code path in the sources - which is typically very simple.*

2) memory ordering is (typically) not visible at application level - it is hidden in the implementation of OS primitives. So you multi-threaded code just runs under ARM without any modification. If you do synchronization without any OS primitives (which you should not do anyway, and i do not know any app which behaves like this) then you need to add memory barriers on ARM.

*Just last week i compiled 7-zip for ARM64 and it did contain assembly for x86, which i could easily switch over to the available c-functions. And while i were at it, i did add ARM64 intrinsics for CRC calculation. The slighly modified source code now compiles for x86,x64 and ARM64 :)
 

Thala

Golden Member
Nov 12, 2014
1,065
393
136
Well single thread performance for short periods of time is not that far between laptops and desktops: i7-1065G7 is within 15% of i7-9900K on CINT2006. OTOH for sustained performance and number of cores desktop is way better.
That is because a single core does not use close to the power available to desktop CPUs from TDP perspective. So a much lower rated mobile CPU does achieve similar performance in single core indeed. However if you are running all cores, it suddenly shows that the desktop TDP is actually required for high performance.

A13 with 52.8 is between i7-1065G7 47.7 score and i7-9900K 54.3. That's extremely impressive but I would not be surprised if a 4 core A13 was rated at more than 10W TDP.
My take is 8xA13 @3GHz < 15W. Not sure where you got the idea from that a single A13 core uses 3W? In this case it would be much less efficient than say Cortex A76...which consumes roughly 750mW@2.8GHz.
Likewise Micrsoft put 4xCortex A76@3GHz + 4Cortex A55@??GHz into a 7W TDP machine (Surface Pro X).

Given how wide the chip is, I'm pretty sure they have many critical paths.
Does not really matter how many critical pathes you have - they all benefit equally from higher voltage. Given that the most critical path allows 2.6GHz at something like 0.8V VCC shows how much frequency headroom there is. And this is without significant binning - the fastest chips are most likely much better.
 
Last edited:

Thala

Golden Member
Nov 12, 2014
1,065
393
136
So Firefox took years to move to x64 on Windows because of API differences from 32 bit Windows then?
There were 2 big issues for Firefox to tackle:

1) A 32 bit program does not necessarily compile for 64 bit. This is in many cases because sizeof(int) != sizeof(void*) under 64 bit but sizeof(int))==sizeof(void*) under 32 bit. You would not believe how many 32 bit programs actually assigning a pointer value to an int variable. Such constructs immediatly fail under 64 bit compilation.
Therefore if the code is only available for 32 bit (x86) i try to first compile it for 64bit (x64) and fixing all the associated issues until it runs on my development machine (x64) and then i just compile for ARM64...which typically immediatly works.

2) Some programs are using dynamic translations (like for instance some emulators, but in any case each web browser for their Javascript engine). This is a non-trivial change as you need to rewrite the whole dynamic code generation modules from scratch.
 
  • Like
Reactions: soresu

Thala

Golden Member
Nov 12, 2014
1,065
393
136
This is what I wrote :)

429.mcf is at 3.79W while 470.lbm is at 6.27W. So there's a 2.5W difference and you will agree that it's unlikely a core running a program at full speed consumes less than 0.5W. So 3W looks like a good approximation of the lower bound of max power consumption of a core.
it is close to impossible to derive core power consumption this way. You need at the very least to look at the performance counters to get an idea where the power is spent. For example if you running at low IPC ther core power is drastically reduced. Likewise if you have much memory access system power ist drastically increased, but cannot be attributed to the cores. So without performance counters your argument is moot.

Where did you get this A76 figure from? Again looking at Andrei results, for SD855 I see 458.sjeng at 1.68W and 470.lbm at 3.44W. That'd be about 2W.
From power simulations on Cortex A76 RTL. This way I can break down power usage to each submodule. But i did not run 470.lbm either so i give you that some compute kernels might use higher power at core level.

You really think that all the 4 big cores can ever run at full speed at the same time? And that this TDP will be sustained? Or like Intel max power consumption can exceed 7W for short periods of time?
On my Cortex A73 tablet i can run 8 cores 100% without any frequency reduction. On NEON heavy code there is sometimes a slight (10%) frequency reduction but i have never seen more than that - and thats with 8 cores running.
I surely going to test this for Cortex A76 once i get my Surface Pro X.
What i do know is, that the ARM devices typically do not increase Voltage in single core situations where the power headroom is huge.


Look at this curve, and let's start talking about increasing voltage and TDP :)

Where is this coming from? Does not look anything like a N7 Frequency Voltage curve.

Oh yes binning. How much does that bring to SD855 derivatives? 0.2 GHz? :D
Little more than that, I have seen deviations for up to 0.4GHz between timing sign-offs nominal vs. slow/worst in the 3GHz range.

I have this SD845 board in front of me. I'm looking at a way to put a fan on it because it keeps on throttling. Locking frequency make it reach 100°C with a single core running. If I don't lock frequencies this thing throttles within a few seconds. Yes that's a smartphone chip with a heatspreader.
Cannot comment on this without more info.
 
Last edited:

Thala

Golden Member
Nov 12, 2014
1,065
393
136
Also this is the first time I hear f/v curves being common across process and not taking uarch into account. How the heck do you account for hitting new critical path limits above certain frequencies?
I did say the appearance is roughly similar aside from scaling of the frequency axis. This means that two different architectures may have different frequencies say at certain voltage but the relative scaling stays the same. Or more strictly speaking cycle time is roughly inverse proportional to (Vcc-Vth)/Vcc. The proportionality factor depends on the (capacitance) of the critical path of the particular architecture.
 

Nothingness

Platinum Member
Jul 3, 2013
2,153
397
126
I wish I could like this a thousand times. "x86 sucks y'all". "OK, then why are we all using it?".
Easy: because Intel and AMD used to make the best CPU at an affordable price. And legacy of course as others wrote.

Like it or not x86 as an instruction set sucks; did you do assembly language programming on it? And on other assembly language to compare? It's just an abomination; it has gotten better with 32-bit and x86-64, but its 8080 roots still show.

But Intel and AMD implementations of x86 are good and this is what matters to the end user (plus legacy obviously).
 
  • Like
Reactions: the2199

Nothingness

Platinum Member
Jul 3, 2013
2,153
397
126
For CPU's the ONLY company that was willing to second source was Intel. Motorola had a much better product (And ISA) at the time, but refused to license for second sourcing.
Ha 68k, that was a nice ISA. It had its shortcomings, but it was so much better than that brain dead x86. Some Motorola people must regret their decision, as much as Otellini regrets turning down Jobs for iPhone CPU.
 

Thunder 57

Golden Member
Aug 19, 2007
1,512
1,371
136
Easy: because Intel and AMD used to make the best CPU at an affordable price. And legacy of course as others wrote.

Like it or not x86 as an instruction set sucks; did you do assembly language programming on it? And on other assembly language to compare? It's just an abomination; it has gotten better with 32-bit and x86-64, but its 8080 roots still show.

But Intel and AMD implementations of x86 are good and this is what matters to the end user (plus legacy obviously).
Never thought about it like that. Yes, x86 assembly sucks. That's probably why they teach MIPS or ARM assembly at most universities. I did MIPS, but they did spend some time on x86 as well. So the assembly may suck, but x86 is still good.

How could a phone have a cpu as fast as fastest desktop cpu? That's a insane situation, most of people still just don't understand it because it should not be possible at all.
Because it's not. Let's see that phone transcode some h264.
 

name99

Senior member
Sep 11, 2010
240
221
116
Probably. But wouldn't that be dedicated hardware, like Quicksync? I bet it is slow as heck on the actual CPU of the SoC.
Why would you want to do it on the CPU?
THAT is the basic problem with your analysis; you're living in the past. Most of the examples you want to give of highly tuned x86 code that don't have ARM counterparts don't have those counterparts because no-one in ARM/Apple-land cares.
Video/audio/image encoding are done with dedicated hardware. Likewise for crypto. Likewise for some types of compression (it remains unclear just what compression Apple still does on the CPU, doubtless with tuned ARM assembly, vs what they have already moved to accelerators.)

So what's left?
There are things like highly tuned interpreters. If you care about running Lua or Python on ARMv8 it MIGHT be slower. Obviously JS is just fine. Anyone have any real data?

There is also highly tuned numerical code. When I compare Mathematica on iMac Pro to Wolfram Player on A12X iPad Pro, for the most part they are comparable in performance, but there are clear areas where Wolfram Player substantially lags.
Most of these differences appear to be policy choices by Wolfram as to how performant to make Wolfram Player so that it doesn't compete too much with Mathematica (eg the parallelization/vectorization support is abysmal).
But there's clearly a non-policy issue with the bignum support, which is just terrible --- that's probably the one (and only) real-world case I am aware of where highly-tuned x86 code has not (yet...) been rewritten to highly-tuned ARMv8 and is probably just using straight C.
 
  • Like
Reactions: Nothingness

soresu

Golden Member
Dec 19, 2014
1,411
584
136
Probably. But wouldn't that be dedicated hardware, like Quicksync? I bet it is slow as heck on the actual CPU of the SoC.
ASIC is a completely different beast designed to run at relatively low clocks (sub Ghz?) compared to CPU cores, because the circuit pretty much replicates software codec functions directly in silicon without extraneous overhead.

Their main benefit is in mobile systems that are highly power constrained, in desktops they just take the load off the CPU, allowing it to be used for other things at the same time (like playing games while streaming encoded video).

Their main disadvantage as a fixed circuit is a lack of tunability, unlike x264/x265/libaom/SVT-AV1/rav1e which can endlessly be updated and made better over time - more quality, more SIMD, more cores.
 

Carfax83

Diamond Member
Nov 1, 2010
5,886
577
126
Why would you want to do it on the CPU?
From what I understand, software encoding gives the highest quality per bitrate at smaller file sizes compared to using hardware encoding. This distinction isn't likely to go away either, as encoders become more computationally complex.

I posted a thread a few weeks ago about Intel's SVT codecs which offers dramatic performance gains compared to other solutions. If Intel can have performance gains like this, whilst maintaining quality, then the case for hardware encoders is not going to look good in the future.
 
Last edited:

soresu

Golden Member
Dec 19, 2014
1,411
584
136
If Intel can have performance gains like this, whilst maintaining quality, then the case for hardware encoders is not going to look good in the future.
The case is still there for the game streaming niche, an ASIC takes the load largely off the CPU - for video encoding on mobiles and video DSLR's/cinecams it's also needed, though the bitrate target tends to be much higher for the latter, so quality tuning is less necessary.

As for the SVT codecs, their main benefit is to systems with a large quantity of cores and memory - owing to the less than stellar quality decrease as you scale thread count in competing codecs.

SVT seemingly has zero quality decrease as you scale thread count, though it does seem to have a performance scaling ceiling - an Epyc 7742 hardly scores worse than 2x Epyc 7742 by Phoronix's testing.

It's my hope that as SVT is now open, we will see those scaling benefits make it into other codecs like x264 and rav1e as the proverbial magic sauce is unravelled.
 
Last edited:

beginner99

Diamond Member
Jun 2, 2009
4,594
944
136
For laptops, I fail to see why it's not possible to design one laptop chip and fuse off parts/adjust clocks to differentiate performance between different product lines. Mac Pros (and to a lesser extent iMacs) are a tougher nut to crack with this approach but certainly not impossible, given the die sizes involved its almost certain that they'd have lots of chips not up to stuff for top clocks/full functions.
For laptops it can work yes maybe even imac with some compromise. But macpro is not doable. You can get macpros with dual xeons and with the next macpro the could go with zen 2 with up to 64 cores.

When one lightning core in an A13 SoC draws 4-5w to get similar single-threaded performance as a Ryzen 2 core in a 3900x drawing ~18w with no process advantage, that's a heck of an incentive to do ditch x86.
Proof needed. Single-threaded in what? geekbench? How do you get the power numbers per core? All the non-core stuff which desktop CPUs have a lot more uses power too. A13 doesn't have pcie, sata or infinity fabric power use. And we have seen how much power that stuff uses.
Only thing I can say is that Apple is known to offer subpar connectivity for the price and makes additional profit on that by selling dongles. Might work for laptop where fanboys still buy even so it only has 1 usb-c port. but on mac pro? Nope.


How could a phone have a cpu as fast as fastest desktop cpu? That's a insane situation, most of people still just don't understand it because it should not be possible at all.
burst performance is one thing sustained completely different. Why can I run the same core in a 5w laptop that is in a full blown server with >200w? Sustained performance. The jump from ULV to server cpus in terms of wattage is far bigger than from Axx to laptop cpus. So your point isn't really much of value. The main difference simply is power management or sustained performance.

And then the fact that apple designs 1 soc that goes into mobile devices only in contrast to intels cores that go into laptops to desktops to servers. And the cores 5w CPUs in ULV laptops are identical to the cores in a 9900k using close to 150w. What's the difference? Cooling or said otherwise sustained performance.
Not to mention x86 backwards compatibility which intel/amd have to adhere to.

Once Apple actually needs to match sustained performance and not just IPC, then the picture changes dramatically.
 

scannall

Golden Member
Jan 1, 2012
1,691
1,065
136
:rolleyes: Piss poor doesn't work in a competitive environment. Do you (and others) really think you're the first to think "ARM awesome! x86 sucks!, Let's scale ARM up"? I'd be willing to bet that in five years ARM is still limited to low power devices while x86 is used in anything where performance matters.
It's more a chicken and the egg thing. x86 isn't good, but it's deeply embedded everywhere. It's hard enough to get companies to move from one vendor to another within x86, let alone to a different ISA. Just the Apple A series chips indicate there is a lot available under the hood, if you throw the transistor count at it. But moving the world to a different ISA? That won't happen anytime soon. It has nothing to do with good or bad, and everything to do with inertia.
 

soresu

Golden Member
Dec 19, 2014
1,411
584
136
The Webkit libraries are allowed but that's part of the OS technically. Safari (and really any other application that wants a browser) just leverages that.
Oh yeah, I forgot that Firefox Focus had to use WebKit's JS engine on iOS.

Brainfart strikes again....
 
  • Like
Reactions: the2199

insertcarehere

Senior member
Jan 17, 2013
302
106
116
For laptops it can work yes maybe even imac with some compromise. But macpro is not doable. You can get macpros with dual xeons and with the next macpro the could go with zen 2 with up to 64 cores.
Even if we assume Apple somehow can't just go the AMD Chiplet route for higher performance applications, a large monolithic die of ~250mm2 on 7nm (Navi 10 size) would fit a buttload of these cores, should Apple really want to pursue such a path (assuming they don't just let the mac pro rot on the vine).

Proof needed. Single-threaded in what? geekbench? How do you get the power numbers per core? All the non-core stuff which desktop CPUs have a lot more uses power too. A13 doesn't have pcie, sata or infinity fabric power use. And we have seen how much power that stuff uses.
Only thing I can say is that Apple is known to offer subpar connectivity for the price and makes additional profit on that by selling dongles. Might work for laptop where fanboys still buy even so it only has 1 usb-c port. but on mac pro? Nope.

Notice the A13 scoring above the 3900x on SpecInt2006 and just below on SpecFP2006, a single-threaded test

Correction: On a chip-by-chip comparison (the A13 in the iphone is almost certainly measured on a chip level), the 3900x consumes 50 W, vs the A13s ~5w, of which ~20w was attributed to the Ryzen 2 core. I shouldn't have to remind you that the A13 SoC also integrates stuff like a LTE Modem, iGPU and various ISPs which are absent on any Ryzen 2 chip.

burst performance is one thing sustained completely different. Why can I run the same core in a 5w laptop that is in a full blown server with >200w? Sustained performance. The jump from ULV to server cpus in terms of wattage is far bigger than from Axx to laptop cpus. So your point isn't really much of value. The main difference simply is power management or sustained performance.

And then the fact that apple designs 1 soc that goes into mobile devices only in contrast to intels cores that go into laptops to desktops to servers. And the cores 5w CPUs in ULV laptops are identical to the cores in a 9900k using close to 150w. What's the difference? Cooling or said otherwise sustained performance.
Why are you penalizing the Apple A13 for being placed in a far more thermally limiting form factor than any x86 processor that's within the same galaxy in terms of performance? Place the same chip in a motherboard with an actively cooled heatsink and suddenly the sustained chip performance would be stellar.
 

beginner99

Diamond Member
Jun 2, 2009
4,594
944
136
I cannot fathom how people think moving from x86 to arm is a piece of cake even for a company with a looked ecosystem like apple
Exactly. most companies even have problems moving away from oracle and if you think x86 is expensive think again. oracle is sucking you dry and still many think it's better than migrating all software or it literally takes 1 decade.
 
  • Like
Reactions: the2199

ASK THE COMMUNITY