Shootout (sum-file)

[Razik]

On Wed, 30 Apr 2008 08:00:38 -0700 (PDT), Isaac Gouy
<ig****@yahoo.comwrote:

>Why don't you go through all...

Let's continue. Next we deal with sum-file...

http://shootout.alioth.debian.org/gp...lang=all#about

"Programs should use built-in line-oriented I/O functions rather than
custom-code. No line will exceed 128 characters, including newline.
Reading one line at a time, the programs should run in constant
space."

According to Haskel people,

"Those guys tell us these benchmarks don't favor C and then impose a
limit on line length? What's the purpose of that if not to allow the
use of C's getline() primitive?"

That's a valid point that you need to address. Why 128 characters
limit if not to help C and C++ guys?

In any case,
C++
http://shootout.alioth.debian.org/de...&lang=gpp&id=2

Java
http://shootout.alioth.debian.org/de...lang=java&id=2

and 14 MB custom file used to test..

1.291s (g++)
0.742s (java -server)
0.706s (jet java net compiler)

Huh? Shame on c++ and g++. Why is still slower despite custom help
provided by Isaac Gouy who imposed artificial 128 char line limit?
Disappointed in C++, once again.

[Richard Heathfield]

Razik said:

>
On Wed, 30 Apr 2008 08:00:38 -0700 (PDT), Isaac Gouy
<ig****@yahoo.comwrote:

>>Why don't you go through all...

Let's continue. Next we deal with sum-file...

http://shootout.alioth.debian.org/gp...lang=all#about

>
"Programs should use built-in line-oriented I/O functions rather than
custom-code. No line will exceed 128 characters, including newline.
Reading one line at a time, the programs should run in constant
space."

According to Haskel people,

"Those guys tell us these benchmarks don't favor C and then impose a
limit on line length? What's the purpose of that if not to allow the
use of C's getline() primitive?"

C doesn't have a getline() primitive.

That's a valid point that you need to address. Why 128 characters
limit

No idea.

if not to help C and C++ guys?

That ain't the reason.

>
In any case,
C++

http://shootout.alioth.debian.org/de...&lang=gpp&id=2

>
Java

http://shootout.alioth.debian.org/de...lang=java&id=2

>
and 14 MB custom file used to test..

1.291s (g++)
0.742s (java -server)
0.706s (jet java net compiler)

Huh? Shame on c++ and g++.

No, just shame on whoever wrote the C++ version. They might want to learn
C++ before writing benchmark programs.

Why is still slower despite custom help
provided by Isaac Gouy who imposed artificial 128 char line limit?
Disappointed in C++, once again.

Why? The fault, dear Razik, lies not in our languages, but in our authors.
On my system, neither the C++ version nor the Java version would compile.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Razii]

On Tue, 06 May 2008 05:49:03 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

This was at least a nice change. Instead of abusive ad hominem posts
from the trolls, you posted at least something on topic. You should be
commended for not trolling.

>Why? The fault, dear Razik, lies not in our languages, but in our authors.
On my system, neither the C++ version nor the Java version would compile.

Perhaps then you should contribute the better C++ version to shootout
site? I can only judge by what is available. And what kind of
compilers are you using? C++ I can understand, but why won't Java
version compile on your system?

[Chris Thomasson]

"Razii" <hk****@gmail.comwrote in message
news:6r********************************@4ax.com...

On Tue, 06 May 2008 05:49:03 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

This was at least a nice change. Instead of abusive ad hominem posts
from the trolls, you posted at least something on topic. You should be
commended for not trolling.

>>Why? The fault, dear Razik, lies not in our languages, but in our authors.
On my system, neither the C++ version nor the Java version would compile.

Perhaps then you should contribute the better C++ version to shootout
site? I can only judge by what is available. And what kind of
compilers are you using? C++ I can understand, but why won't Java
version compile on your system?

Well, how much $$$ are you going to pay Mr. Heathfield for his most valuable
time and energy?

:^|

[Razii]

On Tue, 06 May 2008 02:17:45 -0500, Razii <ui****@gmail.comwrote:

>java -XX:+AggressiveHeap hello

I got refusal email from Isaac Gouy to use this flag in this case. But
he has no problem with adding sse2 flag whenever that helps C++
version. I wonder why the double standard?

[Nick Keighley]

On 6 May, 06:22, Razik <[e-mail]:

