Startup Wants To Put 64-Cores In Your Smartphone

angry tapir writes "Startup chip design company Adapteva has announced the multicore Epiphany processor, which is designed to accelerate applications in servers and low-power devices such as smartphones and tablets. The RISC-based processor is scalable to thousands of cores on a single chip, and can sit alongside CPUs to provide real-time execution of diverse applications. Epiphany chips are currently scalable up to 64 cores in smartphones and up to 4,000 cores in servers. The processor can accelerate tasks like hand gesture recognition, face matching or face tracking, but is not designed to be a full-fledged CPU."

Comments

a toaster oven

[roman_mir]

I wonder what good it would do them if they stick their toaster oven into my Nokia 6303c?

Re:a toaster oven

[syousef]

I wonder what good it would do them if they stick their toaster oven into my Nokia 6303c?

You have 64 cores. That's gonna run much hotter than a toaster oven....though probably not for long enough to make toast.

Re:a toaster oven

[timeOday]

Nah, the total number of transistors in those 64 cores is probably a small fraction of the transistors in one modern CPU - more like stream processing units in a GPU (a GPU has several hundred).

Modern CPUs use huge numbers of transistors for small increases in speed, so there's no question such a chip would be much more efficient for tasks that fit it - again, like GPUs.

Re:a toaster oven

[drewm1980]

They are targeting 1 Watt mobile applications to start with. For reference, a high-end gpu these days is ballpark 500W.

Re:a toaster oven

[Jeremy Erwin]

Some multicore CPUs can shut down unused cores to save power. I imagine that if such technology is not thoroughly encumbered by patents, the Epiphany might be able to do the same thing.

Re:a toaster oven

[Jeremy Erwin]

Totally different architecture.

Re:a toaster oven

[c0lo]

I wonder what good it would do them if they stick their toaster oven into my Nokia 6303c?

Speaking of Nokia, in the near future, they may need to! Coding in C# won't necessary result in low power footprint apps, I imagine.

Re:a toaster oven

[bondsbw]

Architecture doesn't really matter. It only matters how many transistors and electrical components are in use at once. Considering the efficiency of modern CPUs in pipelining and branch prediction (and probably even better stuff since the last time I've heavily studied CPU architecture), I'd venture to guess that the number of transistors active at any moment is reasonably close to the number of transistors available.

Re:a toaster oven

[cheater512]

What do you mean? My deep cycle lead acid battery keeps my low powered C# mobile apps running for hours! It only needs a recharge once or twice a day.

Re:a toaster oven

[hamster_nz]

Like a Quadro 6000 (204W) or a GTX 580 at (244W)

  Even the bleeding edge GTX590 is under 400W...

Re:a toaster oven

[Jeremy Erwin]

This article implies that the 16 core adapteva system on a chip has 40 million transistors-- slightly less than an Atom.

The RV870 has 2.2 billion transistors, not all of which are used for the chip's 1600 stream processors.

Re:a toaster oven

[Jeremy Erwin]

RTFA.

A chip running at 1GHz with 16 cores can consume less than 1 watt of power, Olofsson said.

Re:a toaster oven

[Molt]

