ARM & Parallelism on the desktop: beyond SIMD

[Yossarian22]

With the advent of the mobile market we've seen a surge in computing technology especially with Smartphones.

Right now it is possible to run Netbooks with nothing but ARM, given the massively parallel nature of ARM SoC or development boards (separate processor/DSP for decoding video etc) for the given price point do you see parallel ARM competing directly with VIA, Atom, and Llano style netbooks and notebooks in the very near future?

Also take into consideration Windows 8, Tegra, Snapdragon but also on the flipside improvements to Atom's IGP (PowerVR) and things like Llano? (however I don't think these systems will ever occupy sub 20W space where ARM presently can, depending on end user need).

Are we seeing something very different here or what?

 

[Fenris_Ulf]

OS has always been the problem. Linux based netbooks never sold as well as MS based. Win8 may change that, the Win8 codebase and ability to run legacy software may be very compelling, depending on how well the ARM can handle it. The netbook platform seems to be splitting back into tablets and small notebooks. The netbook has lots of compromises that have become apparent. If you want to be a casual user, the tablet is probably better for consuming content and intuitive interaction. If you need to type or produce something, screen area, mouse, and good keyboard are needed.

 

[pxc]

Atom won't be doing much until the new architecture comes next year and then moves to 22nm. Power consumption and performance/W should be very competitive or better against high performance ARM processors when that happens. Great for netbooks and possibly tablets, but I doubt it will have much success in handsets.

Netbooks have been on the decline. There have been several attempts at making ARM based models at various price points over the years (since netbooks were first released) and all have bombed. ARM chips seem to be doing fine in tablets.

Even with a x86 processor, look at Chromebooks for some of the problems with alternative OSs. Lugging around a semi-functional device that costs the same as a general use small laptop makes little sense to most people.

 

[Cali3350]

OS has always been the problem. Linux based netbooks never sold as well as MS based. Win8 may change that, the Win8 codebase and ability to run legacy software may be very compelling, depending on how well the ARM can handle it.

I was under the distinct impression anything for Windows ARM would have to be recompiled explicitly, meaning you dont get legacy application support.

 

[Verge]

I was under the distinct impression anything for Windows ARM would have to be recompiled explicitly, meaning you dont get legacy application support.

Is this something they might be able to emulate however?



According to everything i've read, the windows8 for ARM is identical to x86 feature wise. It's literally a complete port.

 

[pxc]

According to everything i've read, the windows8 for ARM is identical to x86 feature wise. It's literally a complete port.

Intel has stated that Windows 8 for ARM is not backwards (or forwards) compatible with x86 software. MS has not disputed that. http://www.bit-tech.net/bits/software/2011/06/09/whats-coming-in-windows-8/2 If Windows 8 for ARM contains a full Windows API and full versions of .NET are ported over, it should be relatively easy to run .NET-based apps (Silverlight/XNA/etc) on both architectures. Very little existing commercial software is based on .NET.

It may be possible to emulate, but the speed would be slow for many applications (see DOSBox on ARM). Native API calls could run at close to full speed if the x86 emulator is smart, but there are still a lot of pitfalls. For example, the emulator would have to manage shared x86 components, registration and versioning since the ARM version of Windows can't. IOW, while possible, it's not really practical.

I do think it would be exciting if some future custom ARM processor added x86 emulation acceleration hardware. I'll be happy with a 1lb, 7" LCD handheld that can run full x86 apps. It's coming eventually.

 

[Yossarian22]

I do think it would be exciting if some future custom ARM processor added x86 emulation acceleration hardware. I'll be happy with a 1lb, 7" LCD handheld that can run full x86 apps. It's coming eventually.

We're close... minus the x86 emulation part. Any reason why you desire x86 emulation on ARM?

To quote Eben Upton about the Raspberry Pi:

It’s has a hardware OpenGL ES GPU. No figures on the older OMAP 3530, but a couple of data points to give you an idea

