I can hardly wait for another crappy Intel chip.

So what, you'd rather have a lower quality and performing AMD or a extremely low performing ARM chip? Whether you like it or not Intel is top of the line right now and has been the whole time except for their NetBurst years. It could even be argued that Intel was still top of the line while they were using NetBurst because their chips weren't melting down like AMD's were at the time.

wow you really made a lot of assumptions there.... must be a sensitive soul.

I would rather just have my current generation Intel rather than pay to upgrade to a model that will show 2-3 percent real world performance boost.

Whether YOU like it or not.... I'm not buying that chip.

And how pray tell does that make it "another crappy Intel chip"?

I don't pray. I'm not religious.

autistics and psychopaths are missing that brain parts thats the reason they were handling the doors at extermination camps with Lenin, Mao Zedong and Hitler.

>acutally believes that hitler had extermination camps

The Cherry Trail Geekbench ST number is 990.
Compare with the A8X at around 1800. Even the much-maligned A57 hits around 1500.
There's a low performing chip when we compare ARM to Atom; but I'm not sure it's the chip you think it is...

But yeah, yeah. Next year Goldmont fabbed on 10nm, using special Intel 4-dimensional transistors based on unobtainium and flux capacitors will be more awesome than we can possibly imagine. We've heard this song since before Atom was introduced; believe me we know all the words.

have an ultrabook i7 haswell
it's a literal fucking house fire

10% faster than an AMD chip but 250% more cost.

That's an overexaggeration. But in any case if speed and reliability are what's important to you (I don't know why they wouldn't be) then Intel's for you.

Looks like they have applied all the supposed savings of the 14nm process to the power side (although it seems weird to me to not keep the same thermal envelope and improve the performance, as the others SOC manufacturers usually do).

Even without any modification on the CPU core, the transition to this process is supposed to provide around a 30% improvement in performance (even the CPU clock has increased a 20%, going from 1,3Ghz to 1,6Ghz on the benchmarked SOCs, but they only result on this very modest 5%-8% improvement in performance, this means the IPC has gone down). Like their so much advertised Core M, this processor also fails to impress, maybe their famous 14nm FinFET process, as good as it looks on paper, is not near as effective and mature as they want us to believe.

The overtake of the mobile market they have been promising for the last five years seems will have to wait for next year, as per usual. :-)

I think at this point it's fairly safe to say that they're still having process issues in some form or fashion. Whether they've had to 'tone down' their designs in order to uplift yields or the uArchs themselves are very conservative in order to better utilize the process, is up for debate. What is quite clear is that Intel is going to have to extend their contra-revenue scheme throughout 2015, if they're going to maintain or extend market sharea.

How does this compare to the latest ARM processors from an energy and cost standpoint? Can anyone shed some light on this?

Not very good AFAIK, the latest ARM cores (Apple Cyclone, nVidia Denver, ...) have already achieved the performance of entry level Intel's desktop cores at much lower power consumption, leaving behind Atom BayTrail (and looks like this new Atom won't change that).

http://www.extremetech.com/...

Tegra K1 is using ARM based cores designed for mobile devices, thus uses way less power than an equivalent desktop CPU cores. However Tegra K1's single thread performance (per core) is still much slower (by 2x) than a lowly desktop Celeron G1820 chip: http://browser.primatelabs.... (versus highest Shield tablet score found). Tegra K1 uses all 4 slower cores combined to generate that multi-core score. And that single thread performance also isn't very far from Cherry Trail's (by about 23% with 56% higher frequency). Performance of mobile CPUs have limits, typically frequency and thermals. Clock-to-clock, the desktop CPU core is about 2x faster or more. For Tegra K1 core to catch up to that desktop Celeron core, probably will need twice the frequency (around 4.6GHz to 5GHz) which is unrealistic...

The previous generation Tegra4 although using ARM based cores is actually slower than Cherry Trail: http://browser.primatelabs.... and that Tegra4 has higher frequency as well...

