Java ready for number crunching?
jhc...@gmail.com
Fortran on the numerical tests (spectral norm, planets, etc.) as far
as the running time is concerned.
Let me first say that Java has some undeniable advantages for use in
number crunching:
It has thread semantics in the language definition.
It is memory-safe (very important for debugging and general
correctness) [1]
You can programmatically generate, compile and load Java code at
runtime (specializing the code at runtime may give a huge edge in some
applications)
However, Java also has a very mundane, but serious flaw as far as
numerical computing is concerned: no typedefs. In C++, I like to
define my floating point type as double or float and only use that
alias. Now, when I need to switch the precision in all of the program,
I only change one line.
Another issue is having to duplicate certain functions. Let's say you
are writing a linear equation solver procedure. You might need four
versions of essentially identical code for float, double,
complex<float>, complex<double>, whereas in C++, you could just have
one template.
I'm wondering if people who use Java for number crunching have
opinions on the above.
[1] Memory safety is guaranteed even for buggy multithreaded code with
race conditions, as far as I know.
Mark Space
> However, Java also has a very mundane, but serious flaw as far as
> numerical computing is concerned: no typedefs. In C++, I like to
> define my floating point type as double or float and only use that
> alias. Now, when I need to switch the precision in all of the program,
> I only change one line.
The first thing I would have mentioned is Java doesn't have operator
overloading, resulting in some very unnatural looking algorithms. But I
guess you have a good point. Treating precision as a strategy, and
plugging in a new strategy as desired, as obvious benefits.
>
> Another issue is having to duplicate certain functions. Let's say you
> are writing a linear equation solver procedure. You might need four
> versions of essentially identical code for float, double,
> complex<float>, complex<double>, whereas in C++, you could just have
> one template.
I wonder if something could be added to Java to handle situations like
these. Not a precompiler or C++ style templates, but say a separate
language (like Simula) that handles specialized tasks. The result
should be byte codes and classes linkable to a Java program, although
perhaps not strictly Java internally. A really fancy specialized
handler could handle equations in more than just ascii text. Proper
sigma for summation, anyone?
Actually I'd be surprised if someone hasn't tried to make something like
this already.
none
Java already has Templates now. Check it out, they are on version 1.6, and
I think Templates came in around 1.5 if IRCorrectly
Roedy Green
<jhc...@gmail.com> wrote, quoted or indirectly quoted someone who
said :
> In C++, I like to
>define my floating point type as double or float and only use that
>alias.
Probably a search/replace script to generate the two variants would be
the way to handle it. Each version generates quite different byte
codes. You need two totally different classes you then plug into an
interface.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
lsch...@d.umn.edu
wrote:
> On Sun, 4 May 2008 23:23:16 -0700 (PDT), "jhc0...@gmail.com"
> <jhc0...@gmail.com> wrote, quoted or indirectly quoted someone who
> said :
>
> > In C++, I like to
> >define my floating point type as double or float and only use that
> >alias.
>
> Probably a search/replace script to generate the two variants would be
> the way to handle it. Each version generates quite different byte
> codes. You need two totally different classes you then plug into an
> interface.
Also, there is nothing preventing one from running the C pre-processor
on a Java source file....
Kenneth P. Turvey
could be made to Java to handle math better and one that hadn't been
mentioned yet, that I would very much like to see in Java, is the ability
to handle objects without references.
That is, I would like to be able to include objects as members
themselves, without a reference to them. I would like to be able to call
methods and pass objects into these methods, not references to these
objects.
Basically, I would like a way to reduce the number of levels of
indirection for tight loops. I believe C# already provides this, and of
course, C always has.
--
Kenneth P. Turvey <kt-u...@squeakydolphin.com>
Lew
And Hotspot. This type of thing is better done in HS than in source. If
Hotspot can't do it yet, then have the PTB improve that, rather than clutter
up the language with low-level details. Repeated use of the same object in a
method is easily optimized to the low-level equivalent of with ( instance ) do
{ ... }.
Java was not intended as an assembler language. The distinction between stack
and heap is not intrinsic to OO modeling, nor inherent in Java's
object-allocation strategy even today.
So, basically, Java already gives you what you would like, a way to reduce the
number of levels of indirection for tight loops. It's called Hotspot.
--
Lew
Kenneth P. Turvey
> So, basically, Java already gives you what you would like, a way to
> reduce the number of levels of indirection for tight loops. It's called
> Hotspot.
Fair enough. I guess it just isn't good enough to inspire my confidence
yet.
Tom Anderson
> I was thinking about this thread a bit and what kind of improvements
> could be made to Java to handle math better and one that hadn't been
> mentioned yet, that I would very much like to see in Java, is the
> ability to handle objects without references.
As Lew said, this is something you should leave to the compiler; it's
something it can often do if a class is final, and only has final fields.
Introducing explicit pass-objects-by-value, as in C, leads to a huge mess
of extra complexity.
However, there are some fairly unobstrusive changes that could be made to
the language that would make it much easier for the compiler to do its
magic. The key stumbling block is, i believe, object identity: if a
compiler can't prove that an object will never be subjected to an identity
test (==) which might succeed, it can't inline/unbox it. I think the
minimum you need to achieve this is one new thing and two changes. The new
thing is the ability to declare a class to be a 'value' or 'identityless'
type, presumably with a new keyword (or reuse an old one - native? static?
transient?). This would imply or require that it's final, and that all its
fields are final. The first change is a rule that identity comparisons
where one or both of the operands are variables of identityless type, the
comparison is based not on object identity, but value - the two objects
are equal iff they are of the same class, and their corresponding fields
are also identical (ie for any x, a.x == b.x). The second change is a rule
that object identity need not preserved across assignments to variables of
identityless type (ie with an identityless type 'complex', for Object a =
complex("1+2i"); complex x = (complex)a; Object b = x; boolean eq = a ==
b, then eq would not necessarily be true - although it could be). Those
changes would let compilers inline, stack-allocate and generally muck
about with identityless types to their hearts' content, without having
much of an impact on the way people actually use the language.
tom
--
They didn't have any answers - they just wanted weed and entitlement.
Mark Thornton
> Kenneth P. Turvey wrote:
>> I was thinking about this thread a bit and what kind of improvements
>> could be made to Java to handle math better and one that hadn't been
>> mentioned yet, that I would very much like to see in Java, is the
>> ability to handle objects without references.
>>
>> That is, I would like to be able to include objects as members
>> themselves, without a reference to them. I would like to be able to
>> call methods and pass objects into these methods, not references to
>> these objects.
>> Basically, I would like a way to reduce the number of levels of
>> indirection for tight loops. I believe C# already provides this, and
>> of course, C always has.
>
> And Hotspot. This type of thing is better done in HS than in source.
> If Hotspot can't do it yet, then have the PTB improve that, rather than
> clutter up the language with low-level details. Repeated use of the
> same object in a method is easily optimized to the low-level equivalent
> of with ( instance ) do { ... }.
>
> Java was not intended as an assembler language. The distinction between
> stack and heap is not intrinsic to OO modeling, nor inherent in Java's
> object-allocation strategy even today.
Unfortunately the use of == for object identity makes it difficult to
invisibly convert real objects to 'values'. Objects which don't escape
can be held on the stack, but it is harder to merge objects into others.
The fact that reflection can see private fields means that it isn't
possible to just analyse the visible java code and verify that the field
is never exposed.
As far as I can see, with the current language specification, HotSpot
can't safely do this type of optimisation.
Mark Thornton
Lew
> Unfortunately the use of == for object identity makes it difficult to
> invisibly convert real objects to 'values'. Objects which don't escape
> can be held on the stack, but it is harder to merge objects into others.
> The fact that reflection can see private fields means that it isn't
> possible to just analyse the visible java code and verify that the field
> is never exposed.
>
> As far as I can see, with the current language specification, HotSpot
> can't safely do this type of optimisation.
Hotspot wouldn't optimize portions of the code that contained idioms that
forced a heap allocation, but in blocks that don't do the sorts of things you
mention is most certainly could.
Remember that Hotspot is dynamic, and will de-optimize code at need as runtime
conditions vary. So an object reference might be optimized to register values
in one method but not in another, even though it be the same object.
If Java were limited to static analysis your objections would carry more weight.
--
Lew
Lew
> On Thu, 22 May 2008, Kenneth P. Turvey wrote:
>
>> I was thinking about this thread a bit and what kind of improvements
>> could be made to Java to handle math better and one that hadn't been
>> mentioned yet, that I would very much like to see in Java, is the
>> ability to handle objects without references.
>
> As Lew said, this is something you should leave to the compiler; it's
> something it can often do if a class is final, and only has final
> fields. Introducing explicit pass-objects-by-value, as in C, leads to a
> huge mess of extra complexity.
>
> However, there are some fairly unobstrusive changes that could be made
> to the language that would make it much easier for the compiler to do
> its magic. The key stumbling block is, i believe, object identity: if a
> compiler can't prove that an object will never be subjected to an
> identity test (==) which might succeed, it can't inline/unbox it. I
Which compiler, javac or Hotspot?
Hotspot most certainly can determine whether an object is subject to an ==
comparison. It doesn't need to determine that it never is subject to it, only
that it's not subject to it for a while.
--
Lew
Kenneth P. Turvey
> Which compiler, javac or Hotspot?
>
> Hotspot most certainly can determine whether an object is subject to an
> == comparison. It doesn't need to determine that it never is subject to
> it, only that it's not subject to it for a while.
I must admit that I find this assurance unconvincing. Recently there was
a thread in which boxed and unboxed performance of integer math was
compared (this thread?). Anyway, if the compiler were really smart there
wouldn't be any difference in performance for most of the tests we might
run on these. The compiler would just substitute an unboxed int for the
Integer object we specified and all would be happy.
The fact that the compiler can't see this simple optimization leads me to
believe that relying on the compiler to make these kinds of
optimizations, just isn't reliable yet.
I used to program in Lisp quite a bit. I loved the language. There were
some serious drawbacks to using it though that were mostly solved by
using Java instead. One of the problems with Lisp was that essentially
every variable reference required going through a pointer. In Common
Lisp, type declaration was optional and didn't guarantee that type errors
would be detected. It was solely used to give the compiler hints on how
to optimize code. There were no guarantees it would work, but it made it
possible for the compiler to do some very complex type inference that
could lead to performance on par with C. The problem was that making
Lisp code perform as well as C code was very expensive in terms of
developer time. Usually it was much more expensive than simply rewriting
the code in C. Java is very similar in this regard. Java can perform as
well as C for most applications, but it certainly won't if the code is
developed in a way that would be natural for Java. Making it perform as
well as C is quite expensive and is often more expensive than simply
rewriting the code in the other language. This really eliminates Java
for many kinds of applications. It is too bad that things work out this
way, but it is the truth of the matter.
The language providing constructs that would allow those that really need
to get the most performance possible out of Java would be really nice,
but maybe it is best left to a new language, like Fortress. I must admit
that I'm skeptical that Fortress will be the language we are waiting
for. From what I've read about it, it just doesn't sound like what I
would want to program in. But then it isn't really anywhere near stable
yet, so who knows.
Mark Thornton
Dynamic code optimisation is one thing, but this would require dynamic
object layout changes. That is most unlikely in the foreseeable future.
It just isn't practical to back out merging an object into a parent
object. It is possible to do this for the stack because the allocation
has a well defined lifetime and you have located all references.
Mark Thornton
Mark Thornton
From John Rose (in a comment at
http://blogs.sun.com/jrose/entry/fixnums_in_the_vm)
"The key question is always the deoptimization cost. In this case, it
looks like a full GC could be required to reformat the affected
object(s). It's the Smalltalk "become" primitive, the nasty version
which can change an object's size and layout. I don't think I'm brave
enough to make these transformations automagically. Maybe they would be
justified in the presence of assurances from the user."
You might also look at the comment from Howard Lovatt to the same blog
entry. That refers to the language changes necessary to allow such
optimisations without any fear of having to later deoptimize them.
Mark Thornton
Tom Anderson
> Tom Anderson wrote:
>> On Thu, 22 May 2008, Kenneth P. Turvey wrote:
>>
>>> I was thinking about this thread a bit and what kind of improvements could
>>> be made to Java to handle math better and one that hadn't been mentioned
>>> yet, that I would very much like to see in Java, is the ability to handle
>>> objects without references.
>>
>> As Lew said, this is something you should leave to the compiler; it's
>> something it can often do if a class is final, and only has final fields.
>> Introducing explicit pass-objects-by-value, as in C, leads to a huge mess
>> of extra complexity.
>>
>> However, there are some fairly unobstrusive changes that could be made to
>> the language that would make it much easier for the compiler to do its
>> magic. The key stumbling block is, i believe, object identity: if a
>> compiler can't prove that an object will never be subjected to an identity
>> test (==) which might succeed, it can't inline/unbox it. I
>
> Which compiler, javac or Hotspot?
Hotspot.
> Hotspot most certainly can determine whether an object is subject to an
> == comparison.
No. Not in all cases. In many useful cases, it can, and can then do
unboxing (provided the handful of other restrictions are met too), but
there will be cases where the escape analysis fails, and it just can't
decide whether it will get =='d.
> It doesn't need to determine that it never is subject to it, only that
> it's not subject to it for a while.
Wrong.
tom
--
You are in a twisty maze of directories, all alike. In front of you is
a broken pipe...
Tom Anderson
>> Lew wrote:
>>> Mark Thornton wrote:
>>>
>>>> As far as I can see, with the current language specification, HotSpot
>>>> can't safely do this type of optimisation.
>>>
>>> If Java were limited to static analysis your objections would carry more
>>> weight.
>
> From John Rose (in a comment at
> http://blogs.sun.com/jrose/entry/fixnums_in_the_vm)
>
> "The key question is always the deoptimization cost. In this case, it
> looks like a full GC could be required to reformat the affected
> object(s). It's the Smalltalk "become" primitive, the nasty version
> which can change an object's size and layout. I don't think I'm brave
> enough to make these transformations automagically. Maybe they would be
> justified in the presence of assurances from the user."
Bingo.
> You might also look at the comment from Howard Lovatt to the same blog
> entry. That refers to the language changes necessary to allow such
> optimisations without any fear of having to later deoptimize them.
You mean the link to:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4617197
? He covers all the important things, but also a lot of crazy ideas.