On Wed, 30 Apr 2008 08:00:38 -0700 (PDT), Isaac Gouy

<[e-mail]:

Why don't you go through all...

Let's continue. Next we deal with sum-file...

http://shootout.alioth.debian.org/gp...t=sumcol&lang=...

"Programs should use built-in line-oriented I/O functions rather than
custom-code. No line will exceed 128 characters, including newline.
Reading one line at a time, the programs should run in constant
space."

According to Haskel people,

"Those guys tell us these benchmarks don't favor C and then impose a
limit on line length? What's the purpose of that if not to allow the
use of C's getline() primitive?"

That's a valid point that you need to address. Why 128 characters
limit if not to help C and C++ guys?

In any case,
C++http://shootout.alioth.debian.org/de...test=sumcol&la...

Javahttp://shootout.alioth.debian.org/debian/benchmark.php?test=sumcol&la...

and 14 MB custom file used to test..

1.291s (g++)
0.742s (java -server)
0.706s (jet java net compiler)

Huh? Shame on c++ and g++. Why is still slower despite custom help
provided by Isaac Gouy who imposed artificial 128 char line limit?
Disappointed in C++, once again.

[Nick Keighley]

On 6 May, 06:22, Razik <[e-mail]:

On Wed, 30 Apr 2008 08:00:38 -0700 (PDT), Isaac Gouy

<[e-mail]:

Why don't you go through all...

Let's continue. Next we deal with sum-file...

http://shootout.alioth.debian.org/gp...t=sumcol&lang=...

"Programs should use built-in line-oriented I/O functions rather than
custom-code. No line will exceed 128 characters, including newline.
Reading one line at a time, the programs should run in constant
space."

According to Haskel people,

"Those guys tell us these benchmarks don't favor C and then impose a
limit on line length? What's the purpose of that if not to allow the
use of C's getline() primitive?"

<snip>
please don't post this to comp.lang.c

PLONK

[Mark McIntyre]

Razik wrote:

"Those guys tell us these benchmarks don't favor C and then impose a
limit on line length? What's the purpose of that if not to allow the
use of C's getline() primitive?"

Given that there is no C getline() function, the question is moot!

(aside: its possible that some platforms offer a getline() function as
an extension. It seems unlikely this 'shootout' was specially contrived
to test /that/.)

That's a valid point that you need to address. Why 128 characters
limit

I should imagine it is so that programmers with access to sufficient
memory don't attempt an efficiency by reading the entire dataset into
memory in one go and avoid any percieved inefficiencies of the i/o
substem available to them.

if not to help C and C++ guys?

More likely to help the haskell peeps.

1.291s (g++)
0.742s (java -server)
0.706s (jet java net compiler)

Huh? Shame on c++ and g++.

More likely, whoever wrote the C++ versions wasn't able to optimise
correctly. What compiler options were used? Was the code manually
optimal? Who wrote the IO library?

Disappointed in C++, once again.

You seem to be a Java troll, suggest not crossposting to comp.lang.c
where we're entirely disinterested in compariing the size of our
genitalia as if it were some measure of prowess.

--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[Juha Nieminen]

Razii wrote:

On Tue, 06 May 2008 05:49:03 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

This was at least a nice change. Instead of abusive ad hominem posts
from the trolls, you posted at least something on topic. You should be
commended for not trolling.

Why are you so surprised that if you constantly post to a C++ group
trying to prove that Java is better than C++, people get annoyed? What
you are doing is, technically speaking, trolling: You are constantly and
repeatedly throwing subtle attacks against something other people use.

Given that you are so infatuated with Java, just use Java. There's no
need for all these troll posts.

[Richard Heathfield]

Razii said:

On Tue, 06 May 2008 05:49:03 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

This was at least a nice change. Instead of abusive ad hominem posts
from the trolls, you posted at least something on topic. You should be
commended for not trolling.

>>Why? The fault, dear Razik, lies not in our languages, but in our
authors. On my system, neither the C++ version nor the Java version would
compile.

Perhaps then you should contribute the better C++ version to shootout
site?

<shrugCan't be doing with all that, given that optimal solutions are
forbidden (not allowed to do character-based I/O, which is a stupid
restriction designed to favour limp-along languages). If someone else
wants to put this version up (which is also legal C, by the way), feel
free:

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
char buf[129] = {0};
long int sum = 0;
while(fgets(buf, sizeof buf, stdin) != NULL)
{
sum += strtol(buf, NULL, 10);
}
printf("%ld\n", sum);
return 0;
}

