13 ms·

A 32nm 1000-Processor Array

148 points by lossolo 10y ago

lossolo 10y ago
link to press release: https://www.ucdavis.edu/news/worlds-first-1000-processor-chip https://www.ucdavis.edu/news/worlds-first-1000-processor-chi...
imtringued 10y ago
This reminds me of the Ambric am2045 with 336 cores from 2007. They put 40 of these into an X-Ray machine for a total of 13,000 cores. https://en.wikipedia.org/wiki/Ambric https://en.wikipedia.org/wiki/Ambric http://www.embeddedinsights.com/epd/Diagrams/nethra-am2045.jpg http://www.embeddedinsights.com/epd/Diagrams/nethra-am2045.j...
- jsizz 10y ago
  Yeah whatevs. This reminds me of the ICL DAP with 1024 processors from 1979... https://en.wikipedia.org/wiki/ICL_Distributed_Array_Processor https://en.wikipedia.org/wiki/ICL_Distributed_Array_Processo...
- petra 10y ago
  There's (1) talking about getting ~60 tflops from ~130k compute elements by 3d assembly of 128mb ram . But it requires microfluidics cooling so it would be very expensive. But in another paper(2), the authors say that offering this chip, even expensively ,could start building the ecosystem and and environment to start a Moore's law like race to solve the heat issue via photonics . (1)https://www.semanticscholar.org/paper/Fft-on-Xmt-Case-Study-of-a-Bandwidth-intensive-Edwards-Vishkin/4f9bd24ea869f64c4457f69ad6d9dc2b3ddb93ac/read/page/7/panel/1 https://www.semanticscholar.org/paper/Fft-on-Xmt-Case-Study-... (2)http://drum.lib.umd.edu/handle/1903/17153 http://drum.lib.umd.edu/handle/1903/17153
willvarfar 10y ago
So how do you program such a beast? What progress is being made on that front? Cache coherency seems really hard to give up on, and even CPU-GPU cache coherency is becoming the expected norm, with even ARM delivering it.
- ci5er 10y ago
  These people have some grand claims in that regard: - http://texasmulticore.com/ I keep failing to get plans to match up to talk to their CTO on how this would stack up against what a rebuilt (differently optimized) Erlang VM could do... And, yes, I know: Not open source. No one needs to make that clever observation...
- RachelF 10y ago
  It's very hard. In the mid 1980s there was a CPU called a "Transputer" [1] made some of the people who moved to ARM. These CPUs could be connected together in huge networks and directly talk to each other. The network of CPU's could auto-discover its topology, but coding for so many CPU's was difficult. Some specific algorithms scaled well with the number of CPUs, but most did not. [1] https://en.wikipedia.org/wiki/Transputer https://en.wikipedia.org/wiki/Transputer
  - hexane360 10y ago
    Wow, that reminds me of this[1] game. Lots of tiny processors messaging between each other. I didn't realize there were actual implementations. [1]http://store.steampowered.com/app/370360/ http://store.steampowered.com/app/370360/
  - jacquesm 10y ago
    Occam did it quite nicely. I think the reason transputers didn't 'make it' is not because they were super hard to program (it was only a little bit harder than programming a regular computer), but because the price premium you paid for a transputer set-up was too high and x86 got faster very rapidly. This is right around the time when the first 386 machines were launched and in a very short time we went from 12-20 MHz 286 boxes (and some 68K machines for the lucky ones) to 33 MHz 386 machines with a ton of RAM. So the advantage that transputers had was eroded very quickly and I don't think INMOS was ready to match pace. Now that we've reached the end of the line for that kind of speed increase we are seeing a renewed interest in multi-cpu fabric architectures, of which the transputer was an instance.
    - 10y ago
