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

31–40 of 58 posts

Re: Startup to Open-Source Parallel CPU

#31

Post by nkurz »

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 Intel's smaller process would make it difficult to match.

[1] It feels awkward that this sentence is included twice on such a short page.

Re: Startup to Open-Source Parallel CPU

#32

Post by trsohmers »

lavomme wrote: post #28

First of all, good luck for you guys. I've worked in a start-up company similar to your company. We developed a 256-cores RISC processor, only shared memory was used between all the cores instead of a mash-up of a memory block for each core and DMA for transactions. How do you intend to synchronize work between the different cores? How a compiler will abstract away the memory synchronizations? Which programming langu…

Thanks! If you don't mind me asking, what was the name of the company?

Technically, you don't need to synchronize the cores... it's a MIMD/MPMD system that is not in lockstep. It is up to the programmer (with help from the compiler) to make sure you don't do anything too stupid ;) As for the programming languages, C and Fortran are the big ones to us. We hope once our LLVM backend is improved, you'll be able to run anything you like on the cores themselves. As for the programming model, the three we like the best are CSP (Go), Actor (Erlang), and PGAS (C, Fortran, Chapel, a few other research ones). If you're familiar with SHMEM, that's the closest thing we can think of currently.

When it comes to cost, we're trying to develop as much ourselves to reduce licensing costs. We've been able to do a pretty good job (if I do say so myself) as just two people so far with no capital. Fabrication costs are the killer, with it being about ~$500k per shuttle run, and $5m-$7m for a mask set when we actually go to full production.

Re: Startup to Open-Source Parallel CPU

#33

Post by vardump »

trsohmers wrote: post #11
vardump wrote: post #4

I wonder what kind of penalties there are for transmitting data to neighboring nodes. Same for receiving. If every node does for example receives data from a neighboring node, does a single fused multiply-add and transmits the result to a neighboring node, how many FLOPS you get out of the whole thing? How big chunks of computation you need to do in a node for this to be effective?

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?

Re: Startup to Open-Source Parallel CPU

#34

Post by trsohmers »

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-64 cores.

Intel has not released the official die size for the Phi, but has said it is about ~5 billion transistors (at a 22nm process), and independent "guesstimates" have pegged the die at 600-700mm2 (there is one place that says 350mm2, but that is false). For the top of the line 61 core Xeon Phi, it uses 300W, with a theoretical peak performance of 1.2TFLOP of double precision performance. That gets you to about 4GFLOP/Watt.

In comparison, our entire will be under 100 million gates, with each core (excluding memory) being around 100k gates. At a 28nm process, our core size (without memory) is a little under 0.1mm2. Our theoretical peak performance per compute chip is 256 GFLOPs double precision, while it should be using around 3 Watts, giving us a performance per watt ratio of ~85GFLOPs/Watt.

Intel has even said that their next generation Xeon Phi, made at their 14nm process, will be at 14 to 16GFLOPs/Watt. At SC14 last week, they made a soft announcement for the following generation at 10nm process will be in the ~2018 timeframe, and that is estimated at only being around 25GFLOPs/Watt.

The bottom line is Intel is just following Moore's law, and is sticking to big and complex systems, which while retaining legacy compatibility, kill you when it comes to efficiency.

Re: Startup to Open-Source Parallel CPU

#35

Post by mechagodzilla »

trsohmers wrote: post #30
asb wrote: post #25

Earlier quoted context omitted.

Thanks for the answer. Another quick question. One of the limitations of parallela is the offchip memory bandwidth. Will you be integrating a third party phy?

Our chip-to-chip bandwidth is currently 48GB/s per parallel interface, and we have 8 of those per chip (2 per side), giving us an aggregate bandwidth of 384GB/s. The Epiphany 4's interfaces are 1.5GB/s serial (12.5Gb serdes), and there are 4 of those per chip, giving you an aggregate bandwidth of 6GB/s. If you can spend a bit more power (or wait for 14/16nm process), we think it is possible to double that to 96GB/s p…

Can you provide some more details on your parallel interface? As an ASIC designer, these numbers sound extremely fishy for a non-serdes interface. A 128-bit parallel interface (which is a lot of pins, especially if you need 8 links) would need to be running at 3 GHz, for instance, to hit that. Is it differential/single-ended? Source-synchronous? How big of a package are you planning?

Re: Startup to Open-Source Parallel CPU

#36

Post by lavomme »

trsohmers wrote: post #32
lavomme wrote: post #28

