Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Startup to Open-Source Parallel CPU

eetimes.com

Post reply on HN
Print view View original

41–50 of 58 posts

Re: Startup to Open-Source Parallel CPU

#41

Post by nkurz »

trsohmers wrote: post #34
nkurz wrote: post #31

Unlike GPUs and other SIMD accelerators, Neo's MIMD processor design leverages independent program counters and instruction registers in each core to allow different operations to be performed in parallel on separate pieces of data. [1] Other than the grid interconnect, how does the architecture differ from Xeon Phi? In particular, what allows it to get such dramatically higher power efficiency? I'd have guessed that…

Thanks for that... didn't notice that we had a repeated section (I just updated it with the proper text for that section) As for comparison to the Phi... it is the fact that our actual core size (and thus the whole chip) is MUCH smaller. The Phi's cores are actually based on the original Pentium architecture (they are just downsized P54Cs) with added AVX instructions. Contrary to popular belief, they are not full x86…

Interesting, and a great answer. The usual estimates I've seen put the power efficiency overhead of the legacy x86 layer to be small enough to not be a major factor (http://research.cs.wisc.edu/vertical/papers/2013/hpca13-isa-...). But I suppose as you shrink the core smaller and smaller, that small mostly-fixed difference becomes a greater and greater part of the total power budget.

Re: Startup to Open-Source Parallel CPU

#42

Post by trsohmers »

nkurz wrote: post #41
trsohmers wrote: post #34

Earlier quoted context omitted.

Thanks for that... didn't notice that we had a repeated section (I just updated it with the proper text for that section) As for comparison to the Phi... it is the fact that our actual core size (and thus the whole chip) is MUCH smaller. The Phi's cores are actually based on the original Pentium architecture (they are just downsized P54Cs) with added AVX instructions. Contrary to popular belief, they are not full x86…

Interesting, and a great answer. The usual estimates I've seen put the power efficiency overhead of the legacy x86 layer to be small enough to not be a major factor ( http://research.cs.wisc.edu/vertical/papers/2013/hpca13-isa-... ). But I suppose as you shrink the core smaller and smaller, that small mostly-fixed difference becomes a greater and greater part of the total power budget.

I discredit most people who continue the RISC/CISC debate to this day (As Intel forfeited in ~2006... all modern x86 processors are actually RISC processors. They are RISC at the lowest level, and just decode x86 instruction and translate them into Intel RISC microcode).

Then again, I don't think most popular "RISC" CPUs are very RISC like (Does that make me a RISC hipster?). While making things general purpose, there is no reason for ARM processors to be OoO, do branch prediction/speculative execution, or any more of these crazy things... it reduces efficiency in the long run.

Take a look at this for instance: http://chip-architect.com/news/2013_core_sizes_768.jpg ... an AMD CPU and ARM chip are virtually the same size at the same process node. I find it insane that one of our cores is a bit less than 1/5th of the size of a cortex A7, and can do more FLOPs than it. Then again, we have focused on doing that, but still.

Re: Startup to Open-Source Parallel CPU

#43

Post by fpp »

trsohmers wrote: post #2

I'm the founder and CEO of REX... Check out our website for a brief overview ( http://rexcomputing.com ) and feel free to ask questions here!

Very impressive.

How does this compare to other multi-core processors / architectures e.g. epiphany http://www.adapteva.com/introduction/

Re: Startup to Open-Source Parallel CPU

#44

Post by trsohmers »

fpp wrote: post #43
trsohmers wrote: post #2

I'm the founder and CEO of REX... Check out our website for a brief overview ( http://rexcomputing.com ) and feel free to ask questions here!

Very impressive. How does this compare to other multi-core processors / architectures e.g. epiphany http://www.adapteva.com/introduction/

There are a lot, and I would recommend reading through this page... the basics on Epiphany (and the same can be said about most others) is the fact that we designed from the start to have a very high memory/IO bandwidth (both on and off chip), stuck to RISC, and focused on floating point (one of the few architectures in this area being fully IEEE compliant with this high of a performance per watt ratio).

Re: Startup to Open-Source Parallel CPU

#45

Post by nkurz »

trsohmers wrote: post #42
nkurz wrote: post #41

Earlier quoted context omitted.

Interesting, and a great answer. The usual estimates I've seen put the power efficiency overhead of the legacy x86 layer to be small enough to not be a major factor ( http://research.cs.wisc.edu/vertical/papers/2013/hpca13-isa-... ). But I suppose as you shrink the core smaller and smaller, that small mostly-fixed difference becomes a greater and greater part of the total power budget.

I discredit most people who continue the RISC/CISC debate to this day (As Intel forfeited in ~2006... all modern x86 processors are actually RISC processors. They are RISC at the lowest level, and just decode x86 instruction and translate them into Intel RISC microcode). Then again, I don't think most popular "RISC" CPUs are very RISC like (Does that make me a RISC hipster?). While making things general purpose, ther…

Your .1 mm^2 was without memory, right? I don't know the exact numbers, but to be fair, the ratio does become somewhat closer when you discount the area on the A7 used for memory: http://www.arm.com/images/Single_Cortex-A7_core_layout_image...

Re: Startup to Open-Source Parallel CPU

#46

Post by mng2 »

trsohmers wrote: post #38
mechagodzilla wrote: post #37

Earlier quoted context omitted.

