Green Arrays presentation at Dark Silicon Workshop

[Paul Rubin]

From June 2012 but I just found the slides.

http://darksilicon.ucsd.edu/2012/assets/slides/5

Title: Illuminating Dark Silicon with a Fabric of Simple Computers
Author: Charles H. Moore, Greg Bailey
GreenArrays, Inc.
File size: 935.32 KB
Format: PDF

[Marcel Hendrix]

Paul Rubin <no.e...@nospam.invalid> writes Re: Green Arrays presentation at Dark Silicon Workshop

> From June 2012 but I just found the slides.

> http://darksilicon.ucsd.edu/2012/assets/slides/5

[..]

They answer the question why the chip has almost no RAM.

To me, in the limit the authors' expressed philosophy leads
to the design of e.g. a dedicated video processor, when such
a device is needed. That will be simpler, cheaper, and
higher performance than what the GA144 does now.

Apparently they are working on a 32-bit design. Unexpected,
given the above philosophy.

It is strange that there is no mention of the analog
hardware that is available in the GA144.

-marcel

[RR]

"10 Mb full duplex Ethernet network interface controller has been built in software using 27 nodes connecting pins with external SRAM, and organized into two pipelines for transmit and receive with two nodes between them to implement link negotiation."

Have they ever released / published their software NIC?

[Paul Rubin]

RR <freedo...@gmail.com> writes:
> "10 Mb full duplex Ethernet network interface controller has been

> built in software using 27 nodes..."

> Have they ever released / published their software NIC?

I don't think they have released it. I don't know if they plan to. I
do remember seeing some mention of it but didn't realize it was on 27
nodes.

It does make me a bit sad, thinking of how much programming effort must
have gone into that, only to end up with a 10 mbit NIC. I don't even
remember how long it's been since I last saw any 10 mbit ethernet gear.
Even 100 mbit is kind of creaky these days. Most users want 1000 mbit,
which is completely out of reach for that software approach. And 10000
mbit or even 25000 mbit is starting to make itself felt. (100 gbit is
actually four bonded 25 gbit channels, I think).

[Jason Damisch]

–Must every widget be a unix machine with the resources and versatility of a minicomputer?

–Do we really believe our lamps and toasters require software updates?

LOL

[dam...@web.de]

The concepts there are presenting are important in my opinion but I am curious about the market there want to target. Probably the GA144 can offer flexibility against CPLD's ?!??

[Richard Owlett]

For the market where the GA144 is likely to appear, is more
than 10 mbit/s relavant?

[rickman]

I think the fact that their presentations create more questions than
they answer is important. They are pitching their technology without
mentioning where it applies. That is not a great way to convince
customers.

I don't think you need to dwell on how you designed your product when
potential customers have so many questions about how to use the product.
I've been banging on this for several weeks now and I still haven't
been able to prove to myself that my application is practical on their
device. But I am still working on it.

Rick

[rickman]

What market would that be?

I agree that there are many apps that will work well with 10 Mbps
Ethernet. But there are lots more that could use even just 100 Mbps.

Rick

[Richard Owlett]

>> mbit/s relevant?

>>
>
> What market would that be?
>
> I agree that there are many apps that will work well with 10
> Mbps Ethernet. But there are lots more that could use even
> just 100 Mbps.
>
> Rick

What market? I don't know.
I was extrapolating from comments here about low cost and
low power (watts, not MIPS).
Though not as old as Jerry, I remember when 300 Baud was
high speed.
And for more perspective, my father operated a _legal_
*land* based spark gap transmitter.

Besides the MS Mantra of "bigger and faster - the only
metric of progress" ruffles my feathers. The OWLett ;)

[forther]

http://cdn.intechopen.com/pdfs/37775/InTech-Wavefront_systolic_algorithms_for_implementation_of_stereo_vision_and_obstacle_avoidance_computations_on_a_very_low_power_mimd_many_core_parallel_architecture_applications_for_mobile_systems_and_wearable_visual_guidance_.pdf