foota 10y ago
Does anyone have a link or the name of another weird architecture that was posted a while ago? (~3 months maybe?) I remember that there were a large number of cores that all communicated with each other in some weird way and that they like didn't have main system memory or something like that...
- jacquesm 10y ago
  Sutherlands 'Fleet'?
  - foota 10y ago
    Doesn't look like it... there was an established website for the project. It seemed to have some big names from processor design and such behind it as well (at least from what I gathered on their wikipedia pages ;) ) For future reference, here is a link talking about the arch mentioned so that no one else has to wade through google's results for "fleet architecture": http://arc.cecs.pdx.edu/publications http://arc.cecs.pdx.edu/publications edit: previous (2009) discussion about fleet: https://news.ycombinator.com/item?id=723882 https://news.ycombinator.com/item?id=723882
    - jacquesm 10y ago
      That one?: https://news.ycombinator.com/item?id=11845698 https://news.ycombinator.com/item?id=11845698
- elij 10y ago
  Maybe this? https://news.ycombinator.com/item?id=11845698 https://news.ycombinator.com/item?id=11845698
  - foota 10y ago
    No :/ Thank you both for your suggestions though, they are appreciated :) If it helps it had the same sort of feel as the Mill architecture, in that it was a small project being developed by very enthusiastic people.
mrb 10y ago
It is surprising the paper makes no comparisons with GPUs. So I will do it. For starters it looks like they are talking about integer operations (I only skimmed the paper and it mentions an ALU, not an FPU), whereas my GPU numbers below are single precision floating point numbers. So it is apples vs oranges. So, a modern 14-16nm GPU like the Tesla P100 or RX 480 does about 5 to 10 trillion ops/sec at 200-300 W, and approximately 30 pJ/op. So GPUs are about 5x less power efficient. The paper authors did a good job. However GPUs are not optimized for absolute power efficiency, but mostly for performance per $.
- frozenport 10y ago
  Cursory Google search shows Pascal GPUs at 10pJ/op for double precision (these guys did int, which should be 10x faster)[1,2] [1] http://wccftech.com/nvidia-pascal-volta-gpus-sc15/ http://wccftech.com/nvidia-pascal-volta-gpus-sc15/ [2] http://prism.sejong.ac.kr/download/PRISM3_paper/PRISM_Ajaykumar_Kannan_presentation_final.pdf http://prism.sejong.ac.kr/download/PRISM3_paper/PRISM_Ajayku...
- duckingtest 10y ago
  (Dynamic) Power consumption goes up with square of voltage, so a comparison with a gpu's max power efficiency point (almost certainly underclocked and undervolted) could change the comparison significantly.
  - stcredzero 10y ago
    Power consumption goes up with square of voltage This needs to become common knowledge amongst nerds and tech types.
    - theparanoid 10y ago
      It was more widely known, when every geek overclocked; no more.
      - stcredzero 10y ago
white-flame 10y ago
I think that http://venraytechnology.com/ http://venraytechnology.com/ is the only high CPU density design I've seen that seems useful for general purpose, large-footprint computing, but their launch model (sell to a DRAM manufacturer and cash out) didn't go anywhere. So many of these tons-of-cores chips can't really do much per chip, and are only suited for streaming algorithms like encryption, data packet routing, video stream processing, etc. They also have nowhere near the memory bandwidth to compare to GPUs, or to feed those many processing units with unique data per unit. Would somebody please think of the memory requirements? :-P (or Venray, please seek investment and start pushing your designs yourself)
chongli 10y ago
Would a language like Erlang make sense for a machine like this? Run 1000s of communicating processes without any shared data.
- loxs 10y ago
  I don't think Erlang's VM is that optimized. Currently (as far as I remember) the upper limit is to run 1024 schedulers (threads) but I imagine it certainly wont be 10x more efficient than running 100 schedulers on 100 core machine
  - qaq 10y ago
    Architecturally it's a perfect match for such CPUs. If you listen to Joe talks he was talking about designing for 1000 core cpus more then 10 years ago. It is his stated opinion that Erlang is perfect match for such situations.
    - loxs 10y ago
      Of course it's (much) better than anything else... though my experience is that it's quite hard to scale your application that much... You always need some shared resource and it gets ugly. And I also suspect Erlang has some implementation quirks (for example the algorithm of deciding which scheduler gets which process) that will prevent it from scaling that much. Yeah, I do believe that some day we'll reach such scalability, probably just not today.
      - qaq 10y ago
        Each scheduler has it's own run queue there is higher level migration logic to balance run queues based on statistics collected.
    - shoover 10y ago
      He's also mentioned FPGAs in similar terms, but I've not seen any news lately on that topic. Is it not practical? Not worth the effort? This is a different ballgame but interesting, a recent Raspberry Pi 2 experiment [1] demonstrated good scaling of an Erlang application on multicore ARM up until the concurrency limit inherent in the application (around 128 processes). [1] - https://medium.com/@pieterjan_m/erlang-pi2-arm-cluster-vs-xeon-vm-40871d35d356#.y68s4ha6n https://medium.com/@pieterjan_m/erlang-pi2-arm-cluster-vs-xe...
