Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Rosetta 2 Benchmarks Surface From Mac Mini With A12Z Chip
- Thread starter MacRumors
- Start date
- Sort by reaction score
I don’t doubt anything you say.
Whag you can expect is the first systems will be geared to users who don’t use high end software. They will run Apple apps, Office, and iOS aps well and some other basic apps via Rosetta. These prerelease dev kits are meant for developing apps for those people.
High end Intel systems will remain the go to for 2 years for your customers.
In that time you will have access to a much more robust setup to develop on.
If you are a game developer you probably have a decent gaming rig anyway.
And did you miss that Unity development kit is already running on the new ARM machines...
About 4% impact. A lot? Not a lot? Since we are pretending these numbers mean something, that’s up to you.
Thx for this info!
[automerge]1593498190[/automerge]
This is puzzling for me as well. How long can the iPad do 2.5 GHz? Maybe they want to have a safety margin as they know many will run @100% a lot.
I'll toss in one observation, ``If you need 96GB to compile Maya when 32GB compile Blender Master within 10 minutes on an old FX-8350 speaks poorly to the state of Maya's code base.'' That being said, 16GB for a processor designed to work with 2-4GB on a very locked down system tells me most of that 16GB is for Rosetta to be cached to compensate for the poor system performance. Maya is just going to expose it and be overkill.
On the plus side, Autodesk has an opportunity to optimize the hell out of Maya for x86_64 and ARM64 by the time it reaches Apple Silicon in two years and by then Zen 5 should really scream on it.
On the plus side, Autodesk has an opportunity to optimize the hell out of Maya for x86_64 and ARM64 by the time it reaches Apple Silicon in two years and by then Zen 5 should really scream on it.
Actually it's 3.68% and performance doesn't scale perfectly with clocks anyway so the actual performance loss is lower than that.
If you are a game developer you probably have a decent gaming rig anyway.
And did you miss that Unity development kit is already running on the new ARM machines...
This is wonderful news to hear. Now bring on zbrush and the arm macs will be the perfect laptop for me
Dude, it's just an instruction set. Heck, Unreal Engine 5 already is targeting iOS (read: "Apple Silicon"). I didn't even check the others because it's so "*shrug* it will be ported easily".
Edit: Unity targets iOS also. Decima game studio targets iOS. FrostBite Go targets iOS. iD Tech has games running on iOS. All these can be brought over with relative ease.
Sure it takes some time, but it's not a super high hurdle, compared to a whole game engine itself.
Last edited:
Turns out that in scales pretty close with clock, especially for small changes in clock. I always thought it shouldn’t, but every time I worked on a cpu and sped up the clock by x%, it always improved on benchmarks, on average, by x%.
With bigger clock changes you can start getting into non-linear behavior. And of course some workloads will be less (e.g. memory access-dominated workloads where you don’t also speed up the memory “clock” and rarely some will be more (certain race conditions will resolve in your favor sometimes and buy you a cycle.)
[automerge]1593499637[/automerge]
”page doesn’t exist or is private”
Many people don't realize this, but Apple is making a clear statement here. Meaning, if we can do this, can you imagine what we could do with a Mac dedicated chip? Exciting times ahead.
With all due respect, that is barely something to boast about.
[automerge]1593504877[/automerge]
A completely wild, unverified, baseless supposition: my guess is that these chips might be factory rejects that work but don't qualify for being used in an actual iPad Pro. Lower clocks then would be to increase stability.
You keep harping on about your 230W Core i7 2600 - which checking on Geekbench gets slightly lower single thread at 3.4GHz than this 2.4GHz Apple Silicon.
This developer machine is running an iPad Pro internally with more RAM. If it uses more than 20-30W at the socket I would be surprised because 7.5W SoC + LPDDR4 + SSD don't use much. So it's beating your CPU in single thread in a fraction of the power.
This is a two generation old A12 core - the ARM Macs will use A14 cores, which are going to be around 30-40% higher IPC. They will have a higher TDP, and hence higher clocks. And they will be running native code which is worth 30% on its own.
We don't know how many cores Apple will include, but rumours suggest 8 large cores (and 4 small cores), so multithreaded benchmark scores will skyrocket.
All this is irrelevant. The main task of the dtk is to test your builds - not do the actual build. You can do the actual build on any system with Xcode installed.
How does the ARM architecture differ from x86?
Is the x86 Architecture specially designed to work with a keyboard while ARM expects to be mobile? What are the key differences between the two?stackoverflow.com
"ARM has two different instruction encoding modes: ARM and THUMB. In ARM mode, you get access to all instructions, and the encoding is extremely simple and fast to decode. Unfortunately, ARM mode code tends to be fairly large, so it's fairly common for a program to occupy around twice as much memory as Intel code would."
I'd trust Stackoverflow more than I'd trust you..
StackOverflow in this case has exaggerated the differences, and simplified to the point of unhelpfulness.
Firstly, ARM and THUMB (A32 and T32) are not AArch64, in AArch64 (all Apple Silicon will be) you run A64 code, which includes both 32-bit and 16-bit instructions, and operates on 32-bit and 64-bit words. You cannot change operating modes except on an exception boundary, and it is suggested that Apple Silicon doesn't even support A32/T32. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0801b/IBAIEGDJ.html
A64 code is denser than A32 code.
It is nearly as dense as x86-64 code.
Memory footprint of 64-bit ARM compared to x86-64 - Compilers and Libraries forum - Support forums - Arm Community
I'm new to ARM. My use case: Ubuntu LAMP I need to know how big is the memory footprint for system running 64-bit ARM processor compared to x86-64. (Benchmark is
community.arm.com
Your developers will build on the Mac Pro in XCode as per normal, but they will select the universal binary option.
The final application will be copied to the dev ARM Mac Mini.
The QA testers will run the application to find issues - and for Maya/Fusion this will take a very long time I'm sure, each function would need to be tested. I'm sure a lot of automation exists, but maybe the automation tool needs to be ported too.
The main issue I would expect is where you have optimised x86-64 assembly in the codebase with a low-performance C/C++ fallback. Someone will have to write either optimised C/C++ or hand-optimised ARM for these compute kernels. They may decide to switch to GPU compute via Metal, etc.
This is what this box is for. It's not a development platform, you'll use your existing machines for that. It's a QA platform.
Last edited:
You shouldn't, the accepted answer there is overly simplistic. For example, as an ISA comparison they use "repe cmpsb", which is terribly slow on modern CPUs and therefore not used. It is a remnant of an old x86, where Intel tried to be more CISC-y. When you look at modern x86 instructions, like AVX, they are all following RISK design principles.
In regards to code size, here is a small comparison using a simple quick sort C implementation (https://godbolt.org/z/t54RiQ) :
| ARM64 | x86-64 | |
| optimized for size (-0s) | 108 bytes | 75 bytes |
| optimized for performance (-O2) | 128 bytes | 171 bytes |
| optimized for performance (-O3) | 128 bytes | 258 bytes |
Generally, for short trivial code (like one people like to show in examples but will never occur in real life), x86 will have denser code since the more frequently used instructions are shorter. This is also the reason why the compiler can optimize x86 better for size — it can try to choose shorter instructions even if the generated code is suboptimal (not much freedom on ARM in this regard). For complex algorithms (especially ones involving a lot of computation), ARM will often produce shorter code since a) newer Intel instructions are longer b) ARM has more registers, so the compiler has more room to work.
The i7 2600 is a 95W chip tops.
And it uses the 32nm node, it's 10 years old and it's not even the best i7 Intel launched that generation. The 2700K gets better scores in Geekbench and intel's 15W, 10nm mobile i7 is able to easily outscore the 2700k in Geekbench.
This was a specific response to someone talking about his specific system, and it's system TDP, so I mentioned likely system TDP of the dev mini.
Of course Intel moved on since 2011, and current 15W chips outperform 95W a decade ago.
What we have is what a ~7.5W TDP (we don't know if it's higher in the dev box so it can run at turbos for longer than the iPad) performs like in Rosetta, and a range of benchmark comparisons like 15W IceLake where it compares similarly.
We can guess that the final silicon will be +20% (A13) + 20% (A14) + 30% (native) + 30% (higher clocks) (+more cores) as well, but we don't know the exact figures here.
You said: your 230W Core i7 2600 which is the CPU not the system.
Also what's the point of mentioning the TDP of a PC tower when you can just measure the power draw at the wall?
Why wouldn't it turbo at max frequency when it has much better cooling than on a tablet?
Anyway Geekbench isn't really a good benchmark for X86 CPUs in the first place.
Last edited:
Lol.. the point was I'd trust Stackoverflow over some random dude on these forums. Nobody uses -O3 the benefit is tiny and has some added risk. Even the speed benefit for -O2 in production is small over -O1 and I work on very large software packages.