It may answers some questions, raised in this thread.

[Paul Rubin]

forther <for...@gmail.com> writes:
> [very long url snipped]

> It may answers some questions, raised in this thread.

Thanks. I notice the much friendlier url

http://cdn.intechopen.com/pdfs/37775/InTech.pdf

also works. The numeric part and the .pdf extension identifies the file
and the rest is search keywords.

[Jason Damisch]

well the Mars rovers are in an environment which won't change, or won't change rapidly, that is to say, the Martian environment is static because it is not yet inhabited by people and their machinery.

[rickman]

On 8/20/2012 5:17 PM, forther wrote:
> http://cdn.intechopen.com/pdfs/37775/InTech-Wavefront_systolic_algorithms_for_implementation_of_stereo_vision_and_obstacle_avoidance_computations_on_a_very_low_power_mimd_many_core_parallel_architecture_applications_for_mobile_systems_and_wearable_visual_guidance_.pdf
>
> It may answers some questions, raised in this thread.

I took a look and don't have nearly enough time at the moment to read
the full paper in any depth. Anyone have any ideas on which questions
this paper answers and what those answers are? In other words, can I
get the Cliff Notes version?

Rick

[Andrew Haley]

Jason Damisch <jasond...@yahoo.com> wrote:

> * Must every widget be a unix machine with the resources and
> versatility of a minicomputer?
>
> * Do we really believe our lamps and toasters require software
> updates?
>
> LOL

Right! That reminds me of a request to tender many years ago. It was
for a controller for the display boards at a London railway terminus.
I thought of tendering for the job, but then I saw running on UNIX as
a *requirement*. Why on Earth would a display controller need UNIX?
Years later, I'm fascinated (and appalled) that the railway stations
still have different display boards and, presumably, different custom
software. These days they're probably using a 16-node server with 128
gigabytes of memory...

Andrew.

[gavino_himself]

bring out a pc done in forth and hurry up, one with working web browser and internet :) and file manager in gui as well, but can be inside browser if u want

of course everything runs in 500k ram so rest of 4096M ram can be data right?
do it already

enuf blowing smoke

[John Passaniti]

On Wednesday, September 5, 2012 5:18:28 AM UTC-4, gavino_himself wrote:
> bring out a pc done in forth and hurry up, one with
> working web browser and internet :) and file manager
> in gui as well, but can be inside browser if u want

wont evar happen , dude!!! as u know forth is 2 good and if someone was to make a pc with web browser and internet and file manager and gui and persistance layer (like prevayler !!!!) it would kill industry. larry ellison has to get the money to buy that hawaiian island from somewhere!!!!

real question is : can chicken scheme have higher levels of abstraction than forth or would a window manager in Forth be 10000 time faster and use less resources? could bernd's web server in forth let me write blog in 1 lines of code? how about storing everything in ram? what about if I replaced database with a global variable??

[gavino_himself]

a pc than runs as fast on 1 m ram as the current ones do in 1000 would be impressive

can changes to such global variables be logged to disk? if so it seem bam then all good

you seem like a moron when u word salad my logical questons john and no one thinks of you as smart rather jsut a complainer, show us working apps, thats what we ask!! working apps!!

yeah!!

your not me!

[Mark Wills]

>
> you seem like a moron when u word salad my logical questons john and no one thinks of you as smart rather jsut a complainer, show us working apps, thats what we ask!! working apps!!

Such beautiful irony. Pot, meet kettle.

[Jason Damisch]

> can changes to such global variables be logged to disk? if so it seem bam then all good

Sorry but the Forth way is to not let the global variables 'get away from you' I mean don't let the global variables become a problem. Use as few of them as possible, and then test your words on the command line, that should help. I personally have not had a need to write out variables to disk ever, maybe large buffers, but then again there is DUMP.

[Elizabeth D. Rather]

