Raif S. Naffah wrote:
the attached patch adds support for GNU MP in BigInteger
if/when configured.
How/why is the native version better? Is it really worthwhile to
complicate the code this way? Where are the benchmarks that prove the
native code is faster?
I assume it is already widely know
hello Robert,
On Sunday 03 September 2006 15:26, Robert Lougher wrote:
Hi,
What architecture were you running JamVM on?
here is the uname related lines in my jamvm config.log:
uname -m = i686
uname -r = 2.6.17-1.2174_FC5smp
uname -s = Linux
uname -v = #1 SMP Tue Aug 8 16:00:39 EDT 2006
hello Jeroen,
On Sunday 03 September 2006 18:02, Jeroen Frijters wrote:
...
How/why is the native version better? Is it really worthwhile to
complicate the code this way? Where are the benchmarks that prove the
native code is faster?
the attractiveness of the native code is performance. to
hello Sven,
On Sunday 03 September 2006 19:46, Sven de Marothy wrote:
On Sun, 2006-09-03 at 10:02 +0200, Jeroen Frijters wrote:
Raif S. Naffah wrote:
the attached patch adds support for GNU MP in BigInteger
if/when configured.
How/why is the native version better? Is it really
Raif S. Naffah wrote:
the attractiveness of the native code is performance. to
quickly see how the
new methods improve for example RSA key generation, one can
modify the code
in TestOfRSAKeyGeneration (Mauve) to call the generate()
method N times and
print the duration --on my
Hi,
Try commenting out the code in the function:
setDoublePrecision() located in jamvm/src/os/linux/i386/init.c
This changes the precision of the FPU to 64 bits from extended 80-bit
precision which is the Linux default.
This is necessary to completely conform to the Java specification.
See
Roman reported that the HTML parser eats too much whitespace: the
sequence like
b text /b must be parsed preserving at most one leading and trailing
space
(now all are discarded). As this is an interpretation and not a
programming bug,
this patch may break existing HTML parser tests that
