Adapteva founder promises 4,000-cores with new Epiphany architecture
1–10 of 11 posts
Re: Adapteva founder promises 4,000-cores with new Epiphany architecture
#2anyone have more info? their site http://www.adapteva.com/index.php doesn't have much (no white papers)
Re: Adapteva founder promises 4,000-cores with new Epiphany architecture
#3This is actually a Transputer, side view.
This will suffer from many Transputer's sins and some new ones.
I did a research on chip interconnects, the uniform grid interconnect had shown some unpleasant behaviours, like sudden deadlocks.
Re: Adapteva founder promises 4,000-cores with new Epiphany architecture
#4>Olofsson has a new idea - or, specifically, a variation on an old one...it was common for a central processor to have a 'math co-processor' chip alongside it - a secondary processor which was designed specifically to carry out floating point arithmetic at speeds significantly faster than the main processor
This is exactly how people are currently using GPUs right now. How is this architecture better than a Fermi?
>"A guy straight out of college who's done a course in C programming can take a program and run it on our machine. There's no new constructs to run - you can take a program with legacy code and run it straight out of the box on our machine, and you can't do that on GPU."
If they're using only static compilation, this is very unlikely to be true. A few thousand Ph.D. theses have been sunk into parallelizing imperative programs. Despite the accumulation of sophisticated compiler techniques, it doesn't really work without extensive annotations and cooperation from the programmer. The programmer often ruins potential parallelism by accidentally creating dependencies between loop iterations. Even when analyzing ideal code, the program text doesn't contain sufficient information about the data size to create a good partition.
However, there's some small chance this isn't empty hype and they've actually made some cool breakthrough in runtime parallelization of imperative code. In that case, though, why would they be hyping vaporous hardware rather than just applying their fancy JIT compiler to existing multicore systems?
Re: Adapteva founder promises 4,000-cores with new Epiphany architecture
#5>Olofsson has a new idea - or, specifically, a variation on an old one...it was common for a central processor to have a 'math co-processor' chip alongside it - a secondary processor which was designed specifically to carry out floating point arithmetic at speeds significantly faster than the main processor This is exactly how people are currently using GPUs right now. How is this architecture better than a Fermi? >"…
I too doubt that they have any thing new with regard to parallelization of imperative programs. If the only way to utilize all cores is either by writing functionally or by manual parallelization then they don't really have a significant advantage over FPGA coprocessors. I do agree with them however when they say that this approach is better than creating lots of general purpose cores.
Re: Adapteva founder promises 4,000-cores with new Epiphany architecture
#6>Olofsson has a new idea - or, specifically, a variation on an old one...it was common for a central processor to have a 'math co-processor' chip alongside it - a secondary processor which was designed specifically to carry out floating point arithmetic at speeds significantly faster than the main processor This is exactly how people are currently using GPUs right now. How is this architecture better than a Fermi? >"…
"A few thousand Ph.D. theses have been sunk into parallelizing imperative programs."
This waste of talent continues to piss me off to no end. Why would people willingly spend time on this problem?
Re: Adapteva founder promises 4,000-cores with new Epiphany architecture
#7>Olofsson has a new idea - or, specifically, a variation on an old one...it was common for a central processor to have a 'math co-processor' chip alongside it - a secondary processor which was designed specifically to carry out floating point arithmetic at speeds significantly faster than the main processor This is exactly how people are currently using GPUs right now. How is this architecture better than a Fermi? >"…
I too doubt that they have any thing new with regard to parallelization of imperative programs. If the only way to utilize all cores is either by writing functionally or by manual parallelization then they don't really have a significant advantage over FPGA coprocessors. I do agree with them however when they say that this approach is better than creating lots of general purpose cores.
What no one has mentioned is that 4000 stacks is a lot of memory.
Re: Adapteva founder promises 4,000-cores with new Epiphany architecture
#8Okay I Olofsson completely failed to establish ethos with me when he called MIPS a "great architecture" Anybody who has done systems programming on MIPS knows how painful it is (particularly in pre V2)
Re: Adapteva founder promises 4,000-cores with new Epiphany architecture
#9Earlier quoted context omitted.
I too doubt that they have any thing new with regard to parallelization of imperative programs. If the only way to utilize all cores is either by writing functionally or by manual parallelization then they don't really have a significant advantage over FPGA coprocessors. I do agree with them however when they say that this approach is better than creating lots of general purpose cores.
What no one has mentioned is that 4000 stacks is a lot of memory.
Not if they're done as split/segmented stacks (http://gcc.gnu.org/wiki/SplitStacks)-- basically, you have a collection of 4KB stack pages for each thread instead of one large up-front allocation, and you grow it as needed. It costs a few instructions per function entry/exit, but overall cost is negligible and it allows you to run thousands of coroutines without issues.
Re: Adapteva founder promises 4,000-cores with new Epiphany architecture
#10Earlier quoted context omitted.
What no one has mentioned is that 4000 stacks is a lot of memory.
Not if they're done as split/segmented stacks ( http://gcc.gnu.org/wiki/SplitStacks)-- basically, you have a collection of 4KB stack pages for each thread instead of one large up-front allocation, and you grow it as needed. It costs a few instructions per function entry/exit, but overall cost is negligible and it allows you to run thousands of coroutines without issues.
If you allocate the stacks contiguously using mmap then memory is only used as it is accessed. That's not the problem. The problem is that 4000 concurrent non-trivial threads is a resource hog no matter how the stacks are allocated.