Namespace problem
tech
In file1.h
namespace A
{
class Bar
{
void foo();
};
}
In file2.h
class Bar;
class User
{
Bar* pBar;
};
In file2.cpp
#include "file2.h"
#include "file1.h"
User::func()
{
pBar = new Bar;
pBar->foo(); // linker error here
}
If i try to forward declare in file2.h like this
class A::Bar i get a compiler error saying that A is not a class or
namespace
with MSVC++8.
How to solve this issue.
Martin T.
I think you have to reopen the namespace:
namespace A {
class Bar;
}
class User {
A::Bar* pBar;
}
br,
Martin
Victor Bazarov
> Hi, i have the following problem
>
> In file1.h
>
> namespace A
> {
> class Bar
> {
> void foo();
>
> };
>
> }
>
>
> In file2.h
Add
namespace A {
>
> class Bar;
Add
}
>
> class User
> {
>
> Bar* pBar;
>
> };
>
>
> In file2.cpp
>
> #include "file2.h"
> #include "file1.h"
>
> User::func()
> {
>
> pBar = new Bar;
> pBar->foo(); // linker error here
> }
>
>
> If i try to forward declare in file2.h like this
>
> class A::Bar i get a compiler error saying that A is not a class or
> namespace
> with MSVC++8.
>
> How to solve this issue.
You have to tell the compiler that 'A' is a namespace.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
tech
In file1.h
namespace A
{
class Bar
{
void foo();
};
}
file1.cpp
namespace A
{
Bar::Bar()
{
}
}
In file2.h
namespace A {
class Bar;
}
class User
{
A::Bar* pBar;
};
In file2.cpp
#include "file2.h"
#include "file1.h"
User::func()
{
pBar = new A::Bar;
pBar->foo();
}
Now i have compiler error saying Bar has no default constructor
Victor Bazarov
> Hi, thanks now i have another problem though
>
> In file1.h
>
>
> namespace A
> {
> class Bar
> {
> void foo();
>
>
> };
> }
>
> file1.cpp
>
> namespace A
> {
> Bar::Bar()
> {
> }
> }
Uh... This doesn't see right. The definition of A::Bar class
has the only function, named 'foo' in it. And the implementation
file for some reason attempts to define the default constructor
that you didn't declare.
>
>
> In file2.h
> namespace A {
> class Bar;
> }
>
> class User
> {
>
>
> A::Bar* pBar;
>
>
>
> };
>
>
> In file2.cpp
>
> #include "file2.h"
> #include "file1.h"
>
>
> User::func()
> {
>
> pBar = new A::Bar;
> pBar->foo();
>
> }
>
>
> Now i have compiler error saying Bar has no default constructor
Post your *actual* code.
Razii
http://razi2.blogspot.com/2008/04/shootout-incomplete-benchmarks-game.html
The site at
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
has many computer languages performance on a same few dozen
benchmarks.
For some reason, the java compiled with Jet is not on the site. I
asked him to add Jet to the list, and he gave a really odd excuse
about "license" restrictions. There is nothing in Jet license that
restricts him from posting benchmark results (it's been done on many
web sites). Later he gave even a more weird excuse that they will have
to link to the Jet web page if they include Jet results. Huh? Why
would that be a problem? They already link to every compiler used in
the shootout. The number one ranked compiler on their list is Intel
C++ compiler which is a commercial product (
http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=icpp
). They link to Intel C++ compiler.
Well, since they refused to add what is commonly claimed (we will see)
to be the fastest java compiler, I will run g++ vs jet on my computer
(using the same code that they have and similar flags that they use
for g++). We can then estimate where Jet would rank on their
(incomplete) list .
What I am using:
gcc version 4.3.0 (GCC TDM-2 for MinGW)
Jet version: 6.4 beta
http://www.excelsior-usa.com/jetdlbeta.html
To record time, I downloaded Cygwin and used "time" command. The
output is directed to >/dev/null
Starting today:
binary-trees benchmark
(C++ version)
http://shootout.alioth.debian.org/gp4/benchmark.php?test=binarytrees&lang=gpp&id=2
(java version)
http://shootout.alioth.debian.org/gp4/benchmark.php?test=binarytrees&lang=java&id=2
g++ -pipe -O3 -fomit-frame-pointer -finline-functions binarytrees.cpp
-o binarytrees.exe -march=native
jc -inline+ binarytrees.class
Time in secs as N increases
N 12 14 16
g++ 0.442s 2.343s 13.743s
JVM 0.185s 0.339s 1.281s (-server -Xms64m)
JET 0.284s 0.506s 1.528s
Weird, very weird. According to their site, g++ is 1.6 times faster
than JVM but I don't get the same result using the same source that
they have on their site. With n=13, g++ is 7.5 times slower. huh?
Why? In any case, JVM is faster than JET in this benchmark anyway.
Next benchmark: fannkuch
(coming next).
Razii
Well, as I must find something new to do.
(java version)
http://shootout.alioth.debian.org/gp4/benchmark.php?test=binarytrees&lang=java&id=2
jc -inline+ binarytrees.class
Time in secs as N increases....
N 12 14 16
g++ 0.442s 2.343s 13.743s
JVM 0.185s 0.339s 1.281s (-server -Xms64m)
JET 0.284s 0.506s 1.528s
Weird, very weird. According to their site, g++ is 1.6 times faster
than JVM but I don't get the same result using the same source that
they have on their site. With n=13, g++ is 7.5 times slower. huh?
Why? In any case, JVM is faster than JET in this benchmark anyway.
Next benchmark: fannkuch
coming next
(.........)
Bo Persson
>
> Time in secs as N increases
> N 12 14 16
> g++ 0.442s 2.343s 13.743s
> JVM 0.185s 0.339s 1.281s (-server -Xms64m)
> JET 0.284s 0.506s 1.528s
>
> Weird, very weird. According to their site, g++ is 1.6 times faster
> than JVM but I don't get the same result using the same source that
> they have on their site. With n=13, g++ is 7.5 times slower. huh?
> Why? In any case, JVM is faster than JET in this benchmark anyway.
>
Why don't you just link to the binary-trees result page, so we can all
start using Haskell, ML, Lisp, and Basic for our high performance
programs?
http://shootout.alioth.debian.org/gp4/benchmark.php?test=binarytrees&lang=all
Must be a bad benchmark, as Java 6 -server is at 16th place!
Bo Persson
Martin Gregorie
> Starting today:
> binary-trees benchmark
> (C++ version)
> http://shootout.alioth.debian.org/gp4/benchmark.php?test=binarytrees&lang=gpp&id=2
>
> (java version)
> http://shootout.alioth.debian.org/gp4/benchmark.php?test=binarytrees&lang=java&id=2
>
> g++ -pipe -O3 -fomit-frame-pointer -finline-functions binarytrees.cpp -o
> binarytrees.exe -march=native
>
> jc -inline+ binarytrees.class
>
> Time in secs as N increases....
> N 12 14 16
> g++ 0.442s 2.343s 13.743s
> JVM 0.185s 0.339s 1.281s (-server -Xms64m) JET 0.284s
> 0.506s 1.528s
>
> Weird, very weird. According to their site, g++ is 1.6 times faster than
> JVM but I don't get the same result using the same source that they have
> on their site. With n=13, g++ is 7.5 times slower. huh? Why? In any
> case, JVM is faster than JET in this benchmark anyway.
>
>
There's a hidden factor here: you're not just benchmarking languages and
compilers. You're comparing operating systems as well and doing it with an
algorithm that is hammering memory management.
In this case you're comparing Gentoo Linux against an undeclared edition
of Windows. Linux, like all Unices, is pretty slick at memory management.
It has to be because its design requires it to be fast at spawning
processes and tidying up after they die. UNIX assumes that a lot of small
short life processes are likely to be involved in doing any significant
task while Windows tends to use a single, monolithic program to do the
same job. Things may have changed in the more recent Windows releases, but
in the past its memory management has been spectacularly bad: both slow
and leak-prone.
Binary tree programs tend to allocate small pieces of memory each time a
new node is added to the tree. If, as is likely, the C++ implementation
calls the OS each time it adds a node to the tree while the JVM only asks
the OS for large memory chunks which it internally slices into tree nodes,
then I'd expect the Java process to be a lot faster than the C++ under
Windows. Gentoo memory management is likely to have a similar efficiency
to the JVM, so the website's performance difference could easily be down
to just the JIT and GC overheads.
I strongly suspect that you're seeing the difference in memory management
speeds between Linux and Windows and that this is big enough to mask any
other performance differences between Java and C++.
--
martin@ | Martin Gregorie
gregorie. |
org | Zappa fan & glider pilot
Isaac Gouy
> Well, as I must find something new to do.http://razi2.blogspot.com/2008/04/shootout-incomplete-benchmarks-game...
>
> The site at:http://shootout.alioth.debian.org/gp4/benchmark.php?test=all〈=all
>
> has many computer languages performance on a same few dozen
> benchmarks.
>
> For some reason, the java compiled with Jet is not on the site. I
> asked him to add Jet to the list, and he gave a really odd excuse
> about "license" restrictions. There is nothing in Jet license that
> restricts him from posting benchmark results (it's been done on many
> web sites).
We don't have a JET license.
Excelsior JET non-commercial licensing is conditional - "Authors of
non-commercial Java software willing to exchange links and/or
otherwise promore Excelsior JET are welcome to apply for a free
license."
http://www.excelsior-usa.com/jetpricing.html#non-comm
The fact that others break Excelsior JET license conditions is not a
justification for us to break those license conditions.
> Later he gave even a more weird excuse that they will have
> to link to the Jet web page if they include Jet results. Huh? Why
> would that be a problem? They already link to every compiler used in
> the shootout. The number one ranked compiler on their list is Intel
> C++ compiler which is a commercial product (http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&l...
> ). They link to Intel C++ compiler.
>
> Well, since they refused to add what is commonly claimed (we will see)
> to be the fastest java compiler, I will run g++ vs jet on my computer
> (using the same code that they have and similar flags that they use
> for g++). We can then estimate where Jet would rank on their
> (incomplete) list .
>
> What I am using:
> gcc version 4.3.0 (GCC TDM-2 for MinGW)
> Jet version: 6.4 betahttp://www.excelsior-usa.com/jetdlbeta.html
>
> To record time, I downloaded Cygwin and used "time" command. The
> output is directed to >/dev/null
>
> Starting today:
> binary-trees benchmark
> (C++ version)http://shootout.alioth.debian.org/gp4/benchmark.php?test=binarytrees&...
>
> (java version)http://shootout.alioth.debian.org/gp4/benchmark.php?test=binarytrees&...
>
> g++ -pipe -O3 -fomit-frame-pointer -finline-functions binarytrees.cpp
> -o binarytrees.exe -march=native
>
> jc -inline+ binarytrees.class
>
> Time in secs as N increases....
> N 12 14 16
> g++ 0.442s 2.343s 13.743s
> JVM 0.185s 0.339s 1.281s (-server -Xms64m)
> JET 0.284s 0.506s 1.528s
>
> Weird, very weird. According to their site, g++ is 1.6 times faster
> than JVM but I don't get the same result using the same source that
> they have on their site. With n=13, g++ is 7.5 times slower. huh?
> Why? In any case, JVM is faster than JET in this benchmark anyway.
Different hardware.
Cygwin not Linux
Different gcc.
Windows JVM or Linux JVM?
l...@mail.com
> We don't have a JET license.
>
> Excelsior JET non-commercial licensing is conditional
Did you ask Excelsior for a free license? If yes, did they refuse?
I know for sure they are used to provide free licenses under
conditions other than those you quoted, e.g. to beta testers, and,
guess to whom, to people conducting Java performance studies.
I also recall that, say, the IBM JDK license used to specifically
prohibit publication of benchmark results... Have you reviewed the
licenses of all products you are comparing?
LDV
Isaac Gouy
> On Apr 20, 11:12 pm, Isaac Gouy <igo...@yahoo.com> wrote:
>
> > We don't have a JET license.
>
> > Excelsior JET non-commercial licensing is conditional
>
> Did you ask Excelsior for a free license? If yes, did they refuse?
I haven't asked, I'm not interested in promoting Excelsior JET as a
condition of using it non-commercially.
> I know for sure they are used to provide free licenses under
> conditions other than those you quoted, e.g. to beta testers, and,
> guess to whom, to people conducting Java performance studies.
>
> I also recall that, say, the IBM JDK license used to specifically
> prohibit publication of benchmark results... Have you reviewed the
> licenses of all products you are comparing?
We certainly try to keep up with the changing license conditions. I
removed the Intel compiler measurements when it seemed that the
license forbade publication of benchmark measurements - and now it's
clear that the license for the current non-commercial versions does
not forbid publication of benchmark measurements we are showing the
Intel compilers once more.
Incidentally 4 of the Intel C++ programs don't seem to have the
correct compiler options
http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=icpp&lang2=icpp
I'd welcome advice on how to fix them.
Chris Thomasson
news:12rk04948er3t7ikd...@4ax.com...
> Well, as I must find something new to do..
> http://razi2.blogspot.com/2008/04/shootout-incomplete-benchmarks-game.html
>
> The site at
>
> http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
>
Try this one Razii
Alls this does is attach special allocator's (region and slab) to the
following test:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=binarytrees&lang=gpp&id=2
It performs MUCH better. It should beat Java.
WARNING*
The allocators are not general purpose, there were designed for this test.
Razii
>I also recall that, say, the IBM JDK license used to specifically
>prohibit publication of benchmark results... Have you reviewed the
>licenses of all products you are comparing?
The excuse is bogus. The part that he is quoting only applies to
distributing executables compiled with Jet. In shootout web page, they
are not distributing compiled binaries. They are only posting
benchmark numbers. There is nothing in the license that he quoted that
says you can't quote benchmark results by testing the trial version.
Razii
<cri...@comcast.net> wrote:
>Try this one Razii
>
>http://pastebin.com/m5a125c7b
>
>
>Alls this does is attach special allocator's (region and slab) to the
>following test:
No, it doesn't beat java version because it crashes with n > 14. In
any case, in this thread the topic is the incomplete shootout site.
Chris Thomasson
> On Sun, 20 Apr 2008 11:49:37 -0700, "Chris Thomasson"
> <cri...@comcast.net> wrote:
>
>>Try this one Razii
>>
>>http://pastebin.com/m5a125c7b
>>
>>
>>Alls this does is attach special allocator's (region and slab) to the
>>following test:
>
> No, it doesn't beat java version because it crashes with n > 14.
Yup. Oh well. The slab allocator does not work here.
Roedy Green
wrote, quoted or indirectly quoted someone who said :
>For some reason, the java compiled with Jet is not on the site. I
>asked him to add Jet to the list, and he gave a really odd excuse
>about "license" restrictions. There is nothing in Jet license that
>restricts him from posting benchmark results (it's been done on many
>web sites). Later he gave even a more weird excuse that they will have
>to link to the Jet web page if they include Jet results. Huh? Why
>would that be a problem? They already link to every compiler used in
>the shootout. The number one ranked compiler on their list is Intel
>C++ compiler which is a commercial product (
>http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=icpp
>). They link to Intel C++ compiler.
you can download the trial version of the Jet compiler which generates
code just like the production one and run the benchmarks yourself.
see http://mindprod.com/jgloss/jet.html
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
Chris Thomasson
Sorry about that non-sense Razii. Perhaps I can try again when I get some
free time.
Razii
>Must be a bad benchmark, as Java 6 -server is at 16th place!
There is another problem with the shootout site. The site forces the
java version to either use only -server or use only -Xms64m flag.
C++ version uses different flags with different benchmarks. There are
not zillion of c++ benchmarks, one with only -O2 flag and one with O3
flag for example. However, the shootout site does this with java. That
sounds pretty bogus. Why restrict java to use only -server or only
-Xms64? Only one java benchmark that uses different flags (depending
on what flags produce best result with a particular benchmark) should
be posted (just as C++ benchmark does).
In this benchmark, combining -Xms64m and -server produce best result
when n = 16
4.478s (when only -server flag is used)
1.286s ((when both -server flag and -Xms64 is combined).
Already 4 times faster
Razii
wrote:
>In this benchmark, combining -Xms64m and -server produce best result
>
>when n = 16
>
>4.478s (when only -server flag is used)
>1.286s ((when both -server flag and -Xms64 is combined).
In this benchmark (since it's dependent on GC performance), adding the
flag -XX:NewRatio=1 can further improve the result. This is not so
obvious with n = 16 but with n = 18, you can see the difference.
time java -server binarytrees 18 (only using -server flag)
Time: 11.316s
$ time java -server -Xms64m binarytrees 18 (both -Xms64m and -server)
Time: 0m9.162s
$ time java -server -Xms64m -XX:NewRatio=1 binarytrees 18 (NewRatio 1)
Time: 0m6.105s
Moreover, with n = 18 increasing the total access to memory even
further improves the result with this benchmark
$ time java -server -Xms128m -Xmx128m -XX:NewRatio=1 binarytrees 18
Time: 0m4.575s
Razii
wrote:
>
>time java -server binarytrees 18 (only using -server flag)
>
>Time: 11.316s
>
>$ time java -server -Xms64m binarytrees 18 (both -Xms64m and -server)
>
>Time: 0m9.162s
>
>$ time java -server -Xms64m -XX:NewRatio=1 binarytrees 18 (NewRatio 1)
>Time: 0m6.105s
>
>Moreover, with n = 18 increasing the total access to memory even
>further improves the result with this benchmark
>
>$ time java -server -Xms128m -Xmx128m -XX:NewRatio=1 binarytrees 18
>
>Time: 0m4.575s
there is also the flag
-XX:+AggressiveHeap
This option instructs the JVM to push memory use to the limit: some
GC activity is done in parallel (no Xmx or Xms flags with this option)
$ time java -server -XX:+AggressiveHeap binarytrees 18
0m4.640s
Razii
<igo...@yahoo.com> wrote:
>Incidentally 4 of the Intel C++ programs don't seem to have the
>correct compiler options
>
>http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=icpp&lang2=icpp
>
>I'd welcome advice on how to fix them.
Well, that's interesting. The C++ versions are allowed to use best
compiler options but java version must either use -server or -client
or -Xms64. Why don't you use the best VM options depending on the
benchmark that gives the best result?
Razii
fannkuch benchmark
(c++)
http://shootout.alioth.debian.org/gp4/benchmark.php?test=fannkuch&lang=gpp&id=2
(java)
g++ -pipe -O3 -fomit-frame-pointer -finline-functions fannkuch.cpp -o
fannkuch.exe -march=native
jc -inline+ fannkuch.class
Time in secs as N increases
N 9 10 11
g++ 0.047s 0.392s 5.013s
JVM 0.180s 0.689s 7.057s (-server -Xms64m)
JET 0.278s 0.820s 7.792s
C++ version is faster; however, (given JIT compilation takes time),
the difference decreases with n = 11. With n = 12 (not included in
shootout site), the difference is even smaller
1m34.648s (-server -Xms64m)
1m7.465s (g++)
In any case, JVM is again (slightly) faster than JET native compiler
in this case.
Razii
wrote:
>fannkuch benchmark
>(c++)
>http://shootout.alioth.debian.org/gp4/benchmark.php?test=fannkuch&lang=gpp&id=2
>(java)
http://shootout.alioth.debian.org/gp4/benchmark.php?test=fannkuch&lang=java&id=2
Chris Thomasson
news:LeWdnX_9EpNFEpbV...@comcast.com...
> "Razii" <whatev...@hotmail.com> wrote in message
> news:12rk04948er3t7ikd...@4ax.com...
>> Well, as I must find something new to do..
>> http://razi2.blogspot.com/2008/04/shootout-incomplete-benchmarks-game.html
>>
>> The site at
>>
>> http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
>>
> [...]
>
> Try this one Razii
>
Try this please:
Source-Code
_______________________________________________________
C++: http://pastebin.com/m6db54f31
Java: http://pastebin.com/m15714c90
Build Flags
_______________________________________________________
C++: /O2 /Ob2 /Oi /Ot /Oy /GL /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D
"_UNICODE" /D "UNICODE" /FD /EHsc /MT /Fo"Release\\" /Fd"Release\vc80.pdb"
/W3 /nologo /c /Wp64 /Zi /Gr /TP /errorReport:prompt
Java: -server -Xms64m
Test Results
P4 3.06ghz 512mb
_______________________________________________________
C++: N = 12 / Time: 47 ms
Java: N = 12 / Time: 94 ms
-------------------------------------------------------
C++: N = 13 / Time: 79 ms
Java: N = 13 / Time: 140 ms
-------------------------------------------------------
C++: N = 14 / Time: 172 ms
Java: N = 14 / Time: 250 ms
-------------------------------------------------------
C++: N = 15 / Time: 344 ms
Java: N = 15 / Time: 485 ms
-------------------------------------------------------
C++: N = 16 / Time: 828 ms
Java: N = 16 / Time: 1156 ms
-------------------------------------------------------
C++: N = 17 / Time: 1954 ms
Java: N = 17 / Time: 2359 ms
-------------------------------------------------------
C++: N = 18 / Time: 4485 ms
Java: N = 18 / Time: 7468 ms
-------------------------------------------------------
C++: N = 19 / Time: 11609 ms
Java: N = 19 / Time: 15047 ms
-------------------------------------------------------
C++: N = 20 / Time: 58891 ms
Java: N = 20 / CRASHED! OutOfMemoryError: Java Heap space
-------------------------------------------------------
C++: N = 21 / BOOOOOOM!
Java: N = 21 / CRASHED! OutOfMemoryError: Java Heap space
-------------------------------------------------------
Any thoughts?
Chris Thomasson
Try these with N = 9, 10, 11 Please!
Thank you. Here is results I get on a P4 3.06ghz 512mb system:
Chris Thomasson
[...]
> Try these with N = 9, 10, 11 Please!
>
> C++: http://pastebin.com/m6db54f31
> Java: http://pastebin.com/m15714c90
>
>
> Thank you. Here is results I get on a P4 3.06ghz 512mb system:
>
>
>
>
> Build Flags
> _______________________________________________________
> C++: /O2 /Ob2 /Oi /Ot /Oy /GL /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D
C++ == VC8
Chris Thomasson
This took 15 minutes of my time.
Lew
> This took 15 minutes of my time.
Probably fifteen more minutes than it merited.
--
Lew
Chris Thomasson
news:48ednWg2Jvj2hZHV...@comcast.com...
> Chris Thomasson wrote:
>> This took 15 minutes of my time.
>
> Probably fifteen more minutes than it merited.
:^o
Razii
<cri...@comcast.net> wrote:
>C++: N = 20 / Time: 58891 ms
>Java: N = 20 / CRASHED! OutOfMemoryError: Java Heap space
Well, then increase the heap space. The default heap space is 64m
Chris Thomasson
Strange... I would always assume that native code compiled with JET would
outperform JIT compilation. Odd. I guess its a QOI issue wrt the nature of
the JET compiler.
Razii
<cri...@comcast.net> wrote:
>Try these with N = 9, 10, 11 Please!
>
>C++: http://pastebin.com/m6db54f31
>Java: http://pastebin.com/m15714c90
What does this have to do with fannkuch benchmark benchmark? You are
responding to the wrong post. I am giong to start a new thread with
the third benchmark because once again I don't follow what is going
again.
The output of our C++ version is not correct (at least not with g++ I
haven't tried VC++ yet)
binarytrees2.12
Static Region Reset
Static Region De-Activate
Static Region Activate
Static Region Reset
Static Region Reset
Static Region Reset
Static Region Reset
Static Region Reset
Static Region Reset
Time: 187 ms
The output should look like this for n = 12
Java -server -Xms64m binarytrees 12
stretch tree of depth 13 check: -1
8192 trees of depth 4 check: -8192
2048 trees of depth 6 check: -2048
512 trees of depth 8 check: -512
128 trees of depth 10 check: -128
32 trees of depth 12 check: -32
long lived tree of depth 12 check: -1
Razii
wrote:
>binarytrees2.12
>Static Region Reset
>Static Region De-Activate
>Static Region Activate
>Static Region Reset
>Static Region Reset
>Static Region Reset
>Static Region Reset
>Static Region Reset
>Static Region Reset
>Time: 187 ms
Ops never mind. That was caused by not including /NDEBUG "DEBUG" ..
yuck.
Razii
>This took 15 minutes of my time.
The C++ version crashes on my comp with n = 20
"binarytrees2.exe has encountered problem and needs to be closed
Please tell Microsoft about this problem."
The c++ version compiled with the follwoing flags is slower than java
on my comp
cl /O2 /GL /D "NDEBUG" binarytrees2.cpp /link /ltcg
time binarytrees2 18 >/dev/null
real 0m6.845s
user 0m0.015s
sys 0m0.000s
$ time java -server -Xms512m -Xmx512m -XX:NewRatio=1 binarytrees 18
>/dev/null
real 0m5.316s
user 0m0.015s
sys 0m0.015s
>C++: N = 20 / Time: 58891 ms
>Java: N = 20 / CRASHED! OutOfMemoryError: Java Heap space
If you are going to use such high numbers, increase heap size. The
default is 64m. Try this
java -server -Xms512m -Xmx512m -XX:NewRatio=1 binarytrees 20
l...@mail.com
> On Apr 20, 9:36 am, "l...@mail.com" <l...@mail.com> wrote:
>
> > On Apr 20, 11:12 pm, Isaac Gouy <igo...@yahoo.com> wrote:
>
> > > We don't have aJETlicense.
>
>
> > Did you askExcelsiorfor a free license? If yes, did they refuse?
>
> I haven't asked, I'm not interested in promotingExcelsiorJETas a
> condition of using it non-commercially.
I seem to have failed to explain, sorry. I am sure you can get a free
Excelsior JET license without any such obligations. Just email them a
link to your site and ask if they want their product included in your
studies.
LDV
Razii
Strangely, it crashes with n = 20 with the following flags
cl /O2 /GL /D "NDEBUG" binarytrees2.cpp /link /ltcg
However, it worked with g++....
g++ -pipe -O3 -DNDEBUG -fomit-frame-pointer -finline-functions binar
ytrees2.cpp -o binarytrees2.exe -march=native
$ time binarytrees2 20 >/dev/null
real 0m57.075s
user 0m0.015s
sys 0m0.015s
but was slower than java
$ time java -server -Xms512m -Xmx512m -XX:NewRatio=1 binarytrees 20
>/dev/null
real 0m21.687s
user 0m0.015s
sys 0m0.000s
Razii
<cri...@comcast.net> wrote:
>-------------------------------------------------------
>C++: N = 16 / Time: 828 ms
>Java: N = 16 / Time: 1156 ms
>-------------------------------------------------------
>C++: N = 17 / Time: 1954 ms
>Java: N = 17 / Time: 2359 ms
>-------------------------------------------------------
>C++: N = 18 / Time: 4485 ms
>Java: N = 18 / Time: 7468 ms
>-------------------------------------------------------
>C++: N = 19 / Time: 11609 ms
>Java: N = 19 / Time: 15047 ms
the problem with these high n is that you are restricting java to use
only 64m. If yuo try it with
java -server -Xms512m -Xmx512m
it will improve the result...
Razii
<cri...@comcast.net> wrote:
>C++: N = 20 / Time: 58891 ms
>Java: N = 20 / CRASHED! OutOfMemoryError: Java Heap space
And for n = 20, this should
Razii
>I seem to have failed to explain, sorry. I am sure you can get a free
>Excelsior JET license without any such obligations. Just email them a
>link to your site and ask if they want their product included in your
>studies.
I emailed them with the same question. Their response was....
------- begin quote ---
>Can Excelsior JET 6.4 beta 2 be used with benchmak on the following
We would be happy to provide a full Excelsior JET 6.0 Pro license to
people behind that Web site if they ask us. We would also send them
future updates for as long as they are willing to include our product
in their measurements.
Including a beta version is also OK, as long as its results are
clearly marked as such. We have made a number of application
performance improvements in version 6.4, but not all of them are fully
enabled in the current beta.
Finally, I see they also have Oberon-2 listed, so they may also
include our XDS Modula-2/Oberon-2 compilers
(http://www.excelsior-usa.com/xds.html) XDS is freeware.
---- end quote-----
Obviously there is no problem with including Jet in the shootout.
Razii
<cri...@comcast.net> wrote:
>Try these with N = 9, 10, 11 Please!
>
>C++: http://pastebin.com/m6db54f31
>Java: http://pastebin.com/m15714c90
I guess I figure out why I get different time than you (at least in
this case). The c++ version takes much longer to quit after printing
time
$ time java -server -Xms64m binarytrees2 16
stretch tree of depth 17 check: -1
131072 trees of depth 4 check: -131072
32768 trees of depth 6 check: -32768
8192 trees of depth 8 check: -8192
2048 trees of depth 10 check: -2048
512 trees of depth 12 check: -512
128 trees of depth 14 check: -128
32 trees of depth 16 check: -32
long lived tree of depth 16 check: -1
Time: 1156 ms
real 0m1.277s
user 0m0.015s
sys 0m0.015s
note that it say 1156 ms time and time reported by time command is
pretty close behind 0m1.277s
Now the C++ version
$ time binarytrees2 16
stretch tree of depth 17 check: -1
131072 trees of depth 4 check: -131072
32768 trees of depth 6 check: -32768
8192 trees of depth 8 check: -8192
2048 trees of depth 10 check: -2048
512 trees of depth 12 check: -512
128 trees of depth 14 check: -128
32 trees of depth 16 check: -32
long lived tree of depth 16 check: -1
Time: 843 ms
real 0m1.614s
user 0m0.030s
sys 0m0.000s
Huh? 843 ms reported by internal time (faster than java's 1156 ms but
time reported by time command is 1.614s? The C++ version took longer
to quit after printing 843 ms.
Lew
> responding to the wrong post. I am giong to start a new thread
Please don't.
--
Lew
Chris Thomasson
> On Sun, 20 Apr 2008 21:34:03 -0700, "Chris Thomasson"
> <cri...@comcast.net> wrote:
>
>>"Lew" <l...@lewscanon.com> wrote in message
>>news:48ednWg2Jvj2hZHV...@comcast.com...
>>> Chris Thomasson wrote:
>>>> This took 15 minutes of my time.
>>>
>>> Probably fifteen more minutes than it merited.
>
> Strangely, it crashes with n = 20 with the following flags
>
> cl /O2 /GL /D "NDEBUG" binarytrees2.cpp /link /ltcg
>
> However, it worked with g++....
WIERD!
> g++ -pipe -O3 -DNDEBUG -fomit-frame-pointer -finline-functions binar
> ytrees2.cpp -o binarytrees2.exe -march=native
>
> $ time binarytrees2 20 >/dev/null
>
> real 0m57.075s
> user 0m0.015s
> sys 0m0.015s
>
> but was slower than java
>
> $ time java -server -Xms512m -Xmx512m -XX:NewRatio=1 binarytrees 20
>>/dev/null
>
> real 0m21.687s
> user 0m0.015s
> sys 0m0.000s
What times does the Java and C++ version output for n = 20?
Time: == What?
I am not interested in measuring shutdown time. I will run the tests again
with a bigger heap setting.
Juha Nieminen
Java. In my computer (3.4GHz Pentium4) using gcc 4.1.2 (with the options
-O3 -march=pentium4 -fomit-frame-pointer) it takes 1 min and 17 seconds,
while taking 252 MB of memory (according to 'top').
The task the program solves is in the comment. (Note that I'm not
really asking how fast the *problem* can be solved in Java, but how fast
it can be solved by using this same algorithm/technique.)
/*
Find the largest n for which:
1) n is a prime.
2) The nth prime is smaller than 4200000000.
As the answer, print both n and the nth prime.
And while you are at it, also print the amount of
primes smaller than 4200000000.
*/
#include <bitset>
#include <iostream>
namespace
{
const unsigned MAX_VALUE = 4200000000U;
std::bitset<MAX_VALUE/2> prime;
// http://en.wikipedia.org/wiki/Sieve_of_Eratosthenes
void init()
{
prime.set();
for(unsigned n = 3; n*n < MAX_VALUE; n += 2)
if(prime.test(n/2))
for(unsigned index = n*n; index < MAX_VALUE; index += n)
if(index % 2)
prime.reset(index/2);
}
}
#include <ctime>
int main()
{
const clock_t t1 = std::clock();
init();
unsigned count = prime.count(), p = MAX_VALUE+1;
std::cout << "There are " << count << " primes smaller than "
<< MAX_VALUE << std::endl;
while(true)
{
do p -= 2; while(!prime.test(p/2));
if(count%2 && prime.test(count/2)) break;
--count;
}
const int seconds = (std::clock() - t1)/CLOCKS_PER_SEC;
std::cout << count << "\n" << p << std::endl
<< seconds/60 << " mins " << seconds%60 << " s\n";
}
Chris Thomasson
> On Sun, 20 Apr 2008 21:34:03 -0700, "Chris Thomasson"
> <cri...@comcast.net> wrote:
>
>>"Lew" <l...@lewscanon.com> wrote in message
>>news:48ednWg2Jvj2hZHV...@comcast.com...
>>> Chris Thomasson wrote:
>>>> This took 15 minutes of my time.
>>>
>>> Probably fifteen more minutes than it merited.
>
> Strangely, it crashes with n = 20 with the following flags
>
> cl /O2 /GL /D "NDEBUG" binarytrees2.cpp /link /ltcg
>
> However, it worked with g++....
I know exactly what's causing the delayed shutdown time, and why it crashed.
Apparently, VC++ did not like the static allocator. G++ handled it better,
but it still took a long time to shutdown. Anyway, here is a fix:
Here is the new times I get:
Java: -server -Xms512m -Xmx512m -XX:NewRatio=1
_______________________________________________________
C++: N = 12 / Time: 46 ms
Java: N = 12 / Time: 94 ms
-------------------------------------------------------
C++: N = 13 / Time: 109 ms
Java: N = 13 / Time: 149 ms
-------------------------------------------------------
C++: N = 14 / Time: 281 ms
Java: N = 14 / Time: 297 ms
-------------------------------------------------------
C++: N = 15 / Time: 531 ms
Java: N = 15 / Time: 547 ms
-------------------------------------------------------
C++: N = 16 / Time: 1265 ms
Java: N = 16 / Time: 1078 ms
-------------------------------------------------------
C++: N = 17 / Time: 2140 ms
Java: N = 17 / Time: 1875 ms
-------------------------------------------------------
C++: N = 18 / Time: 4650 ms
Java: N = 18 / Time: 4265 ms
-------------------------------------------------------
C++: N = 19 / Time: 9450 ms
Java: N = 19 / Time: 9109 ms
-------------------------------------------------------
C++: N = 20 / Time: 21671 ms
Java: N = 20 / Time: 23819 ms
-------------------------------------------------------
C++: N = 21 / Time: 42992 ms
Java: N = 21 / Time: 41187 ms
-------------------------------------------------------
The java settings allowed it to complete the N > 19 tests. The C++ version
does not have the static allocator anymore, and all the problems related to
it are gone. Can you test this one please? Its going to have a dramatically
faster shutdown time. Thanks Razii.
Chris Thomasson
Please try this new C++ version:
Here is the new times:
Java: -server -Xms512m -Xmx512m -XX:NewRatio=1
_______________________________________________________
C++: N = 12 / Time: 46 ms
Java: N = 12 / Time: 94 ms
-------------------------------------------------------
C++: N = 13 / Time: 109 ms
Java: N = 13 / Time: 149 ms
-------------------------------------------------------
C++: N = 14 / Time: 281 ms
Java: N = 14 / Time: 297 ms
-------------------------------------------------------
C++: N = 15 / Time: 531 ms
Java: N = 15 / Time: 547 ms
-------------------------------------------------------
C++: N = 16 / Time: 1265 ms
Java: N = 16 / Time: 1078 ms
-------------------------------------------------------
C++: N = 17 / Time: 2140 ms
Java: N = 17 / Time: 1875 ms
-------------------------------------------------------
C++: N = 18 / Time: 4650 ms
Java: N = 18 / Time: 4265 ms
-------------------------------------------------------
C++: N = 19 / Time: 9450 ms
Java: N = 19 / Time: 9109 ms
-------------------------------------------------------
C++: N = 20 / Time: 21671 ms
Java: N = 20 / Time: 23819 ms
-------------------------------------------------------
C++: N = 21 / Time: 42992 ms
Java: N = 21 / Time: 41187 ms
-------------------------------------------------------
Thanks. BTW, this will improve the shutdown time.
cme...@gmail.com
public like this:
namespace A
{
class Bar
{
void foo();
public:
Bar();
};
}
[]
Mello
On Apr 15, 10:59 am, tech <naumansulai...@googlemail.com> wrote:
> Hi, thanks now i have another problem though
>
> In file1.h
>
> namespace A
> {
> class Bar
> {
> void foo();
>
> };
>
> }
>
> file1.cpp
>
> namespace A
> {
> Bar::Bar()
> {
> }
>
> }
>
> In file2.h
> namespace A {
> class Bar;
>
> }
>
> class User
> {
>
> A::Bar* pBar;
>
> };
>
> In file2.cpp
>
> #include "file2.h"
> #include "file1.h"
>
> User::func()
> {
>
> pBar = new A::Bar;
> pBar->foo();
>
> }
>
> Now i have compiler error saying Bar has no default constructor
Juha Nieminen
> for(unsigned index = n*n; index < MAX_VALUE; index += n)
> if(index % 2)
> prime.reset(index/2);
Actually that can be replaced with:
for(unsigned index = n*n; index < MAX_VALUE; index += n*2)
prime.reset(index/2);
OTOH, the speedup is rather small. The runtime was reduced to 1 min
and 13 seconds.
Isaac Gouy
> On Sun, 20 Apr 2008 12:57:30 +0200, "Bo Persson" <b...@gmb.dk> wrote:
> >Must be a bad benchmark, as Java 6 -server is at 16th place!
>
> There is another problem with theshootoutsite. The site forces the
> java version to either use only -server or use only -Xms64m flag.
That's not true! Stop making stuff up!
The JVM flags are clearly shown on the webpages.
> C++ version uses different flags with different benchmarks. There are
> not zillion of c++ benchmarks, one with only -O2 flag and one with O3
> flag for example. However, theshootoutsite does this with java. That
> sounds pretty bogus. Why restrict java to use only -server or only
> -Xms64? Only one java benchmark that uses different flags (depending
> on what flags produce best result with a particular benchmark) should
> be posted (just as C++ benchmark does).
>
> In this benchmark, combining -Xms64m and -server produce best result
>
> when n = 16
>
> 4.478s (when only -server flag is used)
> 1.286s ((when both -server flag and -Xms64 is combined).
>
> Already 4 times faster
Razii
<igo...@yahoo.com> wrote:
>That's not true! Stop making stuff up!
>
>The JVM flags are clearly shown on the webpages.
It's true. The only flag I see are -server -Xbatch -classpath
why not use -server -Xms64m together? Why not use -client if that
helps in a particular benchmark? why have two and three versions, one
only for -server and other only for -client and the other only for
-Xms64m? There are many other flags that can help in cases where a lot
GC activity is included.
Razii
<nos...@thanks.invalid> wrote:
> const unsigned MAX_VALUE = 4200000000U;
huh.
> std::bitset<MAX_VALUE/2> prime;
>
> // http://en.wikipedia.org/wiki/Sieve_of_Eratosthenes
> void init()
> {
> prime.set();
> for(unsigned n = 3; n*n < MAX_VALUE; n += 2)
I am not sure about 64 bit JVM, but on 32 bit (that I have), java
version would be 10 or more times slower because there is no unsigned
in java. That means there is no choice but to use long in all these
loops, which would make it much slower.
Another problem is that this benchmark really depends on how the
Bitsets class is implemented in java. Perhaps C++ library implements
it in more efficient way.
I am going to use MAX_VALUE that stays within the bounds of int (that
also means the index shouldn't go negative also in this loop)
for(int index = n*n;index < MAX_VALUE;index += n)
(c++)
There are 54400028 primes smaller than 1073741824
54399997
1073741173
0 mins 23 s
(java) http://pastebin.com/f58cf4d36
There are 54400028 primes smaller than 1073741824
54399997
1073741173
Time: 47734 ms
java version is still two times slower (it still could be due to
inefficient implementation of Bitset in the library).
By the way, the c++ version crashes with MAX_VALUE == odd number.
Razii
I get similar differences (except for n=20).
Juha Nieminen
> I am going to use MAX_VALUE that stays within the bounds of int (that
> also means the index shouldn't go negative also in this loop)
I think you can safely use a MAX_VALUE of 2000000000 (and in fact a
bit higher) without running into problems.
Chris Thomasson
Yeah. I don't know what happened there. I should have ran each test 5 times
and given an average. Java is pretty damn hard to beat sometimes!
:^D
Isaac Gouy
Steve Wampler
> Another problem is that this benchmark really depends on how the
> Bitsets class is implemented in java. Perhaps C++ library implements
> it in more efficient way.
Definitely. A Java BitSet instance is not fixed in size and can
grow and shrink - and there's quite a bit of code that results from
this. (Clearing a bit, for example, results in a recalculation of the
number of words required to hold the remaining bits - something that
only pays off if you're clearing the rightmost 'on' bits in the set)!
The emphasis of the implementation appears to be more on efficient
space use over the cost of bitwise operations.
Given that this benchmark is really only using a bitset as a (sorta)
space efficient mapping of numbers to primality and makes very
little use of the other bitset features in either C++ or Java, it would
make sense to implement your own more primitive mapping facility
("FixedSizeBitMap", perhaps).
--
Steve Wampler -- swam...@noao.edu
The gods that smiled on your birth are now laughing out loud.
Juha Nieminen
> Given that this benchmark is really only using a bitset as a (sorta)
> space efficient mapping of numbers to primality and makes very
> little use of the other bitset features in either C++ or Java
There's one additional thing where a bitset feature is used
effetively: To count the number of set bits.
I measured how long it takes for the gcc implementation to do so. The
total amount of bits is 2100000000 (ie. half of the max value), from
which 198996103 are 1-bits (ie. the amount of primes smaller than
4200000000). That is, approximately 10% of (quite random) bits are on.
It takes my computer approximately 0.6 seconds to count the number of
1-bits in that bitset. That's approximately one bit test per clock cycle
in average. I'd call that efficient.
Razii
<igo...@yahoo.com> wrote:
>That's not true! Stop making stuff up!
>
>The JVM flags are clearly shown on the webpages.
>
>http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=binarytrees&lang=javaxx&id=2#log
The site so confusing.
Why is -Xms64m flag not added here?
http://shootout.alioth.debian.org/gp4/benchmark.php?test=binarytrees&lang=java&id=2
Why is -Xms64m -server not shown in the ranking on the page?
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
Why is it not shown on ranking on this page?
http://shootout.alioth.debian.org/gp4/benchmark.php?test=binarytrees&lang=all
In any case, there should be one java result that uses the best JVM
options/flags depending on the benchmark.
Bo Persson claimed that java version is ranked 16 but with -server and
Xms64m, it's ranked number 1 in this benchmark. Obviously he too
missed this link on your site given the confused nature of the website
with tons of different flag version used for java instead of one
version with best flags (including -client) depending on the
situation.
Razii
<nos...@thanks.invalid> wrote:
>It takes my computer approximately 0.6 seconds to count the number of
>1-bits in that bitset. That's approximately one bit test per clock cycle
>in average. I'd call that efficient.
Are you on 32-bit OS or 64-bit? If 64-bit, can you compare java vs C++
version? BitSet class uses long arrays of "words". Just make sure to
use -server and enough Xmx value that it doesn't throw out of memory
exception.
Juha Nieminen
Pentium4 is a 32-bit system. Unfortunately I don't have javac
installed here.
(Btw, if you are curious to know how it's even possible for that
function to be so fast, AFAIK it uses this algorithm:
http://en.wikipedia.org/wiki/Hamming_weight )
l...@mail.com
> "Razii" <whatever1...@hotmail.com> wrote in message
>
> news:pgin04h72989d5j53...@4ax.com...
>
>
>
>
>
> > Next:
>
> > fannkuch benchmark
> > (c++)
> >http://shootout.alioth.debian.org/gp4/benchmark.php?test=fannkuch&lan...
> > (java)
>
> > g++ -pipe -O3 -fomit-frame-pointer -finline-functions fannkuch.cpp -o
> > fannkuch.exe -march=native
>
> > jc -inline+ fannkuch.class
>
> > Time in secs as N increases
> > N 9 10 11
> > g++ 0.047s 0.392s 5.013s
> > JVM 0.180s 0.689s 7.057s (-server -Xms64m)
> >JET 0.278s 0.820s 7.792s
>
> > C++ version is faster; however, (given JIT compilation takes time),
> > the difference decreases with n = 11. With n = 12 (not included in
> > shootout site), the difference is even smaller
>
> > 1m34.648s (-server -Xms64m)
> > 1m7.465s (g++)
>
> > In any case, JVM is again (slightly) faster thanJETnative compiler
> > in this case.
>
> Strange... I would always assume that native code compiled withJETwould
> outperform JIT compilation. Odd. I guess its a QOI issue wrt the nature of
> theJETcompiler.
Well, just as HotSpot 6 is in many cases faster than HotSpot 5,
Excelsior claims that Excelsior JET 6.4 beta is 15%-20% faster than
6.0 _on some becnhmarks_, so they surely have more room for
improvement. :)
Any complicated piece of engineering work is full of tradeoffs. For
instance, I know for sure that the HotSpot VM allocates objects on the
heap faster than Excelsior JET VM. But full GC is slower on HotSpot,
dramatically slower if some objects die after being promoted to the
old generation. If GC pauses annoy your users, Excelsior JET may be a
better soluition even if it does not improve overall performance.
http://www.experimentalstuff.com/Technologies/GCold/index.html
LDV
Razii
<nos...@thanks.invalid> wrote:
>for(unsigned index = n*n; index < MAX_VALUE; index += n*2)
this makes 4 sec differences with the newer java version (that
non-libray bitset).
Razii
wrote:
>Given that this benchmark is really only using a bitset as a (sorta)
>space efficient mapping of numbers to primality and makes very
>little use of the other bitset features in either C++ or Java, it would
>make sense to implement your own more primitive mapping facility
>("FixedSizeBitMap", perhaps).
I implemented my own bitset (in fact just copied the part that I
needed from API). The bitset class does not always grow and shrink. It
has a boolean sizeIsSticky = false; which is set to true if the user
uses the constructor BitSet(int nbits).
However, there were still lots of checks ad codes. Using own my own
bitset improved the speed by around 10 sec. Changing the word long[]
words to int [] words further improved the speed by 4 sec.
so here is the c++ version (fixed index += n*2)
http://pastebin.com/fc1186b7
0 mins 21 s (g++ -pipe -O3 -fomit-frame-pointer -march=native)
java version
http://pastebin.com/fef4e048
23813 ms (-server -Xms128m -Xmx128m)
69782 ms (-Xms128m -Xmx128m, i.e -client)
29531 ms (Jet native compiler)
As always -server VM makes a huge difference and is pretty close to
C++ version. It's also again faster than Jet too.
Isaac Gouy
> On Mon, 21 Apr 2008 12:13:28 -0700 (PDT), Isaac Gouy
>
> <igo...@yahoo.com> wrote:
> >That's not true! Stop making stuff up!
>
> >The JVM flags are clearly shown on the webpages.
>
>
> The site so confusing.
Why have you not apologized for repeatedly posting false information,
even after you had been told it was false?
> Why is -Xms64m flag not added here?
> http://shootout.alioth.debian.org/gp4/benchmark.php?test=binarytrees&...
>
> Why is -Xms64m -server not shown in the ranking on the page?
>
> http://shootout.alioth.debian.org/gp4/benchmark.php?test=all〈=all
>
> Why is it not shown on ranking on this page?
>
> http://shootout.alioth.debian.org/gp4/benchmark.php?test=binarytrees&...
>
> In any case, there should be one java result that uses the best JVM
> options/flags depending on the benchmark.
>
> Bo Persson claimed that java version is ranked 16 but with -server and
> Xms64m, it's ranked number 1 in this benchmark. Obviously he too
> missed this link on your site given the confused nature of the website
> with tons of different flag version used for java instead of one
> version with best flags (including -client) depending on the
> situation.
Bo Persson followed the Java URL you posted on Apr 19, 8:24pm & 8:27pm
http://groups.google.com/group/comp.lang.c++/msg/90b91dfa158e6ac6
You didn't post the Java -Xms64m URL even though you posted the Intel C
++ URL for the website that shows Java -Xms64m
Why didn't you post the Java -Xms64m URL?
Why are you still not posting URLs that show these Java measurements?
http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=all
Razii
<igo...@yahoo.com> wrote:
>Why have you not apologized for repeatedly posting false information,
>even after you had been told it was false?
No, it was not false. There is no -Xms64m and -server linked from the
main page.
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
Anyone can go there and check it. You dug up a link but it's not on
the main page. Also,-Xms64m "version" always uses -server flag. Why?
Why it must always use -server flag if the client flag does better in
some cases?
>Bo Persson followed the Java URL you posted on Apr 19, 8:24pm & 8:27pm
Or perhaps Bo Person went to the main page
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
and found the list doesn't have -Xms64m and -server. Anyone can go
there and check it.
Bo Persson
I actually went to the main page, and chose binary-tree in benchmark
selector at the top of the page. That brought me here:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=binarytrees&lang=all
Found it very "interesting" with a benchmark where ML, Haskell,
Erlang, and Lisp is at the top, shortly followed by Eiffel and Basic.
Must have taken a lot of effort to invent that test! :-)
If you look in the "penalty box" at the bottom of the page, you will
of course find that g++ has the best result, but was disqualified for
chosing a faster memory allocation scheme. ROTFL!
Bo Persson
Razii
>I actually went to the main page, and chose binary-tree in benchmark
>selector at the top of the page. That brought me here:
Now he should stop blaming me for posting wrong link and apologize.
The main page doesn't have -Xms64m -server (#1 ranked in this
benchmark). In fact, the main page ranking only uses -server flag (and
not whatever flag that would be fastest in a particular benchmark). I
was correct after all.
The guy is weird, by the way. He also has strange excuses for not
including Jet (even though many other commercial compilers are
included and links to the their commercial site posted).
Isaac Gouy
> On Tue, 22 Apr 2008 09:52:39 -0700 (PDT), Isaac Gouy
>
> <igo...@yahoo.com> wrote:
> >Why have you not apologized for repeatedly posting false information,
> >even after you had been told it was false?
>
> No, it was not false. There is no -Xms64m and -server linked from the
> main page.
>
>
> Anyone can go there and check it. You dug up a link but it's not on
> the main page. Also,-Xms64m "version" always uses -server flag. Why?
> Why it must always use -server flag if the client flag does better in
> some cases?
>
> >Bo Persson followed the Java URL you posted on Apr 19, 8:24pm & 8:27pm
>
> Or perhaps Bo Person went to the main page
>
>
> and found the list doesn't have -Xms64m and -server. Anyone can go
> there and check it.
Why are you posting false information that a page titled "Create your
own Ranking" is the main page?
The main page is titled "The Computer Language Benchmarks Game".
Why are you posting false information that "There is no -Xms64m and -
server linked from the main page"? "Anyone can go there and check it"
and find the link "Java 6 -Xms64m initial java server heap size 64m"
Isaac Gouy
> Razii wrote:
> > On Tue, 22 Apr 2008 09:52:39 -0700 (PDT), Isaac Gouy
> > <igo...@yahoo.com> wrote:
>
> >> Why have you not apologized for repeatedly posting false
> >> information, even after you had been told it was false?
>
> > No, it was not false. There is no -Xms64m and -server linked from
> > the main page.
>
>
> > Anyone can go there and check it. You dug up a link but it's not on
> > the main page. Also,-Xms64m "version" always uses -server flag. Why?
> > Why it must always use -server flag if the client flag does better
> > in some cases?
>
> >> Bo Persson followed the Java URL you posted on Apr 19, 8:24pm &
> >> 8:27pm
>
> > Or perhaps Bo Person went to the main page
>
>
> > and found the list doesn't have -Xms64m and -server. Anyone can go
> > there and check it.
>
> I actually went to the main page, and chose binary-tree in benchmark
> selector at the top of the page.
There is no benchmark selector on the main page
http://shootout.alioth.debian.org/
> That brought me here:
>
> http://shootout.alioth.debian.org/gp4/benchmark.php?test=binarytrees&...
>
> Found it very "interesting" with a benchmark where ML, Haskell,
> Erlang, and Lisp is at the top, shortly followed by Eiffel and Basic.
> Must have taken a lot of effort to invent that test! :-)
>
> If you look in the "penalty box" at the bottom of the page, you will
> of course find that g++ has the best result, but was disqualified for
> chosing a faster memory allocation scheme. ROTFL!
>
> Bo Persson
It's always faster to run just the lap in the stadium rather than the
whole marathon.
Isaac Gouy
> On Tue, 22 Apr 2008 22:56:43 +0200, "Bo Persson" <b...@gmb.dk> wrote:
> >I actually went to the main page, and chose binary-tree in benchmark
> >selector at the top of the page. That brought me here:
>
> Now he should stop blaming me for posting wrong link and apologize.
> The main page doesn't have -Xms64m -server (#1 ranked in this
> benchmark). In fact, the main page ranking only uses -server flag (and
> not whatever flag that would be fastest in a particular benchmark). I
> was correct after all.
The main page is titled "The Computer Language Benchmarks Game".
Why are you posting false information that "There is no -Xms64m and -
server linked from the main page"? "Anyone can go there and check it"
and find the link "Java 6 -Xms64m initial java server heap size 64m"
http://shootout.alioth.debian.org/
Stop posting false information!
>
> The guy is weird, by the way. He also has strange excuses for not
> including Jet (even though many other commercial compilers are
> included and links to the their commercial site posted).
Some compilers are included which have freely available non-commercial
licenses (the Jet non-commercial license is not freely available -
it's restricted).
Razii
<igo...@yahoo.com> wrote:
>There is no benchmark selector on the main page
>
>http://shootout.alioth.debian.org/
There is. If you click on "Show" tab, it takes you to this page.
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
There is no -server -Xms64m on this ranking. That's how Bo apparently
found the link. You should apologize by claiming Bo followed my link.
He didn't. Also, you didn't explain why -Xms64m must always use
-server? Why not -client sometimes if that helps in some cases? Or
other flags?
>Some compilers are included which have freely available non-commercial
>licenses (the Jet non-commercial license is not freely available -
>it's restricted).
There is no restriction on testing and posting the benchmark. You are
lying. The restriction is on distributing compiled executable, which
is irrelevant here.
Razii
<igo...@yahoo.com> wrote:
>There is no benchmark selector on the main page
>
>http://shootout.alioth.debian.org/
Steve Wampler
> (Btw, if you are curious to know how it's even possible for that
> function to be so fast, AFAIK it uses this algorithm:
> http://en.wikipedia.org/wiki/Hamming_weight )
That's most likely the same as in Java's Long/Integer.bitCount()
methods, I think.
The BitSet in Java suffers from the use of longs when run in 32bit
mode, for operations on individual bits. Long operations such as
bit shifting are double-word operations in a 32bit world.
It would be more efficient in this case to use a (simplified) bit
set class that uses ints internally instead of longs. Perhaps
considerably so for the current benchmark.
Razii
<igo...@yahoo.com> wrote:
>Why are you posting false information that a page titled "Create your
>own Ranking" is the main page?
It's clear by now that you and your site has zero credibility. It's a
scam. I won't waste any more time on you after this post.
To summarize, anyone can go to the main site
http://shootout.alioth.debian.org/
where there is no ranking, no numbers, nothing. If you click on "show"
tab, that takes you to this page
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
that does have ranking, but there is no -Xms64m. Also, why -Xms64m
must always use -server flag and vice versa? This guy failed to answer
that. Even Bo Person told him that this is how he found the 16th place
ranking, but this idiot, instead of admitting the obvious, keeps
spining and twisting.
I am done with this fool and will continue posting the rest of the
results.
Isaac Gouy
> On Wed, 23 Apr 2008 07:49:07 -0700 (PDT), Isaac Gouy
>
> <igo...@yahoo.com> wrote:
> >There is no benchmark selector on the main page
>
> >http://shootout.alioth.debian.org/
>
> There is. If you click on "Show" tab, it takes you to this page.
>
>
> There is no -server -Xms64m on this ranking. That's how Bo apparently
> found the link. You should apologize by claiming Bo followed my link.
> He didn't. Also, you didn't explain why -Xms64m must always use
> -server? Why not -client sometimes if that helps in some cases? Or
> other flags?
Bo wrote: "I actually went to the main page, and chose binary-tree in
benchmark selector at the top of the page. That brought me here...".
http://groups.google.com/group/comp.lang.c++/msg/bd2a2ac332ddd04b
As you just discovered - Bo could not have chosen "binary-tree in
benchmark selector at the top of the page".
There is no "binary-tree in benchmark selector at the top of the
page".
There's a button hard-coded to an entirely different webpage!
Isaac Gouy
> On Wed, 23 Apr 2008 07:41:44 -0700 (PDT), Isaac Gouy
>
> <igo...@yahoo.com> wrote:
> >Why are you posting false information that a page titled "Create your
> >own Ranking" is the main page?
>
> It's clear by now that you and your site has zero credibility. It's a
> scam. I won't waste any more time on you after this post.
>
> To summarize, anyone can go to the main site
>
> http://shootout.alioth.debian.org/
>
> where there is no ranking, no numbers, nothing. If you click on "show"
> tab, that takes you to this page
>
>
> that does have ranking, but there is no -Xms64m. Also, why -Xms64m
> must always use -server flag and vice versa? This guy failed to answer
> that. Even Bo Person told him that this is how he found the 16th place
> ranking, but this idiot, instead of admitting the obvious, keeps
> spining and twisting.
>
> I am done with this fool and will continue posting the rest of the
> results
To summarize, anyone can go to the main site
http://shootout.alioth.debian.org/
where there's a "Programming language measurements A to Z" link list
which includes
Bo Persson
> On Apr 23, 1:38 pm, Razii <whatever1...@hotmail.com> wrote:
>> On Wed, 23 Apr 2008 07:49:07 -0700 (PDT), Isaac Gouy
>>
>> <igo...@yahoo.com> wrote:
>>> There is no benchmark selector on the main page
>>
>>> http://shootout.alioth.debian.org/
>>
>> There is. If you click on "Show" tab, it takes you to this page.
>>
>>
>> There is no -server -Xms64m on this ranking. That's how Bo
>> apparently found the link. You should apologize by claiming Bo
>> followed my link. He didn't. Also, you didn't explain why -Xms64m
>> must always use -server? Why not -client sometimes if that helps
>> in some cases? Or other flags?
>
> Bo wrote: "I actually went to the main page, and chose binary-tree
> in benchmark selector at the top of the page. That brought me
> here...".
>
> http://groups.google.com/group/comp.lang.c++/msg/bd2a2ac332ddd04b
>
> As you just discovered - Bo could not have chosen "binary-tree in
> benchmark selector at the top of the page".
>
> There is no "binary-tree in benchmark selector at the top of the
> page".
>
> There's a button hard-coded to an entirely different webpage!
Ok, so I started from there (following Razii's link).
I *could* have gone to the main page, pressed "show", and *then*
selected binary-tree. Big deal!
I now see that Java 6 -server is down to 17th place. :-)
Bo Persson
Isaac Gouy
We don't use labels like 1st place, 2nd place, 3rd place on the
webpages because those labels don't say anything that's interesting.
We use labels that say how much slower the implementation is than the
fastest implementation.
Overall, the geometric mean of those ratios for the Java 6 -server
programs is 1.7 times larger than the geometric mean of those ratios
for the measured Intel C++ programs.
Razii
>I *could* have gone to the main page, pressed "show"...
Exactly. And -Xms64m is not on that page.
>I now see that Java 6 -server is down to 17th place. :-)
The shootout site is bogus and should not be taken seriously. It
forces java version to use only one flag in all tests, regardless if
another flag would do better. The guy also posted bogus excuses why
Jet is not on the site.
Also, as someone pointed out, the newly added Lisaac numbers in
binarytrees are bogus too.
(left = NULL).if {
left := TREENODE.clone;
right := TREENODE.clone;
};
The above tests whether the node has a NULL left branch and only then
creates two new fresh nodes for the left and right branches. Lisaac
version does only a very small fraction of the allocations done by a
correct implementation of the benchmark.
Roedy Green
wrote, quoted or indirectly quoted someone who said :
> fastest java compiler,
By that do you mean?
1. fastest to compile a single class
2. fastest to compile some large group of classes.
3. generates the fastest byte code.
4. generates the fastest machine code
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
Razii
<see_w...@mindprod.com.invalid> wrote:
>> fastest java compiler,
>
>By that do you mean?
It's claimed it generates the fastest machine code (compared to
HotSpot and GCJ), something that has not yet proven. I will finish the
rest of benchmarks from the bogus shootout site later.
Isaac Gouy
> On Fri, 25 Apr 2008 21:57:45 +0200, "Bo Persson" <b...@gmb.dk> wrote:
> >I *could* have gone to the main page, pressed "show"...
>
> Exactly. And -Xms64m is not on that page.
And -Xms64m is not shown
- on the FAQ page
- on any of the Debian : AMD™ Sempron™ pages
- on numerous other pages
And -Xms64m is shown on the main page
"Java 6 -Xint ubiquitous bytecode interpreter virtual machine
Java 6 -Xint Debian
Java 6 -Xms64m initial java server heap size 64m
Java GNU gcj optimizing ahead-of-time compiler
Java GNU gcj Debian
JavaScript JavaScriptCore WebKit-based ECMA scripting implementation
Debian"
http://shootout.alioth.debian.org/
And -Xms64m is shown on this "Create your own Ranking" page
"1.6 Fortran Intel
1.7 Eiffel SmartEiffel
1.7 Java 6 -Xms64m
1.8 Java 6 -server
1.8 OCaml 2.33"
http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=all
And -Xms64m is shown on numerous other pages.
Isaac Gouy
Yes, yesterday, Vesa pointed out that the Lisaac binary-trees program
wasn't doing the right thing, and today that Lisaac binary-trees
program has been removed.
The benchmarks game shows full program source and build & run logs so
that many eyes can see what's going on and cry foul if they think
something is wrong.
4 days ago Vesa commented on reddit that the Eiffel binary-trees
program wasn't doing the right thing, and that Eiffel program was
removed, and someone contributed a new Eiffel program and today that
new Eiffel program is shown on the website.
Find bugs; Fix bugs.
Isaac Gouy
> The shootout site is bogus and should not be taken seriously. It
> forces java version to use only one flag in all tests, regardless if
> another flag would do better.
It's been at least a week since you were shown that both -server and -
Xms64m are used
/opt/sun-jdk-1.6.0.02/bin/java $JDKFLAGS -server -Xms64m -Xbatch -
classpath binarytrees.javaxx-2.javaxx_run binarytrees %A
/opt/sun-jdk-1.6.0.04/bin/java $JDKFLAGS -server -Xms64m -Xbatch -
classpath chameneosredux.javaxx-2.javaxx_run chameneosredux %A
/opt/sun-jdk-1.6.0.03/bin/java $JDKFLAGS -server -Xms64m -Xbatch -
classpath fannkuch.javaxx-2.javaxx_run fannkuch %A
/opt/sun-jdk-1.6.0.02/bin/java $JDKFLAGS -server -Xms64m -Xbatch -
classpath fasta.javaxx-2.javaxx_run fasta %A
/opt/sun-jdk-1.6.0.02/bin/java $JDKFLAGS -server -Xms64m -Xbatch -
classpath knucleotide.javaxx_run knucleotide %A
etc etc
http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=javaxx&lang2=javaxx
Razii
<igo...@yahoo.com> wrote:
>> Exactly. And -Xms64m is not on that page.
>
>
>And -Xms64m is not shown
It's not shown when you click on "show" from the main page. That all
that matters. I don't care where else it's shown. Regardless, the
-Xms64m always uses -server flag when it shouldn't have to when client
is faster in some cases (like startup). There are other flags that
might change the result if there is heavy GC activity. They are not
used either.
Isaac Gouy
> On Tue, 29 Apr 2008 11:32:45 -0700 (PDT), Isaac Gouy
>
> <igo...@yahoo.com> wrote:
> >> Exactly. And -Xms64m is not on that page.
>
> >And -Xms64m is not shown
>
> It's not shown when you click on "show" from the main page. That all
> that matters. I don't care where else it's shown. Regardless, the
> -Xms64m always uses -server flag when it shouldn't have to when client
> is faster in some cases (like startup).
You've spent 10 days making untrue claims:
Apr 20, "The site forces the java version to either use only -server
or use only -Xms64m flag ... In this benchmark, combining -Xms64m and -
server produce best result ..."
http://groups.google.com/group/comp.lang.c++/msg/557c32cfcefbdf49
Apr 21, "The only flag I see are -server -Xbatch -classpath"
http://groups.google.com/group/comp.lang.c++/msg/7d7362cf9db02083
Apr 22, "There is no -Xms64m and -server linked from the main
page. ... You dug up a link but it's not on the main page."
http://groups.google.com/group/comp.lang.c++/msg/c0c282fa0bbac488
etc etc
Now instead of admitting that your claims were wrong, you've changed
what you claim.
(Note: you seem confused about the purpose of "startup")
> There are other flags that
> might change the result if there is heavy GC activity. They are not
> used either.
Apr 20, "In this benchmark (since it's dependent on GC performance),
adding the
flag -XX:NewRatio=1 can further improve the result. This is not so
obvious with n = 16 but with n = 18, you can see the difference. "
And that benchmark is shown on the website N=16.
Why don't you go through all the Java programs measuring every
combination of JVM flag and report what you find?
Razii
<igo...@yahoo.com> wrote:
>You've spent 10 days making untrue claims:
It's not untrue. Clicking show from the mainpage doesn't show -server
hence it's irrelevant where else it's found.
thufir
> It's claimed it generates the fastest machine code (compared to HotSpot
> and GCJ), something that has not yet proven. I will finish the rest of
> benchmarks from the bogus shootout site later.
>
Hmm. My interest would be more along the lines of:
does it generate correct machine code?
Given the http://en.wikipedia.org/wiki/IcedTea project, it seems like
more resources can be thrown at at the http://en.wikipedia.org/wiki/
OpenJDK over the long run. So, even if this compiler has a performance
edge now I don't expect that it will continue to have such an advantage
because the OpenJDK (probably) has more resources (and a head start).
-Thufir
Razii
<igo...@yahoo.com> wrote:
>You've spent 10 days making untrue claims:
No, you are wrong. There is no -Xms when you click on show tab from
the main page. You know that very well. Why waste time on quibbling?
>Why don't you go through all...
Let's continue. The only thing changed is my OS (Vista) and computer
which is now 3 core phenom. Also, instead of > /dev/null on cygwin, I
will use > \Null (since that seems to be 200 times faster on windows).
benchmark: fasta
java version:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=fasta&lang=java&id=2
C++ version
http://shootout.alioth.debian.org/gp4/benchmark.php?test=fasta&lang=gpp&id=4
As a great example of c++ portability, this doesn't even compile with
my version of g++ (mingw), so I will use cygwin to compile. gcc
version 3.4.4 (cygming special)
g++ -pipe -O3 -fomit-frame-pointer -mfpmath=sse -msse2 fasta.cpp -o
fasta.exe
jc -inline+ fasta (jet)
N 250,000 2,500,000 25,000,000
g++ 0.166s 0.954s 8.884s
java 0.297s 1.347s 11.699s (-Xms64m -server)
jet 0.420s 1.701s 14.602s
(note this guy uses -Xbatch flag everywhere. I have to see how that
helps anywhere. It's just slightly slower with -Xbatch flag if
anything).
HotSpot VM is faster than native Jet compiler once again? That's three
in a row. g++ is only slightly faster, not 50 or 100 times as some
think.
Razii
wrote:
>g++ -pipe -O3 -fomit-frame-pointer -mfpmath=sse -msse2 fasta.cpp -o
>fasta.exe
By the way, using the flags -mfpmath=sse -msse2 means the compiled
version won't run on anything without an sse2 instruction set (that
means no Athlon XP).
That's the problem with compiled version that a JIT compiler doesn't
have since it knows on what processor it's running. Removing these
flags makes g++ version about 25% slower.
Bo Persson
> On Wed, 30 Apr 2008 23:43:33 -0500, Razii <tynk...@hotmail.com>
> wrote:
>
>> g++ -pipe -O3 -fomit-frame-pointer -mfpmath=sse -msse2 fasta.cpp -o
>> fasta.exe
>
> By the way, using the flags -mfpmath=sse -msse2 means the compiled
> version won't run on anything without an sse2 instruction set (that
> means no Athlon XP).
>
> That's the problem with compiled version that a JIT compiler doesn't
> have since it knows on what processor it's running.
That's just not true, because the JIT compiler cannot do any magic
here.
If it really can run fast enough on an Athlon XP, just compiler for
that. On anything faster, it will just fly.
> Removing these
> flags makes g++ version about 25% slower.
Is that fast enough? Otherwise skip that target and compile with SSE2.
With JIT it will still be 25% slower. What's the advantage?
Bo Persson
Razii
>Is that fast enough? Otherwise skip that target and compile with SSE2.
If you are selling commercial software, why would you want to skip
Athlon XP? It's still widely used. JIT doesn't have that problem. It
knows what processor it's running on.
>With JIT it will still be 25% slower. What's the advantage?
JIT is new and evolving. It will get faster. In any case, as shown in
this benchmark, java VM was faster in this benchmark than the native
java compiler.
Bo Persson
> On Thu, 1 May 2008 15:34:18 +0200, "Bo Persson" <b...@gmb.dk> wrote:
>
>> Is that fast enough? Otherwise skip that target and compile with
>> SSE2.
>
> If you are selling commercial software, why would you want to skip
> Athlon XP?
I would if it isn't fast enough to run the software. If it is fast
enough, everything else is as well.
> It's still widely used. JIT doesn't have that problem. It
> knows what processor it's running on.
If it runs well enough on an Athlon XP, compile for that. It will run
extremenly well on an overclocked Core 2 Quad.
>
>> With JIT it will still be 25% slower. What's the advantage?
>
> JIT is new and evolving. It will get faster. In any case, as shown
> in this benchmark, java VM was faster in this benchmark than the
> native java compiler.
It can't get faster on old hardware. If your program needs SSE2 and
the processor doesn't have it, how is the JIT compiler supposed to fix
that?
Bo Persson
Isaac Gouy
> On Wed, 30 Apr 2008 08:00:38 -0700 (PDT), Isaac Gouy
>
> <igo...@yahoo.com> wrote:
> >You've spent 10 days making untrue claims:
>
> No, you are wrong. There is no -Xms when you click on show tab from
> the main page. You know that very well. Why waste time on quibbling?
Now instead of admitting that your claims were wrong, you've changed
what you claim.
> >Why don't you go through all...
>
> Let's continue. The only thing changed is my OS (Vista) and computer
> which is now 3 core phenom. Also, instead of > /dev/null on cygwin, I
> will use > \Null (since that seems to be 200 times faster on windows).
> benchmark: fasta
> java version:http://shootout.alioth.debian.org/gp4/benchmark.php?test=fasta〈=j...
> C++ versionhttp://shootout.alioth.debian.org/gp4/benchmark.php?test=fasta〈=g...
>
> As a great example of c++ portability, this doesn't even compile with
> my version of g++ (mingw), so I will use cygwin to compile. gcc
> version 3.4.4 (cygming special)
>
> g++ -pipe -O3 -fomit-frame-pointer -mfpmath=sse -msse2 fasta.cpp -o
> fasta.exe
>
> jc -inline+ fasta (jet)
>
> N 250,000 2,500,000 25,000,000
> g++ 0.166s 0.954s 8.884s
> java 0.297s 1.347s 11.699s (-Xms64m -server)
> jet 0.420s 1.701s 14.602s
>
> (note this guy uses -Xbatch flag everywhere. I have to see how that
> helps anywhere. It's just slightly slower with -Xbatch flag if
> anything).
>
> HotSpot VM is faster than native Jet compiler once again? That's three
> in a row. g++ is only slightly faster, not 50 or 100 times as some
> think.
The numbers you've created show more difference between the c++
program and the java program, show the c++ program as even faster,
than the measurements on the benchmarks game.
Razii
wrote:
>Now instead of admitting that your claims were wrong, you've changed
>what you claim.
You are a quibbling fool and have wasted enough of my time. The claim
was always very clear as even Bo Person understood it very well. There
is no -Xms64m if you click show from the main page and only same kind
of flags are used in every benchmark.
Stop wasting my time with quibbling about something that is clear.
Razii
>If it runs well enough on an Athlon XP, compile for that. It will run
>extremenly well on an overclocked Core 2 Quad.
It could have run 25% faster on Core2. It's running 25% slower on Core
2 Quad because the package was compiled to include Athlon XP.
What's so hard to understand here??
>It can't get faster on old hardware. If your program needs SSE2 and
>the processor doesn't have it, how is the JIT compiler supposed to fix
>that?
The JIT compiler fixed it by not penalizing Core 2 Quad just because
Athlon XP doesn't have sse2. It runs on Core2 with sse2 enabled, and
it runs on Athlon XP. In the case of pre-compiled version, it either
has sse2 enabled for Core2 and doesn't run on Athlon Xp or it has sse2
disabled for both.
What's so hard to understand here?
Bo Persson
> On Thu, 1 May 2008 18:47:35 +0200, "Bo Persson" <b...@gmb.dk> wrote:
>
>> If it runs well enough on an Athlon XP, compile for that. It will
>> run extremenly well on an overclocked Core 2 Quad.
>
> It could have run 25% faster on Core2. It's running 25% slower on
> Core 2 Quad because the package was compiled to include Athlon XP.
>
> What's so hard to understand here??
That there is no need for it, except in benchmarks.
If some software can render a video correctly on an Athlon XP, there
is just no need for it to run 25% faster on a newer machine. Should
the film run faster?!
>
>> It can't get faster on old hardware. If your program needs SSE2 and
>> the processor doesn't have it, how is the JIT compiler supposed to
>> fix that?
>
> The JIT compiler fixed it by not penalizing Core 2 Quad just because
> Athlon XP doesn't have sse2. It runs on Core2 with sse2 enabled, and
> it runs on Athlon XP. In the case of pre-compiled version, it either
> has sse2 enabled for Core2 and doesn't run on Athlon Xp or it has
> sse2 disabled for both.
>
> What's so hard to understand here?
If the program isn't fast enough without SSE2, what does the JIT
compiler do on the old Athlon?
If it is fast enough without SSE2, why bother using it?
The benefit of a JIT compiler is that some programs can be made to run
on Windows, Linux, and OS X without recompilation. Not that it runs
faster on a Quad - everything does that anyway!
Bo Persson
Razii
>That there is no need for it, except in benchmarks.
>
>If some software can render a video correctly on an Athlon XP, there
>is just no need for it to run 25% faster on a newer machine. Should
>the film run faster?!
No, there could be a need for it say in a chess engine. The faster the
chess engine, the stronger it plays. The stronger it plays, more chess
enthusiasts are likely to buy it. Now, if you compile it for Athlon
XP, Core2 would take the penalty because it would run 25% slower. If
you compile it for Core2 by including sse2, it won't run on Athlon XP.
peter koch
Well, for a chess engine it is going to be more or less the same. A
25% change in capacity is not going to change the playing level so
much. A better example would have been for some kind of server where
the processing is CPU-dominated. Here, 25% more capacity would mean
25% more clients possible. But when you write programs for a server,
you normally can allow yourself to write code for the newest
processors only.
/Peter
kwikius
"Razii" <lsa...@hotmail.com> wrote in message
> No, there could be a need for it say in a chess engine. The faster the
> chess engine, the stronger it plays. The stronger it plays, more chess
> enthusiasts are likely to buy it.
hmm... Well That pretty much rules out Java Don't it. Java's slow as old
boots. I'd suggest using C++, or if C++ is too difficult for you to
understand... use C.
regards
Andy Little