greggman 10y ago
I'm certainly hopeful this will lead somewhere useful. Intel tried with Larrabee but apparently couldn't get the perf they wanted, especially with comparisons to GPUs It would be great to know what the trade-offs are with this architecture
- alexnewman 10y ago
  you mean xeon phi. I think it's still around. It is plenty fast, but not much better tdp than a gpu (which are commodity (read this as cheap)).
  - deadgrey19 10y ago
    Xeon Phi is around and used in various financial computations. The problem with GPUs is not TDP, but programming flexibility. Programming a GPU is very hard to do well for generic computations, whereas x86 like CPUs have millions of programmers who can do a pretty decent job.
  - CyberDildonics 10y ago
    The Xeon Phi was never meant to compete with GPUs directly. The first version was underwhelming and expensive but used in order cores. The next version is actually available to buy as some sort of limited release. It has out of order cores and 144 512 bit SIMD units (2 per core * 72 cores). The full box costs $5000 last time I checked.
nickpsecurity 10y ago
It's important for people to know these are eight bit CPU's. Least, that's what every other incarnation has been. https://en.m.wikipedia.org/wiki/Kilocore https://en.m.wikipedia.org/wiki/Kilocore Asking what to do with 1,000 32- or 64-bit cores != 1,000 8-bit cores. Suddenly the value proposition doesnt seem so great. Such designs were used successfully, though, in both neural networks and genetic algorithms. Could probably handle stuff well that normally goes on DSP's.
mntmn 10y ago
Where can I buy a sample?
JoeAltmaier 10y ago
Thinking out loud. Instead of imagining applications per processor, I imagine this device could map threads or message handlers to processors. It could work better with a functional language or at least some language that didn't explicitly manage parallelism in code but rather in the runtime. Offload the app writer to just coding algorithm and not thread synchronization. E.g. imagine each timer wait being a processor spinning; each I/o loop being a processor that blocked/looped on an I/o pin state. With so many processors to schedule, it wouldn't stall application progress to spin or block an individual strand (until you ran out or processors). To make this efficient, they'd want interrupts and semaphore state to be hardware-supported. Instead of polling a memory location, block on a shared register masked where each bit was a condition. So instead of a 'kernel call' it'd be an opcode or small loop. Latency of wakeup then becomes about 1 machine cycle. I imagine with the right runtime support this could be a useful device for a large I/o server. It could reduce latency of processing each client message to just the execution time. No time burned in kernel calls, process switching, stack copying, interrupt/event latency.
- endergen 10y ago
  I'm an ex game engine developer and I bristle anytime anyone thinks any existing functional language is better for multicore. Specifically garbage collection alone will make any language an order of magnitude slower generally per a single core. Also the C/C++ game development community at least has great approaches to multicore which makes C/C++ linearly scale with scores to boot, see for example: http://www.gdcvault.com/play/1022186/Parallelizing-the-Naughty-Dog-Engine http://www.gdcvault.com/play/1022186/Parallelizing-the-Naugh.... I love functional languages, more for thinking in them, prototyping ideas, especially compilers/visualizers, and etc. But for any language that adds garbage collection, immutable data structures (way more operations per write and crazy memory thrashing/alignment issues), unless used sparsely or in a mixed paradigm (ugh, except maybe scala/clojure) are going to pay a magnitude of performance loss. Mind you there are tricks around using more system languages (C/C++/Rust/D etc) for a lot of the heavy lifting with the application core being functional that gets you closer to the best of both worlds.
  - geon 10y ago
