Live data from Hacker News

Forth Inventor Chuck Moore's $20 144 core CPU now in full production

greenarraychips.com

51–60 of 100 posts

Re: Forth Inventor Chuck Moore's $20 144 core CPU now in full production

#51
post #17

The Propeller chip http://www.parallax.com/propeller/ is another embedded market chip in the same vein although nowhere near as many cores. Having something like this make for some interesting embedded designs. Also, check the site for the arrayForth stuff. On another note, it would be interesting if something like these existed in the 64-bit size. Larrabee is interesting, but if it was a simpler stack machine at aro…

Tilera does a 64-bit CPU with 64/100cores.If they would offer access to it using a pay-per-hour model, that would be interesting.

I spoke to one of the Tilera guys a few years back about evaluating their boards for use in a telco project I was working on at the time, but gave up because I wasn't prepared to drop $15K on a development board just to evaluate it.

The technology itself was extremely interesting, though, and would probably have been a good fit for what I was doing. Also, the cost of the dev board included technical support and from speaking to the guy, I got the impression that they actually help you port your code to their platform.

Re: Forth Inventor Chuck Moore's $20 144 core CPU now in full production

#52
post #36

Earlier quoted context omitted.

Unfortunately for the FPGA guys, it seems like in general the closer they get to CPUs the less compelling their product becomes.

I hesitate to divide the world into "FPGA guys" and "non-FPGA guys". It's a continuum of computing power; CPU DSP FPGA, and one moves up and down it as the task varies and technology changes. If anything defines an "FPGA guy" is choice of language. Historically FPGAs have been programmed with an HDL, such as VHDL or Verilog, because these languages are concurrent meaning they handle parallel systems. My prediction is…

As an FPGA guy, I want to ask this - what software programming languages, models, etc. exist to support the description of fundamentally concurrent processing, whether task-parallel, data-parallel, hybrid, or "other" (whatever that may be) that will allow for the supplanting of HDLs? I know that there's been long-standing efforts to do C-to-HDL but to my knowledge the successes of this approach have been limited to relatively constrained solution spaces.

I guess my feeling is that there's a fundamental difference between the sequential execution inherent in something like C and the ability to describe concurrency that is fundamental to HDLs, and it's going to be a hard bridge to build.

Side question: are "SW guys" satisfied with the tools/languages available for multi-core development? I've always thought things like OpenMP and CUDA were steps in the right direction but still hacks. It seems to me like there's still problems to solve there as well.

Re: Forth Inventor Chuck Moore's $20 144 core CPU now in full production

#53
post #52
post #36

Earlier quoted context omitted.

I hesitate to divide the world into "FPGA guys" and "non-FPGA guys". It's a continuum of computing power; CPU DSP FPGA, and one moves up and down it as the task varies and technology changes. If anything defines an "FPGA guy" is choice of language. Historically FPGAs have been programmed with an HDL, such as VHDL or Verilog, because these languages are concurrent meaning they handle parallel systems. My prediction is…

As an FPGA guy, I want to ask this - what software programming languages, models, etc. exist to support the description of fundamentally concurrent processing, whether task-parallel, data-parallel, hybrid, or "other" (whatever that may be) that will allow for the supplanting of HDLs? I know that there's been long-standing efforts to do C-to-HDL but to my knowledge the successes of this approach have been limited to r…

what software programming languages, models, etc. exist to support the description of fundamentally concurrent processing, whether task-parallel, data-parallel, hybrid, or "other" that will allow for the supplanting of HDLs?

Not a SW guy, but I'm pretty sure the options can be boiled down to "pthreads or HDLs"

Re: Forth Inventor Chuck Moore's $20 144 core CPU now in full production

#54

Earlier quoted context omitted.

As far as I know, the cores aren't clocked. Instead Chuck designed his own transistors using his own OKAD II VLSI tools to be efficient on the CMOS process node with switching speeds being dictated by the transistor type and interconnect electrical properties, then designed the cores so that they're only switching those transistors when they do actual work.

Ooh, awesome. Clockless computing seems like a really nifty idea, but its difficult. I imagine it might go mainstream when Moore's law finally runs out.

"difficult" does not even begin to encompass the half of it. It is really cool in theory, but in reality a ridiculously difficult challenge that existing tools are in no way whatsoever up for.

Re: Forth Inventor Chuck Moore's $20 144 core CPU now in full production

#55

Earlier quoted context omitted.

If 1400 picoseconds is the time it takes for a clock cycle (and therefore the minimum instruction time for 1-cycle instructions), that'd be about 700 MHz, which actually seems pretty high compared to what I would've guessed.

As far as I know, the cores aren't clocked. Instead Chuck designed his own transistors using his own OKAD II VLSI tools to be efficient on the CMOS process node with switching speeds being dictated by the transistor type and interconnect electrical properties, then designed the cores so that they're only switching those transistors when they do actual work.

[deleted]

Re: Forth Inventor Chuck Moore's $20 144 core CPU now in full production

#56
post #50

