Re: execution times of MATLAB/LAPACK programs

Jeremy Watts wrote:

> Andy,
>
> Thanks for the reply, most informative. Looking at your results I'd say
> Octave whips Java, although I am fairly unsurprised by this.
>

Jeremy,

I'm glad my reply helped.

> My results for a 30 x 30 LU decomp. using Java is 1219ms, which is just over
> 1.2s, so quite a difference there. The method I am using is Doolittles by
> the way - dont know how MATLAB does it though.
>
> For the eigenvalues, its giving nearly 2seconds, again quite a difference.
>
> I guess a lot of it is that Java isnt a fully compiled language, unlike
> fortran, but it compiles to Java byte code.
>

Although I'd expect the fact that Java isn't fully compiled to make
some difference, I think modern JIT Java compilers, and gcc's Java
implementation can perform really quite fast. I think the main
difference is infact due to the issue you describe in your PS:

> PS the other thing is that I am using 'arbitrary length' arithmetic , which
> technically I dont need to use, switching to standard arithmetic would save
> a lot of time I'd say

I'm not a Java expert, but I think that arbitrary length arithmetic
implemented using software libraries and not the CPU's floating point
hardware instructions is **really** going to cost you a lot of time...
of course, whether of not you worry about run-time efficiency depends
on your application.

Of course, being able to solve an eigenvalue problem to arbitrary
precision is impressive in itself, v. useful if that is what you need,
and is a completely different capability to LAPACK or Matlab's
functionality.

But if all you need is double precision floating point precision, then
switching to hardware floating point will probably make a huge
difference to your runtimes....

Best wishes,
andy

PS: You know there is an initial release of a Java version of LAPACK
around?... and also the JAMA library, which has input from the Matlab
company The Mathworks.... See:

http://math.nist.gov/javanumerics/jama/

(Disclaimer: Seek advice from a Java wizard before you rip apart a code
in favour of usual floating point maths though, in case I'm wrong!! I
don't want to waste your time:-) )

.

Relevant Pages

  • Re: Sines and Cosines
    ... and I've got the DJGPP environment running atop ... and that our libraries are dutifully translating ... floating point processor. ... The thing is that our Java implementations are making different choices ...
    (comp.lang.java.programmer)
  • Re: replacing SAS for SMF reports?
    ... which is a decimal floating point ... These classes are pure Java ... Enterprise Cobol Compiler and generate Java classes which use the above ... Java does not have Decimal Floating Point yet, ...
    (bit.listserv.ibm-main)
  • Re: Code Review - is this code shit
    ... isn't possible to test them on every platform for which they might be used. ... the program absolutely, as in Java. ... of floating point, which was an inefficiency too far. ... The real problem is in the hardware, ...
    (comp.lang.c)
  • COBOL floating-point revisited
    ... short, long, and extended formats using just COBOL and Java, then you may ... It is written entirely in J2SE Java and supports all the problem ... additions which include a few new floating point instructions. ... or extended-precision IEEE binary floating-point values. ...
    (bit.listserv.ibm-main)
  • Re: execution times of MATLAB/LAPACK programs
    ... > Jeremy Watts wrote: ... >> Andy, ... >> Octave whips Java, although I am fairly unsurprised by this. ... > But if all you need is double precision floating point precision, ...
    (sci.math.num-analysis)
Quantcast