There are two models of Tegra K1. The one in the Shield Tablet uses a Cortex A15 quadcore, indeed, but the Tegra K1 in the Nexus 9 uses a Denver dualcore.

Comparing the Denver cores here: http://www.notebookcheck.ne... the desktop Celeron per core is still around 45% faster with only 17% frequency advantage. Multi-core wise the desktop Celeron is 52% faster. Thus still behind a lowly desktop Celeron (not even comparing to the entry level desktop Pentiums or Core i3 yet), and also behind Bay Trail and Cherry Trail. Furthermore the power consumption is much higher also, at 9.2W which is way higher than most mobile SoCs including Apple's A7, Intel's Bay Trail and possibly Intel's Cherry Trail also.

Please don't cheat, 9,2w is the power consumption of the whole tablet at full load.

Besides, the Tegra K1 comes with the biggest GPU on any mobile SOC (a GPU the Celerons can't only dream of). That's by far the lion share of the K1 consumption. Denver are in-order CPU cores, so they only need an small poer supply.

Sorry, I'm on the phone, but when arrive home I'll link you benchmarks that put it on par with several Celerons.

Of course I know its the whole tablet, because they could not measure it at the SoC level. Example review of Z3795 here: http://www.notebookcheck.ne... and this chip has the same 1.6GHz frequency as the Cherry Trail benchmarked device. Quotes...

"The extremely low full-load consumption seems almost more impressive: who would have thought a couple of years ago that you could run a Windows computer with a maximum 5.5 to 8.9 Watt?"

That is still lower than Tegra K1 with Denver dual cores. Mobile SoCs typically do not have the performance of big desktop cores, such as that Haswell based Celeron G1820 (also a dual core). Do beware that there are also Bay Trail based Celerons which are not big desktop cores (these are soldered to the board, typically for low power mini PCs).

No they aren't. ARM changed to being all out-of-order with A53. You'd have to be an idiot to chase performance in in-order cores. You will never tune the assembly well enough on your own, especially with cores managing multiple threads.

ARM has hit a brick wall on performance gains without adding a lot of heat. They must either push clocks or greatly improve the branch predictor. Both will produce a lot of extra heat. Barring that ARM requires more process shrinks. Intel meanwhile is pulling laptop-level performance all the way down to fanless tablets now. It won't be long before we have tablet performance in a phone.

Wow, color me impressed, you have no idea what you are talking about here. Cortex-A53 are in-order cores, and ARM have been building out-of-order cores for years (Cortex-A57, Cortex-A17, Cortex-A15, Cortex-A9, ...).

Check your facts.

No one worth mentioning implements it in-order. ARM's vanilla cores are tweaked even if not wholly redesigned before implementation. The only exceptions to this are initial releases when everyone wants a new chip and new flagship phone out the door on the double.

Cortex-A53 can only be implemented in-order, Sherlock, (Cortex-A57 is the out-of-order high-performance ARMv8 vanilla core).

I already told you, get your shit togeather and check the basics before further embarrassing yourself.

I know the basics and the advanced. Our computer engineering department has samples of each. Both Qualcomm and Samsung implement the A53 design out-of-order to get better performance, and they use their manufacturing techniques to keep it in the same TDP and power usage. No one, and I mean no one worth mentioning, implements ARM's cores as-written by ARM.

Your stubbornness is being truly ridiculous.

http://www.arm.com/products...

Check Specifications, Microarchitecture Features.

The Cortex-A53 cannot be implemented out-of-order. Qualcomm and Samsung implement both, the Cortex-A53 (in-order) and the Cortex-A57 (out-of-order) cores, in a big-LITTLE structure (switching tasks from one to the other per demand).

Here you have deep technical reviews of both their last SOCs.

http://anandtech.com/show/8...
http://anandtech.com/show/8...

These are just the basics, do a favor to yourself and learn it.

You will probably also find useful to learn the parts of a SOC. Everybody implements the vanilla ARM cores exactly like ARM has designed them, is the uncore of the SOC what they tweak and customize (buses, caches, memory manager, GPU, communications, etc. ... ... ...), except of course when they use their own cores instead of ARM vanilla cores (cyclone cores, denver cores, krait cores, ... ...).

Seriously, you have a lot to learn. Take a walk to your engineering department and ask them to explain it to you.

Any in-order design can be implemented out of order and vice versa (though you do lose performance going the other way). Seriously, who taught you computer engineering?

I've read those reviews and know the performance of the chips intimately. You're still mistaken.

Custom cores are designed with almost 0 basis in ARM's designs. Changing the scheduler to be out-of-order and providing a re-order engine while leaving everything else in tact does not qualify as a custom core, but if you dive into the Qualcomm Snapdragon 801 you'll find all 8 cores are out of order. The big difference between the sets of 4 is clock rates to provide low-power options when the big guns aren't needed.

My computer engineer friends are sitting here laughing at you, because you're completely misrepresenting reality.

You are clueless, let your computer engineer friend read the whole thread and you'll see him really laughing.

Snapdragon 801 is not an octocore, genius, is a quadcore. It uses 4 Krait old cores (custom Qualcomm 32 bit cores). And Krait cores are known for dynamically changing its clock rates, not for working at two different clock presets.

https://www.qualcomm.com/pr...

But current high-end Qualcomm SOC is the Snapdragon 810 (64 bits), which uses vanilla ARM cores : 4 Cortex-A53 in-order low-performance low-power cores and 4 Cortex-A57 out-of-order high-performance high-power cores, in big.LITTLE architecture.

I was obviously talking about the Snapdragon 810 (and I linked it to you). If you have read the reviews I have previously linked you'll see they use in-order and out-of-order cores. Lets see an small quote of those reviews :

It is in the context of this fundamental problem that big.LITTLE came to be. While there are multiple solutions to solving the power problem that comes with OoOE, ARM currently sees big.LITTLE as the best solution. Fundamentally, big.LITTLE seeks to use in-order, low power processors for the vast majority of computing in mobile, but switches tasks to big, out-of-order processors when a task is too much for the little cores to handle. In theory, this seems to be the ideal solution as it makes it possible to retain the power-saving advantages of in-order cores and the performance advantages of big OoOE cores.

You are the worst kind of ignorant, your are the kind of ignorant who refuses to learn. Read for once the documentation that people proportionates you and you may change that. And please, check your facts (you would avoid embarrassing yourself saying the Snapdragon 801 haves 8 cores).

I invite you to locate a single reference on Internet of a Cortex-A53 core implemented with an out-of-order execution. It can't be done, genius, it wouldn't be a Cortex-A53 anymore.

I have read the documentation and I've done the testing. ARM's solution was supplanted by better chip designers. Did you know you can also have both clusters of cores simultaneously processing the same or different workloads? It's an octal-core in the purest sense of the word. Just because all 8 cores are not of the same size and strength doesn't make it a quad-core.

I've actually done the testing. They're both out-of-order as implemented by Qualcomm. They aren't vanilla cores, and anyone claiming otherwise clearly never did the work to prove it.

For God's sake, you are confusing everything. The Snapdragon 801 is a quadcore, the Snapdragon 810 is the one that is a octocore.

The Snapdragon 801 implements 4 custom cores (Krait).

https://www.qualcomm.com/pr...

The Snapdragon 810 implements vanilla ARM cores (4 Cortex-A53 + 4 Cortex-A57)

https://www.qualcomm.com/pr...

(Move down to the specifications and read the CPU section)

No, the four Cortex-A53 cores are not out-of-order.

http://www.arm.com/products...

You said that no one implements the Cortex-A53 with an in-order pipeline. But the truth is that all Cortex-A53 are in-order and can only be in-order (we would be talking of an entire different core if it were out-of-order).

Just Google for Cortex-A53 + in-order, and also google for Cortex-A53 + out-of-order

You'll see how every Cortex-A53 is an in-order core, and you cannot find a single implementation of it out-of-order.

I'm getting tired of this, I will no longer answer if you don't supply links to your preposterous claims (good luck trying to locate an out-of-order Cortex-A53).

that was a typo. Sorry, late night. I meant the 810.

I know in vanilla form ARM has the A53 designed as in-order, but it's a trivial thing to change, even though mastering OoOE is not.

You can find them out of order both on Samsung Exynos and Qualcomm 810 processors.

Sorry but you are wrong in that. Qualcomm 810 and Exynos Octa have not out-of-orders A53. They have in-orders A53 and out-of-orders A57.

Anandtext analysis of Snapdragon 810

http://anandtech.com/show/8...

It is in the context of this fundamental problem that big.LITTLE came to be. While there are multiple solutions to solving the power problem that comes with OoOE, ARM currently sees big.LITTLE as the best solution. Fundamentally, big.LITTLE seeks to use in-order, low power processors for the vast majority of computing in mobile, but switches tasks to big, out-of-order processors when a task is too much for the little cores to handle. In theory, this seems to be the ideal solution as it makes it possible to retain the power-saving advantages of in-order cores and the performance advantages of big OoOE cores.

Anandtech analysis of the latest Exynos

http://anandtech.com/show/8...

As with A7, A53 is an in-order design, which in some ways makes it the more interesting of the two ARMv8 designs out of ARM. While A57 gets a comparatively huge die size and power budget to implement high performance features, A53 gets little power, little die size, and ultimately has to get whatever performance it can out of in-order execution. With out-of-order execution being prohibitively expensive in die space and power for A53, this puts ARM in the position of trying to optimize an in-order design as far as they can, explicitly without making the jump to Out-of-Order Execution (OoOE)

TehcReport analysis of the latest Exynos

http://techreport.com/revie...

The A53's microarchitecture borrows heavily from the Cortex-A7 before it. The A53 can issue two instructions per clock cycle, and instructions execute in program order.

Tom's Hardware analysis of the Snapdragon 810
http://www.tomshardware.com...

The other CPU core in the big.LITTLE set is the Cortex-A53, which buildson the Cortex-A7 architecture. Where the A57 is a complex out-of-order core designed for high performance, the A53 is a very simple in-order core optimized for low power.

....
....

....

You can read any analysis and you'll see that the Snapdragon 810, as the Exynos, they implement vanilla Cortex-A53 cores and vanilla Cortex-A57 cores.

You are wrong, changing the A53 core to out-of-order is not a trivial task, you would have to practically re-design the whole core, and nobody has done it or intend to do it (they design their own custom cores if they don't want to use ARM vanilla cores: Qualcomm Krait, Apple Cyclone, nVidia Denver, ... ...).

As I already told you, you won't find in the whole Internet any prove, evidence or even indication of out-of-orders Cortex-A53. They don't exist, it can't be done (it wouldn't be a Cortex-A53 anymore).

Look for it and show me a single reference of them.

I've actually tested a number of A53 implementations. You can mathematically prove they execute out of order with cycle counting. It's tedious but it can be done.

Very interesting, but how have you proved that ?. The Cortex-A53 is 2-wide, it can issue two ops per cycle. Being in-order it needs good compilers to put the code in a form that allows the processor to issue as many parallel instructions as possible (while an out-of-order can rearrange them on the fly by itself).

My point is that an in-order A53 already issues more than an instruction per cycle (being 2-wide). So how can you know from a test execution only that the parallelism in its execution is due to an out-of-order engine or of a good compiler ?. How do you differentiate them ?.

Don't you think that Qualcomm and Samsung, .... would have said it if they have implemented theirs Cortex-A53 with out-of-order pipelines ?.

Every single report, review, announcement, ... out there reports them as vanilla in-order cores. Against that we only have your word, I'm sorry but we need something more, please show me a single link suggesting the possibility that Snapdragon 810 or Exynos have implemented out-of-orders Cortex-A53.

When you know all those specs (including pipeline count) you can design worst-case scenarios including plenty of data hazard, branch hazards, etc. to prove it isn't executing in-order. If it was, even with a branch predictor (and ARM's is in the mid-40% accurate range, one of the main reasons its heat stays down) you can run a 100,000 unit experiment and show it's simply unreasonable to think it's in-order (about 1 in a couple quadrillion chance).