- 3x faster than an OMAP 4430 when rendering high-shader-complexity content
- can play Quake 3 timedemo at 1920×1080, 4xAA at 30-35 fps

So it’s basically an XBox 1 level of performance.

The main processor is a Broadcom 2763 (ARM11) and I think the attached DSPs and co-processors are based off of TI's OMAP stuff.

I guess what I was getting at with the OP: Are we dawning upon parallel computing a lot faster in the realm of not only ARM (where we have Cloud/thinclient computing making a come back in a sort of weird way) but also the fact that we're getting desktop grade parts with 6-8 cores built in.

It seems like we're running the race right into Amdahl's Law. Either single threaded applications are going to be chunked into vectorable instructions by the architecture/subsystem, the operating system, or at the application level.

Gazing into my crystal ball I see netbooks with 3-5 ARM systems inside as a parallel computing cluster
.
Well, if not on the OEM market, I shall build it.

 

[Yossarian22]

OS has always been the problem. Linux based netbooks never sold as well as MS based. Win8 may change that, the Win8 codebase and ability to run legacy software may be very compelling, depending on how well the ARM can handle it. The netbook platform seems to be splitting back into tablets and small notebooks. The netbook has lots of compromises that have become apparent. If you want to be a casual user, the tablet is probably better for consuming content and intuitive interaction. If you need to type or produce something, screen area, mouse, and good keyboard are needed.

You're probably right.
I'm a software engineer/CS student and I work with POSIX style operating systems.
There is definitely a learning curve should you want to do anything complicated however it has come high time for me personally to learn Linux to the full extent of an administrator. This includes having them as operating systems on my own machines.

It's very powerful but for the common user the functionality is far removed from what they're used to and what they expect.

But then again, we have things like Android and Ubuntu's new interface (whatever it is called) not to mention Windows 8 is coming to ARM.

The revolution will not be televised.

 

[defaultluser]

The revolution will not be televised.

Nah, it will be televised. People are not really going to ditch their TVs for handhelds: they like the immersion factor of a big screen too much. Handhelds offer flexibility and options to people who already have a TV and a computer.

In any case, the (soon to be) big three mobile internet providers have all but locked-out high-bandwidth mobile users (Sprint/Virgin is the only one left), so if the revolution is mobile-only, it's going to be restricted to Twitter

 

[Yossarian22]

Nah, it will be televised. People are not really going to ditch their TVs for handhelds: they like the immersion factor of a big screen too much. Handhelds offer flexibility and options to people who already have a TV and a computer.

In any case, the (soon to be) big three mobile internet providers have all but locked-out high-bandwidth mobile users (Sprint/Virgin is the only one left), so if the revolution is mobile-only, it's going to be restricted to Twitter

Oh, I'm totally not saying that. When I made the original post I was sort of in a sleep deprived daze.

The gist of what I'm getting at is both on x86 and the availbility and cheapness of ARM platforms due to the growing mobile sector is making us run head first into Moore's Law. After 18nm, where do we go from there?

But a-hah! At the architecture and OS levels we already have some support for parallelism.

I think that I see workstations for business employees being powered by small ARM cluster or a cluster of ARM processors on a chip, assuming 18nm Atom doesn't beat the hell out of ARM... but Intel will still have to factor in the costs of R&D whereas ARM based products are presently cheap.

So Worker Joe will be using ARM on his desktop is one of my predictions.

The next thing I see becoming big (and already is, sorta... at a slow pace) is parallel processing. We have OpenCL, we have CUDA, we have desktop processors with six cores... at some point in time a software engineer will have to start designing applications with parallel strategies in mind (if applicable, some problems are not solved very well via parallel processing).

 

[defaultluser]

Oh, I'm totally not saying that. When I made the original post I was sort of in a sleep deprived daze.