I asked this previously without seeing that you had answered it here. So you're claiming to have a parallel interface without a SERDES running at 64-bits at 6 Gb/s? How are you maintaining bit alignment between lanes? Do you have any in-line signal conditioning or anything (CTLE, DFE, etc.)? Parallel interfaces are rarely run faster than 1 Gb/s, so 6 Gb/s sounds unlikely.

Relevant paper (by Intel Research, actually)... there are quite a few differences (we are keeping it a lot simpler on the tx and rx ends, but that is some of our secret sauce... I can talk about it offline if you are really interested) http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=648778...

Going over 50 cm of Twinax is great and all, but that's the ideal environment. When you guys put 16 of these things on a board, routing that PCB and getting good signal integrity is not going to be fun, even after you throw in pre-emphasis and so on.

Re: Startup to Open-Source Parallel CPU

#47

Post by trsohmers »

vardump wrote: post #33
trsohmers wrote: post #11

Earlier quoted context omitted.

Our theoretical double precision FLOPs (based on running at 1GHz) per core is 1GFLOP per second, but that is based on doing an add or a multiply. In the case of just doing FMAs, you would be doing 1.5GFLOP. This gives you (theoretical peak) 256 to 384 double precision GFLOPs per chip. Our bandwidth between cores is 16GB/s, while the required bandwidth for doing 1GFLOP is 8GB/s. Our single precision numbers are actual…

So how many I can do if for each FMA I also receive 16 bytes of data from a neighboring node and send 16 bytes of data to a neighboring node? Or is the data transfer free, is the neighboring node memory mapped? If so, how does synchronization work? Edit: didn't notice same was asked before too. Regardless, how many FMAs can be executed in the scenario I gave, also sending 16 bytes and receiving 16 bytes for each FMA?

The superscalar design means Load/Store unit can operate independently from FMA and DMA units, i.e. FMA operation on register operands will not interfere with other operations elsewhere on the chip.

Synchronization should be handled in a dataflow-driven program design. Any sort of mutex/semaphore/etc. will have to be software defined or interrupt-driven.

In regards to neighboring node being memory mapped... are you asking about another compute chip or another node (with the 16 compute chips + GaMMU)? All of the compute chips in a grid are part of the same flat global memory map, and have DMA capabilities between each other. Once you get out of the compute grid (that is managed by the GaMMU), then that is a separate memory space, but can be accessed through some other layer through something like MPI, for instance.

Re: Startup to Open-Source Parallel CPU

#48

Post by trsohmers »

nkurz wrote: post #45
trsohmers wrote: post #42

Earlier quoted context omitted.

I discredit most people who continue the RISC/CISC debate to this day (As Intel forfeited in ~2006... all modern x86 processors are actually RISC processors. They are RISC at the lowest level, and just decode x86 instruction and translate them into Intel RISC microcode). Then again, I don't think most popular "RISC" CPUs are very RISC like (Does that make me a RISC hipster?). While making things general purpose, ther…

Your .1 mm^2 was without memory, right? I don't know the exact numbers, but to be fair, the ratio does become somewhat closer when you discount the area on the A7 used for memory: http://www.arm.com/images/Single_Cortex-A7_core_layout_image...

That is correct, but even with memory we should only be around .2mm^2 to .3mm^2, while having 4x the SRAM as the Cortex-A7.

Re: Startup to Open-Source Parallel CPU

#49

Post by mechagodzilla »

trsohmers wrote: post #38
mechagodzilla wrote: post #37

Earlier quoted context omitted.

I asked this previously without seeing that you had answered it here. So you're claiming to have a parallel interface without a SERDES running at 64-bits at 6 Gb/s? How are you maintaining bit alignment between lanes? Do you have any in-line signal conditioning or anything (CTLE, DFE, etc.)? Parallel interfaces are rarely run faster than 1 Gb/s, so 6 Gb/s sounds unlikely.

Relevant paper (by Intel Research, actually)... there are quite a few differences (we are keeping it a lot simpler on the tx and rx ends, but that is some of our secret sauce... I can talk about it offline if you are really interested) http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=648778...

Getting anything approximating Intel's work, assuming you are rolling all your own IP, is pretty ambitious (and probably a good deal more work than your Core design). Even at only 6 Gbit/s (faster than PCIe Gen2, btw). Just curious - have you ever taped out a chip on a modern process before?

Re: Startup to Open-Source Parallel CPU

#50

Post by Taniwha »

trsohmers wrote: post #42
nkurz wrote: post #41

Earlier quoted context omitted.

Interesting, and a great answer. The usual estimates I've seen put the power efficiency overhead of the legacy x86 layer to be small enough to not be a major factor ( http://research.cs.wisc.edu/vertical/papers/2013/hpca13-isa-... ). But I suppose as you shrink the core smaller and smaller, that small mostly-fixed difference becomes a greater and greater part of the total power budget.

I discredit most people who continue the RISC/CISC debate to this day (As Intel forfeited in ~2006... all modern x86 processors are actually RISC processors. They are RISC at the lowest level, and just decode x86 instruction and translate them into Intel RISC microcode). Then again, I don't think most popular "RISC" CPUs are very RISC like (Does that make me a RISC hipster?). While making things general purpose, ther…

I think it's fair, despite long-time predjudices - to think of the x86 architecture to be midway between RISC and CISC - most instructions (push/etc being the notable exception) make a single memory reference and no addressing mode does a memory indirect or has addressing side effects (auto incs/etc)- that means that instructions are retryable (don't ever need to be able to be restarted in the middle after a page fault) with a single dcache/TLB port
Post reply on HN