commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Al Chou <hotfusion...@yahoo.com>
Subject RE: [math][functor] More Design Concerns
Date Wed, 02 Jul 2003 04:51:25 GMT
--- Brent Worden <brent@worden.org> wrote:
> > -----Original Message-----
> > From: J.Pietschmann [mailto:j3322ptm@yahoo.de]
> > Sent: Tuesday, July 01, 2003 2:43 PM
> > To: Jakarta Commons Developers List
> > Subject: Re: [math][functor] More Design Concerns
> >
> > brent@worden.org wrote:
> > > I would steer away for primative as much as possible.
> >
> > Keep in mind that excessive object creation can and usually is
> > a significant performance drain, both because it is slow in itself
> > despite all kinds of optimization as well as causing more GC.
> 
> Maybe this was a concern a few years ago but with the improvements to
> HotSpot and GC, these arguments against Java object creation have diminished
> in power.
> 
> One of the biggest gains in GC performance has been with short-lived objects
> (the type of objects that commons-math would be creating and using) and
> effectively and efficiently allocating them in memory and releasing them.
> 
> And with HotSpot, frequently executed pieces of code will actually start to
> increase in performance as a application runs longer, and in many occasions
> eclipse C or C++ performance.

Regardless, I think our primary decision is largely philosophical and
architecture/design/maintenance oriented rather than strictly performance
oriented.  While I am fascinated by what I have read so far of _Structure and
Interpretation of Computer Programs_ and what I've read about functional
programming, I am at the same time pulled by old programming habits to keep
efficiency in mind.  I believe the best thing we could do to inform the
architecture and design of commons-math is survey a reasonable size group of
alpha users of the library.  I don't even know if such a group exists, but I
think anecdotes about actual use will speak more strongly than any amount of
the type of abstract discussion we've been engaging in lately.  Even if it were
the case that almost every design would perform about the same in the JVM, the
fact remains that a considerable number of person-hours would have to go into
implementing any substantial changes in the library's design, so I think we
should not undertake such tasks lightly.

I can contribute the use case that I've had in mind for 1-D
interpolation/extrapolation, but I'll hold off to avoid biasing the discussion
prematurely, as I feel my example tends to support the library's current
interface or something very similar to it.


> Here are a few interesting links about Java performance:
> http://java.sun.com/j2se/1.4/performance.guide.html
> http://servlet.java.sun.com/javaone/resources/content/sf2002/conf/sessions/p
> dfs/2583.pdf
> http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
> http://www.visi.com/~khuber/java/JavaC.pdf
> 
> Here's one article that's hard to fathom:
> http://www.javaperformancetuning.com/news/qotm028.shtml

The "answer in the back of the book" is given by a link from that page. 
Basically, the server-mode Java JIT compiler optimized away the empty loop. 
The article even admits that the client-mode JVM would not do that, and that
Microsoft's C++ compiler would have optimized away the loops (note how the
benchmark steers you to use a Unix or GNU compiler?).



Al

=====
Albert Davidson Chou

    Get answers to Mac questions at http://www.Mac-Mgrs.org/ .

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message