The gist of what I'm getting at is both on x86 and the availbility and cheapness of ARM platforms due to the growing mobile sector is making us run head first into Moore's Law. After 18nm, where do we go from there?

But a-hah! At the architecture and OS levels we already have some support for parallelism.

I believe you are confused. Moore's Law has nothing to do with clock speed and IPC. It states simply that the feature size of a transistor will halve every 24 months. It just so happens you could also (for a time) increase frequency and reduce voltage. Designers were dependent on this feature for far too long, and recently it just disappeared when the physics hit a brick wall.

If you suddenly hit a process wall, both single-threaded and parallel performance would stagnate. They are not exclusive - the multithreaded path is simply the least expensive.

I think that I see workstations for business employees being powered by small ARM cluster or a cluster of ARM processors on a chip, assuming 18nm Atom doesn't beat the hell out of ARM... but Intel will still have to factor in the costs of R&D whereas ARM based products are presently cheap.

Are you referring to the insane price gouging Intel pulls with their Xeon lineup? For a workstation the brand name makes no difference: businesses pay for the name because the people in purchasing are stupid.

Intel is perfectly capable of selling a fast 4-core processor for under $200. I guarantee that Arm won't be able to do much better.

So Worker Joe will be using ARM on his desktop is one of my predictions

No he won't. Anyone who actually does WORK on their PC needs the whole Windows/x86 software stack, and that's because of the TOOLS. Tool vendors are lazy assholes who will take forever to support new OS/Architecture/Feature, will charge you through the nose for new software, or they may close shop altogether. This means people who actually get real work done (designers, coders, testers) are stuck using software that's 5-10 years old to help support their product released just 3 years back. And since Windows ARM will NOT support x86 emulation, it's going to halve a helluva time getting tool vendors to port their stuff.

For the rest of the list (people who actually do not create anything), they're perfectly satisfied with the fast dual-core processor they already have. There's no upgrade market for ARM in that area, since you can already buy a desktop dual-core for around $70.

The next thing I see becoming big (and already is, sorta... at a slow pace) is parallel processing. We have OpenCL, we have CUDA, we have desktop processors with six cores... at some point in time a software engineer will have to start designing applications with parallel strategies in mind (if applicable, some problems are not solved very well via parallel processing).

I am a software engineer, and let me tell you, I would LOVE to wave my magic wand and make everything run in-parallel. I actually write multithreaded software for embedded systems, and the OS support is barely there (for example, VxWorks has only supported SMP since 2007). So, now your OS has SMP support right? Well, you need a whole new set of tools to manipulate the OS and to optimize your software, and as I indicated above these things take time.

 

[Yossarian22]

I believe you are confused.

No. It's just that the industry believes in Moore's Law but eventually you will be unable to shrink dies.

Intel is perfectly capable of selling a fast 4-core processor for under $200. I guarantee that Arm won't be able to do much better.

At price per unit/watt and maybe even MIPS? I dunno... If they could, they should, then they can just slay AMD's business model. Lord knows they have the money to do such.
Should, coulda, would.

No he won't. Anyone who actually does WORK on their PC needs the whole Windows/x86 software stack,

Why do I need Windows and since when was software a stack? Unless you meant a stack like burgers. I mean, x86 architecture has a stack and stack frames. Occasionally you push and pop things on there... l

and that's because of the TOOLS. Tool vendors are lazy assholes who will take forever to support new OS/Architecture/Feature, will charge you through the nose for new software, or they may close shop altogether. This means people who actually get real work done (designers, coders, testers) are stuck using software that's 5-10 years old to help support their product released just 3 years back. And since Windows ARM will NOT support x86 emulation, it's going to halve a helluva time getting tool vendors to port their stuff.

Possibly the only point where you're not aggressive and I agree with you.
Even though I use vim, gcc, and make.

For the rest of the list (people who actually do not create anything), they're perfectly satisfied with the fast dual-core processor they already have. There's no upgrade market for ARM in that area, since you can already buy a desktop dual-core for around $70.