beagle3 10y ago
AIseek[0] had 10,000 processor chip in 2006, with simple connectivity and simple ops that were perfectly matched for graph algorithms. Their demo[1] would not be impressive today, but doing it in real time in 2006 was quite a feat and basically impossible without specialized hardware. Unfortunately, they're no longer in business. [0] http://www.extremetech.com/extreme/75766-new-ai-chip-would-make-games-smarter http://www.extremetech.com/extreme/75766-new-ai-chip-would-m... [1] https://www.youtube.com/watch?v=VeSQI2hinp0 https://www.youtube.com/watch?v=VeSQI2hinp0
samfisher83 10y ago
The paper doesn't really explain how the its suppose to handle memory. You have a 1000 processors and 12 modules with 64KB ram. Now if you have to access real ram how will that be done? You would need a massive bus like a GPU so you could keep all the chips with data to do work. How do you keep the processors starving for data. I understand its an academic project, but I wish they would explain what the real life use of this thing would be? Here is another project I found: https://en.wikipedia.org/wiki/Kilocore https://en.wikipedia.org/wiki/Kilocore Not the same thing, but I wonder how much they sold? More like like 1000 small processing units instead of full cpu.
ableal 10y ago
Dug around a bit for the paper, found this 2 page PDF: http://vcl.ece.ucdavis.edu/pubs/2016.06.vlsi.symp.kiloCore/2016.vlsi.symp.kiloCore.pdf http://vcl.ece.ucdavis.edu/pubs/2016.06.vlsi.symp.kiloCore/2...
rntz 10y ago
Arguably the first 1000-processor chip was the CM-1, made in the 1980's: https://en.wikipedia.org/wiki/Connection_Machine https://en.wikipedia.org/wiki/Connection_Machine They also bury the lede somewhat. Apparently the KiloCore is a 1.78 Terahertz chip: > The energy-efficient “KiloCore” chip has a maximum computation rate of 1.78 trillion instructions per second Edit: they later say it's 1.78 GHz. I guess "trillion" is just a mistake?
- deadgrey19 10y ago
  Maybe they mean "effective" speed. 1000x 1.78GHz = 1.78THz. Assuming a job is embarrassingly parallel it might be an ok metric. Realistically, probably not.
- mafuyu 10y ago
  Instructions Per Second is different from the clock speed. In this case, it looks like each core is ~1 Instruction Per Clock, so 1 * 1.78 GHz * 1000 cores. The trick is that getting 1.78 trillion IPS distributed over 1000 cores is very different from getting that over a few cores.
- CyberDildonics 10y ago
  ... 1.78 GHz * 1000 processors ?
- simonster 10y ago
  According to the link, the CM-1 had 16 processors on a chip, but there were a lot of chips (up to 4096 to yield up to 65536 processors). Still, the programming paradigms that were used for the Connection Machine might be useful for the massively parallel chip described here.
- jacquesm 10y ago
  That wasn't a chip.
- tlrobinson 10y ago
  Saying 1000 cores running at 1.78 GHz are a "1.78 THz chip" is a bit like saying 1000 cars driving at 65 mph are a "65,000 mph car"
mpweiher 10y ago
This sort of thing, taken to even greater extremes, could be an interesting match to Actor languages, with an actor mapped to a processor. The overhead would be likely be ridiculous, as most actors would be blocked most of the time. However, if it is true that we are now able to put a lot more transistors on a chip than we can power, that might actually be a feature rather than a bug. Assuming that power management is awesome and these actor-processors consume little or no energy when blocked, the power/performance ratio for most application should be awesome.
i336_ 10y ago
> KiloCore processors ... store data and instructions inside i) local memory, ii) an arbitrary number of nearby processors, iii) on-chip independent memory modules, or iv) off-chip memory. Ah, like GreenArrays' GA144, which contains 144 discrete cores - each with a small amount of memory - that can communicate with each other. The rationale with this chip is that you store data in the memory of one or more neighboring core(s) if it won't fit in the ~64 bytes (IIRC) of the core you're working in.