Why bother with a compiler? Do the assembly by hand. You only need a couple hundred cycles worth of instructions, and then just attach the function name into a loop in a C file (modular compiling/linking FTW).

Lattepanda single board PC with full window 10 half size of an iPhone running Intel Atom Cherry trail .

There is a higher Cherry Trail benchmark result, with proper model number "Intel Atom x7-Z8700": http://browser.primatelabs.... Can be compared to an equally clocked 1.6GHz Bay Trail Z3795 chip: http://browser.primatelabs.... The odd result is actually due to the memory. Otherwise everything else is higher than the previous generation.

Not a very flattering benchmark either, the single core performance is worst than on BayTrail, and the multicore improvement is very small. This only seems to confirm that the Intels' 14nm process seriously fails to deliver its promises.

Did you look the the memory scores in my link posted? The memory scores were lower which contributed to the overall score, including the single threaded one. That is why this article mentioned...

"Memory performance is a bit of a wash, but this could be caused by either an early chip rev or slower memory."

This is only an hypotesis, there are other possible explanations, like a weaker cache subsystem, ... That's the problem with engineering samples, too much unknown variables. For all we known it could have used a huge active cooling to mask throtling.

We will only know for sure when it arrives to final devices, but meanwhile you have to admit that this is disappointing, I'm pretty sure you also expected much better. It doesn't lives up to the huge hype they created around the 14nm node.