Can I? Forgetting the peripherals (we'll assume they cost the same for ARM/x86_64) can I get a fully fledged computer for $70?

I am a software engineer

Me too.

...and let me tell you, I would LOVE to wave my magic wand and make everything run in-parallel. I actually write multithreaded software for embedded systems, and the OS support is barely there (for example, VxWorks has only supported SMP since 2007). So, now your OS has SMP support right? Well, you need a whole new set of tools to manipulate the OS and to optimize your software, and as I indicated above these things take time.

That's the overhead cost of complexity you have to pay is mindlessly sitting there seeing if your algorithm or code is able to be paralleled/vectorable (if it isn't already obvious that is is). Sort of like mindlessly sitting there looking at dumps trying to figure out where the abend happened (that's what MVS - OS/390 likes to call it when a job dies).

 

[Chilly]

Sorry, the desktop won't be running ARM for a long time, if ever.

What *MIGHT* happen is, almost exclusively in business, is their workstations might *USE* but not run on ARM. What do I mean? Thin-Clients. A Thin-Client running on an ARM processor(they already exist) connecting to a HyperV or ESXi or Xen back end, running Virtual Desktops ON the x86 platform. The other siuation that might happen aside from full on Virtual Desktops(XenDesktop, VMware View, RDP, etc) is in a VDI deployment is Windows 8 based Thick-Client used for basic programs(Office{Word, Excel, etc}), with RemoteApp or XenApp used for those "legacy" x86 programs(QuickBooks, Photoshop, AutoCAD, etc).

Partly because of the VDI/Cloud future, which ironically may drive ARM adoption up(but not in the way you say or think), it will also allow developers to continue coding its "enterprise-level" programs on X86, which will counter-balance and also limit ARM adoption.

The desktop will not run ON arm in the near or even distant future, not in any large sizable market share anyways. The exception is maybe Apple computers/desktops, but Apple changes CPU platforms all the time.

 

[defaultluser]

Yossarian22:

I now understand your viewpoint because you are working on some form of *nix, where ARM support is (mostly) just a compile away (even better if your target OS is the same as your dev environment). While there is a sizable contingent of *nix developers, they are outnumbered by developers who use Windows as their dev environment. I'm developing for PPC VxWorks on Windows, so it's quite a mess

Why do I need Windows and since when was software a stack? Unless you meant a stack like burgers. I mean, x86 architecture has a stack and stack frames. Occasionally you push and pop things on there... l

You don't need x86 or Windows. But there are a lot of developers who DO...there are a lot more Windows devs than *nix can claim.

The software stack I emphasized is important on Windows because the new ARM versions will NOT feature any x86 emulation. This means you have to make a clean break with all your tools ported to ARM or .NET, and this is a difficult undertaking because most Windows tools are still not written in .NET. And as you've agreed, the tool vendors can take their sweet time supporting a minority platform like ARM.

Unfortunately, we don't have the source, so there's nothing we can do

No. It's just that the industry believes in Moore's Law but eventually you will be unable to shrink dies.

First: when we cannot make die sizes any smaller (reached the end of Moore's Law), there will be no more performance gains PERIOD (until we develop something new). I got the impression from your original post that you seemed to think parallel performance could continue to grow in this situation, and that's just not possible. Without die shrinks you cannot increase parallel or single-threaded performance.

At price per unit/watt and maybe even MIPS? I dunno... If they could, they should, then they can just slay AMD's business model. Lord knows they have the money to do such.
Should, coulda, would.

People make more of this issue than they should.

The only difference between ARM and x86 is the decoder stage, and the decoder stays mostly the same unless you need to feed some massively-increased instruction thoroughput. FYI: the decode stage has really only been massively revamped once by Intel in the last 15 years: when they added a fourth decoder to support Core 2's massive performance improvement.

Every time you shrink the decoder stage, it becomes less and less of a percentage of total processor die area and power consumption. You can see this in the history of x86 RISC: first it was the desktop processors that consumed competitive amounts of juice, and then it was the notebooks (10w or more you will not notice the added power of the decoder). Now the only holdout is the sub watt market, and Intel is almost there. Once they hit 22nm Atom should be competitive, and there's a roadmap to push the architecture down to 14nm.

The only real problem Intel has is their unwillingness to customize dies for OEMs, but they will learn and change or they will die. I don't expect Intel to give up that easily, so I expect much competition.

 

[Yossarian22]

The only real problem Intel has is their unwillingness to customize dies for OEMs, but they will learn and change or they will die. I don't expect Intel to give up that easily, so I expect much competition.

That's probably the main advantage of ARM, you see ARM processors with other DSPs or other ARM processors to do specific tasks. It's probably also the main crutch. Can't get DSP/video decoder/GPU x because it is proprietary and only packaged with Product X.
Documentation and API are sparse and not well written.

In terms of portability, I thought Microsoft was making a big splash with .NET and of course there is always Java. Lots of just-in-time compile with bytecode. I don't follow .NET and I never have used it, so, I dunno.

Granted, there is a lot of legacy code out there and I haven't imbibed the Kool Aid but in a GNU environment there is literally multiple replacements for every single Windows tool. Except maybe (better) access to Directx API.

Software portability doesn't even have to be a discussion. Google and other companies are pushing their "cloud" technology (taking us back to 1970s). Hell, there is even a service that lets you play games over the "cloud" on your crap netbook or smartphone. This has the prerequisite of fast internet. Something America doesn't have in any particular quantity, sadly.

 

[UnknownSouljer]

There are a lot of distinct back and forths happening in this thread, but just to add something else: there has been a persistent rumor that Apple will build an A6 based laptop. A6 being a licensed ARM architecture like the A4 and A5.

http://www.slashgear.com/apple-a6-macbook-air-by-2013-says-analyst-os-x-and-ios-to-merge-03169286/

 

[jimmyb]

First: when we cannot make die sizes any smaller (reached the end of Moore's Law), there will be no more performance gains PERIOD (until we develop something new). I got the impression from your original post that you seemed to think parallel performance could continue to grow in this situation, and that's just not possible. Without die shrinks you cannot increase parallel or single-threaded performance.
[...]
The only difference between ARM and x86 is the decoder stage, and the decoder stays mostly the same unless you need to feed some massively-increased instruction thoroughput.

Pretty much everything you've said here is false.

 

[Yossarian22]

There are a lot of distinct back and forths happening in this thread, but just to add something else: there has been a persistent rumor that Apple will built an A6 based laptop. A6 being a licensed ARM architecture like the A4 and A5.

http://www.slashgear.com/apple-a6-macbook-air-by-2013-says-analyst-os-x-and-ios-to-merge-03169286/

Not surprised. Still going to be overpriced for what it is, though.

 

[Fort_Major]

Intel has stated that Windows 8 for ARM is not backwards (or forwards) compatible with x86 software. MS has not disputed that. http://www.bit-tech.net/bits/software/2011/06/09/whats-coming-in-windows-8/2 If Windows 8 for ARM contains a full Windows API and full versions of .NET are ported over, it should be relatively easy to run .NET-based apps (Silverlight/XNA/etc) on both architectures. Very little existing commercial software is based on .NET.

Correct. .NET/Java/Silverlight/Flash/Web will be the biggest winners in terms of available software crossing the gap with Windows 8.

Native/Legacy applications all are compiled to x86 by default.

With the API being on PAR if Microsoft ships a vNext or (the next edition of VS with a compatible ARM compiler) it might be semi-trivial to port your codebase to ARM. But the conversion should be taken as lightly as porting an existing code base from x32 to x64 which tons of companies still have unsuccessfully not done today.