In past Forth threads I've complained the the Forth model for a computer seems just too at odds with how modern CPUs actually work for me to want to learn it. Well, I look at this thing and its like the soft draft of the future slipping underneath the door, whispering that maybe I should learn Forth after all.

> maybe I should learn Forth after all http://factorcode.org/ Make it easy on yourself.

That is probably making it harder on yourself as the recommended route for learning factor is to read a forth book and read the factor docs. (Unless something has changed and a book or big tutorial has been written)

With that said, Factor is really cool.

Re: Forth Inventor Chuck Moore's $20 144 core CPU now in full production

#57

Earlier quoted context omitted.

If 1400 picoseconds is the time it takes for a clock cycle (and therefore the minimum instruction time for 1-cycle instructions), that'd be about 700 MHz, which actually seems pretty high compared to what I would've guessed.

As far as I know, the cores aren't clocked. Instead Chuck designed his own transistors using his own OKAD II VLSI tools to be efficient on the CMOS process node with switching speeds being dictated by the transistor type and interconnect electrical properties, then designed the cores so that they're only switching those transistors when they do actual work.

From the site's Green Arrays Architecture paper [1]:

Our architecture explicitly omits a clock, saving energy and time among other benefits.

Also, they quoted instruction execution time as being as low as 1400 picoseconds, so 700MHz equivalence is probably the best case, not the average case.

Edit: They also say in the architecture paper that their goal is one billion operations per second, or 1GHz.

[1] http://www.greenarraychips.com/home/documents/greg/PB002-100...

Re: Forth Inventor Chuck Moore's $20 144 core CPU now in full production

#59
post #52
post #36

Earlier quoted context omitted.

I hesitate to divide the world into "FPGA guys" and "non-FPGA guys". It's a continuum of computing power; CPU DSP FPGA, and one moves up and down it as the task varies and technology changes. If anything defines an "FPGA guy" is choice of language. Historically FPGAs have been programmed with an HDL, such as VHDL or Verilog, because these languages are concurrent meaning they handle parallel systems. My prediction is…

As an FPGA guy, I want to ask this - what software programming languages, models, etc. exist to support the description of fundamentally concurrent processing, whether task-parallel, data-parallel, hybrid, or "other" (whatever that may be) that will allow for the supplanting of HDLs? I know that there's been long-standing efforts to do C-to-HDL but to my knowledge the successes of this approach have been limited to r…

Sequential execution isn't necessarily inherent. C++, Smalltalk, VHDL and others share Simula as a common ancestor. Simula had elements of concurrency and event driven simulation in it. One could envisage an object oriented language, such as C++ or Smalltalk being extended to allow objects to execute in parallel and communicate via methods. Maybe every object would be derived from a root object that fundamentally supports concurrency?

I'm not saying that such languages currently exist, but I do think they will come into being, as programming comes to grips with multicore CPUs. It will be essentially HDL synthesis, with the synthesiser/compiler being smart enough to hide all scheduling issues from the user.

As someone with a foot in both camps, I'm not happy that I have to choose early in the design process whether to run my code on a CPU or FPGA.

Re: Forth Inventor Chuck Moore's $20 144 core CPU now in full production

#60
post #52
post #36

Earlier quoted context omitted.

I hesitate to divide the world into "FPGA guys" and "non-FPGA guys". It's a continuum of computing power; CPU DSP FPGA, and one moves up and down it as the task varies and technology changes. If anything defines an "FPGA guy" is choice of language. Historically FPGAs have been programmed with an HDL, such as VHDL or Verilog, because these languages are concurrent meaning they handle parallel systems. My prediction is…

As an FPGA guy, I want to ask this - what software programming languages, models, etc. exist to support the description of fundamentally concurrent processing, whether task-parallel, data-parallel, hybrid, or "other" (whatever that may be) that will allow for the supplanting of HDLs? I know that there's been long-standing efforts to do C-to-HDL but to my knowledge the successes of this approach have been limited to r…

There are interesting things being done with Haskell: http://www.dougandjean.com/hngn.html http://raintown.org/lava/

For example, I've seen a meaningful subset of Haskell in which the compiler would only accept programs which would provably terminate. The compiler output could then be sent down the FPGA synthesis toolchain.

Side question: are "SW guys" satisfied with the tools/languages available for multi-core development?

Yes and no. The new C++11 memory concurrency model and the atomics and multithreading library support are a huge step in the right direction. But it's nothing particularly slick and it still feels clunky. The fancy tools still seem to be not-perfectly portable and open source.

I've always thought things like OpenMP and CUDA were steps in the right direction but still hacks.

I'm guilty of not having used OpenMP. I should try it.

CUDA seems well-designed and has a decently well-supported toolchain. But it's a vendor-specific technology. OpenCL seems to be almost as fast and supported by more vendors.

It seems to me like there's still problems to solve there as well.

I remember as a kid hearing my father talk about the computer they were building at the university for research on high-level parallelization. That was the Illiac IV, completed in 1976.

Post reply on HN