Live data from Hacker News

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

greenarraychips.com

71–80 of 100 posts

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

#71
post #23
post #4

Love the guy and his passion for its chips, but this 144-computer chip looks like a solution in search of a problem: what is trying to solve? How's the inter-core communication handled? On the other hand, creating weird chips like these, just because you can, is awesome and stimulating a hacker's mind.

Some of the industries greatest advances have began as a solution in search of a problem, such as the microprocessor (which its inventor, Intel, didn't think much of compared with memory chips where the real money was). Most fail of course. If someone can make many-core, in this form, do something useful that can't be done elsewhere (unlike DSP and GPUs, which are already many-core), it will fundamentally upend compu…

> greatest advances have began as a solution in search of a problem

.. and the laser(!)

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

#72
I certainly should voice my opinion here.

I've done analysis of GA144 before: http://news.ycombinator.com/item?id=1810641

Most of the Chuck Moore design (I reviewed several, starting from M17) can be described by quote from Devil Wears Prada: "the same girl- stylish, slender, of course... worships the magazine. But so often, they turn out to be- I don't know- disappointing and, um... stupid". Chuck Moore designs are all slick, slender, stylish, worship Forth, but they turn out to be disappointing and stupid in the end. The only beneficiary often is Chuck Moore itself. You just cannot apply his experience to other places in the world of computing.

Let's see what we have here in GA144.

The memory inside all cores is way too small for general purpose programs, even if you split your program into 144 parts and spread them across cores. 64 words of RAM, ie, 128 bytes. 128 bytes times 144 - 18Kbytes. Same for the (program) ROM, and you should factor communication code in there. Communication cost affects RAM as well.

They offer no compiler from high-level language like C. You had to learn a specific dialect of Forth and some bizarre (albeit small) assembly language.

The only benefit for general population from this affair is the relative ease of the desing of asynchronous hardware.

http://en.wikipedia.org/wiki/Asynchronous_system

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

#73
post #62

Earlier quoted context omitted.

Its worth noting that a number of popular VM's, eg, the JVM, have Forth-like stack-based instruction sets.

OTOH, LLVM is, if anything, a register machine, so as to better map to the register machines we're implementing in hardware right now.

Yes, LLVM is a register machine and CPUs are register machines. My point really was that one shouldn't avoid stack-based languages or virtual machines because CPUs don't work that way, since some of the most used and most popular virtual machines are stack machines and get by just fine. (AFAIK both JVM and CLR are stack-based)

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

#74
post #18

Earlier quoted context omitted.

From this PDF http://www.greenarraychips.com/home/documents/greg/PB001-100... GreenArrays seems to think it would support DSP "SUITABILITY: The GA144 is designed to support the largest and most demanding computing challenges that can be addressed with a modest sized die in a relatively inexpensive and easy to use package while still using well less than 650 mW in most practical applications. The geometry allows for g…

There is a huge difference between supporting DSP and being good at DSP. My $0.50 MSP430, clocked at 32kHz, "supports" DSP.

At the very least, I'd expect instructions for things like saturated addition

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

#75
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…

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

I really like Intel's Threading Building Blocks for multicore programming in C++ and I really like Clojures take on time and concurrency, but overall, I feel language support is very limited and library support doesn't mesh as well with the languages as hoped. I would like to see a practical dataflow-centric language.

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

#76
post #72

I certainly should voice my opinion here. I've done analysis of GA144 before: http://news.ycombinator.com/item?id=1810641 Most of the Chuck Moore design (I reviewed several, starting from M17) can be described by quote from Devil Wears Prada: "the same girl- stylish, slender, of course... worships the magazine. But so often, they turn out to be- I don't know- disappointing and, um... stupid". Chuck Moore designs are…

Your are focusing on classic applications only.

The GA144 is so different from the classic way of computing that it requires new approaches of development. One very interesting feature of GA144 is that all 144 cores can share instructions over I/O lines. That means every core can send instructions to their neighbors who execute them directly without conversion.

I/O ist fast enough. I guess it should be possible to have (someday) an external interface to SRAM which circumvents the low memory problem.

> They offer no compiler from high-level language like C.

That's right, and that's the real weak spot of GA144. Almost every microcontroller board today comes with C or alike. Mr. Moore loves Forth but I doubt that there are many developers out there who like to be forced to learn Forth just for this single platform. I know Forth, it was one of my first languages I ever learned. It is perfectly suitable for embedded systems but you have to learn a lot to master it.

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

#77
post #72

I certainly should voice my opinion here. I've done analysis of GA144 before: http://news.ycombinator.com/item?id=1810641 Most of the Chuck Moore design (I reviewed several, starting from M17) can be described by quote from Devil Wears Prada: "the same girl- stylish, slender, of course... worships the magazine. But so often, they turn out to be- I don't know- disappointing and, um... stupid". Chuck Moore designs are…

Your are focusing on classic applications only. The GA144 is so different from the classic way of computing that it requires new approaches of development. One very interesting feature of GA144 is that all 144 cores can share instructions over I/O lines. That means every core can send instructions to their neighbors who execute them directly without conversion. I/O ist fast enough. I guess it should be possible to ha…

I protyped dynamic dataflow machine which (in theory) could be scaled to hundreds of cores (corelets - something very small which does not have even jump command). In my experiments readying information to be sent accounts for hefty 30%+ of code.

http://thesz.mskhug.ru/svn/hhdl/previous/HSDF/CoreletTest.hs

The link above contains some simple "Hello, world!" program, in five "big instructions" which contains 21 corelet instruction in total. 8 of those 21 instructions are send and front advancing instructions - their only purpose is to establish communication between program parts. My machine sends pointers to "big instructions", up to 32 bytes long (up to 32 instructions if you're lucky) while GA144 could send only 4 instructions max.

30% of 4 instructions is 1 instruction. Another one instruction from those 4 is a loop or jump or something like that. So you have two instructions to perform program logic. And this is best case.

So I again express dislike of GA144 as a computing machine. And I again express my gratitude to Chuck Moore for proving that clockless design works.

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

#78

Earlier quoted context omitted.

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.

Take a look at the Balsa design system: http://apt.cs.man.ac.uk/projects/tools/balsa/

My colleague uses it for research purposes and he said that it is pretty mature.

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

#79
post #4

Love the guy and his passion for its chips, but this 144-computer chip looks like a solution in search of a problem: what is trying to solve? How's the inter-core communication handled? On the other hand, creating weird chips like these, just because you can, is awesome and stimulating a hacker's mind.

> what is trying to solve?

Don't picture each core running C programs. Think the whole chip replacing something you would use an FPGA for, but more flexible, capable of adjusting its own behavior according to the environment.

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

#80
post #62

Earlier quoted context omitted.

Its worth noting that a number of popular VM's, eg, the JVM, have Forth-like stack-based instruction sets.

OTOH, LLVM is, if anything, a register machine, so as to better map to the register machines we're implementing in hardware right now.

In practice, the difference between LLVM and a stack machine like CLR or JVM is quite small.

LLVM SSA, modulo phi nodes, encodes expressions as DAGs in a completely straightforward sense: every operation names its arguments, and those names serve as unique references to a sub-DAG, since they cannot be reassigned. So given the final operation, you can follow the arguments recursively all the way through, completely transparently. Stack machines like the CLR and JVM encode expressions as trees serialized in a post-order - and to the extent that they use 'dup', they also encode expressions as DAGs.

A symbolic interpretation of a CLR or JVM instruction flow, or LLVM SSA instruction flow, can reconstruct the source expression DAG/tree; at which point you can re-encode it using the other approach.

And producing output targeting LLVM is even easier than it appears, because you don't need to worry about SSA yourself; just allocate stack locals (with alloca) and use the mem2reg pass to turn it into valid SSA.

Post reply on HN