I can only judge by what is available.

Nah, you can always write your own.

And what kind of compilers are you using?

If that question is important, it's the wrong kind of question for
comp.lang.c. :-)

C++ I can understand, but why won't Java
version compile on your system?

Because I didn't do it right, it seems. Fixed that, and that means I can
compare results on my system. I now get 0.058 seconds for the 6KB supplied
test file, compared to 0.003 seconds for the C version.

So by my reckoning, C is almost 20 times faster than Java on my system.

I recompiled my C version as C++, too. Here are the final results:

C: 0.003
C++: 0.021
Java: 0.058

I conclude on the basis of this fully representative and statistically
significant sample that C rocks, Java sucks, and C++ isn't sure which it
is.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[santosh]

Nick Keighley wrote:

<snip>

please don't post this to comp.lang.c

PLONK

Replying only encourages trolls. Silence is the best trollicide.

[Razii]

On Tue, 06 May 2008 08:17:49 GMT, Juha Nieminen
<no****@thanks.invalidwrote:

>Given that you are so infatuated with Java, just use Java.

How can I use java? That's not what I do for living. I have never used
java for anything other than posting to these groups. That's how I
learned both Java and some of C++ ;)

[Razii]

On Tue, 06 May 2008 08:28:15 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

>C: 0.003
C++: 0.021
Java: 0.058

I haven't tested your C version yet, but these times are too low. Java
time includes the time for JVM to start and the time for JIT compiler
to compile bytecode to machine code. We already know C/C++ startup
time is way faster than Java. I used 14MB text file. Try that and the
result might be different. Also, make sure to use the -server flag,
i.e

java --server sumcol <inputfile.txt

[Richard Heathfield]

Razii said:

On Tue, 06 May 2008 08:28:15 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

>>C: 0.003
C++: 0.021
Java: 0.058

I haven't tested your C version yet, but these times are too low.

I thought that getting the lowest time was the whole point!

But to put your mind at rest, these times are for the 6KB test file. I
couldn't be bothered to go looking for the 14MBer.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Razii]

On Tue, 06 May 2008 08:28:15 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

>#include <stdio.h>
#include <stdlib.h>

int main(void)
{
char buf[129] = {0};
long int sum = 0;
while(fgets(buf, sizeof buf, stdin) != NULL)
{
sum += strtol(buf, NULL, 10);
}
printf("%ld\n", sum);
return 0;
}

Ok, so I compiled your version with Cygwin

g++ -pipe -Wall -O3 -fomit-frame-pointer sum.cpp -o sum.exe

and the input file was 14 MB; basically the following file made
several times larger
http://shootout.alioth.debian.org/de...all&file=input

$ time sum.exe <sum.txt
11161 14831

real 0m1.269s
user 0m1.185s
sys 0m0.015s

this is not much faster than the original c++ version. What is
11161 14831? that's not the right answer.

Using the same file with java version I get

$ time java -server sumcol <sum.txt
2462944

real 0m0.742s
user 0m0.015s
sys 0m0.015s

the answer should be 2462944

[Bartc]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:-9******************************@bt.com...

Razii said:

>On Tue, 06 May 2008 08:28:15 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

>>>C: 0.003
C++: 0.021
Java: 0.058

I haven't tested your C version yet, but these times are too low.

I thought that getting the lowest time was the whole point!

But to put your mind at rest, these times are for the 6KB test file. I
couldn't be bothered to go looking for the 14MBer.

These timings do look too low to be measured accurately.

You should try the larger file or at least do several iterations to increase
the timings to more sensible values.

It's possible C++ and Java have some start-up delays in which case you
cannot compare /runtimes/ reliably.

--
Bartc

[Richard Heathfield]

Razii said:

<snip>

>
$ time sum.exe <sum.txt
11161 14831

real 0m1.269s
user 0m1.185s
sys 0m0.015s

this is not much faster than the original c++ version. What is
11161 14831? that's not the right answer.

<shrugI have no idea. It's bog-standard C, and it works just fine here.
If you think the program is broken, perhaps you'd care to explain what
rule of C you think I've breached?

Using the same file with java version I get

$ time java -server sumcol <sum.txt
2462944

real 0m0.742s
user 0m0.015s
sys 0m0.015s

the answer should be 2462944

My timings with a 17993728-byte input file are as follows:

