The Intel Atom Thread

Page 179 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

Exophase

Diamond Member
Apr 19, 2012
4,439
9
81
No :)

EDIT: you edited. No there's no big difference.

@Arachnotronic: it's unimpressive on all fronts, most of the integer increase comes from cryptographic benches, isn't it ironic?

Yeah, this is pretty embarrassing, I feel like every time I use the GB site I screw up something ;) I think I'm just going to leave it to other people now.

The comparison is actually kind of interesting, because it looks like the places where Broxton improves the best in integer are also some of the places where 64-bit has the biggest effect. There isn't really a lot to go on, but I wonder if this means that it's less sensitive to stack spills. IIRC one of Silvermont's (and presumably Airmont's) design weaknesses was that it could only service one load or store per cycle, while ARM CPUs have moved to load + store or wider. Moving to load + store would help a lot with register constrained scenarios.

I wonder if Intel is going to say anything at all about what they changed here...
 

Sweepr

Diamond Member
May 12, 2006
5,148
1,142
131
No :)

EDIT: you edited. No there's no big difference.

@Arachnotronic: it's unimpressive on all fronts, most of the integer increase comes from cryptographic benches, isn't it ironic?

Right, and you're basing this on the first and only Geekbench result out there, from an unknown model/system. It's entertaining to see how much you want Intel to screw up.

Broxton Pro (ES?) SiSoftware Scores

- Processor Arithmetic
Broxton: 29.88GOPS
Atom x7-Z8700 (average): 22.79GOPS
Core m3-6Y30 (average): 29.31GOPS

- Processor Multi-Media
Broxton: 54.84Mpix/s
Atom x7-Z8700 (average): 31.47Mpix/s
Core m3-6Y30 (average): 81.65Mpix/s

- Processor Cryptography (High Security)
Broxton: 1.83GB/s
Atom x7-Z8700 (average): 0.80GB/s
Core m3-6Y30 (average): 2.07GB/s

http://ranker.sisoftware.net/show_s...e3deeec8a09dad8bf3cefed8bdd8e5d5f380bd85&l=en

Being recognized as a Pentium II, just like Geekbench. 4C/4T 1.19GHz 2x 1MB L2.
 
Last edited:

dark zero

Platinum Member
Jun 2, 2015
2,655
138
106
Last edited:

Nothingness

Platinum Member
Jul 3, 2013
2,400
733
136
Right, and you're basing this on the first and only Geekbench result out there, from an unknown model/system.
Yes, that's exactly what I wrote: this result is unimpressive and as I wrote we should wait for non-ES results. But think what you want, the result we have doesn't look good for a chip that's one year late.

It's entertaining to see how much you want Intel to screw up.
Me wanting Intel to screw up? That's a funny one. I'm just not a blind fanboy, if you see (pun intended) what I mean.
 
  • Like
Reactions: Grazick

Exophase

Diamond Member
Apr 19, 2012
4,439
9
81
I wonder if Intel will update the optimization manual to include Goldmont. They've done it for the last several Core tocks including Skylake, and they've done it for the last major Atom uarchs of Saltwell and Silvermont. So I think they probably will. The Atom uarch descriptions thus far have been quite comprehensive.

On the other hand, the manual does refer to Broadwell while Airmont is nowhere to be seen, and I don't think it's a straight shrink.
 

nvgpu

Senior member
Sep 12, 2014
629
202
81
https://lkml.org/lkml/2016/4/15/467

http://www.intel.com/content/dam/ww...s-software-developer-vol-3b-part-2-manual.pdf

Updated April 2016 with some Goldmont references, nothing about architecture yet.

https://software.intel.com/en-us/articles/intel-software-development-emulator

  • Emulation support for the Intel® Secure Hash Algorithm (Intel® SHA) extensions present on the Intel Goldmont microarchtiecture.
  • Emulation support for the Intel® Memory Protection Extensions (Intel® MPX) present on the Intel Skylake microarchitecture and Intel Goldmont microarchitecture.
Goldmont even has features that isn't in any Core microarchitecture yet, Intel SHA extensions.
 

Thala

