Just as the constant increase of entropy is the basic law of the universe,
so it is the basic law of life to be ever more highly structured and to
struggle against entropy! Václav Havel
units package (e.g. SI units) developped in collaboration with
the JSR-108 experts group. Length by a Duration returns a Velocity instance).Standard, Relativistic,
High-Energy, Quantum and Natural physical models.math package which includes a generic Matrix class,
Real and Complex numbers (and soon LargeInteger
and LargeFraction numbers).This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License (LGPL).
Runtime Environment: J2SE 1.4+
Compilers: JavaTM, JikesTM or GNU Compiler for Java (GCJ)
Build tool: Apache Ant
Collaborative Tool: java.net (code development, comments, issues, bug reporting).
The JADE library is highly optimized for speed. It also provides real-time classes to accelerate code execution by avoiding or postponing memory allocation and garbage collection.
As shown below, gain can be of several orders of magnitude.
|
"Performs 100 successive concatenations of this string." |
HotSpot 1.4.1 |
GCJ 3.2 |
|
String (immutable) |
4.10 ms |
13.89 ms |
|
StringBuffer (mutable) |
0.31 ms |
0.96 ms |
|
StringRT in heap context (immutable) |
0.31 ms |
1.02 ms |
|
StringRT in pool context (mutable) |
0.12 ms |
0.13 ms |
Below the benchmark results on Windows 2000, Compaq at 2.26GHz:
D:\jade-4.6>java -jar jade.jar perf Java(TM) Addition to Default Environment (http://jade.dautelle.com/) Version 4.6.6 June 25 2003 Benchmark... Initialization: 0.17 s JVM Heap allocation versus Pool-Context java.lang.Double (8 bytes) Heap Creation: 42 ns char[128] Heap Creation: 650 ns char[256] Heap Creation: 1263 ns com.dautelle.math.Real (8 bytes) Pool-Context Creation: 33 ns char[128] Pool-Context Creation: 56 ns char[256] Pool-Context Creation: 61 ns Mathematical operations: com.dautelle.math.Real add: 37 ns com.dautelle.math.Complex add: 56 ns com.dautelle.physics.Quantity add: 97 ns com.dautelle.math.Real multiply: 39 ns com.dautelle.math.Complex multiply: 64 ns com.dautelle.physics.Quantity multiply: 122 ns StringRT versus String/StringBuffer: "Performs 100 successive concatenations of this string." java.lang.String Concatenation: 1.497 ms java.lang.StringBuffer Concatenation: 0.106 ms com.dautelle.realtime.StringRT Concatenation(Heap-Context): 0.113 ms com.dautelle.realtime.StringRT Concatenation(Pool-Context): 0.031 ms XML Parsing org.apache.crimson.parser.XMLReaderImpl (Sax2 Parser): 2922 com.dautelle.xml.sax.RealtimeParser: 594 com.dautelle.xml.sax.XmlReaderImpl (Sax2 Wrapper of RealtimeParser): 984 More performance analysis in future versions...
OpenGLTM/DirectXTM bridge API (any help welcome!)
math classes: LargeInteger and
LargeFraction sensitive to the current modulus context
(not set by default). They implements the Operable interface,
making it easy to resolve "modulo" equations (Ref. Number Theory) and
to find the exact solutions to linear equations.
Polynomial class (extends
Function).
July 6, 2003: JADE 4.6.7
Much faster algorithms for the generic
Matrix class.
Member of java.net.Utf8StreamReader (buffer overflow) and
TypeFormat (precision for negative number).java.lang.CharSequence interface (allows for search,
concatenation and comparison with any CharSequence such as itself,
java.lang.String or java.lang.StringBuffer).String several order of magnitude faster
than java.lang.String. Concatenation for example, executing in the default JVM heap
context (where immutability is guaranteed) is basically as fast as if StringBuffer
were being used! For even greater performance, you may execute within
a real-time context, then StringRT
is 2x-3x time faster than java.lang.StringBuffer
(see Benchmark).The real-time package has been finalized. This framework was initially intended for real-time systems, but its "accelerating" effect might appeal to any system dynamically allocating memory.
The cost of memory allocations/initialization can be huge (90% of CPU is not rare) and using mutable objects is unsafe... The framework provides "immutable objects" safety and convenience (e.g. no need to specify a "returnValue" parameter) with the performance of "mutable objects".
Comments To: Jean-Marie Dautelle