C: 1.33 seconds
C++: 1.44 seconds
Java: 17.59 seconds

and all three programs give the same result (which is obviously different
to yours, because I used more data). Since the original input file was
1000 lines totalling 500 each, I would expect the answer for my data
(which was 4096 times as big) to be 4096 * 500, or 2048000, which is
indeed the result given by my C version, my C++ version, and the site's
Java version.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Razii]

On Tue, 06 May 2008 09:59:33 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

><shrugI have no idea. It's bog-standard C, and it works just fine here.
If you think the program is broken, perhaps you'd care to explain what
rule of C you think I've breached?

This was just weird behavior by cygwin. I renamed the file to
sumcpp.exe and it works then.

$ time sumcpp.exe < sum.txt
2048000

real 0m0.952s

if I rename it back to sum.exe

$ time sum.exe < sum.txt
58339 21572

Weird.

In any case, yes this was faster. Using the same file with java,

$ time java -server sumcol < sum.txt
2048000

real 0m0.992s

>Java: 17.59 seconds

That's pretty strange. what version does it show when you type java
-version?

[Joachim Schmitz]

Razii wrote:

On Tue, 06 May 2008 09:59:33 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

><shrugI have no idea. It's bog-standard C, and it works just fine
here. If you think the program is broken, perhaps you'd care to
explain what rule of C you think I've breached?

This was just weird behavior by cygwin. I renamed the file to
sumcpp.exe and it works then.

$ time sumcpp.exe < sum.txt
2048000

real 0m0.952s

if I rename it back to sum.exe

$ time sum.exe < sum.txt
58339 21572

Weird.

Because there's a sum.exe somewhere earlier in your PATH and so you were not
executing the one you expected to execute.

Bye, Jojo

[Richard Heathfield]

Razii said:

<snip>

>
In any case, yes this was faster. Using the same file with java,

$ time java -server sumcol < sum.txt
2048000

real 0m0.992s

>>Java: 17.59 seconds

That's pretty strange. what version does it show when you type java
-version?

me@heregcc --version
2.95.3
me@hereg++ --version
2.95.3
me@herejava -version
java version "1.1.8"

All ancient, of course, by the standards of yoofotoday.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Razii]

On Tue, 06 May 2008 11:17:43 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

>me@heregcc --version
2.95.3
me@hereg++ --version
2.95.3
me@herejava -version
java version "1.1.8"

1.1.8? That's probably 10 years old and does not include HotSpot JIT
compiler. It's probably 100% interpreted.

[Richard Heathfield]

Razii said:

On Tue, 06 May 2008 11:17:43 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

>>me@heregcc --version
2.95.3
me@hereg++ --version
2.95.3
me@herejava -version
java version "1.1.8"

1.1.8? That's probably 10 years old and does not include HotSpot JIT
compiler. It's probably 100% interpreted.

<shrugRight, but so what? It's still Java, right? And please note that
the gcc and g++ versions are equally old.

The point is that this "shoot-out" thing isn't a race between languages (as
it claims), but between *implementations* - which makes the whole thing a
wild goose chase.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Tobin]

In article <-c******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>1.1.8? That's probably 10 years old and does not include HotSpot JIT
compiler. It's probably 100% interpreted.

><shrugRight, but so what?

So the comparison is irrelevant in practice.

And please note that the gcc and g++ versions are equally old.

A 10 year old Java implementation is more irrelevant than a 10 year
old C implementation. It's like comparing a 10 year old C
implementation with a 10 year old Fortran implementation in 1985.

>The point is that this "shoot-out" thing isn't a race between languages (as
it claims), but between *implementations* - which makes the whole thing a
wild goose chase.

You could make it be more about languages by using the best
implementations, provided the language is reasonably mature.

-- Richard
--
:wq

[Richard Heathfield]

Richard Tobin said:

In article <-c******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>>1.1.8? That's probably 10 years old and does not include HotSpot JIT
compiler. It's probably 100% interpreted.

>><shrugRight, but so what?

So the comparison is irrelevant in practice.

Yes, I know (sigh). That small coin is still accelerating away from the
Earth and shows no sign of reversing course.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Razii]

On Tue, 06 May 2008 11:51:59 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

><shrugRight, but so what? It's still Java, right? And please note that
the gcc and g++ versions are equally old.

