A8X chips was an anomaly. Apple moving back to dual core CPUs.

[AlTech]

Note - All graphics and images are from Anandtech

 

So apparently the A8X chip in the iPad Air 2 was a mistake and shouldn't have happened if the laws of physics weren't broken. The reason why apple had to throw another core at the problem was cos they couldn't make the chip run any faster without a massive power efficiency penalty. 

 

To recap the A8x has a triple core 1.5GHz using codenamed Typhoon cores.

 

But the new iPad Pro features a dual core 2.26GHz (That's extremely fast by Apple standards!) codenamed Twister cores.

 

 

In addition to this, benchmarks suggest that Apple went with either a custom 10 core graphics chip (with 320 stream processors) or 12 core (with 384 stream processors).

Either a highly clocked 10 core graphics (quite feasible giving high CPU clock speed) or a moderately clocked 12 core. And according to firestrike unlimited, the graphics are around the level of Intel HD 4200 Graphics (Haswell Y series CPU in Surface Pro 3).

 

 

Edit:

 

Here are CPU benchmarks

 

 

 

 

 

Source: http://anandtech.com/show/9780/taking-notes-with-ipad-pro/2

 

I think that Apple is getting more adventurous and trying to push their chip design to the limit with the X chips. And the normal chips are where Apple tries to push power efficiency to the limit. 

 

Leave a comment below!

[PlayStation 2]

Awww.... the triple-core CPU was a pretty good idea ,

[AlTech]

Awww.... the triple-core CPU was a pretty good idea ,

Same! I was like "YES iPad finally is triple core beast! Muhahaha".

 

RIP A8X.

[Dietrichw]

oh, I didn't know that the iPad Pro was dual core. I thought it was triple or quad. Damn...  it is beating dual core Intel core series chips.

[AlTech]

oh, I didn't know that the iPad Pro was dual core. I thought it was triple or quad. Damn...  it is beating dual core Intel core series chips.

Apparently the benchmarks aren't accurate. What WOah. Mind blown.

[patrickjp93]

oh, I didn't know that the iPad Pro was dual core. I thought it was triple or quad. Damn...  it is beating dual core Intel core series chips.

In benchmarks that are wildly ARM-biased. Never trust a benchmark where you can't see the code for yourself. ARM's branch has code that was obviously hand-done assembly (disassemble it with clang if you're so inclined). x86's was obviously compiled with Visual Studio without optimization enabled, a double-whammy.

 

It's one thing for ARM to be beating x86 in some database benchmarks since x86 was not designed as a transactional architecture and is only now starting to make that switch (TSX extensions being the first step, HMC being a second one), but in actual standard workload performance? You should take one look at it and go "BS."

 

If you think Intel was slimy for not optimizing for AMD's and VIA's processors in ICC (it still doesn't btw), ARM's a million times worse. It's basically bought benchmark makers who are otherwise irrelevant software companies. Throw open-source benchmarks at both chips and even Sandy Bridge mobile I3s decimate the A8X.

[AlexGoesHigh]

oh, I didn't know that the iPad Pro was dual core. I thought it was triple or quad. Damn...  it is beating dual core Intel core series chips.

Like other said some benches are stupidly biased in favor of ARM, Geekbench the biggest of all, browser based benches are more trustworthy.

[TechGod]

Same! I was like "YES iPad finally is triple core beast! Muhahaha".

 

RIP A8X.

But if two wider cores offer better performance than a triple core config, why would you be saying RIP?

[AlTech]

But if two wider cores offer better performance than a triple core config, why would you be saying RIP?

Because I wanted the 3 core Legacy to continue :angry:

[TechGod]

In benchmarks that are wildly ARM-biased. Never trust a benchmark where you can't see the code for yourself. ARM's branch has code that was obviously hand-done assembly (disassemble it with clang if you're so inclined). x86's was obviously compiled with Visual Studio without optimization enabled, a double-whammy.

 

It's one thing for ARM to be beating x86 in some database benchmarks since x86 was not designed as a transactional architecture and is only now starting to make that switch (TSX extensions being the first step, HMC being a second one), but in actual standard workload performance? You should take one look at it and go "BS."

 

If you think Intel was slimy for not optimizing for AMD's and VIA's processors in ICC (it still doesn't btw), ARM's a million times worse. It's basically bought benchmark makers who are otherwise irrelevant software companies. Throw open-source benchmarks at both chips and even Sandy Bridge mobile I3s decimate the A8X.

Since you're literally the only one that might even bother to answer this for me, SMT relies on a front end that's significantly faster at executing instructions than what can be fed to the CPU, right? (correct me if I'm wrong), could future AxX cores support SMT? Or mobile ARM SOCs in general. 

[TechGod]

Because I wanted the 3 core Legacy to continue :angry:

But...but why??? I don't get it...this is proof right here that more cores aren't always better. 

[patrickjp93]

Since you're literally the only one that might even bother to answer this for me, SMT relies on a front end that's significantly faster at executing instructions than what can be fed to the CPU, right? (correct me if I'm wrong), could future AxX cores support SMT? Or mobile ARM SOCs in general. 

SMT relies on having a fast fetch and decode. Execution on the ALUs, AGUs, and FPUs is a separate matter that obviously affects performance, but all the same if the fetch/decode is choked, the rest doesn't matter. SMT tries to fit more instructions into the pipeline of a single core. Good programming design for this involves having different tasks that use different instructions. If two tasks share the same data, the benefits are greater due to reduction in cache misses.

 

Taking it one step further, compiling a program to take advantage of SMT would further require two target threads don't share the same registers either. Every resource in contention during any subset of cycles results in lower performance potential. This is why the top x86 supercomputers use ICC. Intel's extracted more than 33% extra performance per core under hyperthreading thanks to the tricks it's built into the optimization engine. Compile time shoots through the roof, but the results are well worth it if SMT is implemented correctly and then properly programmed for.

 

Nothing is stopping any company in the world from implementing SMT. IBM has its own flavor, and AMD will have one. ARM can implement it at any point; and so may Apple, Samsung, Qualcomm, Mediatek, Rockchip, Huawei, and VIA.

[AlTech]

SMT relies on having a fast fetch and decode. Execution on the ALUs, AGUs, and FPUs is a separate matter that obviously affects performance, but all the same if the fetch/decode is choked, the rest doesn't matter. SMT tries to fit more instructions into the pipeline of a single core. Good programming design for this involves having different tasks that use different instructions. If two tasks share the same data, the benefits are greater due to reduction in cache misses.

 

Taking it one step further, compiling a program to take advantage of SMT would further require two target threads don't share the same registers either. Every resource in contention during any subset of cycles results in lower performance potential. This is why the top x86 supercomputers use ICC. Intel's extracted more than 33% extra performance per core under hyperthreading thanks to the tricks it's built into the optimization engine. Compile time shoots through the roof, but the results are well worth it if SMT is implemented correctly and then properly programmed for.

 

Nothing is stopping any company in the world from implementing SMT. IBM has its own flavor, and AMD will have one. ARM can implement it at any point; and so may Apple, Samsung, Qualcomm, Mediatek, Rockchip, Huawei, and VIA.

How the F*** are you this good with CPU knowledge?

[patrickjp93]

But...but why??? I don't get it...this is proof right here that more cores aren't always better. 

Because people don't understand Amdahl's Law is an inescapable fact of mathematics and computer science. People will continue to pursue moar coars until they turn blue in the face. IBM picked fewer, faster cores with 8-way SMT on Power 8, and it's the best database and scale-up architecture in the world right now (Oracle's latest SPARC being a good second, Intel at a distant 3rd with ARM actually beating it in some cases since x86 just wasn't designed with transactions in mind oh so long ago). Intel's put 4-way SMT onto its Xeon Phi. It's only a matter of time until that comes to its Xeons as well to better position itself in scale-up workloads. Whether or not we see a 12-core 4.3 GHz beast from Intel in the next 3 years... I doubt it.

[TechGod]

How the F*** are you this good with CPU knowledge?

Masters in computer science probably means they have to have *some* understanding of the hardware they're programming for. 

[patrickjp93]

How the F*** are you this good with CPU knowledge?

Because I took 1 high performance computing class with the professor who runs the Miami University supercomputing lab (MUSE), and I aced it. Now I'm the TA. Also, I paid attention in computer architecture. You don't get to be a master's student by doing the minimum.

 

And not to sound cocky, but at this level it's not even difficult. I've forgotten everything about analyzing basic circuits from intro electrophysics. I wouldn't be able to tell you the first thing about how to make an ALU. Processes and algorithms are my forte. Since everything on a CPU reduces to an algorithm (there are published algorithms for bit-wise addition and how to add 32 bits to 32 bits in a single cycle, and basically you translate that to logic gates on a circuit), this simply isn't difficult for me. It just makes sense. When you start discussing cache miss ratios, noisy neighbor effects, cache miss penalties, multi-level caches, bandwidth vs. latency, cache size vs. access time, then it gets to the point I have a very difficult time analyzing the macro-scale effects over the course of a given program. Sure I can tell you the exact penalties of missing at L1 but finding in L2 or missing there and finding in L3, and now with Intel freaking L4, and then RAM, and then virtual memory, but the math to actually show you the amortized total effect over the course of a program? Way out of my league. This is kid stuff in my department. The graduate version of HPC was the first class I had to drop out of (Fall Junior Year) because it was simply too difficult for me to understand. Maybe now that I've done Linear Algebra and Advanced Algorithms I can go back again, but that's the level I can't cut it at right now.

[TechGod]

SMT relies on having a fast fetch and decode. Execution on the ALUs, AGUs, and FPUs is a separate matter that obviously affects performance, but all the same if the fetch/decode is choked, the rest doesn't matter. SMT tries to fit more instructions into the pipeline of a single core. Good programming design for this involves having different tasks that use different instructions. If two tasks share the same data, the benefits are greater due to reduction in cache misses.

 

Taking it one step further, compiling a program to take advantage of SMT would further require two target threads don't share the same registers either. Every resource in contention during any subset of cycles results in lower performance potential. This is why the top x86 supercomputers use ICC. Intel's extracted more than 33% extra performance per core under hyperthreading thanks to the tricks it's built into the optimization engine. Compile time shoots through the roof, but the results are well worth it if SMT is implemented correctly and then properly programmed for.

 

Nothing is stopping any company in the world from implementing SMT. IBM has its own flavor, and AMD will have one. ARM can implement it at any point; and so may Apple, Samsung, Qualcomm, Mediatek, Rockchip, Huawei, and VIA.

So by fast fetch and decode, we're talking about an increase in L3 cache (more L3 wouldn't be *faster* per say but since it'd hold more instructions it would mean we have eliminated *some* latency which exists by fetching from RAM) same goes for L2 cache and maybe also for L1-D? Isn't cache expensive in terms of die area AND power consumption? or is there another way of improving fetch/decode performance? What I suggested seems to be more of a bandaid as opposed to a real solution. 

[patrickjp93]

So by fast fetch and decode, we're talking about an increase in L3 cache (more L3 wouldn't be *faster* per say but since it'd hold more instructions it would mean we have eliminated *some* latency which exists by fetching from RAM) same goes for L2 cache and maybe also for L1-D? Isn't cache expensive in terms of die area AND power consumption? or is there another way of improving fetch/decode performance? What I suggested seems to be more of a bandaid as opposed to a real solution. 

I mean having enough fetch and decode pipelines to actually have enough data and instructions to be able to dispatch them to the other parts of the CPU. For Haswell you have a 256-bit vector ALU, a 256-bit hybrid Floating Point Vector Unit, and 2 64-bit integer ALUs if memory serves, and I think Haswell has 2 or 3 AGUs. 6-7 functional units to dispatch both data and an instruction to. If you wanted to dispatch to all of that at once using 32-bit values, that's 8 for the vector ALU alone, 4 for the integer ALUs, up to 8 for the FPVU, and up to 4-6 for the AGUs for the data alone, and what if you wanted to dispatch data to the registers as well? That's 5 to 10 for the GP registers (the 6th of the original register file shouldn't be touched since it controls the stack pointers),. You'd need 24-26 prefetch pipelines or you'd need 12-13 double-pumped the CPU's clock speed to keep absolutely everything fed with data, let alone the instructions which may be up to 64 bits in length, requiring 2 32-bit fetchers and decoders once again for absolutely perfect performance capability for each functional unit.

 

Where the cache would come in would be having parallel, super low latency access. And the more you can minimize cache miss penalties between cache levels levels, and the more accurate you can make your branch predictor and translation lookahead buffer, the faster you can access that data, and the more that data can be where it needs to be before you ask for it.

 

Cache is itself RAM cells (DRAM or SRAM I can't recall), and yes it is expensive thermally, electrically, and spatially. Every cell is a capacitor that has to be recharged to maintain state by a special (but stupid) circuit, so it can't even be made nearly as small as the functional units. That said, the more of it you have, at as low a latency and as high a bandwidth as possible, the better your conditions are for SMT and multicore use in general.

 

If Memristors ever do become practical and can run at high frequency, cache would suddenly be the least expensive thing on the whole CPU.

[AlTech]

I mean having enough fetch and decode pipelines to actually have enough data and instructions to be able to dispatch them to the other parts of the CPU. For Haswell you have a 256-bit vector ALU, a 256-bit FPU, and 2 64-bit integer ALUs if memory serves, and I think Haswell has 2 or 3 AGUs. 6-7 functional units to dispatch both data and an instruction to. If you wanted to dispatch to all of that at once using 32-bit values, that's 8 for the vector ALU alone, 4 for the integer ALUs, up to 8 for the FPU, and up to 4-6 for the AGUs for the data alone, and what if you wanted to dispatch data to the registers as well? That's 5 for the GP registers (the 6th of the original register file shouldn't be touched since it controls the stack pointers), and . You'd need 24-26 prefetch pipelines or you'd need 12-13 double-pumped the CPU's clock speed to keep absolutely everything fed with data, let alone the instructions which may be up to 64 bits in length, requiring 2 32-bit fetchers and decoders once again for absolutely perfect performance capability.

 

Where the cache would come in would be having parallel, super low latency access. And the more you can minimize cache miss penalties between cache levels levels, and the more accurate you can make your branch predictor and translation lookahead buffer, the faster you can access that data, and the more that data can be where it needs to be before you ask for it.

 

Cache is itself RAM cells (DRAM or SRAM I can't recall), and yes it is expensive thermally, electrically, and spatially. Every cell is a capacitor that has to be recharged to maintain state by a special (but stupid) circuit. That said, the more of it you have, at as low a latency and as high a bandwidth as possible, the better your conditions for SMT and multicore use in general for shared caches.

You sound unbelievably smart. Can you help me make a decision?

 

http://linustechtips.com/main/topic/484859-opinions-wanted/#entry6502830

[patrickjp93]

You sound unbelievably smart. Can you help me make a decision?

 

http://linustechtips.com/main/topic/484859-opinions-wanted/#entry6502830

Believe me I pale in comparison to my ex girlfriend who just graduated U Penn with a 4.0 in both business and aerospace engineering in less than 4 years. I'm smart. She's a genius, and a great bassoonist.

 

I'd tell you save your money for 3 months because Surface 4 prices should be falling soon and the next iteration of the iPad Mini will be due out in the next quarter once iPhone sales slow down and the A9X SOCs have to find a new home.

[AlTech]

Believe me I pale in comparison to my ex girlfriend who just graduated U Penn with a 4.0 in both business and aerospace engineering in less than 4 years. I'm smart. She's a genius, and a great bassoonist.

 

I'd tell you save your money for 3 months because Surface 4 prices should be falling soon and the next iteration of the iPad Mini will be due out in the next quarter once iPhone sales slow down and the A9X SOCs have to find a new home.

I think you missed the iPad Mini 4 launch. It came out a month ago. The surface 3 is 5 months  old.

[patrickjp93]

I think you missed the iPad Mini 4 launch. It came out a month ago. The surface 3 is 5 months  old.

I did miss that launch, though I stand by what I said about the Surface (Pro) 4.

 

Admittedly school's kept me out of the tech loop this semester. I'll give it another once-over.

[patrickjp93]

 

I think you missed the iPad Mini 4 launch. It came out a month ago. The surface 3 is 5 months  old.

If you are dead set on running visual studio (though I'd sorely recommend against it, as I've come to hate Visual Studio with a burning passion in my graphics class since it never cleans solutions and projects properly), then go with the Surface option. The MAC OS/iOS version of VS is puke-worthy.

 

If you need it for C# programming, I understand, but if this is for C/C++, I'd tell you to do yourself a favor and get a text editor with syntax highlighting (Notepad++, Emacs, and VI/Vim are all free) and learn to compile from the command line. The compile times on Visual Studio take so long even on my Haswell Macbook Pro Retina I could write about 100 lines before it'll finish. Setting up pre-compiled headers is also a bit of a nightmare, and the gains are not as good as marketed, at least for VS 2013. I can't move to 2015 until after this semester is over since the graphics labs all start with 2013 solution files.

[RagnarokDel]

oh, I didn't know that the iPad Pro was dual core. I thought it was triple or quad. Damn...  it is beating dual core Intel core series chips.

It all depends, I'd like to know what kind of wattage it's using in comparison to core-m chips?

[BuckGup]

It sucks when you see the 6s not far behind at all.