Login

ARM The Architecture For The Digital World  

ARM Community: Embedded and Desktop - Similarities and Differences - ARM Community

Jump to content

Embedded and Desktop - Similarities and Differences

Posted Image
In case you missed the start of this discussion, my blog CPUs Have Been Doing GPU Computing Badly for Years started a dialog with Gary Smith who responded with Sub-Optimal Processing. Here is my response.

****er’s Law (name changed to protect the guilty)
It used to be said that the embedded space was about 7 years behind the desktop in the sense that technological changes tended to appear in (what was then) mainstream computing seven years before the embedded and mobile markets, but in many ways that isn’t true now. If we look at the innovations in OpenGL ES as compared to OpenGL for example, I think we can see that we’re at least on par in the graphics space. Where I think we’re well ahead of the game is in AMP systems. The average wireless SoC contains many processors (one high-end smartphone SoC I know of, was rumoured to have 12 different computational devices). These processors (and other computational accelerators) were by no means all from ARM, though I am obviously smug about the fact that about half of them were Posted Image . Energy consumption, thermal issues, and simple “can it be physically done?” practicality have made the embedded (and particularly the mobile) industry choose domain-specific solutions to computational problems where they make sense, and have found ways in which to make these heterogeneous systems (CPUs, different CPUs, GPUs, video processors, audio processors, DSPs and other obscure bits of compute accelerators to do baseband coding) work together in a co-operative way.

Embedded leading the desktop world?
A change away from the “one big CPU” story is increasingly coming to the desktop as well. The ”frequency wall” (and perhaps more importantly the power dissipation wall – dissipating more than 150W of heat is hard for desktop CPU manufacturers) means that there is little choice for them if they want to add better functionality. However, I don’t believe they are enjoying it. In the desktop hardware world, it is no longer possible to say “buy my new CPU - it goes faster, your software will run gloriously”, and in the desktop software world, the big software companies can no longer rely on regular boosts in CPU speed to help improve the software user experience. Hardware needs to go many-core, and software needs to be optimized and to be written for many-core systems. That will be hard (thus expensive), and therefore will happen more slowly than we might wish for.

CPU/GPU wars? No thanks
Would it be too bold of me to suggest that this is a continuation of business as normal for us? There’s lots of fuss about GPU Computing in the desktop space since there are very large companies with very large vested interests involved and it’s currently being talked about as being a war between CPU and GPU (for which read war between the big x86 CPU companies and the big GPU companies). Down here in the energy-conscious world, we’ve been picking the right device for computational workloads for some years now… Perhaps we can miss out on some of the hype? Or am I just being naïve?

Heterogeneous processing solved? Not Yet. CPUs will have a long life in our low power world...
OK, before someone pokes at the obvious hole in that, I’ll do it myself. We’ve been great at having separate problems done with separate heterogeneous processors (e.g. audio, video, graphics, comms). Where the problem comes is in taking the “general-purpose applications workload” and making that suitable for many-core (or even multicore). General-purpose CPUs have indeed served us very well over the years. They have long-life architectures, ecosystems (for which read tools that we poor programmers have understood, and made to work), and they enable programmers to build programs relatively easily that change people’s lives. I predict that general-purpose CPUs will have a long and useful life ahead of them – they just won’t be the only game in town any more…

Jem is an ARM Fellow and likes to think of himself as "The Godfather" to technical talent in ARM. After spending some time in his youth writing software for satellites and traffic-lights among other fascinating things, Jem spotted the technical inflection point of the mobile industry: graphics, video and other visual processing. As VP of technology in the Media Processing Division of ARM, Jem is busy with a lot of projects involving the future of cool ARM technology, which will revolutionise how people experience and interact with digital devices.

Shortlink to this post: http://bit.ly/dxIktm
All company and product names appearing in the ARM Blogs are trademarks and/or registered trademarks of ARM Limited per ARM’s official trademark list. All other product or service names mentioned herein are the trademarks of their respective owners.

1 Comments On This Entry

Please log in above to add a comment or register for an account

Page 1 of 1

GarySmith 

16 November 2010 - 12:10 AM
Jem,
I'm continuing the discussion with my new blog as well:

Optimize despite Amdahl’s Law:

Jem Davies and I have been having a running conversation on Domain Specific, or Application Specific microprocessors. There probably is a set definition for both terms but as they seem to be merging I’ll continue to call then Application Specific for now. Jem’s last blog (Embedded and Desktops – Similarities and Differences) reminded me of an Industry Note (our term for blog – it’s free) I was going to write last month. As expected my notes were lost in one of my piles on my desk.


Amdahl’s Law and Parallel Computing
I was at Synopsys, eighteen months or so ago, in a product review. They were introducing a parallel version of HSPICE. They gave some performance estimates that I replied were probably unobtainable. Amdahl’s Law came up and I pointed out that optimizing HSPICE would probably give them a maximum of four times speed up. If they were to reach the ten times plus they would have to rewrite HSPICE, from the algorithm down.

I’d love to take credit for that but as with most of what I pass on, that actually came from someone else, in this case Gene Amdahl himself. Patrick Madden invited Gene to talk at IC CAD 2007 and after the talk I was fortunate enough to be on a panel with Gene on the topic of parallel computing. At the end of the panel someone from the audience asked Gene how he could get around Amdahl’s Law. Gene’s answer was rewrite the algorithm.

It continues on my blog: http://www.garysmith...story=iNotes_83
0
Page 1 of 1
Maximise
Minimise
» 

My Blog Links

» 

ARM Onsite

» 

Search My Blog