GCC 1.0 was released in 1987, long before Java even existed. By 1997,
GCC had already been improved for 10 years. The comparison is invalid.
The 1.18 JVM is from the time when JIT technology was in infancy. It
doesn't even include HotSpot JIT compiler.

[Isaac Gouy]

On May 6, 4:51 am, Richard Heathfield <[e-mail]:

Razii said:

On Tue, 06 May 2008 11:17:43 +0000, Richard Heathfield
<[e-mail]:

>me@heregcc --version
2.95.3
me@hereg++ --version
2.95.3
me@herejava -version
java version "1.1.8"

1.1.8? That's probably 10 years old and does not include HotSpot JIT
compiler. It's probably 100% interpreted.

<shrugRight, but so what? It's still Java, right? And please note that
the gcc and g++ versions are equally old.

The point is that this "shoot-out" thing isn't a race between
languages (as it claims), but between *implementations* -
which makes the whole thing a wild goose chase.

From the top of the home page:

"Benchmarking programming languages?

How can we benchmark a programming language?
We can't - we benchmark programming language implementations.

How can we benchmark language implementations?
We can't - we measure particular programs."
http://shootout.alioth.debian.org/

[Richard Heathfield]

Isaac Gouy said:

<snip>

>
From the top of the home page:

"Benchmarking programming languages?

How can we benchmark a programming language?
We can't - we benchmark programming language implementations.

How can we benchmark language implementations?
We can't - we measure particular programs."

And we can't benchmark particular programs except within the contexts of
language and implementation. So we're stuffed.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Isaac Gouy]

On May 6, 7:49 am, Richard Heathfield <[e-mail]:

Isaac Gouy said:

<snip>

From the top of the home page:

"Benchmarking programming languages?

How can we benchmark a programming language?
We can't - we benchmark programming language implementations.

How can we benchmark language implementations?
We can't - we measure particular programs."

And we can't benchmark particular programs except within the contexts of
language and implementation. So we're stuffed.

We can't benchmark particular programs except within the context of
language and implementation - and that's what we all do.

[Bo Persson]

Razii wrote:

On Tue, 06 May 2008 09:59:33 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

><shrugI have no idea. It's bog-standard C, and it works just
fine here. If you think the program is broken, perhaps you'd care
to explain what rule of C you think I've breached?

This was just weird behavior by cygwin. I renamed the file to
sumcpp.exe and it works then.

$ time sumcpp.exe < sum.txt
2048000

real 0m0.952s

if I rename it back to sum.exe

$ time sum.exe < sum.txt
58339 21572

Weird.

$ sum --help
Usage: sum [OPTION]... [FILE]...
Print checksum and block counts for each FILE.

-r defeat -s, use BSD sum algorithm, use 1K blocks
-s, --sysv use System V sum algorithm, use 512 bytes blocks
--help display this help and exit
--version output version information and exit

With no FILE, or when FILE is -, read standard input.

Report bugs to <bu***********@gnu.org>.

:-)

[Razii]

On Tue, 06 May 2008 03:56:28 -0500, Razii <gj*****@gmail.comwrote:

>I got refusal email from Isaac Gouy to use this flag in this case. But
he has no problem with adding sse2

Also, with gcc version, the comments says....

* Tell GCC that we don't want atexit, we don't want to use the heap,
* and we really don't want anything. Can't even call write the
"normal"
* way, because write() isn't linked in....
*
* Compile flags are picky for this. I used:
* gcc -pipe -Wall -O3 -fomit-frame-pointer -march=pentium4
-ffreestanding -nostartfiles -s -static -o start3 start3.c
*/

the gcc version doesn't even compile with cygwin. However, Gouy
refused to use -XX:+AggressiveHeap flag when it's clearly much faster
for this benchmark.

[Razii]

On Tue, 06 May 2008 06:02:28 -0500, Razii <gj*****@gmail.comwrote:

>$ time java -server sumcol < sum.txt
2048000

real 0m0.992s

Instead of using built in line reader, I can more than double the
speed by using my own implementation.

http://pastebin.com/f3a23e56d

$ time java -server sumcol <sum.txt
2048000

real 0m0.394s

[Razii]

On Fri, 09 May 2008 07:58:01 -0500, Razii <gj*****@gmail.comwrote:

>http://pastebin.com/f3a23e56d

$ time java -server sumcol <sum.txt
2048000

real 0m0.394s

and even faster
http://pastebin.com/fa1fedab

$ time java sumcol <sum.txt
2048000

real 0m0.358s