"Jeff M." <massung@[EMAIL PROTECTED]
> writes:
>> Yes, but the issue raised by Jeff M.'s post was whether there was
>> reason to be concerned that there was no Forth programming model that
>> would be workable for massively superparallel computing.
I believe that's more a matter of opportunity rather than a basic
problem. I.e., one could add extensions appropriate for such systems
just as one they have been added to Fortran or C, it just has not been
done. The reason is probably that most Forth programmers work at the
other end of the computing spectrum (from small embedded systems to
PCs). And of course there's the usual feedback at work (there's no
Forth for supercomputers, so nobody programs supercomputers in Forth).
However, I don't think that this is a reason for concern, because
supercomputers are a pretty specialized niche, and excelling there
does not tend to help in other areas.
>Yes. And in small-scale parallel processing (but across multiple cores
>- not just threads).
Multi-cores, OTOH, are really the future for a large part of
computing, and we should be able to utilize them.
What do you mean with "not just threads"? The typical way to utilize
m cores is to divide your program into n>=m threads.
>The Xbox 360 has 6 cores
3 cores, each SMT with two hardware threads.
> and the PS3 has a 2 core PPU
1 core, and AFAIK no SMT (i.e., 1 thread).
> and multiple SPU
The Cell model does not look like having a big future to me. It comes
out of supercomputer thinking (give us fast, hard-to-program hardware,
and we will optimize our kernels for that, and a few years later we'll
rewrite everything for the next hardware).
However, because the SPUs have limited local memory (256K), Forth
would have an advantage there. However, as mentioned, I think any
success on that model will be short-lived, because it cannot be
transferred to future hardware.
>I seriously cannot
>picture myself solving the kind of problems I'm solving daily (in
>regards to job scheduling, timing memory accesses, ...) in Forth just
>as I can't picture myself writing embedded code in Pascal. But,
>perhaps that's because I've just never tried.
Probably.
>I just wondered if there were attempts at making Forth work
>on more "modern" hardware: vector processors,
Very modern at over 30 years. Marcel Hendrix' work on using BLAS and
other numerical libraries should help on vector processors (including
their modern offspring, the SIMD units of current general-purpose CPUs
(e.g., SSE2 etc.).
> IBM's new CELL,
As I mentioned, I don't think that Cell has a long-term future.
>accessing non-unified memory
What do you mean by that? Distributed memory? Or distributed shared
memory (often called NUMA for "non-uniform memory access", because
local memory access is cheaper than remote memory access)?
Distributed memory tends to be used in special-purpose computers (both
embedded and super), and is often replaced with (distributed) shared
memory as general-purpose computers expand their capabilities to
encompass the application (certainly in supercomputing, probably not
as much in ambedded systems). Forth has been used in such systems
(e.g., the Riad airport system can be seen as a huge
distributed-memory system).
Shared-memory multi-processing is certainly a future trend, due to
multi-cores. On larger (i.e., multiple CPU socket) machines, this is
(going to be) NUMA, but that's only a performance issue. The first
issue we have to deal with is to have support for multi-threading,
adding support for NUMA optimizations comes later.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2008:
http://www.complang.tuwien.ac.at/anton/euroforth/ef08.html
|
