The APEX APL to SAC/SISAL/D compiler, as a proof of concept,
should convince you that creating a J subset compiler that obtains
excellent serial and parallel performance is definitely feasible.
There are some hard decisions to be made, though, e.g.:
- automatic type promotion(e.g., Boolean -> integer -> double)
is a non-starter in most compiled languages that care about
performance.
- automatic type demotion, too: floor(double), for example, either
must always produce a double or always produce an int.
You can't do the dance of "Well, this one is too big for an int,
so we'll make the result a double."
- Execute and its buddies are also out the door, of course.
- How do you propose to implement data types that are
not native to C? [E.g., bigints] The SAC approach here, which
I think works very well, is via modules and libraries, in
which the new data type support is written in SAC.
- Who is going to fund the work? I think the place to start
is with those people who will benefit materially from
having high-performance J-based applications.
Bob
On 14-02-04 02:48 PM, Raul Miller wrote:
...
Mostly what I want for J is a compiler for a limited subset of the
language. This would let us address a variety of performance issues,
and would also introduce some new problems. Problems, though, that we
should welcome.
Hypothetically speaking, J (or subsets) could be a language for use on
GPU clusters, on large distributed clusters, and for a variety of
other contexts. There's no technical reason we couldn't have process
management vocabularies in the language. But if we go there we'd need
to support the resulting user community, and that needs someone to
pilot it and support it. Lots of people, potentially. It's not just
about the job possibilities - we'd need textbooks for teaching people
and drawing connections to interesting topics, we'd need to support
the academics who found some relevance in our approaches and we'd have
to do that while managing to trim back some of the suggestions.
It seems to me that we could have a J subset targeted at just the
features needed to implement LAPACK and wired into gcc for code
generation.
Thanks,
--
Robert Bernecky
Snake Island Research Inc
18 Fifth Street
Ward's Island
Toronto, Ontario M5J 2B9
[email protected]
tel: +1 416 203 0854
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
