On Wed, 30 Apr 2008 08:00:38 -0700 (PDT), Isaac Gouy
<igouy2@yahoo.com> wrote:

>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 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
provided by Isaac Gouy who imposed artificial 128 char line limit?
Disappointed in C++, once again.

Razik said:

>
> On Wed, 30 Apr 2008 08:00:38 -0700 (PDT), Isaac Gouy
> <igouy2@yahoo.com> wrote:
>
>>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 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
> 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

>On Wed, 30 Apr 2008 08:00:38 -0700 (PDT), Isaac Gouy
<igouy2@yahoo.com> wrote:

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

startup benchmark...

http://shootout.alioth.debian.org/gp...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.

On Tue, 06 May 2008 05:49:03 +0000, Richard Heathfield
<rjh@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?

"Razii" <hkasdh@gmail.com> wrote in message
news:6r1024dcjf9bu8u2h9q6qk8f6p2s814o8t@4ax.com...
> On Tue, 06 May 2008 05:49:03 +0000, Richard Heathfield
> <rjh@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?

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

:^|

On 6 May, 06:22, Razik <hrtt...@mail.com> wrote:
> 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/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 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
> provided by Isaac Gouy who imposed artificial 128 char line limit?
> Disappointed in C++, once again.

On 6 May, 06:22, Razik <hrtt...@mail.com> wrote:
> 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/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

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 C and C++ guys?

More likely to 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>

Razii wrote:
> On Tue, 06 May 2008 05:49:03 +0000, Richard Heathfield
> <rjh@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.

Razii said:

> On Tue, 06 May 2008 05:49:03 +0000, Richard Heathfield
> <rjh@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.

--
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

Nick Keighley wrote:

<snip>

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

Replying only encourages trolls. Silence is the best trollicide.

On Tue, 06 May 2008 02:17:45 -0500, Razii <uiyffk@gmail.com> wrote:

>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 s C++
version. I wonder why the double standard?

Razii said:

> On Tue, 06 May 2008 08:28:15 +0000, Richard Heathfield
> <rjh@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.

--
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

[copy of post sent to c.l.c++]
"Richard Heathfield" <rjh@see.sig.invalid> wrote in message
news:-9OdnXIZ5Pjbgr3VnZ2dneKdnZydnZ2d@bt.com...
> Razii said:
>
>> On Tue, 06 May 2008 08:28:15 +0000, Richard Heathfield
>> <rjh@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

Bartc said:

> [copy of post sent to c.l.c++]
> "Richard Heathfield" <rjh@see.sig.invalid> wrote in message
> news:-9OdnXIZ5Pjbgr3VnZ2dneKdnZydnZ2d@bt.com...
>> Razii said:
>>
>>> On Tue, 06 May 2008 08:28:15 +0000, Richard Heathfield
>>> <rjh@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 <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

On Tue, 06 May 2008 08:17:49 GMT, Juha Nieminen
<nospam@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++

On Tue, 06 May 2008 08:28:15 +0000, Richard Heathfield
<rjh@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" <rjh@see.sig.invalid> wrote in message
news:YKmdnTjH8aINu73VnZ2dnUVZ8uKdnZ2d@bt.com...
> Bartc said:
>
>> [copy of post sent to c.l.c++]
>> "Richard Heathfield" <rjh@see.sig.invalid> wrote in message
>> news:-9OdnXIZ5Pjbgr3VnZ2dneKdnZydnZ2d@bt.com...
>>> Razii said:
>>>
>>>> On Tue, 06 May 2008 08:28:15 +0000, Richard Heathfield
>>>> <rjh@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.

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

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.

<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.

--
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

Bartc said:

>
> "Richard Heathfield" <rjh@see.sig.invalid> wrote in message
> news:YKmdnTjH8aINu73VnZ2dnUVZ8uKdnZ2d@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.

--
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

On Tue, 06 May 2008 08:28:15 +0000, Richard Heathfield
<rjh@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/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

"Richard Heathfield" <rjh@see.sig.invalid> wrote in message
news:Z76dnZQYG-54sb3VnZ2dnUVZ8q2dnZ2d@bt.com...
> Bartc said:
>
>>
>> "Richard Heathfield" <rjh@see.sig.invalid> wrote in message
>> news:YKmdnTjH8aINu73VnZ2dnUVZ8uKdnZ2d@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

Bartc said:

> "Richard Heathfield" <rjh@see.sig.invalid> wrote in message
> news:Z76dnZQYG-54sb3VnZ2dnUVZ8q2dnZ2d@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;
}

--
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 Heathfield" <rjh@see.sig.invalid> wrote in message
news:cpKdne1e4ZCqrr3VnZ2dnUVZ8vmdnZ2d@bt.com...
> Bartc said:
>
>> "Richard Heathfield" <rjh@see.sig.invalid> wrote in message
>> news:Z76dnZQYG-54sb3VnZ2dnUVZ8q2dnZ2d@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

On Tue, 06 May 2008 09:59:33 +0000, Richard Heathfield
<rjh@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?