[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Matthew Thornton

12/25/2009 3:40:00 AM



--
Looking to make money at selling items on the web? Give us a try at
www.your-best-auctions.com. We are economical and cheaper then our
competitors. To unsubscribe, please reply with unsubscribe in the subject
line.

21 Answers

SG

9/6/2009 2:54:00 PM

0

On 6 Sep., 16:12, Juha Nieminen <nos...@thanks.invalid> wrote:
>
>   You don't even have to resort to such dirty trickery to "prove" it.
> Just make a program which allocates 10 million small objects dynamically
> in both languages, and there you go: You have proven Java to be vastly
> faster than C++.

Done.

sg@home:~/ccpp/perform$ time ./a.out

real 0m0.972s
user 0m0.776s
sys 0m0.196s

sg@home:~/ccpp/perform$ time java alloc

real 0m4.130s
user 0m4.516s
sys 0m0.596s

Oh my!

Cheers!
SG

Juha Nieminen

9/6/2009 4:49:00 PM

0

SG wrote:
> sg@home:~/ccpp/perform$ time ./a.out
>
> real 0m0.972s
> user 0m0.776s
> sys 0m0.196s
>
> sg@home:~/ccpp/perform$ time java alloc
>
> real 0m4.130s
> user 0m4.516s
> sys 0m0.596s

I assume you are not using gcc? Or you are using your own specialized
allocator?

joshuamaurice

9/6/2009 8:48:00 PM

0

On Sep 6, 7:53 am, SG <s.gesem...@gmail.com> wrote:
> On 6 Sep., 16:12, Juha Nieminen <nos...@thanks.invalid> wrote:
>
>
>
> >   You don't even have to resort to such dirty trickery to "prove" it.
> > Just make a program which allocates 10 million small objects dynamically
> > in both languages, and there you go: You have proven Java to be vastly
> > faster than C++.
>
> Done.
>
>   sg@home:~/ccpp/perform$ time ./a.out
>
>   real  0m0.972s
>   user  0m0.776s
>   sys   0m0.196s
>
>   sg@home:~/ccpp/perform$ time java alloc
>
>   real  0m4.130s
>   user  0m4.516s
>   sys   0m0.596s
>
> Oh my!

At least be marginally fair and run with java -client and java -
server, and possibly with a slightly larger test to try and balance
out the startup costs of -server. It defaults to -client, which is
like ~6 slower for the last random application I was testing. -client
has a smaller memory footprint and starts up quicker, but it's a lot
slower, on average.

James Kanze

9/6/2009 8:54:00 PM

0

On Sep 6, 4:12 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> Christof Donat wrote:
> > Java needs to be interpreted or JIT compiled, while C++ is
> > compiled directly into machine code. At compile time the
> > compiler with knowledge of the CPU can heavily optimize the
> > code which is not possible in a JIT, that has much stricter
> > run time requirements.

> One factor which makes C++ faster is that it's an "unsafe"
> language. This means that clock cycles are not spent on
> boundary checks and other such checks which, in a bug-free
> program, are 100% useless overhead.

That's not true. C++ makes many things "undefined behavior",
where Java requires a specific behavior (usually the wrong
behavior), but "undefined behavior" means that an implementation
is free to do whatever is best for its users, and all of the
implementations I regularly use (now that I'm no longer using
Sun CC) do implement bounds checking, at least for the standard
containers.

> Of course many people don't like to program in an "unsafe"
> language, so your mileage may vary.

> C++ is not faster than Java in everything. Memory allocation
> in most systems is considerably slower in C++ (and C) than in
> java. (OTOH Java lives on constant memory allocation due to
> how the language works, while most C++ programs don't.)

> > It depends on what you compare.

> > There are shootouts that compare C++ code compiled for a 386
> > with 387 FPU with Suns Hot Spot engine on a current CPU.
> > Since the java engine knows the CPU that it is running on,
> > it can optimize for the MMX and SSE units and the more
> > subtle issues of that specific CPU. Those shootouts are
> > usually used to "prove" that java was faster than C++.

> You don't even have to resort to such dirty trickery to
> "prove" it. Just make a program which allocates 10 million
> small objects dynamically in both languages, and there you go:
> You have proven Java to be vastly faster than C++.

More realistically, tell me which language you want to win, and
I'll write a benchmark which "proves" it to be faster. For
Java, lots of array accesses with arrays of basic types, with
the arrays passed to functions for the actual work; for C++,
just change the type of the array member to a very simple struct
(which means that every element must be individually allocated
in Java), with many short lived (but large) arrays.

--
James Kanze

woodbrian77

9/6/2009 11:06:00 PM

0

On Sep 6, 3:53 pm, James Kanze <james.ka...@gmail.com> wrote:
[snip]
> for C++,
> just change the type of the array member to a very simple struct
> (which means that every element must be individually allocated
> in Java), with many short lived (but large) arrays.
>


The results here may be relevant --
bannalia.blogspot.com/2008/09/profiling-stablevector.html.

The comment about short-lived, large arrays reminds me
of a vector that is out growing it's capacity and has
to copy it's contents into a new block.


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

Chris M. Thomasson

9/7/2009 1:32:00 AM

0

"Juha Nieminen" <nospam@thanks.invalid> wrote in message
news:drPom.151$As.6@read4.inet.fi...
[...]
> C++ is not faster than Java in everything. Memory allocation in most
> systems is considerably slower in C++ (and C) than in java. (OTOH Java
> lives on constant memory allocation due to how the language works, while
> most C++ programs don't.)
[...]
> You don't even have to resort to such dirty trickery to "prove" it.
> Just make a program which allocates 10 million small objects dynamically
> in both languages, and there you go: You have proven Java to be vastly
> faster than C++.

IMVHO, you're assertions are wrong Juha. Take this Java code:


http://pastebin.com...


vs this C++ code:

http://pastebin.com...




On my old P4 3.06gz w/ 512mb ram I am getting the following output using
Unix `time' command:




C++ version - gcc (GCC) 3.4.5 (mingw special)
______________________________________________________________________
$ time ./test

real 0m19.766s
user 0m0.015s
sys 0m0.031s




Java version - java version "1.6.0_05"
______________________________________________________________________
$ time java tree
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at tree.create_tree(tree.java:13)
at tree.create_tree(tree.java:14)
at tree.create_tree(tree.java:14)
at tree.create_tree(tree.java:15)
at tree.create_tree(tree.java:15)
at tree.create_tree(tree.java:14)
at tree.create_tree(tree.java:15)
at tree.create_tree(tree.java:15)
at tree.create_tree(tree.java:14)
at tree.create_tree(tree.java:15)
at tree.create_tree(tree.java:14)
at tree.create_tree(tree.java:15)
at tree.create_tree(tree.java:15)
at tree.create_tree(tree.java:15)
at tree.create_tree(tree.java:14)
at tree.create_tree(tree.java:15)
at tree.create_tree(tree.java:15)
at tree.create_tree(tree.java:15)
at tree.create_tree(tree.java:15)
at tree.create_tree(tree.java:15)
at tree.create_tree(tree.java:15)
at tree.main(tree.java:25)

real 0m3.367s
user 0m0.015s
sys 0m0.031s





Why is Java so crappy at memory management? I mean, I am able to make the
program work using C++ and a crappy little region allocator I whipped up. On
the other hand, Java simply runs out of memory and crashes! WTF is up with
that non-sense!?!?!?!?!

OUCH!


Am I doing something wrong in the Java version????


;^/






Well, I suppose I could create a cached allocator in Java, but won't that
completely defeat the purpose of not having to use manual memory management
in a garbage collected environment? I mean, you would have to explicitly
allocate/free objects from/to the cache. That's sounds manual to me!


;^)






BTW, the region allocator in the C++ code can be greatly improved upon. For
instance, why the heck am I using `std::list'?!?!? That's stupid because
it's going to be making extra allocations. I should use a simple intrusive
linked-list instead. But, you know, I wanted to give Java a fighting
chance...

;^o

DDD

9/7/2009 3:21:00 AM

0

On Sep 7, 9:32 am, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> "Juha Nieminen" <nos...@thanks.invalid> wrote in message
>
> news:drPom.151$As.6@read4.inet.fi...
> [...]
>
> >  C++ is not faster than Java in everything. Memory allocation in most
> > systems is considerably slower in C++ (and C) than in java. (OTOH Java
> > lives on constant memory allocation due to how the language works, while
> > most C++ programs don't.)
> [...]
> >  You don't even have to resort to such dirty trickery to "prove" it.
> > Just make a program which allocates 10 million small objects dynamically
> > in both languages, and there you go: You have proven Java to be vastly
> > faster than C++.
>
> IMVHO, you're assertions are wrong Juha. Take this Java code:
>
> http://pastebin.com...
>
> vs this C++ code:
>
> http://pastebin.com...
>
> On my old P4 3.06gz w/ 512mb ram I am getting the following output using
> Unix `time' command:
>
> C++ version  -  gcc (GCC) 3.4.5 (mingw special)
> ______________________________________________________________________
> $ time ./test
>
> real    0m19.766s
> user    0m0.015s
> sys     0m0.031s
>
> Java version  -  java version "1.6.0_05"
> ______________________________________________________________________
> $ time java tree
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
>         at tree.create_tree(tree.java:13)
>         at tree.create_tree(tree.java:14)
>         at tree.create_tree(tree.java:14)
>         at tree.create_tree(tree.java:15)
>         at tree.create_tree(tree.java:15)
>         at tree.create_tree(tree.java:14)
>         at tree.create_tree(tree.java:15)
>         at tree.create_tree(tree.java:15)
>         at tree.create_tree(tree.java:14)
>         at tree.create_tree(tree.java:15)
>         at tree.create_tree(tree.java:14)
>         at tree.create_tree(tree.java:15)
>         at tree.create_tree(tree.java:15)
>         at tree.create_tree(tree.java:15)
>         at tree.create_tree(tree.java:14)
>         at tree.create_tree(tree.java:15)
>         at tree.create_tree(tree.java:15)
>         at tree.create_tree(tree.java:15)
>         at tree.create_tree(tree.java:15)
>         at tree.create_tree(tree.java:15)
>         at tree.create_tree(tree.java:15)
>         at tree.main(tree.java:25)
>
> real    0m3.367s
> user    0m0.015s
> sys     0m0.031s
>
> Why is Java so crappy at memory management? I mean, I am able to make the
> program work using C++ and a crappy little region allocator I whipped up. On
> the other hand, Java simply runs out of memory and crashes! WTF is up with
> that non-sense!?!?!?!?!
>
> OUCH!
>
> Am I doing something wrong in the Java version????
>
> ;^/
>
> Well, I suppose I could create a cached allocator in Java, but won't that
> completely defeat the purpose of not having to use manual memory management
> in a garbage collected environment? I mean, you would have to explicitly
> allocate/free objects from/to the cache. That's sounds manual to me!
>
> ;^)
>
> BTW, the region allocator in the C++ code can be greatly improved upon. For
> instance, why the heck am I using `std::list'?!?!? That's stupid because
> it's going to be making extra allocations. I should use a simple intrusive
> linked-list instead. But, you know, I wanted to give Java a fighting
> chance...
>
> ;^o

In a nutshell, java needs a virtual machine, which occupies at least
300M memories itself.

Chris M. Thomasson

9/7/2009 5:35:00 AM

0

"DDD" <1983ddd@gmail.com> wrote in message
news:678fabda-d5b8-4188-9bc8-136a33f37b17@v23g2000pro.googlegroups.com...
On Sep 7, 9:32 am, "Chris M. Thomasson" <n...@spam.invalid> wrote:
[...]
> > Why is Java so crappy at memory management? I mean, I am able to make
> > the
> > program work using C++ and a crappy little region allocator I whipped
> > up. On
> > the other hand, Java simply runs out of memory and crashes! WTF is up
> > with
> > that non-sense!?!?!?!?!
> >
> > OUCH!
> >
> > Am I doing something wrong in the Java version????
> >
> > ;^/
> >
> > Well, I suppose I could create a cached allocator in Java, but won't
> > that
> > completely defeat the purpose of not having to use manual memory
> > management
> > in a garbage collected environment? I mean, you would have to explicitly
> > allocate/free objects from/to the cache. That's sounds manual to me!
> >
> > ;^)
> >
> > BTW, the region allocator in the C++ code can be greatly improved upon.
> > For
> > instance, why the heck am I using `std::list'?!?!? That's stupid because
> > it's going to be making extra allocations. I should use a simple
> > intrusive
> > linked-list instead. But, you know, I wanted to give Java a fighting
> > chance...
> >
> > ;^o

> In a nutshell, java needs a virtual machine, which occupies at least
> 300M memories itself.

Well, damn. IMVHO, the Java version should be able to run on my old platform
as-is. Piece of shi%.

Chris M. Thomasson

9/7/2009 5:52:00 AM

0

"Juha Nieminen" <nospam@thanks.invalid> wrote in message
news:HJRom.210$As.149@read4.inet.fi...
> SG wrote:
>> sg@home:~/ccpp/perform$ time ./a.out
>>
>> real 0m0.972s
>> user 0m0.776s
>> sys 0m0.196s
>>
>> sg@home:~/ccpp/perform$ time java alloc
>>
>> real 0m4.130s
>> user 0m4.516s
>> sys 0m0.596s
>
> I assume you are not using gcc? Or you are using your own specialized
> allocator?

Ummm, what about something simple like:




C++ version:
___________________________________________________________
#include <cstdlib>


struct foo
{
int m_foo;
};


int
main()
{
for (int i = 0; i < 1000; ++i)
{
std::free(std::malloc(10000000 * sizeof(foo)));
}

return 0;
}
___________________________________________________________




Java version:
___________________________________________________________
public final class tree
{
int m_foo;

public static void main(String[] args) {
for (int i = 0; i < 1000; ++i)
{
tree[] t = new tree[10000000];
}
}
}
___________________________________________________________








Here is the output I get for the C++ version:
___________________________________________________________
$ time ./test

real 0m0.159s
user 0m0.046s
sys 0m0.031s
___________________________________________________________




Here is the output I get for the Java version:
___________________________________________________________
$ time java tree

real 1m36.386s
user 0m0.046s
sys 0m0.031s
___________________________________________________________





Am I doing something wrong in the Java version? Keep in mind that the old
platform I am using right now only has 512mb of ram. C++ seems to do fine,
Java... Not so much. I must be missing something important here!

;^/

SG

9/7/2009 5:57:00 AM

0

On 6 Sep., 18:48, Juha Nieminen <nos...@thanks.invalid> wrote:
> SG wrote:
> >   sg@home:~/ccpp/perform$ time ./a.out
>
> >   real  0m0.972s
> >   user  0m0.776s
> >   sys   0m0.196s
>
> >   sg@home:~/ccpp/perform$ time java alloc
>
> >   real  0m4.130s
> >   user  0m4.516s
> >   sys   0m0.596s
>
>   I assume you are not using gcc? Or you are using your own specialized
> allocator?

I used GCC and no special allocator. To be specific:
G++ 4.3.3 versus Sun's HotSpot VM, Java 1.6.0_16
on a i686 Linux box running in 32bit mode.

alloc.cpp:
int main()
{
const long count = 10000000;
int** pp = new int*[count];
for (long i=0; i<count; ++i) {
pp[i] = new int(i);
}
for (long i=count-1; i>=0; --i) {
delete pp[i];
}
delete[] pp;
}

alloc.java:
class alloc {
static class intref {
public int value;
public intref(int v) { value = v; }
};
public static void main(String[] args) {
int count = 10000000;
System.out.println("h");
intref[] ia = new intref[count];
for (int i=0; i<count; ++i) {
ia[i] = new intref(i);
}
}
}

Cheers!
SG