From: Ken Tilton on


Tim Bradshaw wrote:
> George Neuner wrote:
>
>
>>Well, on Cells the private memories are not cache but staging memories
>>... the main processor has to move data into and out of them on behalf
>>of the coprocessors. It's very similar to the multi-level memory
>>system used on the old Cray's where the CPU had to fetch and organize
>>data to feed the array processors and store the results back to the
>>shared main memory.
>
>
> It doesn't matter very much who moves the data, it's still cache :-).
> The issue that counts, really, is what the programming model is at the
> user level.

http://common-lisp.net/project/cells/

<sigh>

kenny
From: Alex Mizrahi on
(message (Hello 'Tim)
(you :wrote :on '(9 Jan 2007 23:45:28 -0800))
(

TB> Unfortunately there are almost no tools available which show how much
TB> time a processor spends stalled waiting for memory rather than doing
TB> anything useful - certainly all the standard tools show that time as
TB> the processor being busy.

what's about Intel VTune profiler for Intel processors?
there's also AMD profiler for AMD processors (not that cool though).

)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")


From: Tim Bradshaw on
Ken Tilton wrote:

> http://common-lisp.net/project/cells/

That's either a good pun or you weren't reading the thread carefully
enough. Or perhaps you're a variant Kibo.

From: Tim Bradshaw on
Alex Mizrahi wrote:

> what's about Intel VTune profiler for Intel processors?
> there's also AMD profiler for AMD processors (not that cool though).

I don't know about these, but yes, there are profilers of course - to
be useful they typically need to be able to get access to various
counters in the processor which let them know how many instructions are
stalling, what's happening to the caches, etc. What I really meant was
that a lot of the tools people use to decide where the time is going
don't usefully tell you whether the system is waiting for memory all
the time or whether it's actually really busy.

From: joswig on

Ben schrieb:

> On Jan 8, 8:21 am, "sailormoo...(a)gmail.com" <sailormoo...(a)gmail.com>
> wrote:
> > >From this linkhttp://itpro.nikkeibp.co.jp/a/it/alacarte/iv1221/matsumoto_1.shtml
> > (Note : Japanese)
> > Matsu, the creator of Ruby, said in the next 10 years, 64 or 128 cores
> > desktop computers will be common, it's nearly impossible to simply
> > write that many threads, it should be done automatically, so maybe
> > functional language will do a better job in parallel programming than
> > procedural language like C or Ruby.
>
> Large embedded system quite often have that many threads. Obviously,
> they aren't all actually executing simultaneously on the processors we
> have right now, but various numbers of them are run depending on the
> platform, so the system is (or should be anyway) coded to handle each
> thread executing at any time. Not that I disagree with your point -
> functional programming would be a great help as our systems grow in
> complexity.
>
> Begin old embedded programmer rant:
> Kids these days just have no idea how to watch for side effects and
> avoid them, or why they should. What are they learning in school?!
> And don't even ask them to create a formal state machine for the side
> effects they need. They'd rather throw fifteen booleans in there and
> hope they can cover every possibility!
> End rant.
>
> Regardless of the language used on an actual product, training people
> in functional programming teaches them the skills they need when
> writing large scale concurrent apps, or small, single threaded apps, or
> any code that they don't want to be patching for the next 30 years.
>
> BTW: Has anyone done any hard real time work using Lisp? How'd it go?

There was a LispWorks version with a real-time GC running on a large
ATM Switch.
G2 from Gensym uses a Lisp without GC.