Earlier quoted context omitted.
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…
Garbage collection is not slow. 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…
A 32nm 1000-Processor Array
71–80 of 107 posts
Re: A 32nm 1000-Processor Array
#72Arguably 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?
Re: A 32nm 1000-Processor Array
#73Arguably 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?
Re: A 32nm 1000-Processor Array
#74Thinking 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…
> So instead of a 'kernel call' it'd be an opcode or small loop. Like a Wait For Interrupt instruction? If all idle processors sleep, I imagine it could save some power as well.
Existing OSs use a kernel call to wait, because they want to manage the (tiny number of) hyperthread(s) closely. But with essentially unlimited hyperthreads, they can manage themselves! And avoid the whole kernel-round-trip latency.
Re: A 32nm 1000-Processor Array
#75Does 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...
Videos:
https://www.youtube.com/channel/UCKdGg6hZoUYnjyRUb08Kjbg/
The Mill CPU Architecture – The Compiler [video] (youtube.com):
https://news.ycombinator.com/item?id=9856334
Wiki:
Re: A 32nm 1000-Processor Array
#76Arguably 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?
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"
I wouldn't say they are a 1.78THz chip or 65KMPH car, but like them.
Re: A 32nm 1000-Processor Array
#77Earlier quoted context omitted.
I think that the concept of purity, present mostly in functional languages, helps a lot for writing parallellizable (?) code. My naive assumption would be that pure code could be adapted for a 1000-core machine with only changes to the compiler and runtime environment. That said, few things in CS are written with this kind of parallellism in mind: even most algorithms' pseudocode is written in imperative style, and a…
> My naive assumption would be that pure code could be adapted for a 1000-core machine with only changes to the compiler and runtime environment. Perhaps for use cases where current, garbage collected languages are suitable. For areas where (today) asm/c/c++/rust is a must, you would need a functional language that can give you guarantees about garbage generation, so you can be sure you won't need to collect garbage,…
That's the entire point of the "purity" idea. Pure FP languages give you very strict guarantees about garbage generation.
The only question is if everyday code has enough pure code to fill a 1000 cores processor.
Re: A 32nm 1000-Processor Array
#78It 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 a…
(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.
This needs to become common knowledge amongst nerds and tech types.
Re: A 32nm 1000-Processor Array
#79Earlier quoted context omitted.
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"
It is. But while it sounds absurd, there are cases where it makes sense. For loads that are parallelizable, both the 1.78 THz chip and 65KMPH car make sense for similes. I wouldn't say they are a 1.78THz chip or 65KMPH car, but like them.
I think this makes even less sense as we go to 1,000 processing elements -- even Amdahl's law is too optimistic for the workloads deployed in these scenarios (i.e., having an embarrassingly parallel computation workload doesn't help if we still need to access memory, including going through the shared interconnect(s) to do this, while also keeping cache coherence in mind--and most workloads have phases that have to be synchronized, assuming we eventually want to write the results of our computation somewhere): http://blogs.msdn.com/b/ddperf/archive/2009/04/29/parallel-s...
Re: A 32nm 1000-Processor Array
#80Earlier quoted context omitted.
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"
It is. But while it sounds absurd, there are cases where it makes sense. For loads that are parallelizable, both the 1.78 THz chip and 65KMPH car make sense for similes. I wouldn't say they are a 1.78THz chip or 65KMPH car, but like them.
hertz and instructions are not the same thing. do you know what a data pipeline is, lady?