First of all, good luck for you guys. I've worked in a start-up company similar to your company. We developed a 256-cores RISC processor, only shared memory was used between all the cores instead of a mash-up of a memory block for each core and DMA for transactions. How do you intend to synchronize work between the different cores? How a compiler will abstract away the memory synchronizations? Which programming langu…

Thanks! If you don't mind me asking, what was the name of the company? Technically, you don't need to synchronize the cores... it's a MIMD/MPMD system that is not in lockstep. It is up to the programmer (with help from the compiler) to make sure you don't do anything too stupid ;) As for the programming languages, C and Fortran are the big ones to us. We hope once our LLVM backend is improved, you'll be able to run a…

http://plurality.com/ - website is not very good and the company is dead. You can read more information in wikipedia: https://en.wikipedia.org/wiki/Plurality_%28company%29

All our cores shared the same memory for both data and instruction and we based our synchronization of work-load on a hardware instead of software. It yielded such a huge speedup for execution time that most of the companies simply ignored our results as fake. :)

Choosing a programming language is crucial - we went with C and a declaration language for tasks. Today (4 years after we closed the company) I am not sure whether it was the best decision. The simpler the parallel definition in code the better. Programmers as getting confused easily.

Re: Startup to Open-Source Parallel CPU

#37

Post by mechagodzilla »

trsohmers wrote: post #20
trsohmers wrote: post #8

Earlier quoted context omitted.

Custom ISA that we have developed... we developed it in parallel to RISCV (before they released their public 2.0 ISA), but we have diverged a bit... we are a static 64 bit ISA, have no options to have VLIW expandability, our FPU (and thus its instructions) are able to do two single precision IEEE754-2008 FLOPs per cycle, and one double precision per cycle. We have also added a set of DMA instructions. We currently ha…

I realized I didn't fully answer the chip-to-chip interconnect questions... it is an extremely simple parallel interface (that I would not even call a "bus", as that is assuming it has a lot more control logic than it has). Instead of having a full serdes per lane, our solution is to use a very simple latch and buffer, along with PLLs on each chip to have a MUCH (50-70%) smaller and more power effecient point-to-poin…

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.

Re: Startup to Open-Source Parallel CPU

#38

Post by trsohmers »

mechagodzilla wrote: post #37
trsohmers wrote: post #20

Earlier quoted context omitted.

I realized I didn't fully answer the chip-to-chip interconnect questions... it is an extremely simple parallel interface (that I would not even call a "bus", as that is assuming it has a lot more control logic than it has). Instead of having a full serdes per lane, our solution is to use a very simple latch and buffer, along with PLLs on each chip to have a MUCH (50-70%) smaller and more power effecient point-to-poin…

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...

Re: Startup to Open-Source Parallel CPU

#39

Post by trsohmers »

mechagodzilla wrote: post #35
trsohmers wrote: post #30

Earlier quoted context omitted.

Our chip-to-chip bandwidth is currently 48GB/s per parallel interface, and we have 8 of those per chip (2 per side), giving us an aggregate bandwidth of 384GB/s. The Epiphany 4's interfaces are 1.5GB/s serial (12.5Gb serdes), and there are 4 of those per chip, giving you an aggregate bandwidth of 6GB/s. If you can spend a bit more power (or wait for 14/16nm process), we think it is possible to double that to 96GB/s p…

Can you provide some more details on your parallel interface? As an ASIC designer, these numbers sound extremely fishy for a non-serdes interface. A 128-bit parallel interface (which is a lot of pins, especially if you need 8 links) would need to be running at 3 GHz, for instance, to hit that. Is it differential/single-ended? Source-synchronous? How big of a package are you planning?

(Copied from another comment on this page):

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....

Re: Startup to Open-Source Parallel CPU

#40

Post by [deleted] »

mechagodzilla wrote: post #35
trsohmers wrote: post #30

Earlier quoted context omitted.

Our chip-to-chip bandwidth is currently 48GB/s per parallel interface, and we have 8 of those per chip (2 per side), giving us an aggregate bandwidth of 384GB/s. The Epiphany 4's interfaces are 1.5GB/s serial (12.5Gb serdes), and there are 4 of those per chip, giving you an aggregate bandwidth of 6GB/s. If you can spend a bit more power (or wait for 14/16nm process), we think it is possible to double that to 96GB/s p…

Can you provide some more details on your parallel interface? As an ASIC designer, these numbers sound extremely fishy for a non-serdes interface. A 128-bit parallel interface (which is a lot of pins, especially if you need 8 links) would need to be running at 3 GHz, for instance, to hit that. Is it differential/single-ended? Source-synchronous? How big of a package are you planning?

[deleted]
Post reply on HN