In my experience, global variables in Forth aren't a problem, and
they're appropriate whenever you have data that will be used by several
definitions. I think all this abhorrence of global variables comes from
dire warnings in other languages (back in the day Fortran programmers
were taught to hate and fear them).

And in the past we have defined a few project-critical variables to have
copies residing on disk, so if a reboot is necessary the system can pick
up where it left off. Nowadays, of course, we'd just put them in flash :-)

Cheers,
Elizaeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[Mark Wills]

On Sep 14, 1:03 am, "Elizabeth D. Rather" <erat...@forth.com> wrote:
> On 9/13/12 8:25 AM, Jason Damisch wrote:
>
>
>
> >> can changes to such global variables be logged to disk? if so it seem bam then all good
>
> > Sorry but the Forth way is to not let the global variables 'get away from you'
> > I mean don't let the global variables become a problem. Use as few of them as
> > possible, and then test your words on the command line, that should help.  I
> > personally have not had a need to write out variables to disk ever, maybe
> > large buffers, but then again there is DUMP.
>
> In my experience, global variables in Forth aren't a problem, and
> they're appropriate whenever you have data that will be used by several
> definitions. I think all this abhorrence of global variables comes from
> dire warnings in other languages (back in the day Fortran programmers
> were taught to hate and fear them).
>
> And in the past we have defined a few project-critical variables to have
> copies residing on disk, so if a reboot is necessary the system can pick
> up where it left off. Nowadays, of course, we'd just put them in flash :-)
>
> Cheers,
> Elizaeth
>
> --
> ==================================================
> Elizabeth D. Rather   (US & Canada)   800-55-FORTH
> FORTH Inc.                         +1 310.999.6784
> 5959 West Century Blvd. Suite 700

> Los Angeles, CA 90045http://www.forth.com

>
> "Forth-based products and Services for real-time
> applications since 1973."
> ==================================================

Depends where one sees Forth in the programming language spectrum, I
suppose. I see Forth somewhere close to Assembly - a sort of super-
duper Assembly language on steroids that supports unlimited factoring
and thus abstraction. Assembly has got on just fine with global
variables over the years ;-)

It's interesting that, in my own mind, whilst I consider Forth to be
every bit as 'elastic' as, say, Java (in terms of how you can abstract
the implementation of your application, I still consider Forth to be a
lower level language. I do think it's more malleable (sp?) than Java,
but it's interesting how Forth can be super low-level and highly
abstracted at the same time! One doesn't get that sense/feeling when
using other languages.

[Brad Eckert]

On Sunday, August 19, 2012 1:04:03 AM UTC-7, Marcel Hendrix wrote:
> Apparently they are working on a 32-bit design. Unexpected,
> given the above philosophy.
>

Too many requests for 32-bit. Maybe they should have a mix of core types, rather than a uniform array.

[rickman]

On 8/19/2012 4:04 AM, Marcel Hendrix wrote:
> Paul Rubin<no.e...@nospam.invalid> writes Re: Green Arrays presentation at Dark Silicon Workshop
>
>> From June 2012 but I just found the slides.
>
>> http://darksilicon.ucsd.edu/2012/assets/slides/5
> [..]
>
> They answer the question why the chip has almost no RAM.

Ok, I give up, why almost no RAM? I can't find this.

> To me, in the limit the authors' expressed philosophy leads
> to the design of e.g. a dedicated video processor, when such
> a device is needed. That will be simpler, cheaper, and
> higher performance than what the GA144 does now.
>
> Apparently they are working on a 32-bit design. Unexpected,
> given the above philosophy.

After looking at some of the limitations of the instructions being
packed into an 18 bit word, I have wondered why not a 20 bit word? If
the data size matches 20 bits will work better for audio apps which
aren't typically 16 bits anymore. 18 bits is a bit tight for audio. 20
bits gives a lot more headroom and each word provides for a FULL 4
instructions of 5 bits each.

> It is strange that there is no mention of the analog
> hardware that is available in the GA144.

Yes, that is a bit odd. I guess that just didn't fit into their focus
on low engergy.

Rick