Re: The coming death of all RISC chips.


"Mayan Moudgill" <mayan@xxxxxxxxxxx> wrote in message
news:K5udndh0H9ZGZIrXnZ2dnUVZ_qCdnZ2d@xxxxxxxxxxxxxx
Torben Ægidius Mogensen wrote:
Mayan Moudgill <mayan@xxxxxxxxxxx> writes:



Mayan Moudgill <mayan@xxxxxxxxxxx> wrote:


Prolog, Lisp, Scheme, ML, OCaml, Smalltalk, APL, Matlab, CLU,
Alphard, Ada, Pascal, Modula-2/3, Simula, Occam, CSP, CM-Lisp,
Concurrent Euclid, Id, Forth, Postscript,VHDL.

Consensus of opinion is that the majority of these are better off
compiled to a standard micro-processor.


This may change with massively parallel computers. These will
benefit
from the lack of unrestricted side-effects and aliasing present in
most mainstream languages.


This may be economic (not enough market to justify high-end
specialized machinery), but its been demonstrated that for many of
these, its not possible to get any kind of radical speed-up.


Not on uniprocessor machines, no. In any case, there is little
market
value in making a machine that is optimised for a specific
programming
language, but there may be market value in making a machine that
has
massive compute power, even if you need a specific language to
exploit
this.

Torben

When is a multi-processor necessary?
1. When the performance needed to solve the problem in any
reasonable amount of time exceeds that of a uniprocessor
2. When the coding is sloppy enough and the problem is
parallelizable enough that, though the problem could be solved on a
uniprocessor by more careful programming, its cheaper to throw more
machines at the problem.

Case 1 is a small market where the solution includes programmers who
will do whatever it takes to wring the last iota of performance out
of the machine. I don't think they need new languages, though they
might adopt one (BTW: whatever happenned to Tera's MTA? {Well Cray,
I guess})

Case 2 is a model that (anecdotally) is used in the financial
industry, ERP, and by some of the Web 2.0 companies. The focus here
is on programmer productivity; some of the motivations here are:
- mapping of the language to the application
- legacy
- programmer familiarity with language
- constant code modification/feature enhancement

My current belief is that most people just can't think in terms of
parallel behavior. At one point, I thought that at least people who
had been using VHDL would be an exception, but if you look at the
actual code and the bugs in the code, its not true.

Given that, case 2 will probably desire either sequential languages
augmented with some parallel constructs (and I'd suggest it would be
a shared nothing, message-passing, CSP-derived model), or an
application specific language where the parallelism is inherent in
the data model (Matlab, SQL,...)

People do think in parallel behavior all the time. It's just that
programmers have become used to thinking procedurally and
sequentially. As we used to say "a good programmer can write fortran
in any language" . Ever look at apl code and see a dead ringer for a
do loop?

In real life people don't think so sequentially, in my opinion.

del


.

Relevant Pages

  • Re: Python or PHP?
    ... > every language here and there more ways to do something. ... The best the programmer can do, as you imply, is to ... parse out into proper perl expressions. ... > lists, dictionaries, etc. etc. ...
    (comp.lang.python)
  • Re: Python or PHP?
    ... >> every language here and there more ways to do something. ... The best the programmer can do, as you imply, is to ... I am curious of a list of extraneous methods in Perl (more about the ... I just had a glance on Python, ...
    (comp.lang.python)
  • Re: The War On HLA
    ... Take a look at the HLA compile-time language. ... Macros can be abused just like any other language feature. ... I find it amusing, however, that HLL programmers (e.g., Delphi, ... > feature is left to the programmer to invent his own uses for. ...
    (alt.lang.asm)
  • Re: Is Lisp a Blub?
    ... known in the abstract space of programming language design that "ought" to be ... When the source code changes the programmer ... business needs of the customers who pay the bills. ... What about the Transformation Programmer? ...
    (comp.lang.lisp)
  • [LONG] Re: Why code completion and early error checking are needed
    ... > the programmer who wants such features. ... the guiding principles in the evolution of the c++ language should be ... the problem with this is that ide must first be able to assume ... libraries to find the type declaration. ...
    (comp.lang.cpp)