There has also been an history of infighting, apparently some folks were and continue to try grab a larger piece of the pie, before its finished cooking.
We can either contribute to move it forward, or sit back and wait (and optionally complain). I'm not able to contribute much, so I've learned patience while waiting.
We can either contribute to move it forward, or sit back and wait (and optionally complain).
I won't be contributing, nor will I be waiting. There aren't enough hours in the day to do everything I want to do on platforms I already use and love. OTOH, I may buy a pre-soldered GA144 against the day they disappear. Then, when I'm 88 and sitting in my mtn cabin looking for something new and interesting to do, I can pull it out. But I don't see the potential for much of a return on time invested right now.
Has anyone tried reading the app notes for this device? Like how to calculate MD5 sums, totally unintelligible.
Which means of course, there is something deep going on here that is over my head or it's just over complicated for what it is.
Which means of course just now I can't tell. Perhaps the over complication is worth it to get down to the claimed miniscule power consumptions in some cases.
All I know is that I am not going to live long enough to understand it. Like most things I guess:)
The impasse that I have with using the GA144 has not been about Forth, it is the need for an 18 x 8 matrix of processors.
It seems others want to use their lack of knowing what to do with a large matrix as a way to justify a dislike of Forth.
If you want to use a Nvidia video card, you can get a far more vast matrix with somewhat more conventional CPUs. And I doubt the same persons will have more imagination about what to do.
Historically, Unix provided an excellent educational environment for computing as a collaborative art - mult-users, multi-tasking, big programs.
Forth tends to favor single adept users, smaller programs, and so on. I really like it for the individual that wants to develop a rather complex control system to be later ported over to a more conventional approach. It was certainly a pleasure to get a few stepper motors running as I could adjust and tweak timing without having to compile and load each test. Once the parameters are right, I could compile is just about anything.
I just don't have a project that needs a huge matrix of processors. I am finding it hard enough to keep a Propeller busy.
I sit here with about 10 Propellers, maybe 50 SX chips, a dozen or so Basic Stamps and clones -- any I just don't have much that I really need to automate and control. But it has been fun to explore the concepts and skills involved, and intellectually rewarding.
I also have few more 'regular' computers and OSes than a really need.
Hmm, I looked at Jupiter and the moon through my newtonian telescope a few nights ago, and I saw very sharp images of the craters on the moon and Jupiter with it's four Galilean moons. I've tried looking through the other end of the telescope, and all I see is a magnified image of myself. Maybe Forth is just a magnified image of Chuck Moore.
Doug, you know I spent three solid months programming in Forth, and writing three different interpreters. I looked through both sides of the programming telescope, and Forth seems to be on the wrong side of the optics. The only potential use for Forth is to bootstrap a development system on a new processor that only has an assembler, and nothing else. Once high level language tools are brought up on a processor Forth is no longer needed. Of course there are ways of doing this without involving Forth at all.
I've always wondered about this bootstrapping idea.
Back in the day we had a Motorola 6809 some RAM and ROM and serial I/O. We had to build that into a working board ourselves to start with. No languages available to us, not even an assembler. There was nothing for it but to roll up our sleeves and write code in HEX and get that blown into the EPROM via a a PROM programmer.
So the drill is:
1) Write the code you want in pseudo code on paper, in our case something that looked like ALGOL.
2) Hand compile that design into assembler. Again on paper.
3) Hand assemble that into HEX. Again on paper.
4) Punch that HEX onto paper tape.
4) Blow EPROM by feeding paper tape into our PROM programmer.
5) Insert into board and run.
Soon we had a monitor program up and running. Rather like the monitor in the Prop II ROM. Then the ability to load/save data to audio cassette tape. Then added debug features, go, break, break points, etc.
Had we continued down that road we would soon have had a simple editor and assembler running on that machine. If we were a bit smarter and knowledgeable that might have led onto a compiler for a simple HLL.
So my question is: Do, or have, people ever used Forth to do that kind of thing? And why?
Hmm, I looked at Jupiter and the moon through my newtonian telescope a few nights ago, and I saw very sharp images of the craters on the moon and Jupiter with it's four Galilean moons. I've tried looking through the other end of the telescope, and all I see is a magnified image of myself. Maybe Forth is just a magnified image of Chuck Moore.
Doug, you know I spent three solid months programming in Forth, and writing three different interpreters. I looked through both sides of the programming telescope, and Forth seems to be on the wrong side of the optics. The only potential use for Forth is to bootstrap a development system on a new processor that only has an assembler, and nothing else. Once high level language tools are brought up on a processor Forth is no longer needed. Of course there are ways of doing this without involving Forth at all.
@Dave
I don't think anyone recently has worked harder at understanding Forth. And I think you may even be right about using other high level languages onces the devices are resolved.
I still like Forth as it is so easy and so flexible tool to explore what is going on in a new processor. I have very high hopes for it to provide a fun introduction to the Propeller 2.
1) Write the code you want in pseudo code on paper, in our case something that looked like ALGOL.
2) Hand compile that design into assembler. Again on paper.
3) Hand assemble that into HEX. Again on paper.
4) Punch that HEX onto paper tape.
4) Blow EPROM by feeding paper tape into our PROM programmer.
5) Insert into board and run.
You left out the steps about walking a mile up hill through 2 feet of snow both to an from work...
I remember doing steps 1 to 3 for both the 1802 and 8085, I never had paper tape though, just a hex keypad and cassette tape.
might as well use the GA144 and a single processor.
As far as I can tell you have to. In the app notes I looked at the first thing that happens is that calculations are spread over at least two node just because you don't have enough bit width in one processor. Then you need nodes for you input and output. Not sure what the minimum useful node count would be.
Clearly, with your depth of experience, you know all there is to know.
I looked through both sides of the programming telescope, and Forth seems to be on the wrong side of the optics.
You looked at forth as if it were C, and found it lacking. Good for you.
The only potential use for Forth is to bootstrap a development system on a new processor that only has an assembler, and nothing else. Once high level language tools are brought up on a processor Forth is no longer needed. Of course there are ways of doing this without involving Forth at all.
You are right. If you already have tools that do what you want, you are wasting time trying tools that you have already decided don't do what you want. I think you've given it as fair a shake as you can.
On the other hand, if one wants to use more powerful,little weight tools, that eliminate the need for external hardware and the baggage brought on from the needs of much larger systems out of the scope of a micro processor environment, well, there are other options.
Forth is not a general purpose tool that tries to be all things to all people. It is a very specific tool, common interface for micro controllers or other systems with limited resources.
The GA144 chip is a very unique piece of hardware that we haven't figured out a use for. The "micro code" can be directly programmed in a high level-ish language, forth.
I've always wondered about this bootstrapping idea.
...
So my question is: Do, or have, people ever used Forth to do that kind of thing? And why?
Thats pretty much how its used. Why, because once communication is established, a programmer with a little skill and experience can forth up and running in a few hours, and get the monitor and diagnostic started. One can fully exercise and debug the hardware, and lay the ground work for th high level tools. This is why Sun , Apple, OLPC etc boot to forth, (so the diagnostics are present), then load the user OS. When something breaks, it was considered handy to have a full interactive diagnostics suite in ROM, and it cost nothing in terms of extra hardware or additional programming. Very handy.
And if one decides the Full user OS is too slow on the unit, one can simple boot to forth and stay there. An original IMAC is a complete dog running Apple OS, but boot to forth and it runs like a rocket. Same with OLPC, and old Spark workstations.
But one probably doesn't want to use the GA144 as a retro commuter. A better use would be to prefilter and preprocess some fat data stream from a sensor or sensor array, and send the cooked data to another unit for user level crunching, etc.
You looked at forth as if it were C, and found it lacking. Good for you.
At least I looked at it. I felt that I couldn't do a fair comparision of Forth versus other languages without learning the language and programming style. I would like to see some of the Prop Forth guys program in PropGCC for 3 months, and then get their comparisons between Forth and C on the Prop. I don't think you can really comment on the pros and cons of the two languages until you've done that execise.
Hi Dave,
Actually reading your C code for ANSI Forth is one of my ambitions and has been since you started. And I think it might be an excellent way to learn C as it would provide a large array of examples of various short functions. There is nothing wrong with programing Forth in C on a larger, faster computer - it is just microcontrollers that need to use assembler to overcome there lesser speed and more limited resource.
There is nothing wrong with ANSI Forth either. But we know saying that is going to get me buried in deep shinola with the pundits of Forth on the Propeller.
If there is one thing I have learned by listening to Prof Braino, it is that he seems to need to have the last word. Personally I question the value of getting the last word, and I often find that people that need this may not have much clarity about what the discussion is about. But they often get it because the discussion ended long before when pleas to listen were not recognized.
Your efforts and your opinions are valid and have genuine value. But why bother with debate that leads nowhere.
I don't think you can really comment on the pros and cons of the two languages until you've done that execise.
My comments are based on sitting in on code reviews from professional programmers. My comments are: C in general is great for what it was designed for, which is writing operating systems for workstations. Forth is designed for the more limited environment of a micro controller. But you could use either for either, if you wish. I have no comment on PropGCC beyond that.
Sal programs in just about every language I've heard of, when he finds them appropriate. He says he uses C all the time, but this is usually outside the context of propforth, so is out of scope for our discussions. He have found Go to be more useful on the PC for the support for the propforth automation, because of the Go channels (previously called CSP channels), so we talk about that frequently. Personally I never program in C, life is too short and everybody else has that pretty well covered without my help. I don't know about any other propforth guys, but I think mindrobots is using PropGCC.
My comments are based on sitting in on code reviews from professional programmers.
No wonder you have such a skewed view of C. Spend at least a few days writing a few lines of C code, and maybe you'll have a better understanding of it. Until you do that I can't really take anything you say about Forth versus other languages seriously. Try looking through both ends of the telescope.
No wonder you have such a skewed view of C. Spend at least a few days writing a few lines of C code, and maybe you'll have a better understanding of it. Until you do that I can't really take anything you say about Forth versus other languages seriously. Try looking through both ends of the telescope.
Please do not take anything I say seriously. Except that I leave writing C code to you, as you are the expert; and that forth is designed for micro controllers and limited resources. And I did try it, my telescope works very well one way, and not very well the other way.
Why not just connect together 18 propeller chips and design it the way you want. It already runs Forth and C.
The variance with telescope references is one guy has a reflector telescope and the other guy has a refractor. If you peer into the reflector which uses mirrors, you can see yourself, into the refractor which uses lenses, a vast but tiny expanse compression. It just goes to show, there's no standard as requirements vary and different people have different ideas, opinions, needs, and apps. It's a good idea to give others space and credence in the Universe.
Coulda, woulda, shoulda. Seriously, until the GA144 does something useful, and does it faster and better than the ARM chip in a Shenzhen tablet, it has no credibility at Chaos Central.
Schmartboard sells one GA144 chip with breakout board.$34.95. You seem to be comparing the cost of DIY Parallax Propeller solution with a complete system built with added features.
Get your economic comparison right. One GA144 for $34.95 verses 18 Propeller chips at $7.99 for $143.83.
Of course, if you want to buy 18 Parallax development boards or 18 Parallax Protoboards and then compare costs, that might be a bit closer to comparing to the GA144 development board. But you would likely have a lot of problems to fully integrated 18 of these boards and to get anything useful.
I've already admitted that I just can't seem to imagine what I want to do with 144 processors tied together. But I am reading and rereading the GA144 documents with an open mind in hopes of being inspired rather than being a Forth nay sayer.
What useful product has a 144 core Propeller project produced?
It appears both options remain highly developmental and unresolved.
Get your economic comparison right. One GA144 for $34.95 verses 18 Propeller chips at $7.99 for $143.83. Schmartboard sells one GA144 chip with breakout board $34.95. You seem to be comparing the cost of DIY Parallax Propeller solution with a complete system built with added features.
Your comparison and my comparison are both correct. This is based on a completed working Propeller parallel machine project listed at the link - the DIY Propeller solution includes board, Propeller chips, active components, assembly (wiring etc.) and built in features.
The Propeller chip solution includes many of the GA144 hardware solutions but implemented in free software - no hardware needed (see the OBEX for details), which keep costs down and offerings high. This solution is mentioned as it may be more suitable for those already familiar with the Propeller chip and its paralleled architecture capabilities.
"The cost of 36 paralleled props with 288 cores on a DIY board is about $350. Several parallel Propeller machines are built that equal or exceed this core count. http://humanoidolabs.blogspot.tw/p/genealogy.html "
Of course, if you want to buy 18 Parallax ... Protoboards ... you would likely have a lot of problems to fully integrated 18 of these boards and to get anything useful.
...I just can't seem to imagine what I want to do with 144 processors tied together.
There are all sorts of real-world problems that can exploit massively parallel architecture, provided that an efficient mechanism for distributing code and data is provided. I saw a Connection Machine at a supercomputer conference in Chicago in '88 that had thousands of processors, and I watched it deliver incredible performance on a real-world problem. So I'm totally in favor of the concept, and have worked professionally in the field. (Once upon a time, parallel processing boards I designed were being shipped to all sorts of crazy places around the globe. I've got a picture, cut out of a New Zealand newspaper, of a university professor holding one of my boards.) I'm definitely not a parallel processing naysayer.
All GA would have to do to make me a convert would be to provide a few gates in each F18A devoted to data serialization and routing so that each computer could spend its time computing. I'm really not asking for much. Unfortunately they cut one corner too many, rendering the GA144 a hopeless PITA to use. Pity CM didn't make available FPGA code that the rest of us could vet.
Comments
Moore is 75 years old, http://en.wikipedia.org/wiki/Charles_H._Moore
and is pre-occupied by occasional health problems, such as cancer. http://www.colorforth.com/blog2.htm scan for "cancer".
There has also been an history of infighting, apparently some folks were and continue to try grab a larger piece of the pie, before its finished cooking.
Its slow going, but progressing. http://www.colorforth.com/haypress.htm
We can either contribute to move it forward, or sit back and wait (and optionally complain). I'm not able to contribute much, so I've learned patience while waiting.
I won't be contributing, nor will I be waiting. There aren't enough hours in the day to do everything I want to do on platforms I already use and love. OTOH, I may buy a pre-soldered GA144 against the day they disappear. Then, when I'm 88 and sitting in my mtn cabin looking for something new and interesting to do, I can pull it out. But I don't see the potential for much of a return on time invested right now.
Which means of course, there is something deep going on here that is over my head or it's just over complicated for what it is.
Which means of course just now I can't tell. Perhaps the over complication is worth it to get down to the claimed miniscule power consumptions in some cases.
All I know is that I am not going to live long enough to understand it. Like most things I guess:)
They have a lot of moxie to spin this into a feature, but you've got to give them props for honesty!
After all if I program in Verilog or VHDL for an FPGA it feels like that's what I am doing. I have to take care of every bit as fast as possible.
Replace FPGA logic cells with multiple processors and some clever port tricks and you have the XMOS devices. Ultra fast bit banging.
Which, by the way is what is going on with the Propeller and more so with Propeller II
Exactly where the Grren Array chip fits on this scale of "unprecedended bit banging" I'm not sure.
It seems others want to use their lack of knowing what to do with a large matrix as a way to justify a dislike of Forth.
If you want to use a Nvidia video card, you can get a far more vast matrix with somewhat more conventional CPUs. And I doubt the same persons will have more imagination about what to do.
Historically, Unix provided an excellent educational environment for computing as a collaborative art - mult-users, multi-tasking, big programs.
Forth tends to favor single adept users, smaller programs, and so on. I really like it for the individual that wants to develop a rather complex control system to be later ported over to a more conventional approach. It was certainly a pleasure to get a few stepper motors running as I could adjust and tweak timing without having to compile and load each test. Once the parameters are right, I could compile is just about anything.
I just don't have a project that needs a huge matrix of processors. I am finding it hard enough to keep a Propeller busy.
I sit here with about 10 Propellers, maybe 50 SX chips, a dozen or so Basic Stamps and clones -- any I just don't have much that I really need to automate and control. But it has been fun to explore the concepts and skills involved, and intellectually rewarding.
I also have few more 'regular' computers and OSes than a really need.
The way you look through the telescope is very consistent, but still the wrong way around
Doug, you know I spent three solid months programming in Forth, and writing three different interpreters. I looked through both sides of the programming telescope, and Forth seems to be on the wrong side of the optics. The only potential use for Forth is to bootstrap a development system on a new processor that only has an assembler, and nothing else. Once high level language tools are brought up on a processor Forth is no longer needed. Of course there are ways of doing this without involving Forth at all.
Back in the day we had a Motorola 6809 some RAM and ROM and serial I/O. We had to build that into a working board ourselves to start with. No languages available to us, not even an assembler. There was nothing for it but to roll up our sleeves and write code in HEX and get that blown into the EPROM via a a PROM programmer.
So the drill is:
1) Write the code you want in pseudo code on paper, in our case something that looked like ALGOL.
2) Hand compile that design into assembler. Again on paper.
3) Hand assemble that into HEX. Again on paper.
4) Punch that HEX onto paper tape.
4) Blow EPROM by feeding paper tape into our PROM programmer.
5) Insert into board and run.
Soon we had a monitor program up and running. Rather like the monitor in the Prop II ROM. Then the ability to load/save data to audio cassette tape. Then added debug features, go, break, break points, etc.
Had we continued down that road we would soon have had a simple editor and assembler running on that machine. If we were a bit smarter and knowledgeable that might have led onto a compiler for a simple HLL.
So my question is: Do, or have, people ever used Forth to do that kind of thing? And why?
@Dave
I don't think anyone recently has worked harder at understanding Forth. And I think you may even be right about using other high level languages onces the devices are resolved.
I still like Forth as it is so easy and so flexible tool to explore what is going on in a new processor. I have very high hopes for it to provide a fun introduction to the Propeller 2.
With the 144 processors, it would just be the same situation... if the processors were not dedicated stack machines. One might as well get a F18A chip and explore that before bothering with big matrices, but that may be a bit more complex to do.
http://www.eetimes.com/design/programmable-logic/4213192/Creating-the-F18A---An-FPGA-based-TMS9918A-VDP
Prof_Braino paints with a very broad brush. Forth is not 'all and everything', but it is something of value.
You left out the steps about walking a mile up hill through 2 feet of snow both to an from work...
I remember doing steps 1 to 3 for both the 1802 and 8085, I never had paper tape though, just a hex keypad and cassette tape.
C.W.
Ha:)
Actually there was some of that as well. I did not own a car at the time and even 1mm of snow brings British public transport to a halt.
I don't think the hill was uphill both ways though:)
Still, it would be nice to prototype just one processor as a learning tool.
No single F18A chips available... might as well use the GA144 and a single processor.
As far as I can tell you have to. In the app notes I looked at the first thing that happens is that calculations are spread over at least two node just because you don't have enough bit width in one processor. Then you need nodes for you input and output. Not sure what the minimum useful node count would be.
Clearly, with your depth of experience, you know all there is to know.
You looked at forth as if it were C, and found it lacking. Good for you.
You are right. If you already have tools that do what you want, you are wasting time trying tools that you have already decided don't do what you want. I think you've given it as fair a shake as you can.
On the other hand, if one wants to use more powerful,little weight tools, that eliminate the need for external hardware and the baggage brought on from the needs of much larger systems out of the scope of a micro processor environment, well, there are other options.
Forth is not a general purpose tool that tries to be all things to all people. It is a very specific tool, common interface for micro controllers or other systems with limited resources.
The GA144 chip is a very unique piece of hardware that we haven't figured out a use for. The "micro code" can be directly programmed in a high level-ish language, forth.
If you need C on an arduino, this is not that.
Thats pretty much how its used. Why, because once communication is established, a programmer with a little skill and experience can forth up and running in a few hours, and get the monitor and diagnostic started. One can fully exercise and debug the hardware, and lay the ground work for th high level tools. This is why Sun , Apple, OLPC etc boot to forth, (so the diagnostics are present), then load the user OS. When something breaks, it was considered handy to have a full interactive diagnostics suite in ROM, and it cost nothing in terms of extra hardware or additional programming. Very handy.
And if one decides the Full user OS is too slow on the unit, one can simple boot to forth and stay there. An original IMAC is a complete dog running Apple OS, but boot to forth and it runs like a rocket. Same with OLPC, and old Spark workstations.
But one probably doesn't want to use the GA144 as a retro commuter. A better use would be to prefilter and preprocess some fat data stream from a sensor or sensor array, and send the cooked data to another unit for user level crunching, etc.
Actually reading your C code for ANSI Forth is one of my ambitions and has been since you started. And I think it might be an excellent way to learn C as it would provide a large array of examples of various short functions. There is nothing wrong with programing Forth in C on a larger, faster computer - it is just microcontrollers that need to use assembler to overcome there lesser speed and more limited resource.
There is nothing wrong with ANSI Forth either. But we know saying that is going to get me buried in deep shinola with the pundits of Forth on the Propeller.
If there is one thing I have learned by listening to Prof Braino, it is that he seems to need to have the last word. Personally I question the value of getting the last word, and I often find that people that need this may not have much clarity about what the discussion is about. But they often get it because the discussion ended long before when pleas to listen were not recognized.
Your efforts and your opinions are valid and have genuine value. But why bother with debate that leads nowhere.
My comments are based on sitting in on code reviews from professional programmers. My comments are: C in general is great for what it was designed for, which is writing operating systems for workstations. Forth is designed for the more limited environment of a micro controller. But you could use either for either, if you wish. I have no comment on PropGCC beyond that.
Sal programs in just about every language I've heard of, when he finds them appropriate. He says he uses C all the time, but this is usually outside the context of propforth, so is out of scope for our discussions. He have found Go to be more useful on the PC for the support for the propforth automation, because of the Go channels (previously called CSP channels), so we talk about that frequently. Personally I never program in C, life is too short and everybody else has that pretty well covered without my help. I don't know about any other propforth guys, but I think mindrobots is using PropGCC.
Please do not take anything I say seriously. Except that I leave writing C code to you, as you are the expert; and that forth is designed for micro controllers and limited resources. And I did try it, my telescope works very well one way, and not very well the other way.
The variance with telescope references is one guy has a reflector telescope and the other guy has a refractor. If you peer into the reflector which uses mirrors, you can see yourself, into the refractor which uses lenses, a vast but tiny expanse compression. It just goes to show, there's no standard as requirements vary and different people have different ideas, opinions, needs, and apps. It's a good idea to give others space and credence in the Universe.
The GA144 would be faster. And quite a bit cheaper. and lower power.
The Propeller is easier to use and has more information and support. There are ways to speed up the Propeller as discussed in other threads. Several forum members have created ultra low power prop configurations. The GA development board with 2 chips at 288 cores is $450.00. The cost of 36 paralleled props with 288 cores on a DIY board is about $350. Several parallel Propeller machines are built that equal or exceed this core count.
http://humanoidolabs.blogspot.tw/p/genealogy.html
http://forums.parallax.com/showthread.php/127983-55-Parallax-Propeller-s-Parallells-Processing-of-Permanent-Perturbations.?highlight=perturbations
Coulda, woulda, shoulda. Seriously, until the GA144 does something useful, and does it faster and better than the ARM chip in a Shenzhen tablet, it has no credibility at Chaos Central.
Schmartboard sells one GA144 chip with breakout board.$34.95. You seem to be comparing the cost of DIY Parallax Propeller solution with a complete system built with added features.
Get your economic comparison right. One GA144 for $34.95 verses 18 Propeller chips at $7.99 for $143.83.
Of course, if you want to buy 18 Parallax development boards or 18 Parallax Protoboards and then compare costs, that might be a bit closer to comparing to the GA144 development board. But you would likely have a lot of problems to fully integrated 18 of these boards and to get anything useful.
I've already admitted that I just can't seem to imagine what I want to do with 144 processors tied together. But I am reading and rereading the GA144 documents with an open mind in hopes of being inspired rather than being a Forth nay sayer.
What useful product has a 144 core Propeller project produced?
It appears both options remain highly developmental and unresolved.
http://www.schmartboard.com/index.asp?page=products_csp&id=532
Your comparison and my comparison are both correct. This is based on a completed working Propeller parallel machine project listed at the link - the DIY Propeller solution includes board, Propeller chips, active components, assembly (wiring etc.) and built in features.
The Propeller chip solution includes many of the GA144 hardware solutions but implemented in free software - no hardware needed (see the OBEX for details), which keep costs down and offerings high. This solution is mentioned as it may be more suitable for those already familiar with the Propeller chip and its paralleled architecture capabilities.
"The cost of 36 paralleled props with 288 cores on a DIY board is about $350. Several parallel Propeller machines are built that equal or exceed this core count. http://humanoidolabs.blogspot.tw/p/genealogy.html "
There's a 160 core Propeller project with twenty Parallax Proto Boards and there was no problem fully integrating these boards and conducting many useful experiments.
http://humanoidolabs.blogspot.tw/p/genealogy.html
What one finds useless may be highly useful to another, and visa versa.
This list has 13 parallel Propeller projects listed starting with 160 cores leading up to over 800 cores.
http://humanoidolabs.blogspot.tw/2010/07/multiple-props-projects-list.html
There are all sorts of real-world problems that can exploit massively parallel architecture, provided that an efficient mechanism for distributing code and data is provided. I saw a Connection Machine at a supercomputer conference in Chicago in '88 that had thousands of processors, and I watched it deliver incredible performance on a real-world problem. So I'm totally in favor of the concept, and have worked professionally in the field. (Once upon a time, parallel processing boards I designed were being shipped to all sorts of crazy places around the globe. I've got a picture, cut out of a New Zealand newspaper, of a university professor holding one of my boards.) I'm definitely not a parallel processing naysayer.
All GA would have to do to make me a convert would be to provide a few gates in each F18A devoted to data serialization and routing so that each computer could spend its time computing. I'm really not asking for much. Unfortunately they cut one corner too many, rendering the GA144 a hopeless PITA to use. Pity CM didn't make available FPGA code that the rest of us could vet.