Shootout (sum-file)
Razik
On Wed, 30 Apr 2008 08:00:38 -0700 (PDT), Isaac Gouy
<igo...@yahoo.com> wrote:
>Why don't you go through all...
Let's continue. Next we deal with sum-file...
http://shootout.alioth.debian.org/gp4/benchmark.php?test=sumcol&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/debian/benchmark.php?test=sumcol&lang=gpp&id=2
Java
http://shootout.alioth.debian.org/debian/benchmark.php?test=sumcol&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
>
> On Wed, 30 Apr 2008 08:00:38 -0700 (PDT), Isaac Gouy
> <igo...@yahoo.com> wrote:
>
>>Why don't you go through all...
>
> Let's continue. Next we deal with sum-file...
>
>
http://shootout.alioth.debian.org/gp4/benchmark.php?test=sumcol&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/debian/benchmark.php?test=sumcol&lang=gpp&id=2
>
> Java
>
http://shootout.alioth.debian.org/debian/benchmark.php?test=sumcol&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
>Why don't you go through all...
startup benchmark...
http://shootout.alioth.debian.org/gp4/benchmark.php?test=hello&lang=all
Damn! C & C++ are killing java in this benchmark. Though I discovered
a trick that improves the speed somewhat and saves some face...
With n = 200 (i.e 200 startups in continuous order).
java hello
time: 23.433s
However, just adding the flag -XX:+AggressiveHeap
java -XX:+AggressiveHeap hello
time: 9.914s
that's a huge improvement.
Razii
<r...@see.sig.invalid> wrote:
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
news:6r1024dcjf9bu8u2h...@4ax.com...
Well, how much $$$ are you going to pay Mr. Heathfield for his most valuable
time and energy?
:^|
Razii
>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 Wed, 30 Apr 2008 08:00:38 -0700 (PDT), Isaac Gouy
>
> <igo...@yahoo.com> wrote:
> >Why don't you go through all...
>
> Let's continue. Next we deal with sum-file...
>
>
> "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,
>
> Javahttp://shootout.alioth.debian.org/debian/benchmark.php?test=sumcol&la...
Nick Keighley
>
> <igo...@yahoo.com> wrote:
> >Why don't you go through all...
>
> Let's continue. Next we deal with sum-file...
>
>
> "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
> "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
> On Tue, 06 May 2008 05:49:03 +0000, Richard Heathfield
> <r...@see.sig.invalid> wrote:
>
> 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
> On Tue, 06 May 2008 05:49:03 +0000, Richard Heathfield
> <r...@see.sig.invalid> wrote:
>
> 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?
<shrug> Can'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.
Razii
<nos...@thanks.invalid> wrote:
>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++ ;)
santosh
<snip>
> please don't post this to comp.lang.c
>
> PLONK
Replying only encourages trolls. Silence is the best trollicide.
Razii
<r...@see.sig.invalid> wrote:
>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
> On Tue, 06 May 2008 08:28:15 +0000, Richard Heathfield
> <r...@see.sig.invalid> wrote:
>
>>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.
Razii
<r...@see.sig.invalid> wrote:
>#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/debian/iofile.php?test=sumcol&lang=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" <r...@see.sig.invalid> wrote in message
news:-9OdnXIZ5Pjbgr3V...@bt.com...
> Razii said:
>
>> On Tue, 06 May 2008 08:28:15 +0000, Richard Heathfield
>> <r...@see.sig.invalid> wrote:
>>
>>>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
> [copy of post sent to c.l.c++]
> "Richard Heathfield" <r...@see.sig.invalid> wrote in message
> news:-9OdnXIZ5Pjbgr3V...@bt.com...
>> Razii said:
>>
>>> On Tue, 06 May 2008 08:28:15 +0000, Richard Heathfield
>>> <r...@see.sig.invalid> wrote:
>>>
>>>>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.
I sometimes wonder about this universe. Did nobody see what I wrote
originally? And I quote: "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."
Now then, let's start simple. Can you spell "iron"? And do you know what it
means? If so, we can build up from there.
> It's possible C++ and Java have some start-up delays in which case you
> cannot compare /runtimes/ reliably.
Rubbish. It takes how long it takes. If WonderfulNewLanguage*= can process
the data in a time comparable to, say, Java, *provided* you discount
WonderfulNewLanguage*='s 20-minute startup delay, does that mean
WonderfulNewLanguage*= is as good at Java over that "distance"? Clearly
not. When you're racing for money, you don't give head starts.
Richard Heathfield
<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.
<shrug> I 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.
Bartc
"Richard Heathfield" <r...@see.sig.invalid> wrote in message
But the Java startup isn't 1200000ms; whatever it is, it's no more than 58ms
in this case, which is insignificant; probably less than the time it took to
press the Enter key or click the button to start the test.
Suppose the C startup was 0ms, and that of Java was 50ms. And supposing you
were testing an empty program, which, with inevitable OS overheads (loading
the executable etc), took 1ms in each case. 1ms and 51ms. What would you
conclude from that? That Java is 50x faster? And if the overhead was only
0.1ms, that Java was 500x faster? And if the overhead was 10ms, that Java
was only 6x faster?
If someone is really interested in how much faster Java is than C, I would
not trust your tests. Because with timings at these level, the figures are
unreliable.
--
Bartc
Richard Heathfield
>
> "Richard Heathfield" <r...@see.sig.invalid> wrote in message
> news:YKmdnTjH8aINu73V...@bt.com...
>> Bartc said:
>>
<snip>
>>> It's possible C++ and Java have some start-up delays in which case you
>>> cannot compare /runtimes/ reliably.
>>
>> Rubbish. It takes how long it takes. If WonderfulNewLanguage*= can
>> process the data in a time comparable to, say, Java, *provided* you
>> discount WonderfulNewLanguage*='s 20-minute startup delay, does that
>> mean WonderfulNewLanguage*= is as good at Java over that "distance"?
>> Clearly not. When you're racing for money, you don't give head starts.
>
> But the Java startup isn't 1200000ms; whatever it is, it's no more than
> 58ms in this case, which is insignificant; probably less than the time it
> took to press the Enter key or click the button to start the test.
If it's insignificant, why bother to raise it in the first place?
> Suppose the C startup was 0ms, and that of Java was 50ms. And supposing
> you were testing an empty program, which, with inevitable OS overheads
> (loading the executable etc), took 1ms in each case. 1ms and 51ms. What
> would you conclude from that?
That would depend on whether I expected my conclusion to be read by bright
people.
Bartc
"Richard Heathfield" <r...@see.sig.invalid> wrote in message
> Bartc said:
>
>>
>> "Richard Heathfield" <r...@see.sig.invalid> wrote in message
>> news:YKmdnTjH8aINu73V...@bt.com...
>>> Bartc said:
>>>
> <snip>
>
>>>> It's possible C++ and Java have some start-up delays in which case you
>>>> cannot compare /runtimes/ reliably.
>>>
>>> Rubbish. It takes how long it takes. If WonderfulNewLanguage*= can
>>> process the data in a time comparable to, say, Java, *provided* you
>>> discount WonderfulNewLanguage*='s 20-minute startup delay, does that
>>> mean WonderfulNewLanguage*= is as good at Java over that "distance"?
>>> Clearly not. When you're racing for money, you don't give head starts.
>>
>> But the Java startup isn't 1200000ms; whatever it is, it's no more than
>> 58ms in this case, which is insignificant; probably less than the time it
>> took to press the Enter key or click the button to start the test.
>
> If it's insignificant, why bother to raise it in the first place?
Because you were testing a benchmark with such a small runtime that it
became significant! A 50ms startup wouldn't be an issue with anybody, in
practical terms. But in this case, it could have been obscuring actual
runtime differences. Perhaps Java was twice the speed of C, after startup,
but your test wouldn't show it!
Your figures also showed C++ to be 7x as slow as C, but in your other post
(where the timings were more substantial) it was only 8% slower.
--
Bartc
Richard Heathfield
> "Richard Heathfield" <r...@see.sig.invalid> wrote in message
> news:Z76dnZQYG-54sb3V...@bt.com...
<snip>
>> If it's insignificant, why bother to raise it in the first place?
>
> Because you were testing a benchmark with such a small runtime that it
> became significant!
Words fail me.
Observe:
#include <stdio.h>
int main(void)
{
double u = 0; /* init velocity */
double a = 2; /* accel due to thrust */
double g = -1; /* decel due to earth's gravity */
double v = 0; /* current velocity */
double t = 0; /* time of flight */
double h = 0; /* current height above sea level */
puts("Launching small coin NOW");
do
{
++t;
v = u + (a + g) * t;
h += v;
} while(h > 0);
puts("Contact re-established with ground.");
return 0;
Bartc
"Richard Heathfield" <r...@see.sig.invalid> wrote in message
> Bartc said:
>
>> "Richard Heathfield" <r...@see.sig.invalid> wrote in message
>> news:Z76dnZQYG-54sb3V...@bt.com...
>
> <snip>
>
>>> If it's insignificant, why bother to raise it in the first place?
>>
>> Because you were testing a benchmark with such a small runtime that it
>> became significant!
>
> Words fail me.
You'll have to explain. My point is merely that with timings near zero, and
with normally tiny overheads becoming significant, performance cannot be
compared reliably. Such as the C and C++ timings.
>
> Observe:
>
> #include <stdio.h>
>
> int main(void)
> {
> double u = 0; /* init velocity */
> double a = 2; /* accel due to thrust */
> double g = -1; /* decel due to earth's gravity */
> double v = 0; /* current velocity */
> double t = 0; /* time of flight */
> double h = 0; /* current height above sea level */
>
> puts("Launching small coin NOW");
> do
> {
> ++t;
> v = u + (a + g) * t;
> h += v;
> } while(h > 0);
> puts("Contact re-established with ground.");
> return 0;
> }
And again. (This coin will accelerate towards outerspace (despite gravity
staying constant) because it seems to have built-in thrusters.)
--
Bartc
Razii
<r...@see.sig.invalid> wrote:
><shrug> I 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
> On Tue, 06 May 2008 09:59:33 +0000, Richard Heathfield
> <r...@see.sig.invalid> wrote:
>
>
>> <shrug> I 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.
executing the one you expected to execute.
Bye, Jojo
Richard Heathfield
<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@here> gcc --version
2.95.3
me@here> g++ --version
2.95.3
me@here> java -version
java version "1.1.8"
All ancient, of course, by the standards of yoofotoday.
Razii
<r...@see.sig.invalid> wrote:
>me@here> gcc --version
>2.95.3
>me@here> g++ --version
>2.95.3
>me@here> java -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
<shrug> Right, 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 Tobin
Richard Heathfield <r...@see.sig.invalid> wrote:
>> 1.1.8? That's probably 10 years old and does not include HotSpot JIT
>> compiler. It's probably 100% interpreted.
><shrug> Right, 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
> In article <-cqdneImBbv02L3V...@bt.com>,
> Richard Heathfield <r...@see.sig.invalid> wrote:
>
>>> 1.1.8? That's probably 10 years old and does not include HotSpot JIT
>>> compiler. It's probably 100% interpreted.
>
>><shrug> Right, 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>
Razii
<r...@see.sig.invalid> wrote:
><shrug> Right, 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
> Razii said:
>
> > On Tue, 06 May 2008 11:17:43 +0000, Richard Heathfield
> > <r...@see.sig.invalid> wrote:
>
> >>me@here> gcc --version
> >>2.95.3
> >>me@here> g++ --version
> >>2.95.3
> >>me@here> java -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.
>
> <shrug> Right, 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."
Richard Heathfield
<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.
Isaac Gouy
> 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
> On Tue, 06 May 2008 09:59:33 +0000, Richard Heathfield
> <r...@see.sig.invalid> wrote:
>
>
>> <shrug> I 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 <bug-co...@gnu.org>.
:-)
Dann Corbit
> Razii said:
>
>> On Tue, 06 May 2008 08:28:15 +0000, Richard Heathfield
>> <r...@see.sig.invalid> wrote:
>>
>>>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.
Heads up to news:comp.lang.c:
Razii has been trolling news:comp.lang.c++ for some time now and just now
started crossposting here. If you recall a similar incident where a certain
Scott Nudds started crossposting from news:comp.lang.asm.x86 it quickly
ballooned into a mess. I suggest it might be worthwhile to check out his
technique by examination of some of his news:comp.lang.c++ mile long flame
chains. Or just take my word for it. At any rate, this guy is a pure
troll, and a very successful one.
** Posted from http://www.teranews.com **
Mark McIntyre
> Suppose the C startup was 0ms, and that of Java was 50ms.
You're missing the point: in the case shown, C was faster than Java.
It doesn't matter what aspect of Java caused that, it was simply slower.
So for this specific test case of a 6kB file, Java is slower.
And supposing you
Supposing you ran the C version on an 8080 and the Java version on a Sun
M8000? Supposing you excluded from your time-count all operations whose
opcode has a vowel in? Supposing you ran the C version while running a
huge Fortran numerical simulation with lots of disk IO in another thread?
> If someone is really interested in how much faster Java is than C, I would
> not trust your tests. Because with timings at these level, the figures are
> unreliable.
As Richard said, can anyone here spell the action of flattening
garmentry with a hot metal object?
--
Mark McIntyre
CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
Mark McIntyre
> "Richard Heathfield" <r...@see.sig.invalid> wrote in message
> news:cpKdne1e4ZCqrr3V...@bt.com...
>> Bartc said:
>>
>>> "Richard Heathfield" <r...@see.sig.invalid> wrote in message
>>> news:Z76dnZQYG-54sb3V...@bt.com...
>> <snip>
>>
>>>> If it's insignificant, why bother to raise it in the first place?
>>> Because you were testing a benchmark with such a small runtime that it
>>> became significant!
>> Words fail me.
>
> You'll have to explain.
http://dictionary.reference.com/search?q=irony&x=0&y=0
points 6-8 seem appropriate.
Razii
>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.
Bart
OK. But what's the coin all about? Or flattening garments for that
matter?
--
Bartc
Keith Thompson
<http://www.usingenglish.com/reference/idioms/the+penny+dropped.html>
(It may be more a common expression in British English than in US
English.)
flattening garments --> ironing --> irony
--
Keith Thompson (The_Other_Keith) <ks...@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Bart
> Bart <b...@freeuk.com> writes:
> >> > You'll have to explain.
>
> >>http://dictionary.reference.com/search?q=irony&x=0&y=0
>
> >> points 6-8 seem appropriate.
>
> > OK. But what's the coin all about? Or flattening garments for that
> > matter?
>
> <http://www.usingenglish.com/reference/idioms/the+penny+dropped.html>
> (It may be more a common expression in British English than in US
> English.)
>
> flattening garments --> ironing --> irony
If I couldn't see the original irony, what chance did I have with all
these oblique references to iron, ironing and coins in space?..
Anyway yesterday (Tuesday) I was perhaps a little too busy to read the
thread in-depth, and RH has once or twice in the past drawn (real)
conclusions based on too-brief tests...
--
Bartc
Richard Heathfield
<snip>
> If I couldn't see the original irony, what chance did I have
None, obviously. People who want to give chances don't use irony. You
either understand irony or you don't.
<snip>
> Anyway yesterday (Tuesday) I was perhaps a little too busy to read the
> thread in-depth, and RH has once or twice in the past drawn (real)
> conclusions based on too-brief tests...
I think your conclusion is overly hasty. If I were you, I would wait for
more supporting data to become available.
Mark McIntyre
> I think your conclusion is overly hasty. If I were you, I would wait for
> more supporting data to become available.
And /that's/ humorous sarcasm, just in case anyone missed it.
Razii
>$ 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.
$ time java -server sumcol <sum.txt
2048000
real 0m0.394s
Razii
>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