Golden Member
Nov 12, 2014
1,355
653
136
but I wonder if this means that it's less sensitive to stack spills. IIRC one of Silvermont's (and presumably Airmont's) design weaknesses was that it could only service one load or store per cycle, while ARM CPUs have moved to load + store or wider. Moving to load + store would help a lot with register constrained scenarios.

In this case x64 would not have a chance against Aarch64 anyway due to only having half of the architectural registers. So in scenarios, where x64 is already happily spilling, Aarch64 might not have to spill at all. Relying on 2 operand instructions does not help either here due to additional move instructions the compiler would have to insert. Note that register renaming does not save much in above scenarios.
I don't know how Intel will ever overcome the disadvantages in the ISA.
 

Exophase

Diamond Member
Apr 19, 2012
4,439
9
81
In this case x64 would not have a chance against Aarch64 anyway due to only having half of the architectural registers. So in scenarios, where x64 is already happily spilling, Aarch64 might not have to spill at all. Relying on 2 operand instructions does not help either here due to additional move instructions the compiler would have to insert. Note that register renaming does not save much in above scenarios.
I don't know how Intel will ever overcome the disadvantages in the ISA.

In this scenario we're talking about sensitivity in legacy 32-bit x86, so spills might not be present (or as bad) in x86-64.
 

mikk

Diamond Member
May 15, 2012
4,133
2,136
136
Oh I see, I didn't even see that part, sorry >_> I just looked at the OS version and assumed that referred to binary type. When you have it in compare mode it doesn't even list the binary type, it seems...

Here's a proper 64-bit one, I hope:

https://browser.primatelabs.com/geekbench3/5964263

It's pretty close.


And here we have another try from you with a 64 bit Z8700 score lol. Something is wrong with you. This is exactly the problem, comparing 64 bit (top notch) results with a 32 bit from Broxton, even if there isn't a big diffference. So why do you link to another x64 score??? Please give up, you don't understand the point.
 
Mar 10, 2006
11,715
2,012
126
I wonder if Intel will update the optimization manual to include Goldmont. They've done it for the last several Core tocks including Skylake, and they've done it for the last major Atom uarchs of Saltwell and Silvermont. So I think they probably will. The Atom uarch descriptions thus far have been quite comprehensive.

On the other hand, the manual does refer to Broadwell while Airmont is nowhere to be seen, and I don't think it's a straight shrink.

Here you go, changes to Airmont:

1ZntCGV.png
 

Exophase

Diamond Member
Apr 19, 2012
4,439
9
81
Here you go, changes to Airmont:

Thank you, I had never seen that. If anyone else is curious, it's from Intel's Hot Chips presentation: http://www.hotchips.org/wp-content/...pub/HC27.25.740-Atom-CherryTrail-Tu-Intel.pdf

At first I was confused and thought these were Goldmont changes, and didn't understand how such mundane changes could result in the performance differences we're seeing. But for Airmont this fits the benchmark results well.

On paper Silvermont actually looks a lot like Cortex-A9: dual issue, OoO ALU with relatively shallow ROB plus in-order memory and SIMD/FP, load or store per cycle, similar pipeline length etc. Given this I'd say Silvermont punched above its weight and did significantly better than Cortex-A9, maybe because of lower L2 latency and perhaps better branch prediction and prefetching.

For Goldmont I expect fundamental changes to load/store.
 

Exophase

Diamond Member
Apr 19, 2012
4,439
9
81
And here we have another try from you with a 64 bit Z8700 score lol. Something is wrong with you. This is exactly the problem, comparing 64 bit (top notch) results with a 32 bit from Broxton, even if there isn't a big diffference. So why do you link to another x64 score??? Please give up, you don't understand the point.

I understand the point, okay? I just kept making mistakes using their site. I didn't realize until after I posted it that it was the Broxton score that was 32-bit, not the Surface 3 one. I already addressed this and apologized afterwards. If the site didn't make it so hard to see what you're actually comparing against I wouldn't have this problem.

It didn't really help that you listed the binary descriptions in the opposite order from how you listed their respective links, where you put 64-bit first in one and 32-bit first in the other.
 

cbn

Lifer
Mar 27, 2009
12,968
221
106
You're implying Ubuntu phone is going to be basically a desktop computer in phone form-factor. I highly doubt that, especially with so many binary blobs that need to be taken care of. I think it will be closer to current Android x86 phones instead.

Some info on how Cannonical is working towards the convergence:

https://insights.ubuntu.com/2016/04/20/canonical-unveils-6th-lts-release-of-ubuntu-with-16-04/

Ubuntu 16.04 LTS adds new “snap” application package format, enabling further convergence across IOT, mobile and desktop

Ubuntu 16.04 LTS introduces a new application format, the ‘snap’, which can be installed alongside traditional deb packages. These two packaging formats live quite comfortably next to one another and enable Ubuntu to maintain its existing processes for development and updates.

The snap format is much easier to secure and much easier to produce, and offers operational benefits for organisations managing many Ubuntu devices, which will bring more robust updates and more secure applications across all form factors from phone to cloud.

Creating snaps is simplified for developers with the introduction of a new tool called “snapcraft” to easily build and package applications from source and existing deb packages. Snaps enable developers to deliver much newer versions of apps to Ubuntu 16.04 LTS over the life of the platform, solving a long-standing challenge with free platforms and enabling users to stay on a stable base for longer while enjoying newer applications.

The security mechanisms in snap packages allow for much faster iteration across all versions of Ubuntu and Ubuntu derivatives, as snap applications are isolated from the rest of the system. Users can install a snap without having to worry whether it will have an impact on their other apps or their system. Similarly, developers have a much better handle on the update cycle as they can decide to bundle specific versions of a library with their app. Operationally, transactional updates make deployments of snap packages more robust and reliable.

Snaps mark an important milestone in Canonical’s efforts to create a converged Ubuntu across IOT, mobile and desktop. Snaps originate from the world of IOT and “snappy” Ubuntu Core, marking the convergence of Ubuntu’s desktop and IOT efforts, and building on the introduction earlier this year of Ubuntu’s first tablet, which can be turned into a full PC. Supporting snap packages on Ubuntu 16.04 LTS unifies the experience for Ubuntu developers, whether they are creating software for PC, Server, Mobile, and IoT Devices.
 

Sweepr

Diamond Member
May 12, 2006
5,148
1,142
131
Broxton-P (HD Graphics) - Linux OpenGL Results

- Manhattan Offscreen
Broxton Pro: 72.3 FPS
HD 530: 43.4 FPS

- T-Rex Offscreen:
Broxton Pro: 194.0 FPS
HD 530: 104.1 FPS

https://gfxbench.com/device.jsp?ben...ype=GPU&hwname=Intel(R)+Broxton-P+HD+Graphics

The results are so impressive it actually makes me question if they really belong to Broxton. Perhaps there's something I'm missing here? Also, is it possible to determine the number of EUs from the info section?
 

dark zero

Platinum Member
Jun 2, 2015
2,655
138
106
I think that is a Atom X7 with 32 Mb of EDRAM. That is the only way to show up their worth.

Also seems that Broxton is having the Kabylake GPU based one and not the Skylake GPU based one.
 

IntelUser2000

Elite Member
Oct 14, 2003
8,686
3,785
136
I think that is a Atom X7 with 32 Mb of EDRAM. That is the only way to show up their worth.

Also seems that Broxton is having the Kabylake GPU based one and not the Skylake GPU based one.

Let's not be too hasty.

It could be that its finally taking advantage of FP16 fully?

Because in texturing performance its significantly behind HD 520.

If this is true though, they'll be competitive with the best in mobile at least in graphics.

Update:
Big texturing performance improvement between Iris 6100 and Iris 540. That suggests memory bandwidth plays a role, and Broxton-P is almost at half of HD 520 and as low as 1/4 of Iris 540. eDRAM not included.
 
Last edited:

IntelUser2000

Elite Member
Oct 14, 2003
8,686
3,785
136
I think that is a Atom X7 with 32 Mb of EDRAM. That is the only way to show up their worth.
Also seems that Broxton is having the Kabylake GPU based one and not the Skylake GPU based one.
Nope and nope.

1. eDRAM is on package with current products. That makes the package significantly larger. Also, the price addition is not as much due to die size, but the addition of it. Do we also believe that Intel will add $30 eDRAM to a $25 chip?

2. http://www.anandtech.com/show/10256/intel-unveils-apollo-lake-14nm-goldmont

Gen 9, same as Skylake, not Gen 9.5 or 10 as rumored for Kabylake

There's another possibility though. The rumor is that Broxton was going to have Wide I/O 2 memory. Of course looking at 2.5D HBM's difficulty in coming to products, and that WIO2 is supposed to be 3D(though 2.5D is possible) perhaps the delay of the SoC is attributed to it as well. That would somewhat justify being delayed until 2017.

Though can we believe Intel is competent enough to do that? I'm not sure.
 
Last edited:
Mar 10, 2006
11,715
2,012
126
Nope and nope.

1. eDRAM is on package with current products. That makes the package significantly larger. Also, the price addition is not as much due to die size, but the addition of it. Do we also believe that Intel will add $30 eDRAM to a $25 chip?

2. http://www.anandtech.com/show/10256/intel-unveils-apollo-lake-14nm-goldmont

Gen 9, same as Skylake, not Gen 9.5 or 10 as rumored for Kabylake

There's another possibility though. The rumor is that Broxton was going to have Wide I/O 2 memory. Of course looking at 2.5D HBM's difficulty in coming to products, and that WIO2 is supposed to be 3D(though 2.5D is possible) perhaps the delay of the SoC is attributed to it as well. That would somewhat justify being delayed until 2017.

Though can we believe Intel is competent enough to do that? I'm not sure.

Intel did in fact have a Wide-I/O 2 version of Broxton in the works, but it was likely axed.
 

IntelUser2000

Elite Member
Oct 14, 2003
8,686
3,785
136
Intel did in fact have a Wide-I/O 2 version of Broxton in the works, but it was likely axed.

Too bad it doesn't show memory configuration on GFXBench.

The game test results and the ALU results are excellent but the texturing results are not.

The results for the ALU seems to scale with EUs, but unless Broxton has 48EUs running 33% faster than Airmont GPU or so it doesn't make sense. The texturing result doesn't make sense if there's 48 EUs because then it should be comparable with Iris parts that have eDRAM, not be a fraction of it and be lower than Iris ones without eDRAM.

The T-Rex results seem a strength for Gen 9 versus Gen 8 when also compared with Manhattan.
 
Last edited: