3 ms·

I took a close look at Green Array recently and found a few blogs from engineerings who were beginning to play with them. At first they seemed too good to be tr

I took a close look at Green Array recently and found a few blogs from engineerings who were beginning to play with them. At first they seemed too good to be true, but it appears that the architecture is only a good match for tasks that can easily be parallelized by hand. Computer vision would be one of those tasks, but then is rewriting CV code from scratch on a new architecture something you can viably do anymore? Anyway, I hope these find a niche so that this kind of architecture might one day make a comeback. The advantages are staggering.

gruseom 15y ago
the architecture is only a good match for tasks that can easily be parallelized by hand Could you expand on that?
- tern 15y ago
  It forces you to structure your application as tiny communicating processes which you route by hand. You're actually coding quite close to the hardware. When you want a process to communicate with another – correct me if I'm wrong somebody – you can only communicate processes that are physically adjacent on the chip and you actually write something like "the one to the left/right". Each process is very small and one of the blogs I looked at was very much about optimizing code-size to fit in such a small place. This results in a situation where if your problem does not easily map to this kind of architecture, then you have no other option. But the same thing can be said of programming at a low level with a Von Neumann architecture. Such architectures are an exceptionally bad match for what the Green Array (dataflow) architecture is good for, namely highly concurrent applications involving processing flows of data such as sensor networks, computer vision, and all manner of routers. The way that Von Neumann systems handle this problem is by having high-level programming languages (like C), which gives you some level of abstraction from the hardware so that you can model your program however you like and force it to map to the architecture, even if the problem intrinsically doesn't map well. This is why parallel programming is a hard problem. It's not actually a hard problem (well, it could be intrinsically harder), it's just a hard problem for architectures that are not designed for it. On a Green Arrays chip, parallelism is the most natural thing in the world. Currently Green Arrays has no equivalent of C, and as I understand, this is unlikely to change as the philosophy of Forth is to stay close to the metal and make that an enjoyable experience. That's probably a good thing actually. it's more efficient to design problems to fit the hardware than to use one architecture for absolutely everything as we've been doing for the past 40 years or whatever (with notable exceptions like the Transputer, the Connection Machine, Xmos XCore chips and FPGA's to a certain extent).
  - RodgerTheGreat 15y ago
    Your description of inter-core communication in the GA144 is on the money. In addition to the challenge of mapping your problem to the grid, you have the interesting problem of initializing all those cores with their programs, since it's only possible to do serial communication with a few cores on the edges of the chip. In one of his recent "fireside chats", Chuck discussed how he first fills the chip with a zigzag pattern of of programs that act as a pipeline and then pumps the desired binary along, replacing the scaffolding backwards toward the serial port he's using. It reminds me a bit of the design of biological systems- not only do you have to write a program, you have to make it self-assemble. If anybody's interested in the GA144, GreenArrays recently put up a series of free self-paced courses about the architecture: http://school.arrayforth.com/ http://school.arrayforth.com/
    - msutherl 15y ago
      That sounds awesome – reminds me of cellular automata – but also, um, I just can't see Joe Engineer figuring that out. My first thought when I started researching Green Arrays was that this was an amazing idea that I would love to see take off, but their UX and marketing will really get in the way. Not like that have much competition though – the entire microcontroller world is hopelessly obscure with the exception of Arduino and all of the projects that it inspired.
      - RodgerTheGreat 15y ago
        Fortunately Chuck's already done the nasty parts and you can (presumably) leverage his upload code if you use GreenArrays' tools, but there's always the possibility that your code will require some very specific sequence of node initialization and you'll have to wade in and do it manually. I agree that this tech will probably never be mainstream. If I had an unlimited supply of free time I would be very tempted to develop some third-party devtools for GA chips- I enjoy programming in Forth and I could get used to the F18 instruction set, but using a custom keyboard layout and ditching my text editors and source control systems in favor of a block editor is pretty hard to swallow.
      - 15y ago
daniel-cussen 15y ago
So that's the thing for me: I know there's this huge payoff if I can successfully use the GA144, but I also know that it's going to be a GIANT pain in the ass. Oh well. Where there's muck, there's brass.

gruseom 15y ago

the architecture is only a good match for tasks that can easily be parallelized by hand Could you expand on that?

tern 15y ago
It forces you to structure your application as tiny communicating processes which you route by hand. You're actually coding quite close to the hardware. When you want a process to communicate with another – correct me if I'm wrong somebody – you can only communicate processes that are physically adjacent on the chip and you actually write something like "the one to the left/right". Each process is very small and one of the blogs I looked at was very much about optimizing code-size to fit in such a small place. This results in a situation where if your problem does not easily map to this kind of architecture, then you have no other option. But the same thing can be said of programming at a low level with a Von Neumann architecture. Such architectures are an exceptionally bad match for what the Green Array (dataflow) architecture is good for, namely highly concurrent applications involving processing flows of data such as sensor networks, computer vision, and all manner of routers. The way that Von Neumann systems handle this problem is by having high-level programming languages (like C), which gives you some level of abstraction from the hardware so that you can model your program however you like and force it to map to the architecture, even if the problem intrinsically doesn't map well. This is why parallel programming is a hard problem. It's not actually a hard problem (well, it could be intrinsically harder), it's just a hard problem for architectures that are not designed for it. On a Green Arrays chip, parallelism is the most natural thing in the world. Currently Green Arrays has no equivalent of C, and as I understand, this is unlikely to change as the philosophy of Forth is to stay close to the metal and make that an enjoyable experience. That's probably a good thing actually. it's more efficient to design problems to fit the hardware than to use one architecture for absolutely everything as we've been doing for the past 40 years or whatever (with notable exceptions like the Transputer, the Connection Machine, Xmos XCore chips and FPGA's to a certain extent).
- RodgerTheGreat 15y ago
  Your description of inter-core communication in the GA144 is on the money. In addition to the challenge of mapping your problem to the grid, you have the interesting problem of initializing all those cores with their programs, since it's only possible to do serial communication with a few cores on the edges of the chip. In one of his recent "fireside chats", Chuck discussed how he first fills the chip with a zigzag pattern of of programs that act as a pipeline and then pumps the desired binary along, replacing the scaffolding backwards toward the serial port he's using. It reminds me a bit of the design of biological systems- not only do you have to write a program, you have to make it self-assemble. If anybody's interested in the GA144, GreenArrays recently put up a series of free self-paced courses about the architecture: http://school.arrayforth.com/ http://school.arrayforth.com/
  - msutherl 15y ago
    That sounds awesome – reminds me of cellular automata – but also, um, I just can't see Joe Engineer figuring that out. My first thought when I started researching Green Arrays was that this was an amazing idea that I would love to see take off, but their UX and marketing will really get in the way. Not like that have much competition though – the entire microcontroller world is hopelessly obscure with the exception of Arduino and all of the projects that it inspired.
    - RodgerTheGreat 15y ago
      Fortunately Chuck's already done the nasty parts and you can (presumably) leverage his upload code if you use GreenArrays' tools, but there's always the possibility that your code will require some very specific sequence of node initialization and you'll have to wade in and do it manually. I agree that this tech will probably never be mainstream. If I had an unlimited supply of free time I would be very tempted to develop some third-party devtools for GA chips- I enjoy programming in Forth and I could get used to the F18 instruction set, but using a custom keyboard layout and ditching my text editors and source control systems in favor of a block editor is pretty hard to swallow.
    - 15y ago

daniel-cussen 15y ago

So that's the thing for me: I know there's this huge payoff if I can successfully use the GA144, but I also know that it's going to be a GIANT pain in the ass. Oh well. Where there's muck, there's brass.