The 5xx series has been moderately well-behaved on the power-usage, but other fairly recent generations have not been so kind. The GTX480 could pull 450W and the GTX295 would happily use 487W (Stats from Tom's Hardware), and from that I'd say that a ballpark of 500W is fair enough, after all the 6xx series could well be very different from the 5xx series and so again have increased power usage.

I'm impressed

[colinrichardday]

That's a lot of cores for a smart phone.

Re:I'm impressed

[$RANDOMLUSER]

Yeah. With that many cores, you could have TWO websites that use Flash open at the same time!

Re:I'm impressed

[Penguinisto]

Only question is, how much can you burden each core?

After all, you could have a bajillion cores in a chip, but if each core in it can only handle one-bajillionth the load of a single-core x86 or PPC chip, then where's the advantage?

Re:I'm impressed

[Anonymous Coward]

Parallelism is only good for certain applications though, not everything can be decomposed so simply and/or programmers still lack the skills to make quality highly-parallel applications.

Re:I'm impressed

[DigiShaman]

Bullshit! Will never happen. Flash calculates Pi to infinity. Find that subroutine, and we will have solved the Flash performance problem.

Re:I'm impressed

[errandum]

just imagine the concurrency nightmare of 64 threads/processes working at the same time. The overhead for controlling such a thing would be so large that you'd waste more time synchronizing everything than the one you saved (I bet).

Re:I'm impressed

[Rockoon]

Most parallel problems can be defined in terms that require no locks within the inner loops, such as the class of problems mentioned in the grandparent (image recognition..)

I find that people that dont know shit about algorithms always think that the "hard" parts of parallel strategies somehow magically apply to most highly parallel problems... which is stupid.. but there you are.

Don't bother replying until you have mastered a functional language to the point where the reason I am asking you to master one dawns on you.

Re:I'm impressed

[TheRaven64]

This is not an advantage. Rule number 1 of parallel programming: It's easier to run a parallel task on a serial processor than it is to run a serial task on a parallel processor. This is why we haven't had multicore chips until recently: one core that's twice as fast lets you do more than two cores. It's only when building one core that's twice as fast becomes hard that adding more cores looks interesting.

Re:I'm impressed

[errandum]

Honestly, where did this come from?

Not saying I have mastered, but I did study concurrency in two separate courses, which I actually enjoyed.

Obviously, most applications will not falter if you don't care about it. But then you'll start using semaphores (be it POSIX or simply java's synchronize, for example) and things will halt. They will halt because your very weak cores will be running one at a time and context switching will be needed.

Yes, I know there are many things that don't require any kind of concurrency. I also imagine that this would be ideal for running a highly scalable web service for example (in this case, with 4000 cores, the load could be effectively spread between them - assuming you used 1 thread/process per request).

My initial point was: Concurrency with weak single cores WILL slow you down to a crawl because each core seems to be extremely slow. That's it.

Re:I'm impressed

[Coren22]

How about many serial tasks? On my phone, I have Pandora, Google Navigate, and several background processes. Each of those single apps could be multithreaded. The benefit of multicore isn't always on a single application.

Re:I'm impressed

[hattig]

Well the eetimes article says they have achieved 25GFLOPS/W on their 65nm 16-core testbed running at 1GHz. This is using regular C apparently.

To compare, an AMD Zacate processor at 1.6GHz with 80 shader cores can get similar results, but in 18W on 40nm. And you have to use OpenCL, not regular C, although the tools will be a lot better at auto-parallelising.

Their aim is 50GFLOPS/W, and they're planning a shrink to 28nm where they expect to use a quarter of the power, or 100GFLOPS/W. I presume the 28nm design will be a 64-core design in around 160m transistors.

However they need to license the end design to ARM SoC manufacturers if they want to get into mobile devices. Or maybe get bought by Apple for some unique feature on their future ARM SoCs.

Re:I'm impressed

[TheRaven64]

It's almost as if you didn't read my post at all. Multiple serial tasks are equivalent to one parallel task, and can be run just as easily on one fast core as on multiple slow ones. Given the choice between a 2GHz quad-core CPU and a single core 8GHz CPU or the same architecture, you would (all other things being equal) get better performance with the 8GHz core. The reason that multicore chips are attractive now is that you can't get the 8GHz version.

risc

[Anonymous Coward]

risc is gonna change everything...

Re:risc

[narcc]

Yeah... RISC is good...

Re:risc

[mydnite]

nice Hackers reference.

Um...why?

[drb226]

At some point you do need things to be performed in sequence. Performing a bajillion parallel operations can only get you so far. Can the simple tasks required of a smartphone (e.g. AngryBirds) really benefit from that many cores?

Re:Um...why?

[Darinbob]

Because marketing thinks that if they have N cores it will sell better than a phone with only N-1 cores. And they're probably right.

Re:Um...why?

[Threni]

It might mean that the Android version runs at more than 20 frames per second.... you know, like games used to on 7mhz, 512k Amigas 25 years ago.

Re:Um...why?

[eln]

Sure, it will play at 64 frames per second. The trick is, it will display all 64 of those frames simultaneously, for a duration of one second. Playability may be affected.

Re:Um...why?

[$RANDOMLUSER]

Hey, it works with digital cameras and megapixels. Worked with processors and mega/giga hertz for a loooong time.

Re:Um...why?

[dhavleak]

People are in such a hurry to add cores, nobody's even stopping to think about this question.

Smartphone workloads are inherently serial. Even two cores can be overkill for a smartphone -- with one core underutilized even when the device is being actively used, and one core being powered down entirely while the other one's clock is scaled down, when the device is in your pocket. Why not just save the die space, have just one core, and optimize the heck out of that scenario?

Re:Um...why?

[RightwingNutjob]

Video processing can (depending on what you're doing) be very parallel. So can some kinds of data compression. The real question is gonna be in terms of power. Are 64 mostly-idle cores going to consume less power than one or two fully loaded cores multiplexing those same tasks.

Re:Um...why?

[LurkerXXX]

You mean YOUR smartphone workloads are inherently serial. I'm streaming Pandora, while playing a video game, while receiving notifications that new email is arriving, new SMS messages coming in, while waiting on the batch files to finish running in my ssh session to my server at work.

Re:Um...why?

[timeOday]

Can the simple tasks required of a smartphone (e.g. AngryBirds) really benefit from that many cores?

Most of the computation in Angry Birds is filling in pixel values, and that's certainly parallelizable. (But that's why phones already have GPUs with fine-grained parallelism for such tasks).

Second would be the physics simulation of falling pillars and such. I guess the question there is, do you think the falling blocks in a real-life Jenga game are taking turns?

Re:Um...why?

[Nikker]

I actually beg to differ. On smartphones or low powered devices breaking it down to smaller physical processors is likely the most elegant and efficient route. Each aspect of the smartphone OS is compartmentalized. Email is scheduled to run at a specific interval, web browser is refreshing at a different interval all serial on their own in many cases but when it comes to sharing with other processes not very friendly. Then you have 3rd party apps that are all over the board. I think being able to assign specific tasks to dedicated units would help as far as context switching as well as data protection and sandboxing. From the users prospective each app can run smoothly and if the odd one craps out then the OS can just knock out the CPU and dump a report.

I doubt the processors they are talking about have much to them as to consider them CPU's but as we see with the trend of multiple low power cores even scaling to 4 or 8 would likely handle a decent work load equivalent to a few atom procs (enough for a presentation and a web browser) in your pocket at decent resolutions of 1080p minimum.

Re:Um...why?

[dhavleak]

That's true about video processing, but ideally any processor you use in a smartphone will already have fixed function encode/decode units for whatever audio and video you throw at it (*cough* webm notwithstanding *cough*)

Re:Um...why?

[dhavleak]

Oh -- and regarding idle power consumption -- no they won't consume less power, but that isn't even the point. When will you even have all 64 cores active? If you have cores that you never need, well, why have them at all? Why not have a single core or 2 cores that's buttloads faster?

Re:Um...why?

[dhavleak]

Receiving notifications for email, and receiving SMS messages don't require active threads -- there shouldn't be cores dedicated to those tasks even if you do have a 64-core CPU. The batch files, if I understand correctly, are running on your server at work. The Pandora stream's audio decode should be handled by a dedicated auio decode unit. So all you have going is data transfer over the network. I think old single core 486s could handle that -- as can today's single core or dual core snapdragons / tegras / OMAPs / whatever.

Re:Um...why?

[dhavleak]

I actually beg to differ. On smartphones or low powered devices breaking it down to smaller physical processors is likely the most elegant and efficient route.

But this is not a new challenge (of how to handle multiple processes/threads) -- whether on single-core or multi-core CPUs, or even if you have a machine with multiple CPUs, each of which has multiple cores. All modern OSes can already deal with mutiples threads/processes in each of these scenarios, and the app developer never needs to even think of the underlying implementation. The only design choice remaining relates to workloads. Are they inherently serial or parallel? If inherently serial, then many cores are not needed (or even usable). If inherently parallel or parallelizable, then they are. It so happens that smartphone workloads are inherently serial.

Each aspect of the smartphone OS is compartmentalized. Email is scheduled to run at a specific interval, web browser is refreshing at a different interval all serial on their own in many cases but when it comes to sharing with other processes not very friendly.

This is true, but its not the same as serial/parallel workloads. For example, even if you have 6 different email accounts all setup to sync automatically on your smartphone, that's actually a serial workload. There's a single listener on an event, that wakes up when you receive an email, does the needful, and goes back to a blocked state, leaving the CPU to do other things. You might have a weather app that updates once per hour -- still a serial task that should a miniscule time-slice every hour. Most of the work it's doing is network I/O.

Then you have 3rd party apps that are all over the board.

This is true. Doesn't make them inherently parallel, but the day you have virus scanners, search indexers, bit torrent clients (i.e. active processes) all running simultaneously while you're checking email/browsing/making phone calls, yes, you absolutely will benefit from having multiple cores.

I think being able to assign specific tasks to dedicated units would help as far as context switching as well as data protection and sandboxing. From the users prospective each app can run smoothly and if the odd one craps out then the OS can just knock out the CPU and dump a report.

This is just not true. As I mentioned earlier -- modern OS kernels have had these functions nailed for some time now -- and that holds true for single core / muti core and multi processor environments. Sandboxing and data protection aren't necessarily related to processor cores. Killing an errant process and creating a dump is also not related to how many cores you have.

I doubt the processors they are talking about have much to them as to consider them CPU's

This is very true (and TFA says as much). They are likely thinking more along the lines of the cell processor in the PS3. Instead of having the various dedicated units that go into an SOC, the idea is to have many general purpose FPUs (most likely) that can be programmed to each of those tasks. Color me skeptical. SOCs are excellent solutions for smartphones because their functions are well understood, so you know exactly what to build into them.

but as we see with the trend of multiple low power cores even scaling to 4 or 8 would likely handle a decent work load equivalent to a few atom procs (enough for a presentation and a web browser) in your pocket at decent resolutions of 1080p minimum.

This trend is prevalent on desktops and laptops where paralell or paralellizable workloads are common. Mobile phones with dual-core processors have yet to prove that they do anything better than their single-core bretheren. And SOC solutions for mobile phones are already capable of putting out 1080p video -- that is not related to your CPU cores unless your solution is completely software based, in which case you will need a ton of cores, not to mention a really big battery and well cooled underpants.

Re:Um...why?

[Custard Horse]

How about *more* angry birds. And make them angrier. Angry x 64 = spitting feathers.

Re:Um...why?

[LurkerXXX]

You kind of missed playing a game. Need For Speed, Hawk, etc, tend to need a bit of CPU. I'd like a core for that itself while all the other stuff is handled by another core.

Re:Um...why?

[dhavleak]

Why is there so much ignorance about mobile processors (SOCs) on slashdot?? (I really don't mean to be rude.. my apologies)..

The functions you pointed out are handled by specifc DSP units on the SOC. A snapdragon or tegra or omap CPU used in smartphones *today*, *already has* dedicated DSPs for these tasks. They are not handled by the CPU to begin with. If you want a (any number of cores) CPU, and software to handle this, be prepared for a costly phone (CPUs are ill-suited to these functions so it will take a CPU with considerable horsepower), a huge phone (all that horsepower results in a large die size and more heat to be dissipated), and poor battery life (all that heat dissipated indicates that your processor eats amperes for breakfast).

These functions are possible, or close to possible, *today* -- the limiting factors being battery life, I/O bandwidth, network bandwidth, and on-device storage. 4 cores or 64 cores won't solve those problems (and they'll make the battery life considerably worse). Jeez!

Re:Um...why?

[dhavleak]

Not really -- on an old 486 or pentium (single core obviously) did you never have say outlook running in the background, while playing need for speed? At the most, you might need 2 cores to ensure jitter-free gaming during an event such as receiving a new email (etc). Beyond that, the game developers care a hell of a lot more about your SOC a good GPU.

Don't get me wrong -- i'm all for crazy fast processors -- it's just that the importance of processor speed (and cores in this case) is often completely misunderstood. Even in modern desktops, you're often in a situation where your quad-core i7 with dual hyperthreading (so 8 cores, depending on how you count) has at least 4 cores sitting in a state of utter and complete data-starvation. To solve data starvation issues, you need either more paralell (or parallelizable) workloads, and greater I/O bandwidth (more cache at each level, faster cache at each level, more RAM, faster RAM, wider RAM buses, more data per clock (ddr/qdr), faster hdd/ssd, lower latency hdd/ssd, faster and wider i/o bus, faster network, lower latency network, etc.). Just adding cores doesn't make something faster -- you need work for those cores to do, otherwise they're just sitting there consuming your battery. Worse -- if you have 64 super tiny ultra minimal cores each of them is guaranteed to be a very inferior integer pipeline compared to what you get in a full-blow ARM Cortext (for example). So when you are single tasking on a non-parallizeable workload (say checking email), you're only going to be able to use a tiny handful of your 64 cores, and that application will be slow as molasses. And consume more power while doing so. And when you do use all your cores by doing something like video decoding you'll still barely achieve the results that dedicated DSPs (that are already present in current-day SOCs) already achieve, and you'll take way more power doing so.

Disclaimer: There are some overgeneralizations in what I said, but the gist of it holds true. Bottom line: in the quest for awesome speed, people are salivating over something that will turn smartphones into slugs. It's like people drooling over the old Pentium 4 (netburst) gigahertz all over again, only to realize that the so-called fastest PC processor is actually a dog, an expensive one at that, and it generates insane amounts of heat. Sometimes you have to examine the details properly.

Re:Um...why?

[dhavleak]

Beyond that, the game developers care a hell of a lot more about your SOC a good GPU

doh! care a hell of a lot more about your SOC *having* a good GPU

Re:Um...why?

[thehodapp]

"Apple is proud to announce the iPhone 5. With a 64 core processor. That's 32 times any available phone on the market. And that means you can multitask like never before. At 32 times the speed."

I can just see it now...God save us. From the consumers.

And before any fanboi gets riled up, any phone company could do it. I just see Apple doing this first.

Re:Um...why?

[Zero__Kelvin]

Smartphone workloads are inherently serial? Are you fsck'ng serious? So when I am googling around while my GPS is keeping track of my location ad I listen to some Joe Satriani being decoded from my SSD and a call comes in and my phone determines what ring to use based on the caller ID ... What the hell are you smoking? (and where can I get some)

Re:Um...why?

[AmiMoJo]

Megapixel levels in digital cameras levelled out a few years back. Instead the focus shifted to features and image processing. DSLRs and Micro 4/3 cameras are mostly hovering around the 12MP level. There just isn't much to be gained from going above that because the limiting factor is the size of the lens and camera body.

Re:Um...why?

[AmiMoJo]

Problem is with 64 cores you spend a lot of time just managing them all. Not only does the OS have to feed them all tasks to perform, putting them in low power mode when needed, but it has to arbitrate access to shared resources that can only be used by one core at a time.

The only applications that benefit from 64+ cores are severs that do heavy processing scientific apps. Assuming they are not too limited bt disk or memory access speed.

A better solution is the one that everyone else has settled on. A few CPU cores and lots of simple data processing cores. The latter are usually part of the GPU and can chew through things like video decoding far faster than a CPU core. In fact phones have used dedicated data processing cores, traditionally referred to as DSPs, since the early days to process radio comms.

Re:Um...why?

[Zero__Kelvin]

Since you ignored etiquette and replied as an AC I have replied here to circumvent your attempt to circumvent my reply. You really should pay attention more. For example just because dedicated silicon decodes the mp3 or mp4 stream, that doesn't mean there is no parallel activity. Perhaps you were unaware that as the steam plays my screen is indicating the songs progress for example. You are basically clueless, and clearly have no real world experience writing software for real time embedded systems. I recommend that you accept that you know less than those of us who actually implement such systems and either learn something or just move along and wallow in your cluelessness.

Re:Um...why?

[LurkerXXX]

I don't have an iphone.

Re:Um...why?

[gl4ss]

that works well for lg right now.

oh wait...

Re:Um...why?

[Coren22]

Naa, Apple would do it second, the common thread of everything Apple has been take a good idea, and make it shiny.

Re:Um...why?

[Coren22]

Ok, so you have Pandora, it receives audio from the internet, so that is one core handling the connection with the web server, one core making sure all the packets are there, one core interfacing with your DSP to decode the audio, another core handling the GPS signal comms with the server to coordinate your adverts. While you are doing all of this, you have another core continuously checking for new mail, another one communicating with the Cell radio to make sure everything is going to make it through and deciding if it should force the radio to switch towers as it knows quite well where you are headed and where the towers are. Also, what is to say we won't be pulling all these DSP units into the processor again? Condensing as much as posible into the processor has been a theme since computers started (486 added in the floating point proc, Pentium brought in some of the graphics processing, so on and so forth.) If you have 64 cores, you don't need much of a GPS unit, nor much of a Cell radio, the processing overhead involved in these items can be handled by the CPU instead. The newest CPUs from Intel and AMD both brought the "video card" into the processor, but there are still many chips outside of the CPU; audio, southbridge, bluetooth, wifi, etc.

Re:Um...why?

[Coren22]

Who needs audio decode processors outside the CPU when you have 64 cores? Who needs an external GPU when you can move it into the processor?

Re:Um...why?

[Coren22]

I have an android, and can say IU have never had this issue. (Droid X)

Re:Um...why?

[Coren22]

I have also replied to many of his comments. Why have dedicated anything when you have 64 cores, the whole path of phones is integrating as much as possible into the proc so you have less chips on the board. Every time he brings up the SOC, he is assuming that there will still be one. Why have dedicated silicon when you can have generic that has the free processors to toss at a job.

Re:Um...why?

[hattig]

To be fair with Grand Central and Apple's 'blocks' they could probably make some use of such a chip. And it's 'only' a couple of hundred million transistors for a 64-core implementation.

What I see these being is actually more along the line of a Cell SPU, but optimised for low power and inter-core communications. Like Transputer shagged an SPU. As programmers have raised issues with the SPU's 128KB of local RAM, I wonder if the 32KB of local RAM on this design will prove to be an issue in the future.

Might sound silly, but if they could provide an OpenCL front-end to their chip they will make it more desirable, but maybe that would not utilise the features that make their design worthwhile over a low-power GPU.

Re:Um...why?

[hattig]

Of course if we were talking about a 64-way SMP machine what you write would be correct.

However in this case we are talking about a 1 or 2 way SMP machine with an array of 64 (and so far only 16 implemented) C-programmable cores that can be used.

The OS may provide a concurrent API to manage sending tasks to these cores, and getting the results out at the end. Or the applications themselves will handle this aspect. But the OS will not be scheduling standard applications themselves onto these cores.

I don't even know if this array of cores can access shared memory outside its domain - each core has 32KB of local memory.

The advantage over a GPU here is that it is very low power, and can get high GFLOPS/W compared to what's currently on the market.

Re:Um...why?

[Zero__Kelvin]

Try looking up page flipping for one proof of how little you understand about the topics you purport to grasp.

Re:Um...why?

[dhavleak]

Also, what is to say we won't be pulling all these DSP units into the processor again?

They are already there. Every single function we've takled about has dedicated silicon for it, *inside one single chip*, which also includes the CPU. Aaargghh!

Pentium brought in some of the graphics processing, so on and so forth

Same point. Already done. Read up SOC architechture before replying. Look up a block diagram of what lives on a single chip for say a tegra or a snapdragon.

The newest CPUs from Intel and AMD both brought the "video card" into the processor, but there are still many chips outside of the CPU; audio, southbridge, bluetooth, wifi, etc.

Same point. Already done. Smartphone processors integrate all the functions into one single chip. Please, please, please do a little reading before replying again.

Re:Um...why?

[Zero__Kelvin]

I especially like the way he switched to posting as AC so he can keep spouting his nonsense while effectively putting his fingers in his ears and shouting NA NA NA NA. It doesn't leave much wonder why he is so clueless.

Re:Um...why?

[dhavleak]

I especially like the way he switched to posting as AC so he can keep spouting his nonsense while effectively putting his fingers in his ears and shouting NA NA NA NA. It doesn't leave much wonder why he is so clueless.

And we've entered a fact-free zone and reduced to childish bickering.

Let's take this down a notch. It does nobody any good to be disrespectful. Let's be specific -- what *problem* with current SOC implementations do you think a 64 core CPU will solve? For arguments sake, and for sanity, lets assume 4 of them are integer cores, and 60 (odd number, but what can you do) of them are FPU cores. What problem is it solving, or how is it better?

Re:Um...why?

[dhavleak]

Certainly. Page 1 of what?

Re:Um...why?

[Zero__Kelvin]

You have it backwards. The correct question is if I have 64 cores I didn't have at my disposal before, what value is added in terms of doing things on the new device that were either difficult or impossible to do with the ancestral architecture.

Re:Um...why?

[dhavleak]

You have it backwards. The correct question is if I have 64 cores I didn't have at my disposal before, what value is added in terms of doing things on the new device that were either difficult or impossible to do with the ancestral architecture.

Very well then, if you have 64 cores that you didn't have at your disposal before, what value is added in terms of doing things on the new device that were either difficult or impossible to do with the current (ancestral assumes shared lineage) architecture?

Re:Um...why?

[Zero__Kelvin]

Exactly !

Re:Um...why?

[vlsi4all]

To be fair with Grand Central and Apple's 'blocks' they could probably make some use of such a chip. And it's 'only' a couple of hundred million transistors for a 64-core implementation.

What I see these being is actually more along the line of a Cell SPU, but optimised for low power and inter-core communications. Like Transputer shagged an SPU. As programmers have raised issues with the SPU's 128KB of local RAM, I wonder if the 32KB of local RAM on this design will prove to be an issue in the future.

Might sound silly, but if they could provide an OpenCL front-end to their chip they will make it more desirable, but maybe that would not utilise the features that make their design worthwhile over a low-power GPU.

Not sure if the Cell SPU is a good comparison. Their core is much more of a general purpose processor than the Cell SPU. Basically comparable to a ARM9/11 capable 1GHz core with built in floating point capability but at a fraction of the area.

I'm nostalgic of days when phones were just phones

[youn]

heck I even liked the big rotary dials with the extensible extension cord... but maybe that's just me.

soon, when we buy a phone, we'll ask... hey, is a phone included with that? :)

Graphics processor?

[feedayeen]

Graphics processors' architecture resembles that of a CPU with hundreds (thousands?) of parallel cores. These cores are incredibly limited but it is a rendering format optimized for the information format that they receive (heavily parallelized). Apart from this, GPU's are extremely poor at performing other types of computations.

Re:Graphics processor?

[drewm1980]

Graphics processors' architecture resembles that of a CPU with hundreds (thousands?) of parallel cores.

Cpu is more like 6 cores, with 4 (or soon 8) single precision width vector units. For cuda, it's more like 16 cores, with 32 (or 64 depending on how you're counting) width single precision vector units. Nvidia marketing uses a funny definition of "core"; an cuda SMP is roughly analogous to a cpu core running at a much slower clock, but with a much wider vector unit.

Re:Graphics processor?

[Jeremy Erwin]

The CM-1 was designed by Thinking Machines Corporation, not Cray. However, the blinkinlights of a CM-5 did appear in Jurassic Park, which also featured the Cray XMP. Knowing Hollywood, they might have gotten their wires crossed.

Any tech that has testimonials

[mrmeval]

Smells of infomercials and burned popcorn.

Re:Any tech that has testimonials

[mrmeval]

I'm out of mod points *tears*

BTW how many commodore 64 emulators can you fit on a high end FPGA? Right. That's what I'm talkin' about. Give me 64 C64's or give me armpit!

Re:I'm nostalgic of days when phones were just pho

[$RANDOMLUSER]

That's pretty much The Big Question for the Xoom right now.

zzzzzzzz

[O('_')O_Bush]

TFA is so chalk full of buzzwords and unsubstantiated claims that I can't help but call this a slashvertisement.

Re:zzzzzzzz

[Threni]

I think it's a startup searching for a VC to give it some money. "Loads of cores.. that's good, right? These guys are doing good stuff on smartphones, and I keep reading about them on blogs, so I think it must be worth sinking a few millions dollars on".

Not General Purpose

[adisakp]

FTA: However, we do not have a memory management unit, so we can not act as a host for operating systems such as standard Linux or Windows.

In other words, they either access fixed shared memory pool or they have some directly mapped memory on each core or both.

These are more like a different take on the SPU cores in a CELL (PS3) processor than a traditional multicore CPU.

Re:Not General Purpose

[Svartalf]

Seems to me that it's more akin to Chuck Moore's GA144 that's about to ship- except that these are claimed to be programmable by C as opposed to Forth.

Re:Not General Purpose

[drinkypoo]

In other words, they either access fixed shared memory pool or they have some directly mapped memory on each core or both.

You mean, in other words, you're alive, or you're dead?

It does seem a bit daft to not have an MMU. Getting MMUs in desktop machines was a major step forwards in personal computing. I don't particularly want to do without one any time I am running multiple processes...

Re:Not General Purpose

[mlosh]

I've been following Chuck Moore's new startup GreenArrays and their progress with much interest. I hope they can announce some major design wins soon.

Re:Not General Purpose

[gl4ss]

it seems to me they made a dsp architechture and then sticked on smartphone cpu stickers on the press release, because they read on the news that smartphones are a hot investor field.

Re:Not General Purpose

[adisakp]

You mean, in other words, you're alive, or you're dead?

It does seem a bit daft to not have an MMU. Getting MMUs in desktop machines was a major step forwards in personal computing. I don't particularly want to do without one any time I am running multiple processes...

No, it's not all possible states. There are many things you can rule out from the limited information in the article. While there are dozens of ways to connect hardware to each other and have them access memory or communicate, the way this chip seems to work is as a limited accelerator (i.e. like video cards or physics cards) rather than a true CPU for the OS. There's only so many ways a chip like this can coexist with a modern CPU and a modern OS and without an MMU. You can't have it access the same memory as the CPU directly because without an MMU, you have no memory protection so it'd be a huge security hole. Probably, either on a bus or card and again with a small pool of local memory and possibly on chip memory. They made CELL-based SPU accelerator cards for PC's and this is very likely in the same category.

Number is overrated

[microbee]

I only care about hardness

Re:I'm nostalgic of days when phones were just pho

[yodleboy]

i know you joke, but for me that's been the question since maybe 2003. They all do phone stuff, which honestly is the least used feature for me. What else can you do for me without costing as much as a laptop? I spent years going through a couple of phones a year trying to find what was basically a small computer that happened to make calls and was repeatedly disappointed by most phones. For all its faults, the iPhone was a game changer and made the other manufacturers wake up. Now that I've gone Android, I've finally gotten what I always wanted. More cores? Bring it on...

Believe it when I see it

[AaronW]

I'll believe it when I see it. If anything, the processor cores will be very simple. The biggest bottlenecks will be memory bandwidth and synchronization between the cores. It sounds like what they are doing may be more akin to what GPUs are doing today, though they say nothing about floating point support or even if it's 8, 16, 32 or 64-bits per core.

The company I work for, Cavium Networks, has a 32 core 64-bit MIPS processor (and yes, it runs Linux).

-Aaron

Re:Believe it when I see it

[Svartalf]

Heh... It should be said that I wouldn't consider the Octeon as a low-power device- it's more intended for high-end network processing engines, isn't it?

Re:Yes but...

[nugatory78]

I can't believe I got this far in the comments before finding a reference to a Beowulf Cluster.

Zii

[ajlitt]

So, how's that working out for Creative Labs?

Pfft Good luck

[Dreth]

You'd need over 4GB of ram to run that stuff!

Could someone explain this part?

[SanityInAnarchy]

The processor also differs from FPGAs (field-programmable gate arrays), which are reprogrammable circuits that can help execute specific tasks such as XML processing. The Epiphany chips are not restricted to running specific tasks, Olofsson said.

So... what... they can run a "non-specific" task, and an FPGA can't? Just what is it that these can do that an FPGA can't?

My understanding is that by being actual processors, they can probably operate faster than an FPGA design for a lot of tasks... might that be it?

If anyone has any idea what this guy meant, please elaborate. It looks to me like there might've been a useful comment in there, but it might've been lost going through a CEO to being paraphrased by a journalist... But maybe it's obvious to someone.

Re:Could someone explain this part?

[Vectormatic]

yeah, he's full of shit, an FPGA can do anything any other piece of silicon can, just not as fast.

I've worked with FPGAs which had "soft-core" cpu's loaded, running generic ARM code, the same is possible for any cpu architecture

Re:Could someone explain this part?

[hattig]

"not restricted to running specific tasks"

i.e., you load your FPGA core at startup, and then you're stuck with it until you re-boot the FPGA. And yes, I know that there are some FPGAs out there that can be re-programmed as it is running.

Their system, being far closer to a CPU, lets you just load the new program into its RAM which it executes. The photo app runs face detection until you take the photo, then RAW image processing, then image enhancement, then it runs JPEG encode. The game runs physics and head tracking for 3D effects. The music apps runs DSP effects.

C64-cores

[Vectormatic]

Am i the only one who initially parsed the title as "c64-cores"? i figured someone wanted to put a bunch of commode-64 cpu's in there :P

Re:Yes but...

[Jeremy Erwin]

Just because a chip uses a Message Passing scheme does not mean that it's a Beowulf. Oh wait... it's probably close enough for slashdot.

Laptop heat

[shenglee]

My laptop fever, how?

Background/Foreground Add-ons

[Kamiza Ikioi]

Because simple background processes, like downloading Facebook updates, and foreground add-on and system processes, like Swype, gestures, volume controls, and loading small lists (contacts) shouldn't have to interrupt the main CPU which is carrying the high throughput foreground app.

It's hard enough for a phone to stream Pandora in the background while playing Angry Birds. But let's say you do that, but everytime you touch the screen, either the music skips or Angry Birds freezes. I can't tell you how many times I've seen the slingshot freeze in the pulled back position because some background update jumps in that really didn't need the full CPU.

And that's the killer app(s) for this. Background and foreground add-ons like onscreen keyboards and controls.

submission title incorrect

[Thud457]

this story should actually be titled : Nefarious New World Order plan for mass sterilizations in the developed world


please god, +1 funny, not +1 insightful...

Just so you don't cry

[Zero__Kelvin]

How about mesh networking, real time encryption, video redirection, and language conversion for starters?

Re:Just so you don't cry

[dhavleak]

Encrypting stuff on the fly is a great example. Let's say you benefit from having a core for that, in addition to your existing core. So you're at 2 cores now, with 62 left to go. I do understand that several ciphers will benefit from extra cores, but you have a device with finite storage, and finite battery power, so it begs the question as to how much stuff you're encrypting that you need to dedicate more than 1 core to it.

Video redirection is very unclear -- I don't see it as a moblie workload -- but perhaps I don't get your scenario yet. In any case, that seems like a completely data-bound process.

Mesh networking (any networking), given a standard protocol is not something the CPU should be taxed with. It should be 99% I/O bound

Language conversion (I don't know your exact scenario -- is this text, speech, what is it?) is not something you can do even today, even with 64 (or more) cores -- so it'll be a while before you have an application that attempts to do that on the phone. Language conversion apps require some serious data backing and number crunching -- it's best implemented as a cloud service that you stream the audio to, and it returns back the results -- very similar to how voice search apps on phones currently work (or say, similar to something like Shazam).

Re:Just so you don't cry

[Zero__Kelvin]

You are just babbling, and you are not so much interested in looking for uses for cores as looking for an argument. I am posting all these from my smartphone, so I'd rather let you think you won than go through all the effort of showing you how much advantage a bit of imagination could be.

Re:Just so you don't cry

[dhavleak]

You are just babbling, and ....... looking for an argument

I replied as AC to put a stop to the nonsense, and you came back with a santimonious lecture about etiquette. Further -- when you say something I agree with, I freely admit it (see the disk encryption scenario you mentioned). To each their own I guess.

You are not so much interested in looking for uses for cores

Correct. A sane design approach is to understand use profiles and requirements, and then solve them. Proposing 64 core CPUs without first having a need for it is a backwards approach. The use case you pointed out a thread above (mesh networking + encryption + video redirection + language conversion, simultaneously mind you) would cover what -- 0.09% of smartphone users? Never mind the point that 64 general purpose cores is still an inefficient approach for addressing it. And you persistently ignore issues related to finite battery life, and limited heat dissipation capabilities in a smartphone form factor.

I'd rather let you think you won

I feel like I've won when I've had a rational discussion, and one or both parties come away with a bit of insight. I fear I might have polarized you into a particular line of thinking that I am very certain is limited. I hate it when that happens.

showing you how much advantage a bit of imagination could be.

Imagination is a wonderful thing. A little bit of real-world engineering does have a habit of raining on the imagination parade from time to time.

Sterilizations ?

[DrYak]

Why bothering to sterilize with silicon-induced high in-trouser temperatures and microwave radiation ?

With smartphones, the idiots will be anyway too busy playing "Angry Birds" to think about fucking and reproducing...