You're a twit to think Intel of all companies is cutting corners on cache when trying to break into a space on merit.

Also, Cherry Trail is still only a Bay Trail process shrink. New chips on the 14nm process are the real thing to wait for. Intel tick-tocks all of its architectures. No one expects a giant leap just on the tick (process shrink).

"Atom x3, x5, and x7. According to Intel, these will be roughly synonymous with the Core i3 / i5 / i7 distinctions, with the Core i3 being marketed towards basic day-to-day smartphone or tablet use, the x5 family offering solid midrange performance," I believe you intended to say x3 for smartphones and tablets not i3...

Yeah, because the code names in the i3 / i5 / i7 branches have definitely not exploded and are absolutely not confusing today !

"It’ll still be some time before the company’s 14nm modem technology is ready for integration into its own SoC"

Intel has 14nm modem technology? Are you sure? I was very much under the impression we don't have SoFIA chips on 14nm until the LTE 2 and MID is because the modem technology they bought from Infineon is still not on 14nm yet, so they had to make it on TSMC's 28nm.

Only in 2016, with LTE 2 and MID, will SoFIA be on Intel's 14nm, and I'm pretty sure (not positive though), that is because all the former Infineon technologies are not available on 14nm, yet.

Right. It'll be some time. Meaning it'll be late this year or into 2016 (I couldn't find a specific timeline for when the hardware will be ported) but they have said they'll do a 14nm modem.

Here is a much newer and higher Cherry Trail benchmark result, this time with proper model number "Intel Atom x7-Z8700": http://browser.primatelabs.... Compared to an equally clocked 1.6GHz Bay Trail chip: http://browser.primatelabs....

Additionally, some videos of possible Sofia 3G chips here: https://www.youtube.com/wat... and https://www.youtube.com/wat... and https://www.youtube.com/wat... These actually use ARM cores, instead of x86 cores.

Thank you for the data points. This isn't dramatically different from what we see in the first results, bearing in mind that device thermals can play a huge role in performance comparisons like this.

It looks like Cherry Trail is sitting at peak clock for longer based on its multi-core perf, and some of the tests are better, but I think 6-10% is still a reasonable projection.

With transistors packed more closely/tightly at smaller process nodes, thermals can be a problem. Hopefully those memory issues will get sorted out before release...

No VESA's Adaptive Sync in this? This must be really REAAAAALLY budget... I wonder if the i3/i5/i7 line has VESA's Adaptive Sync....

Anything with eDP has adaptive sync. Please get your foot out of your mouth.