148 points by lossolo 10y ago

link to press release: https://www.ucdavis.edu/news/worlds-first-1000-processor-chip https://www.ucdavis.edu/news/worlds-first-1000-processor-chi...

imtringued 10y ago

This reminds me of the Ambric am2045 with 336 cores from 2007. They put 40 of these into an X-Ray machine for a total of 13,000 cores. https://en.wikipedia.org/wiki/Ambric https://en.wikipedia.org/wiki/Ambric http://www.embeddedinsights.com/epd/Diagrams/nethra-am2045.jpg http://www.embeddedinsights.com/epd/Diagrams/nethra-am2045.j...

jsizz 10y ago
Yeah whatevs. This reminds me of the ICL DAP with 1024 processors from 1979... https://en.wikipedia.org/wiki/ICL_Distributed_Array_Processor https://en.wikipedia.org/wiki/ICL_Distributed_Array_Processo...
petra 10y ago
There's (1) talking about getting ~60 tflops from ~130k compute elements by 3d assembly of 128mb ram . But it requires microfluidics cooling so it would be very expensive. But in another paper(2), the authors say that offering this chip, even expensively ,could start building the ecosystem and and environment to start a Moore's law like race to solve the heat issue via photonics . (1)https://www.semanticscholar.org/paper/Fft-on-Xmt-Case-Study-of-a-Bandwidth-intensive-Edwards-Vishkin/4f9bd24ea869f64c4457f69ad6d9dc2b3ddb93ac/read/page/7/panel/1 https://www.semanticscholar.org/paper/Fft-on-Xmt-Case-Study-... (2)http://drum.lib.umd.edu/handle/1903/17153 http://drum.lib.umd.edu/handle/1903/17153

willvarfar 10y ago

So how do you program such a beast? What progress is being made on that front? Cache coherency seems really hard to give up on, and even CPU-GPU cache coherency is becoming the expected norm, with even ARM delivering it.

ci5er 10y ago
These people have some grand claims in that regard: - http://texasmulticore.com/ I keep failing to get plans to match up to talk to their CTO on how this would stack up against what a rebuilt (differently optimized) Erlang VM could do... And, yes, I know: Not open source. No one needs to make that clever observation...
RachelF 10y ago
It's very hard. In the mid 1980s there was a CPU called a "Transputer" [1] made some of the people who moved to ARM. These CPUs could be connected together in huge networks and directly talk to each other. The network of CPU's could auto-discover its topology, but coding for so many CPU's was difficult. Some specific algorithms scaled well with the number of CPUs, but most did not. [1] https://en.wikipedia.org/wiki/Transputer https://en.wikipedia.org/wiki/Transputer
- hexane360 10y ago
  Wow, that reminds me of this[1] game. Lots of tiny processors messaging between each other. I didn't realize there were actual implementations. [1]http://store.steampowered.com/app/370360/ http://store.steampowered.com/app/370360/
- jacquesm 10y ago
  Occam did it quite nicely. I think the reason transputers didn't 'make it' is not because they were super hard to program (it was only a little bit harder than programming a regular computer), but because the price premium you paid for a transputer set-up was too high and x86 got faster very rapidly. This is right around the time when the first 386 machines were launched and in a very short time we went from 12-20 MHz 286 boxes (and some 68K machines for the lucky ones) to 33 MHz 386 machines with a ton of RAM. So the advantage that transputers had was eroded very quickly and I don't think INMOS was ready to match pace. Now that we've reached the end of the line for that kind of speed increase we are seeing a renewed interest in multi-cpu fabric architectures, of which the transputer was an instance.
  - 10y ago

foota 10y ago

Does anyone have a link or the name of another weird architecture that was posted a while ago? (~3 months maybe?) I remember that there were a large number of cores that all communicated with each other in some weird way and that they like didn't have main system memory or something like that...

