61–70 of 107 posts
Arguably the first 1000-processor chip was the CM-1, made in the 1980's: 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?
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
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)).
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…
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…
Actually it's probably the fastest dynamic allocation method. Allocating data with a copying garbage collector is O(1), which is as fast as allocating something on the stack, while malloc() is usually O(log(n)) with n being the number of live objects in the heap.
Running a collection on a such GC is usually O(n), with n begin the number of live objects. This is way faster than calling free() on each allocated object, but slower than using the stack.
They idea that languages that rely on a garbage collector are slower is not really due to the garbage collector, but to the fact that they allocate way too much on the heap (I'm looking at you, Java). C/C++/Rust are awesome because they allow you to control way more where data is allocated. Also, it's theoretically possible for a compiler in a functional programming language to decide to allocate on the stack instead of the heap.
Another issue is that the time is will take to execute the collection can be unpredictable. It can happen that the GC will stop the entire program for a few milliseconds every few seconds. This is highly undesirable for realtime applications such as video-games.
Arguably the first 1000-processor chip was the CM-1, made in the 1980's: 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?
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.
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…
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…
Functional programming languages do not _require_ a GC. They just largely have it.
"Fibers" like you linked in the presentation (m:n green thread scheduling) have been in use for decades. Many, many languages other than C++ have had them for over a decade. Go is built on them.
Functional languages _can be_ better for multicore because of referential transparency. As a game dev you are used to working on 4-8 cores. Some of us work on 40-80 cores * 10k machines and have been for years. Much of your complaints such as immutable data overhead make sense if it let's you work on 10x more cores at the same time. I will also point out that immutable data _really_ is not 10x slower, unless you think those Haskell micro bench marks are all lies.
Earlier quoted context omitted.
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
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.
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-xe...
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.
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/T…
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.
- http://texasmulticore.com/
And, yes, I know: Not open source. No one needs to make that clever observation...
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
Not the same thing, but I wonder how much they sold? More like like 1000 small processing units instead of full cpu.