Re: Fortress without JVM
> I think the issue here is that Fortress is being aimed at
> scientific computing. That domain is currently being dominated by
> FORTRAN, C, C++, MATLAB and Mathematica. There are other libraries
> useful too like OpenMP, MPI, BLAS and LAPACK.
> So, a sort of a "vision statement" (if there is any) will be
> helpful. eg. Is Fortress being envisioned as a JVM language ?
I think that Fortress is envisioned as a programming language, but in
the short-to-medium term, we plan to be hosted on the JVM. If/when
that is the largest cause of performance difficulties, then I think
we reconsider. That's years out, and, given that the JVM has largely
been open-sourced who knows where it will be by then.
See, for instance, John Rose's blog: http://blogs.sun.com/jrose/ .
Right now they're making changes for dynamic languages, but that's
more change than I recall seeing in the VM for quite a few years.
Some of those changes (interface injection, in particular) will make
it much, much easier to host Fortress on the JVM.
If you look at the full suite of functionality provided by a JVM,
it's a minimum of 25 person-years of hard work (some of this is based
on personal experience, some of this is based on history of other
similar projects) if you include all the features that make a VM
interesting, and that estimate may be low by a factor of 4 or 10, if
you include QA, etc. That's a lot of work we'd like to avoid
duplicating.
> If so then are there JVM spec changes being investigated that would
> allow things like MPI (or something superior), superior floating
> point performance, easier linking with LAPACK, BLAS, and tons of
> stuff already available in FORTRAN (and may be C/C++ stuff too).
Yes, no, maybe.
The short answer is, you don't always need VM changes, but maybe
instead you need a motivated compiler-writer. The mapping from
source code to object code is sometimes convoluted in ways that
surprise normal humans. The best interfaces to Fortran might use
some of the unsafe Java extensions. Best FP probably does require VM
changes, but by the time we get to that being the most important
performance problem for Fortress, perhaps those changes will already
have happened. One option is to change the JVM in ways that would
allow it to run Fortran directly (Fortran's cleaner than C, at least
to a compiler writer, so that is an easier job) and thus there would
be no native translation barrier.
> Keep in mind that HPC crowd already deals with things like
> optimizing cache access, coding parts of code in SSE etc which are
> impossible to do with JVM. So some quite radical changes will be
> needed in JVM if Fortress is being envisaged as a JVM language.
I think that there's "impossible", and merely tricky. If the SSE
semantics can be described in standard Java/bytecodes, or if their
behavior can be defined in an "intrinsic" or "native" function, it is
entirely likely that a (dynamic) compiler could recognize the idiom/
intrinsic/native and perform inline substitution. The advantage of
doing it like this is that the resulting code is still portable to
machines that lack SSE hardware -- if you use the C trick of
including inline assembly language, that code just plain won't port.
Recognizing idioms/intrinsics is standard tech in compilers, given
motivated compiler writers. For example, in (32-bit) C, you might write
long long int xy =
((long long int) x << 32) +
((long long int) y & 0xffffffffLL)
and get it compiled into register moves (or perhaps it is all done in
the register allocator).
Or, if you needed a 32x32 into 64 multiplication, you might write
unsigned long long int xy =
((unsigned long long int) x & 0xffffffffLL) *
((unsigned long long int) y & 0xffffffffLL)
The code generator contains patterns for the "obvious" ways to say
this, and all the widening and masking vanishes, to be replaced by a
simple (on Sparc v8, including mandated nops) UMUL x, y, xylo; nop;
nop; nop; rdy xyhi.
These are not contrived examples -- I wrote recognizers for these
very patterns in a compiler developed 15 years ago. That same
compiler had a delightful facility for "inline intrinsics" that would
probably deal with SSE.
David
RSS Feed