jacquesm 10y ago
Sutherlands 'Fleet'?
- foota 10y ago
  Doesn't look like it... there was an established website for the project. It seemed to have some big names from processor design and such behind it as well (at least from what I gathered on their wikipedia pages ;) ) For future reference, here is a link talking about the arch mentioned so that no one else has to wade through google's results for "fleet architecture": http://arc.cecs.pdx.edu/publications http://arc.cecs.pdx.edu/publications edit: previous (2009) discussion about fleet: https://news.ycombinator.com/item?id=723882 https://news.ycombinator.com/item?id=723882
  - jacquesm 10y ago
    That one?: https://news.ycombinator.com/item?id=11845698 https://news.ycombinator.com/item?id=11845698
elij 10y ago
Maybe this? https://news.ycombinator.com/item?id=11845698 https://news.ycombinator.com/item?id=11845698
- foota 10y ago
  No :/ Thank you both for your suggestions though, they are appreciated :) If it helps it had the same sort of feel as the Mill architecture, in that it was a small project being developed by very enthusiastic people.

mrb 10y ago

It is surprising the paper makes no comparisons with GPUs. So I will do it. For starters it looks like they are talking about integer operations (I only skimmed the paper and it mentions an ALU, not an FPU), whereas my GPU numbers below are single precision floating point numbers. So it is apples vs oranges. So, a modern 14-16nm GPU like the Tesla P100 or RX 480 does about 5 to 10 trillion ops/sec at 200-300 W, and approximately 30 pJ/op. So GPUs are about 5x less power efficient. The paper authors did a good job. However GPUs are not optimized for absolute power efficiency, but mostly for performance per $.

frozenport 10y ago
Cursory Google search shows Pascal GPUs at 10pJ/op for double precision (these guys did int, which should be 10x faster)[1,2] [1] http://wccftech.com/nvidia-pascal-volta-gpus-sc15/ http://wccftech.com/nvidia-pascal-volta-gpus-sc15/ [2] http://prism.sejong.ac.kr/download/PRISM3_paper/PRISM_Ajaykumar_Kannan_presentation_final.pdf http://prism.sejong.ac.kr/download/PRISM3_paper/PRISM_Ajayku...
duckingtest 10y ago
(Dynamic) Power consumption goes up with square of voltage, so a comparison with a gpu's max power efficiency point (almost certainly underclocked and undervolted) could change the comparison significantly.
- stcredzero 10y ago
  Power consumption goes up with square of voltage This needs to become common knowledge amongst nerds and tech types.
  - theparanoid 10y ago
    It was more widely known, when every geek overclocked; no more.
    - stcredzero 10y ago

white-flame 10y ago

I think that http://venraytechnology.com/ http://venraytechnology.com/ is the only high CPU density design I've seen that seems useful for general purpose, large-footprint computing, but their launch model (sell to a DRAM manufacturer and cash out) didn't go anywhere. So many of these tons-of-cores chips can't really do much per chip, and are only suited for streaming algorithms like encryption, data packet routing, video stream processing, etc. They also have nowhere near the memory bandwidth to compare to GPUs, or to feed those many processing units with unique data per unit. Would somebody please think of the memory requirements? :-P (or Venray, please seek investment and start pushing your designs yourself)

chongli 10y ago

Would a language like Erlang make sense for a machine like this? Run 1000s of communicating processes without any shared data.

loxs 10y ago
I don't think Erlang's VM is that optimized. Currently (as far as I remember) the upper limit is to run 1024 schedulers (threads) but I imagine it certainly wont be 10x more efficient than running 100 schedulers on 100 core machine
- qaq 10y ago
  Architecturally it's a perfect match for such CPUs. If you listen to Joe talks he was talking about designing for 1000 core cpus more then 10 years ago. It is his stated opinion that Erlang is perfect match for such situations.
  - loxs 10y ago
    Of course it's (much) better than anything else... though my experience is that it's quite hard to scale your application that much... You always need some shared resource and it gets ugly. And I also suspect Erlang has some implementation quirks (for example the algorithm of deciding which scheduler gets which process) that will prevent it from scaling that much. Yeah, I do believe that some day we'll reach such scalability, probably just not today.
    - qaq 10y ago
      Each scheduler has it's own run queue there is higher level migration logic to balance run queues based on statistics collected.
  - shoover 10y ago
    He's also mentioned FPGAs in similar terms, but I've not seen any news lately on that topic. Is it not practical? Not worth the effort? This is a different ballgame but interesting, a recent Raspberry Pi 2 experiment [1] demonstrated good scaling of an Erlang application on multicore ARM up until the concurrency limit inherent in the application (around 128 processes). [1] - https://medium.com/@pieterjan_m/erlang-pi2-arm-cluster-vs-xeon-vm-40871d35d356#.y68s4ha6n https://medium.com/@pieterjan_m/erlang-pi2-arm-cluster-vs-xe...

