Performance in comparison to Java
Richard Develyn
Can anyone point me to a recent study of comparitive performance between
these two languages - in particular with large scale applications (including
memory useage which is tightly controlled in C++ but doesn't appear to be so
in Java).
The sort of applications we've been writing in C++ here but which are being
challenged by the Java bench are high performing middleware ones.
Cheers
Richard
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Carlos Moreno
Richard Develyn wrote:
>
> Hi all,
>
> Can anyone point me to a recent study of comparitive performance between
> these two languages - in particular with large scale applications (including
> memory useage which is tightly controlled in C++ but doesn't appear to be so
> in Java).
>
> The sort of applications we've been writing in C++ here but which are being
> challenged by the Java bench are high performing middleware ones.
Did you ever try to compare, for instance, applications written in C
versus
applications written in interpreted GW-BASIC or something like that??
I don't have any concrete experience, but comparing Java and C++ *in
performance* sounds to me like one of the biggest jokes ever!!!
Comparing the benefits of the languages, the OO features, the
convenience
that they both offer to write portable and maintainable code efficiently
and buglessly, that would be a different thing -- I personally dislike
Java,
and think that its portability is partly a myth; but I guess it would
be a
matter of personal views (I mean that I would understand that there are
two
points of view).
As an example, try downloading JBuilder 3 for Linux (or was it 2.5??);
it's
an IDE fully written in Java. The minimum requirement in memory is 128
MB!!
And it takes between 30 seconds to 1 minute to *load* on a 450 MHz K6-3
with 128 MBytes... (without running any other application)
I guess that would speak for Java's runtime performance...
Carlos
--
ka...@gabi-soft.de
|> Richard Develyn wrote:
|> > Can anyone point me to a recent study of comparitive performance
|> > between these two languages - in particular with large scale
|> > applications (including memory useage which is tightly controlled
|> > in C++ but doesn't appear to be so in Java).
|> > The sort of applications we've been writing in C++ here but which
|> > are being challenged by the Java bench are high performing
|> > middleware ones.
|> Did you ever try to compare, for instance, applications written in C
|> versus applications written in interpreted GW-BASIC or something
|> like that??
Certainly, comparing recent technology with that 10 or 15 years old
should favor the recent technology. Java is recent technology, however,
and Java interpreters can give C++ compilers a run for their money in
most everyday cases.
The exact question concerned middleware, however, and memory use, rather
than runtime speed. The first, most obvious comment, is that any answer
will be implementation dependant. Several points to consider, however:
- Generally, while garbage collection may be fast, it typically has
noticeable space overhead. If space is really that critical, Java's
obligatory garbage collection may be a problem. On the other hand,
nothing makes a program bigger than a memory leak. And memory leaks
are much easier to avoid with garbage collection. Also, most
implementations of STL are real memory hogs as well.
- Most Java implementations are not only byte-code interpreted; they
only link on running the program, and they do an ultrasafe, but
ultraslow, link. This means that program start-up times can be a
killer for short running applications.
- Finally, a lot of middleware needs to access low-level facilities.
If this is the case, Java poses a problem.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Carlos Moreno
ka...@gabi-soft.de wrote:
>
> |> Did you ever try to compare, for instance, applications written in C
> |> versus applications written in interpreted GW-BASIC or something
> |> like that??
>
> Certainly, comparing recent technology with that 10 or 15 years old
> should favor the recent technology.
I don't know if you understood how I meant that comment... I was
talking
about comparing a GW-BASIC program with a C program *at that time*...
I was somehow suggesting that the performance of C++ is to the
performance
of Java as the performance of C is (was) to the performance of GW-BASIC
or similarly slow technology... (sure, it was probably overstated, but
I was just trying to emphasize that, of all the advantages that C++ may
have over Java, if there is one that is extremely obvious, is runtime
performance)
Carlos
--
Wil Evers
> (sure, it was probably overstated, but I was just trying to
> emphasize that, of all the advantages that C++ may have over
> Java, if there is one that is extremely obvious, is runtime
> performance)
True for now, but I'm not so sure about the future. Java compiler
technology is improving. Many Java implementations translate Java byte
code into machine code on the fly; others (take, for example, the GNU
Java compiler) are capable of doing that before the program is even
run, much like a C++ compiler. I don't believe there's any obvious
reason why a Java program prepared like this has to be much slower than
a C++ program using equivalent language constructs.
If we add garbage collection to the picture, then the Java version might
even turn out to be faster than the C++ version. A garbage collector
for Java can use compile-time information about which memory locations
hold pointers to heap-allocated objects, while a garbage collector for
C++ has to operate at a lower level, and scan lots of memory for
things that look like pointers.
Of course, such a benchmark would be unfair, because it compares a
Java program to a Java-style C++ program. A properly written C++
program doesn't stress the heap as much as a Java program does, and
takes advantage of compile-time type checking in cases where Java must
do so at run-time.
My guess is that in the end, C++ will win as long as the programmer
knows C++ well. Which is of course the real reason people like Java:
there are simply too many idiots out there who will never understand the
difference between 'Date *d = new Date(*today);' and 'Date d(today);'.
- Wil
--
Wil Evers, DOOSYS IT Consultants, Maarssen, Holland
[Wil underscore Evers at doosys dot com]
Mark Wilden
news:kjcgo8...@lnwie.intra.doosys.com...
> In article <39A97486...@mochima.com>, Carlos Moreno wrote:
>
> I don't believe there's any obvious
> reason why a Java program prepared like this has to be much slower than
> a C++ program using equivalent language constructs.
I can think of some. In Java, all member functions are virtual. All types
can be identified at runtime by default. All code is potentially
thread-safe.
> If we add garbage collection to the picture, then the Java version might
> even turn out to be faster than the C++ version.
That's another one. A Java GC may be faster than a C++ GC, but a GC is
slower than no GC.
Francis Glassborow
<bou...@dev.null> writes
>If we add garbage collection to the picture, then the Java version might
>for Java can use compile-time information about which memory locations
>hold pointers to heap-allocated objects, while a garbage collector for
>C++ has to operate at a lower level, and scan lots of memory for
>things that look like pointers.
You do not have to use a conservative garbage collector, you could write
your program using a garbage collecting allocator and avoid the
constructs that break such a GC.
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Wil Evers
> In article <kjcgo8...@lnwie.intra.doosys.com>, Wil Evers
> <bou...@dev.null> writes
[snip]
> >A garbage collector for Java can use compile-time information about
> >which memory locations hold pointers to heap-allocated objects,
> >while a garbage collector for C++ has to operate at a lower level,
> >and scan lots of memory for things that look like pointers.
> You do not have to use a conservative garbage collector, you could
> write your program using a garbage collecting allocator and avoid
> the constructs that break such a GC.
Agreed. In pratice, however, I would expect big problems with
third-party libraries and other legacy that was never written with a
non-conservative collector in mind, or for which the source code is not
accessible. I'd be surprised to see a real-world C++ project that
succesfully uses non-conservative GC.
- Wil
--
Wil Evers, DOOSYS IT Consultants, Maarssen, Holland
[Wil underscore Evers at doosys dot com]
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Wil Evers
> "Wil Evers" <bou...@dev.null> wrote in message
> news:kjcgo8...@lnwie.intra.doosys.com...
> >
> > I don't believe there's any obvious reason why a Java program
> > prepared like this has to be much slower than a C++ program using
> > equivalent language constructs.
>
> I can think of some. In Java, all member functions are virtual.
Not necessarily so in the final machine code image. An optimizing Java
compiler with access to the complete program could check for calls to
methods that are never overridden and replace these with simple
subroutine calls (this has actually been done for C++). Furthermore,
IIRC, Java has a 'final' keyword which prevents derived classes from
overriding a method.
> All types can be identified at runtime by default.
That would only effect the program's performance when that information
is actually used, much like C++'s dynamic_cast. Of course, Java
has no templates, so it has to rely on run-time type information more
often. But as I said, the comparison is between a Java program and a
C++ program using equivalent language constructs.
> All code is potentially thread-safe.
AFAIK, only 'synchronized' methods require locks.
> > If we add garbage collection to the picture, then the Java version
> > might even turn out to be faster than the C++ version.
> That's another one. A Java GC may be faster than a C++ GC, but a GC
> is slower than no GC.
Last time I checked, the GC people claimed they were rapidly getting
closer.
Paolo Carlini
from a practical point of view I find very interesting some recent
publications by Lutz Prechelt (http://wwwipd.ira.uka.de/~prechelt), for
instance:
Comparing Java vs. C/C++ efficiency differences to inter-personal
differences.
Communications of the ACM 42(10):109-112, October 1999.
This paper and many others can be also downloaded from his web pages.
Paolo.
Richard Develyn wrote:
>
> Hi all,
>
> Can anyone point me to a recent study of comparitive performance between
> these two languages - in particular with large scale applications (including
> memory useage which is tightly controlled in C++ but doesn't appear to be so
> in Java).
>
> The sort of applications we've been writing in C++ here but which are being
> challenged by the Java bench are high performing middleware ones.
>
> Cheers
>
> Richard
>
> [ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
> [ about comp.lang.c++.moderated. First time posters: do this! ]
--
Paolo Carlini
Universita' degli Studi della Tuscia
Via de Lellis, snc - Viterbo -ITALY
Ph. +39 0761357027 - Fax. +39 0761357179
Ian McCulloch
>
> Hi all,
>
> Can anyone point me to a recent study of comparitive performance between
> these two languages - in particular with large scale applications (including
> memory useage which is tightly controlled in C++ but doesn't appear to be so
> in Java).
>
> The sort of applications we've been writing in C++ here but which are being
> challenged by the Java bench are high performing middleware ones.
>
> Cheers
>
> Richard
>
> [ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
> [ about comp.lang.c++.moderated. First time posters: do this! ]
I have no benchmarks to present but last time I checked Java floating
point airthmetic was crippled by requiring exact reproducibility on
every platform. Meaning,
(1) FPU's that have extra features (like extra rounding modes etc) that
go beyond the basic Java types cannot be used at all.
(2) FPU's that don't give exact bit-for-bit results that Java requires
can't be used at all, instead Java floating point would have to be
implemented by software emulation. I'm not 100% sure, but probably Cray
floating point fits into this category!!
This makes Java (even with a native compiler) essentially useless for
any flotating point applicatations, numerics, games, etc etc etc. Of
course, this was last time I checked. Sun might have seen the light
since then.
Cheers,
Ian McCulloch
llewe...@edevnull.dot.com
> Hi all,
>
> from a practical point of view I find very interesting some recent
> publications by Lutz Prechelt (http://wwwipd.ira.uka.de/~prechelt), for
> instance:
>
> Comparing Java vs. C/C++ efficiency differences to inter-personal
> differences.
> Communications of the ACM 42(10):109-112, October 1999.
Interesting points:
Instead of comparing a single implementation of a particular
problem in C++ to a single implementation of the same problem in
Java, Prechelt compares 24 programs written Java to 11 programs
written in C++ and 5 programs written in C. (All programs solve
the same problem.)
'As of JDK 1.2, Java programs are typically indeed much slower than
programs written in C or C++. They also consume more memory.'
(quoted from page 5) (In another post, James Kanze points out a
likely reason for the greater memory consumption.)
'The three fastest Java programs are about twice as fast as the
median C/C++ programs, and 10 times slower than the three fastest
C/C++ programs.' (quoted from pg 4)
'... even for one and the same language the inter-personal
differences between implementations of the same program written by
different programmers (good/bad) ratio are much larger than the
average difference between Java and C/C++ ...' (quoted from pg 5)
(Which seems to uphold the long standing belief in computer science
that careful choice of data structures and algorithms usually
makes the biggest difference.)
Prechelt compares g++ 2.7.2 (released in late 1995) to JDK 1.2
(released in (I think) mid 1999) .
Prechelt also notes that the Java programmers had (on average) only
1/2 as much experience as the C++ programmers.
By the way, in my opinion, for most applications, modern hardware +
compilers can deliever good performance whatever the implementation
langauge - and, I believe that C++ has advantages (templates, for
example) that are usually more important than its performance.
External factors are also often more important than performance; if
you have 9 good Java programmers, and no good C++ programmers, your
choice is clear.
>
>
> This paper and many others can be also downloaded from his web pages.
Including one that assess the benefits of type checking (compares K&R
C to ANSI (1989) C), and two that examine the benefits of the
design patterns described in GoF. Perhaps I should have summarized
one of those instead; they are all more interesting.
David Bradley
<ka...@gabi-soft.de> wrote in message news:86snrhe...@gabi-soft.de...
> "Mark Wilden" <ma...@pagm.com> writes:
>
> |> That's another one. A Java GC may be faster than a C++ GC, but a GC
> |> is slower than no GC.
>
> needs some type of dynamic memory management. Often, manual management
> is more expensive than garbage collection.
>
> But again, it all depends on the program.
It depends not only on the program, but the implementation of the GC and
heap allocator. A good GC implementation compared against a poor heap
allocator, GC is sure to win. A good heap allocator versus a poor GC
implementation, the heap is going to win.
And that's one of my pet peeves against Java. They assume the JVM
implementer is going to have the best GC implementation and that no one
could possibly come up with something better. I'd be much happier if I
could
pick and choose the GC implementation, or choose not to use GC at all.
David Bradley
news:m2bsy5i...@brownie.frogger.foobar.snot...
> Paolo Carlini <pcar...@unitus.it> writes:
> External factors are also often more important than performance; if
> you have 9 good Java programmers, and no good C++ programmers, your
> choice is clear.
Yes it is, you get them up to speed on C++ quick ;-) Seriously, it's not as
clear as you might think. If it were, we'd all still being doing COBOL
because most business used to have a ton of COBOL programmers.
Pete Becker
>What Java requires is that the floating point MUST conform to the IEEE 754
>standard for binary floating point arithmetic. Far from crippling Java,
>this is a vast improvement over what has gone before.
What Java requires is a rather naive subset of IEEE 754. Floats are IEEE
754 floats (32 bits), doubles are IEEE 754 doubles (64 bits). There is no
allowance for extended double (80 bits), which is the native floating point
type on Intel chips. You can set an Intel chip to do 64-bit and 32-bit
math, as required by Java, and you get a 10-15% performance hit. Neither C
nor C++ imposes such a limitation. If you want speed and are willing to put
up with additional precision in order to get it, you can do it in C and
C++. You cannot do it in Java.
>Don't worry about the multiple rounding rules. IEEE 754 mandates four
>rounding rules: round to nearest (with ties broken in favor of the even
>choice), round toward zero, round toward +infinity, and round toward
>=infinity. By requiring IEEE 754 conformance, the Java standard requires
>support for these four rounding rules.
Java has no support at all for controlling rounding modes in floating point
math*. Most C libraries let you control rounding, and C99 standardizes
access to rounding modes.
Java also has no provision for accessing the IEEE 754 sticky bits, which
are essential for understanding what has happened in a floating point
computation. Again, most C libraries give you access to these bits, and C99
standardizes how you get at them.
Bit-for-bit reproducibility sounds good on the surface, but it doesn't do
you any good if the bits that were chosen don't get you what you need. As
usual, Java's approach works well for most code, and is unusable for the
rest. C and C++ have always provided flexibility, requiring more
understanding to get things to work, but allowing knowledgeable programmers
to get the most out of their hardware.
----
*On the other hand, java.math.BigDecimal supports eight rounding modes, not
IEEE's piddling four.
-- Pete
Dinkumware, Ltd.
"Genuine Software"
llewe...@edevnull.dot.com
> <llewe...@edevnull.dot.com> wrote in message
> news:m2bsy5i...@brownie.frogger.foobar.snot...
> > Paolo Carlini <pcar...@unitus.it> writes:
> > External factors are also often more important than performance; if
> > you have 9 good Java programmers, and no good C++ programmers, your
> > choice is clear.
>
> Yes it is, you get them up to speed on C++ quick ;-)
Well, if you have the time and other resources, of course ... :-)
> Seriously, it's not as
> clear as you might think. If it were, we'd all still being doing COBOL
> because most business used to have a ton of COBOL programmers.
[snip]
Good point.
Dietmar Kuehl
David Bradley (brad...@nospam.digineer.com) wrote:
: <llewe...@edevnull.dot.com> wrote in message
: news:m2bsy5i...@brownie.frogger.foobar.snot...
: > Paolo Carlini <pcar...@unitus.it> writes:
: > External factors are also often more important than performance; if
: > you have 9 good Java programmers, and no good C++ programmers, your
: > choice is clear.
: Yes it is, you get them up to speed on C++ quick ;-) Seriously, it's not
as
: clear as you might think. If it were, we'd all still being doing COBOL
: because most business used to have a ton of COBOL programmers.
If you have 9 good Java programmers and at least one excellent C++
programmer, C++ is a choice. Without the excellent C++ person I would
recommend to stick with Java. Also, there are some things which are
much easier to be programmed in Java anyway and where I'm using Java,
too. For example, I wouldn't create GUIs in C++ unless I'm in for some
hard core (in which case I would hack away using Xlib, only optionally
using Xt - I love X11 but, honestly, I'm not happy with the libraries
built on top of it, at least not with those I have looked into). On the
other hand, I would not at all get the idea to write algorithm oriented
stuff in Java. That's simply a ridiculous idea :-)
--
<mailto:dietma...@yahoo.de>
<http://www.fmi.uni-konstanz.de/~kuehl/>
I am a realistic optimist - that's why I appear to be slightly pessimistic
David J. Littleboy
"Paolo Carlini" <pcar...@unitus.it> wrote:
>
> from a practical point of view I find very interesting some recent
> publications by Lutz Prechelt (http://wwwipd.ira.uka.de/~prechelt), for
> instance:
I'm surprised that no one has mentioned Kernighan and Pike's "The Practice
of Programming", which contains a Markov algorithm example worked out and
compared in detail in C, Java, C++, Awk, and Perl.
It looked to me as though the C++ version of the program was somewhat
inefficiently implemented; I thought it's use of standard containers was
serious overkill for what it was actually doing.
I'd appreciate comments on whether the above is seriously wrong or not...
David J. Littleboy
Tokyo, Japan
Robert O'Dowd
>
> Ron Hunsinger wrote:
> >What Java requires is that the floating point MUST conform to the IEEE 754
> >standard for binary floating point arithmetic. Far from crippling Java,
> >this is a vast improvement over what has gone before.
>
> What Java requires is a rather naive subset of IEEE 754. Floats are IEEE
> 754 floats (32 bits), doubles are IEEE 754 doubles (64 bits). There is no
> allowance for extended double (80 bits), which is the native floating point
> type on Intel chips. You can set an Intel chip to do 64-bit and 32-bit
> math, as required by Java, and you get a 10-15% performance hit. Neither C
> nor C++ imposes such a limitation. If you want speed and are willing to put
> up with additional precision in order to get it, you can do it in C and
> C++. You cannot do it in Java.
:-) In many applications, additional precision is not an issue (and, if
anything, is a bonus). In some specialised research areas, such as
testing/evaluating convergence of numerical algorithms, it is necessary
to know you don't accidentally get more precision than you bargained
for. And, the researchers are prepared to lose speed to achieve that.
This means you've made an intriguing case for using Java in some rather
specialised numerical codes. Achieving the same thing is typically
possible with FORTRAN compilers with some effort (most mainsteam
compilers do provide options that allow control of the precision/speed
balance) but Java does it natively, albeit as an unintended side effect.
I've yet to be able to do a similar thing conveniently or portably
with C/C++, although it is obviously technically possible.
>
> >Don't worry about the multiple rounding rules. IEEE 754 mandates four
> >rounding rules: round to nearest (with ties broken in favor of the even
> >choice), round toward zero, round toward +infinity, and round toward
> >=infinity. By requiring IEEE 754 conformance, the Java standard requires
> >support for these four rounding rules.
>
> Java has no support at all for controlling rounding modes in floating point
> math*. Most C libraries let you control rounding, and C99 standardizes
> access to rounding modes.
IIRC, the control that most C libraries provides over such things is not
standardised. C99 standardising such things, particularly if such
standardisation can also be done in a future C++, would be a step
forward.
>
> Java also has no provision for accessing the IEEE 754 sticky bits, which
> are essential for understanding what has happened in a floating point
> computation. Again, most C libraries give you access to these bits, and C99
> standardizes how you get at them.
That is not precisely true. Java provides a "native" mechanism
that can be used to call a C function. Of course, that sort of thing
is at odds with many other goals of Java.
[Snip]
Philippe Grabarsky
Indeed I feel that the question is Java better than C++ is often not
the good one. The good question is often: Should I use Java or C++ ?
And this involves a much different approache.
The points are:
- Should it run on the Internet (intranet) ?
- Do you really need the C++ speed performance ? (Just a note:
expression template is nice but I would be crazy to use it according
the common C++ compilers available in the industry).
- Is you team skilled in C++ and/or Java ?
- Do you have a GUI ? Can you use MFC, Ilog Views, sthg else ?
- etc...
The truth is I am strong C++ developer but honestly I have changed my
mind about Java. It is not as slow as I expected (about 2 times slower
in the common use). The real technical problem is that it eats a lot of
memory. I have tryed to use JBuilder 3.5 on my 64Mo 500Mhz Celeron with
Linux and it just swap too much.
Issues like data visibility, overload resolution principles in Java vs
C++ are just for languages lawyers. Let us speek about C++ exception
handling... The fun is that in Java it is simpler but often not well
performed because developers are first-timers.
An other point to consider is that C++ is an ISO standard and Java is
owned by Sun Microsystem. And, according to me, it a major issue. In 5
years will we regret to have chosen Java for our projects ? For
instance, how will end the fight EJB/Corba ?
You said, C++ or Java ? Well,... depends. But if it is for a
middleware, I
would chose C++ (BEA do you hear me ?) because it is time critical.
Sent via Deja.com http://www.deja.com/
Before you buy.
Steve Molitor
> I wouldn't create GUIs in C++ unless I'm in for some
> hard core (in which case I would hack away using Xlib, only optionally
> using Xt - I love X11 but, honestly, I'm not happy with the libraries
> built on top of it, at least not with those I have looked into).
Some of the newer (last 5-10 years) C++ gui libraries are actually
quite nice to program for, such as Qt (Unix, Windows), and Borlands
VCL (Windows only in C++ for now). Certainly these libraries'
performance is much better than Swing, and I think the learning curve
is much easier.
Unfortunately, when people think of C++ and gui, they either think of
MFC (what a monstrosity), or, if they have a Unix backgroud, "OO in
straight C" type libraries like Xt, Motif, or Gtk+. These libraries
work, but they are harder to program for.
--
Steve Molitor
smol...@erac.com
Gabriel Dos Reis
| Pete Becker wrote:
| >
| > Ron Hunsinger wrote:
| > >What Java requires is that the floating point MUST conform to the IEEE
754
| > >standard for binary floating point arithmetic. Far from crippling
Java,
| > >this is a vast improvement over what has gone before.
| >
| > What Java requires is a rather naive subset of IEEE 754. Floats are
IEEE
| > 754 floats (32 bits), doubles are IEEE 754 doubles (64 bits). There is
no
| > allowance for extended double (80 bits), which is the native floating
point
| > type on Intel chips. You can set an Intel chip to do 64-bit and 32-bit
| > math, as required by Java, and you get a 10-15% performance hit.
Neither C
| > nor C++ imposes such a limitation. If you want speed and are willing to
put
| > up with additional precision in order to get it, you can do it in C and
| > C++. You cannot do it in Java.
|
|:-) In many applications, additional precision is not an issue (and, if
| anything, is a bonus).
Hmm, you must be selective in your "many applications". Polynomial
systems solving, Gröbner Basis computations (yes, definitely best done
with exact arithmetic), comptuational geometry (evaluating
predicates), ODE stiff equations to name few, certainly benefit from
additional precision.
--
Gabriel Dos Reis, g...@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
http://www.codesourcery.com/gcc-compile.shtml
Pete Becker
Not at all. As I said above, you can generally force a particular
precision (with suitable and widely available compiler support) in C and
in C++.
> Achieving the same thing is typically
> possible with FORTRAN compilers with some effort (most mainsteam
> compilers do provide options that allow control of the precision/speed
> balance) but Java does it natively, albeit as an unintended side effect.
> I've yet to be able to do a similar thing conveniently or portably
> with C/C++, although it is obviously technically possible.
You haven't tried very hard. Sure, it's not portable. But it's trivial:
usually one function call, or one compile-time switch.
>
> >
> > >Don't worry about the multiple rounding rules. IEEE 754 mandates four
> > >rounding rules: round to nearest (with ties broken in favor of the
even
> > >choice), round toward zero, round toward +infinity, and round toward
> > >=infinity. By requiring IEEE 754 conformance, the Java standard
requires
> > >support for these four rounding rules.
> >
> > Java has no support at all for controlling rounding modes in floating
point
> > math*. Most C libraries let you control rounding, and C99 standardizes
> > access to rounding modes.
>
> IIRC, the control that most C libraries provides over such things is not
> standardised.
Yes, that's why I didn't say that it's standardized in C90, but said
that it's standardized in C99.
> C99 standardising such things, particularly if such
> standardisation can also be done in a future C++, would be a step
> forward.
I suppose I shouldn't continue to be surprised at how Java boosters
muddles tenses. When a new feature is under discussion for Java you hear
that Java has that feature. And when C99 already standardizes access to
rounding control, you hear "C99 standardizing such things ... would be a
step forward." News flash: it's already there. The C99 standard was
adopted last year, as its name implies.
>
> >
> > Java also has no provision for accessing the IEEE 754 sticky bits,
which
> > are essential for understanding what has happened in a floating point
> > computation. Again, most C libraries give you access to these bits, and
C99
> > standardizes how you get at them.
>
> That is not precisely true. Java provides a "native" mechanism
> that can be used to call a C function. Of course, that sort of thing
> is at odds with many other goals of Java.
>
And how do you know that the sticky bits have been preserved when you
get into native code? No guarantees, sorry.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)
Robert O'Dowd
>
> >
> >:-) In many applications, additional precision is not an issue (and, if
> > anything, is a bonus). In some specialised research areas, such as
> > testing/evaluating convergence of numerical algorithms, it is necessary
> > to know you don't accidentally get more precision than you bargained
> > for. And, the researchers are prepared to lose speed to achieve that.
> >
> > This means you've made an intriguing case for using Java in some rather
> > specialised numerical codes.
>
> Not at all. As I said above, you can generally force a particular
> precision (with suitable and widely available compiler support) in C and
> in C++.
Sure. Except that the "suitable and widely available compiler support"
varies a lot between systems. The ability to force a particular
numerical precision is highly compiler or library dependent with
both C/C++ and [to a lesser extent] FORTRAN.
I just found it intriguing --- having had to scratch my head doing that
with a number of FORTRAN and C++ compilers --- that Java, almost by
accident, provides a fixed precision that will happen to suit certain
requirements. I am certainly not trying to use that as a selling
point for Java, as you seem to believe.
>
> > Achieving the same thing is typically
> > possible with FORTRAN compilers with some effort (most mainsteam
> > compilers do provide options that allow control of the precision/speed
> > balance) but Java does it natively, albeit as an unintended side effect.
> > I've yet to be able to do a similar thing conveniently or portably
> > with C/C++, although it is obviously technically possible.
>
> You haven't tried very hard. Sure, it's not portable. But it's trivial:
> usually one function call, or one compile-time switch.
Depends on your perspective, I guess.
With some compilers/libraries no such facility is provided, although
you're correct when you observe that it is a common facility. With
some compilers you use a compile time switch, which is no problem
when porting. However "one function call" is a problem when you
have a hard and fast requirement for "portable code that avoids
compiler dependencies". With that sort of requirement non-portability
of code can be a real issue --- one non-portable function call
is one too many.
>
> >
> > >
> > > >Don't worry about the multiple rounding rules. IEEE 754 mandates four
> > > >rounding rules: round to nearest (with ties broken in favor of the
> even
> > > >choice), round toward zero, round toward +infinity, and round toward
> > > >=infinity. By requiring IEEE 754 conformance, the Java standard
> requires
> > > >support for these four rounding rules.
> > >
> > > Java has no support at all for controlling rounding modes in floating
> point
> > > math*. Most C libraries let you control rounding, and C99 standardizes
> > > access to rounding modes.
> >
> > IIRC, the control that most C libraries provides over such things is not
> > standardised.
>
> Yes, that's why I didn't say that it's standardized in C90, but said
> that it's standardized in C99.
Fair enough. In your previous post, that wasn't obvious to me so I
stated it.
>
> > C99 standardising such things, particularly if such
> > standardisation can also be done in a future C++, would be a step
> > forward.
>
> I suppose I shouldn't continue to be surprised at how Java boosters
> muddles tenses. When a new feature is under discussion for Java you hear
> that Java has that feature. And when C99 already standardizes access to
> rounding control, you hear "C99 standardizing such things ... would be a
> step forward." News flash: it's already there. The C99 standard was
> adopted last year, as its name implies.
Firstly, I'm not a "Java booster". My preference comes down firmly
on the C++ side of the fence. But I'm not afraid to acknowledge
strengths of Java over C++ when they exist --- or exploit those
strengths when appropriate.
Second, I am aware that C99 exists, although I'm not aware of any
implementations [haven't done much with C in the last few months].
My comment about that being a way forward was more concerned with
the fact that C++ does not include all the non-C90 features of C99,
and that something similar to this may be worthwhile in a future
minor evolution of C++.
[Snip]
James Kanze
> In article <39B17EF7...@student.anu.edu.au>, Ian McCulloch
> <s314...@student.anu.edu.au> wrote:
> > I have no benchmarks to present but last time I checked Java floating
> > point airthmetic was crippled by requiring exact reproducibility on
> > every platform. Meaning,
> > (1) FPU's that have extra features (like extra rounding modes etc) that
> > go beyond the basic Java types cannot be used at all.
> > (2) FPU's that don't give exact bit-for-bit results that Java requires
> > can't be used at all, instead Java floating point would have to be
> > implemented by software emulation. I'm not 100% sure, but probably Cray
> > floating point fits into this category!!
> > This makes Java (even with a native compiler) essentially useless for
> > any flotating point applicatations, numerics, games, etc etc etc. Of
> > course, this was last time I checked. Sun might have seen the light
> > since then.
They've seen the light, and have relaxed the floating point
requirements.
> What Java requires is that the floating point MUST conform to the
> IEEE 754 standard for binary floating point arithmetic. Far from
> crippling Java, this is a vast improvement over what has gone
> before.
> It is true this effectively demands bit-for-bit identical
> results. That's because, for the basic operations (add, subtract,
> multipy, divide, remainder, and square root), IEEE 754 specifies, to
> the bit, what the correct result must be.
For a single operation. For a list of operations, many IEEE floating
point processors maintain the intermediate results in internal
registers with higher precision. Java didn't allow this. They now
do, since not doing so has a detrimental effect on performance on
Intel processors. Note, however, that it also means that results of
relatively simple expressions can vary widely from one implementation
to the next. Consider the following program:
#include <iostream>
double a() { return 1e18 ; }
double b() { return 1 ; }
int
main()
{
double x = 2*(a()+b()) - 2*a() ;
cout << x << '\n' ;
return 0 ;
}
With g++, under Windows NT on an Intel box, the results are either 0
or 2, depending on the level of optimization. The original Java
standard required 0 (I believe) -- the current version allows either
result, at least when certain options are given.
> But that demand is easily met on a large number of processors. IEEE
> 754 is implemented on the Intel 8087 and its successors (basically,
> all the Intel FPUs), by the Motorola 68881 and successor (basically,
> all the Motorola FPUs), and in software by SANE (Standard Apple
> Numerics Environment). This is not a coincidence. The four major
> driving forces in the creation of the IEEE 754 standard were
> Dr. W. Kahan, of UC Berkeley (who had been waging a decades-long
> one-man war against the prevailing chaos in floating point
> implementations), Apple, Motorola, and Intel.
See above. The results, at least on Intel, may vary. In practice, if
the two terms above are calculated in separate expressions, you will
always get 0. In the same expression, with optimization, you get the
more correct result of 2, and you get it faster. Or you can set some
flags on the math processor, and get 0 in every case, but not as
quickly.
The initial Java specification required that this flag be set; they
weakened it because it cost too much run time.
Finally, I read an article somewhere on the net by Dr. Kahan in which
he ranted against processors (like Sparc) which didn't support the
extended precision. His initial intention was, apparently, that
extended precision regularly be used so that a naïve user, with an
expression like the above, would get the correct results.
> Don't worry about the multiple rounding rules. IEEE 754 mandates
> four rounding rules: round to nearest (with ties broken in favor of
> the even choice), round toward zero, round toward +infinity, and
> round toward =infinity. By requiring IEEE 754 conformance, the Java
> standard requires support for these four rounding rules.
So where is it? What do I have to do to set the rounding rules? Part
of the intent was that I could run the same code twice, once with
round down and once with round up, to get a range.
I can (now) do this in standard C, provided the processor supports
IEEE. I cannot do it in standard C++, but it is a widespread
extension. And I cannot do it in Java except by means of JNI.
> On the one hand, it's true that IEEE 754 places stringent demands on
> floating point that are not easily met on a (still) large number of
> machines. That's why most languages place almost no requirements on
> the quality of floating point arithmetic.
> But on the other hand, the lack of such language-imposed requirements means
> that people writing real numerical analysis programs have a very difficult
> task writing programs that can be guaranteed to produce meaningful results.
That's true generally, regardless of the format. You're right,
however, that machines with varying precisions (IBM mainframes, for
example), make it particularly difficult, even without considerations
of portability.
> The best they can do is choose defensive algorithms that do extra
> operations to ensure reasonably accurate results. According to
> Kahan, researchers at Los Alamos report that this extra defensive
> coding AT LEAST triples the run time of their programs.
Which is still faster than a software emulation of IEEE on a machine
which doesn't support it.
> Knowing that they will have IEEE 754 arithmetic at their disposal is
> a godsend to people trying to do numerical analysis. Even if the
> floating point has to be done in software, that's still often better
> than the alternative. If you're serious about the results.
The problem is that you need both speed and accuracy. IEEE 754 was a
major step forward for the accuracy, and on newer processors, there is
no speed penalty either. The next step will no doubt be to use it
correctly (and to insist on the presence of extended precision).
> (Note that a machine that has floating point hardware that does not
> conform to IEEE 754 can often leverage off that hardware to simulate
> IEEE 754 more efficiently than a software-only implementation would
> permit. The defective hardware needn't be completely ignored.)
> I consider Java's stringent floating-point requirements to be one of
> its strong points. I wish other languages (C++, Ada) were so
> enlightened.
The argument would be stronger if the stringent requirements had been
the right ones:-). But I can't see Sun requiring something that would
require software emulation on a Sparc. And it is probably extremely
confusing if storing the results of the two terms above in a variable
and then subtracting the variables is required to give different
results than doing it all in one expression.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627