greggman 10y ago

I'm certainly hopeful this will lead somewhere useful. Intel tried with Larrabee but apparently couldn't get the perf they wanted, especially with comparisons to GPUs It would be great to know what the trade-offs are with this architecture

alexnewman 10y ago
you mean xeon phi. I think it's still around. It is plenty fast, but not much better tdp than a gpu (which are commodity (read this as cheap)).
- deadgrey19 10y ago
  Xeon Phi is around and used in various financial computations. The problem with GPUs is not TDP, but programming flexibility. Programming a GPU is very hard to do well for generic computations, whereas x86 like CPUs have millions of programmers who can do a pretty decent job.
- CyberDildonics 10y ago
  The Xeon Phi was never meant to compete with GPUs directly. The first version was underwhelming and expensive but used in order cores. The next version is actually available to buy as some sort of limited release. It has out of order cores and 144 512 bit SIMD units (2 per core * 72 cores). The full box costs $5000 last time I checked.

nickpsecurity 10y ago

It's important for people to know these are eight bit CPU's. Least, that's what every other incarnation has been. https://en.m.wikipedia.org/wiki/Kilocore https://en.m.wikipedia.org/wiki/Kilocore Asking what to do with 1,000 32- or 64-bit cores != 1,000 8-bit cores. Suddenly the value proposition doesnt seem so great. Such designs were used successfully, though, in both neural networks and genetic algorithms. Could probably handle stuff well that normally goes on DSP's.

mntmn 10y ago

Where can I buy a sample?

JoeAltmaier 10y ago

Thinking out loud. Instead of imagining applications per processor, I imagine this device could map threads or message handlers to processors. It could work better with a functional language or at least some language that didn't explicitly manage parallelism in code but rather in the runtime. Offload the app writer to just coding algorithm and not thread synchronization. E.g. imagine each timer wait being a processor spinning; each I/o loop being a processor that blocked/looped on an I/o pin state. With so many processors to schedule, it wouldn't stall application progress to spin or block an individual strand (until you ran out or processors). To make this efficient, they'd want interrupts and semaphore state to be hardware-supported. Instead of polling a memory location, block on a shared register masked where each bit was a condition. So instead of a 'kernel call' it'd be an opcode or small loop. Latency of wakeup then becomes about 1 machine cycle. I imagine with the right runtime support this could be a useful device for a large I/o server. It could reduce latency of processing each client message to just the execution time. No time burned in kernel calls, process switching, stack copying, interrupt/event latency.

endergen 10y ago
I'm an ex game engine developer and I bristle anytime anyone thinks any existing functional language is better for multicore. Specifically garbage collection alone will make any language an order of magnitude slower generally per a single core. Also the C/C++ game development community at least has great approaches to multicore which makes C/C++ linearly scale with scores to boot, see for example: http://www.gdcvault.com/play/1022186/Parallelizing-the-Naughty-Dog-Engine http://www.gdcvault.com/play/1022186/Parallelizing-the-Naugh.... I love functional languages, more for thinking in them, prototyping ideas, especially compilers/visualizers, and etc. But for any language that adds garbage collection, immutable data structures (way more operations per write and crazy memory thrashing/alignment issues), unless used sparsely or in a mixed paradigm (ugh, except maybe scala/clojure) are going to pay a magnitude of performance loss. Mind you there are tricks around using more system languages (C/C++/Rust/D etc) for a lot of the heavy lifting with the application core being functional that gets you closer to the best of both worlds.
- geon 10y ago

beagle3 10y ago

AIseek[0] had 10,000 processor chip in 2006, with simple connectivity and simple ops that were perfectly matched for graph algorithms. Their demo[1] would not be impressive today, but doing it in real time in 2006 was quite a feat and basically impossible without specialized hardware. Unfortunately, they're no longer in business. [0] http://www.extremetech.com/extreme/75766-new-ai-chip-would-make-games-smarter http://www.extremetech.com/extreme/75766-new-ai-chip-would-m... [1] https://www.youtube.com/watch?v=VeSQI2hinp0 https://www.youtube.com/watch?v=VeSQI2hinp0

samfisher83 10y ago

The paper doesn't really explain how the its suppose to handle memory. You have a 1000 processors and 12 modules with 64KB ram. Now if you have to access real ram how will that be done? You would need a massive bus like a GPU so you could keep all the chips with data to do work. How do you keep the processors starving for data. I understand its an academic project, but I wish they would explain what the real life use of this thing would be? Here is another project I found: https://en.wikipedia.org/wiki/Kilocore https://en.wikipedia.org/wiki/Kilocore Not the same thing, but I wonder how much they sold? More like like 1000 small processing units instead of full cpu.

ableal 10y ago

Dug around a bit for the paper, found this 2 page PDF: http://vcl.ece.ucdavis.edu/pubs/2016.06.vlsi.symp.kiloCore/2016.vlsi.symp.kiloCore.pdf http://vcl.ece.ucdavis.edu/pubs/2016.06.vlsi.symp.kiloCore/2...

rntz 10y ago

Arguably the first 1000-processor chip was the CM-1, made in the 1980's: https://en.wikipedia.org/wiki/Connection_Machine https://en.wikipedia.org/wiki/Connection_Machine They also bury the lede somewhat. Apparently the KiloCore is a 1.78 Terahertz chip: > The energy-efficient “KiloCore” chip has a maximum computation rate of 1.78 trillion instructions per second Edit: they later say it's 1.78 GHz. I guess "trillion" is just a mistake?

deadgrey19 10y ago
Maybe they mean "effective" speed. 1000x 1.78GHz = 1.78THz. Assuming a job is embarrassingly parallel it might be an ok metric. Realistically, probably not.
mafuyu 10y ago
Instructions Per Second is different from the clock speed. In this case, it looks like each core is ~1 Instruction Per Clock, so 1 * 1.78 GHz * 1000 cores. The trick is that getting 1.78 trillion IPS distributed over 1000 cores is very different from getting that over a few cores.
CyberDildonics 10y ago
... 1.78 GHz * 1000 processors ?
simonster 10y ago
According to the link, the CM-1 had 16 processors on a chip, but there were a lot of chips (up to 4096 to yield up to 65536 processors). Still, the programming paradigms that were used for the Connection Machine might be useful for the massively parallel chip described here.
jacquesm 10y ago
That wasn't a chip.
tlrobinson 10y ago
Saying 1000 cores running at 1.78 GHz are a "1.78 THz chip" is a bit like saying 1000 cars driving at 65 mph are a "65,000 mph car"

mpweiher 10y ago

This sort of thing, taken to even greater extremes, could be an interesting match to Actor languages, with an actor mapped to a processor. The overhead would be likely be ridiculous, as most actors would be blocked most of the time. However, if it is true that we are now able to put a lot more transistors on a chip than we can power, that might actually be a feature rather than a bug. Assuming that power management is awesome and these actor-processors consume little or no energy when blocked, the power/performance ratio for most application should be awesome.

i336_ 10y ago

> KiloCore processors ... store data and instructions inside i) local memory, ii) an arbitrary number of nearby processors, iii) on-chip independent memory modules, or iv) off-chip memory. Ah, like GreenArrays' GA144, which contains 144 discrete cores - each with a small amount of memory - that can communicate with each other. The rationale with this chip is that you store data in the memory of one or more neighboring core(s) if it won't fit in the ~64 bytes (IIRC) of the core you're working in.