«

The source code is available from
http://peterhi.dyndns.org/write_it_in_c/index.html

On Tue, Aug 01, 2006 at 05:48:41PM +0900, Peter Hickman wrote:
> The source code is available from
> http://peterhi.dyndns.org/write_it_in_c/index.html

Great! Thanks.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Brian K. Reid: "In computer science, we stand on each other's feet."

Peter Hickman wrote:
> The source code is available from
> http://peterhi.dyndns.org/write_it_in_c/index.html

There are some details missing from the webpages
1) which C implementation?
2) which Java implementation?
3) what hardware?


For example, using the code from the webpage

1) gcc version 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.

gcc -pipe -Wall -O3 -fomit-frame-pointer -funroll-loops -march=pentium4
latin.c -o latinc
time ./latinc > /dev/null 2>&1

user 0m0.820s
sys 0m0.000s


2) /sun-jdk-1.5.0.07/bin/javac Latin.java
time java Latin > /dev/null 2>&1

user 0m3.800s
sys 0m0.644s


3) 2GHz Intel P4

Isaac Gouy wrote:
> Peter Hickman wrote:
>
>> The source code is available from
>> http://peterhi.dyndns.org/write_it_in_c/index.html
>>
>
> There are some details missing from the webpages
> 1) which C implementation?
>
[peterhickman]$ gcc -v
Using built-in specs.
Target: powerpc-apple-darwin8
Configured with: /private/var/tmp/gcc/gcc-5341.obj~1/src/configure
--disable-checking -enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8
--target=powerpc-apple-darwin8
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5341)

> 2) which Java implementation?
>
[peterhickman]$ javac -version
javac 1.5.0_06

Additionally

[peterhickman]$ perl -V
Summary of my perl5 (revision 5 version 8 subversion 6) configuration:

[peterhickman]$ ruby -v
ruby 1.8.4 (2005-12-24) [powerpc-darwin]

> 3) what hardware?
>
>
Macintosh G4 with 1Gb ram

Peter Hickman wrote:
> Isaac Gouy wrote:
> > Peter Hickman wrote:
> >
> >> The source code is available from
> >> http://peterhi.dyndns.org/write_it_in_c/index.html


I recall someone stating "benchmarking without analysis is bogus".

As a first step, comment out the print statements

time ./latinc

user 0m0.492s
sys 0m0.004


time java Latin

user 0m0.992s
sys 0m0.052s


With the print statements ~5.4x
without print statements ~2.1x

iirc the Java program is shuffling around double byte unicode chars and
the C program is handling single byte chars.

Peter Hickman wrote:
> The source code is available from
> http://peterhi.dyndns.org/write_it_in_c/index.html

Hmm, it would look much better for me if you had included Kristof
Bastiaensen's Curry version
into the party... Heck, if that code is not smart then nothing is, and
in a way, it's a much more
interesting question how a compiled functional language compares to
compiled imepative ones
than the thousand time discussed interpreted vs. compiled match-up.

Yes, Curry is anything but mainstream, but you can't say a decent
compiler is not at your disposal.
The Munster CC (which was used by Kristof, and AFAIK that's the most
commonly used implementation) does even have an IDE for OS X.

Regards,
Csaba

On Wed, 02 Aug 2006, Charles O Nutter defenestrated me:
>
> First, some notes on benchmarking:
>
> - NEVER include IO when benchmarking a numeric algorithm; IO speeds vary
> greatly from system to system and can vary from run to run depending on what
> else is happening

IO can be noisy. I say avoid it for any benchmarking since it can
greatly influence timings. Usually the IO is not what you want to
measure so why add this variable into things?

> - If you're building up a large chunk of strings, write to an internal
> buffer and then write out at the end; don't write for every little tiny
> operation. At the very least, use a buffer per-line, rather than a separate
> write for every element on that line.

I just informally thought I would measure a few things involving IO.
I only changed the printing and nothing else:

Unaltered test: ~3.8s
Use of StringBuffer to print out a single row: ~2.1s
Use of StringBuffer for entire run: ~1.5s
Preallocated StringBuffer for entire run: ~1.4s

As you can see IO can have a large affect on clock time. I demonstrated
that in Java's case the IO in the benchmark accounted for over 2/3 of the
wall clock time (which is interesting because a decent chunk that is
left over is JVM startup overhead).

Some stack allocated space will likely improve the C run as well (and in
this case you can output it in a single write system call).

-Tom

--
+ http://www.tc.umn.edu/~enebo +---- private.php?do=newpm&u= ----+
| Thomas E Enebo, Protagonist | "Luck favors the prepared |
| | mind." -Louis Pasteur |

csaba wrote:
> Peter Hickman wrote:
>> The source code is available from
>> http://peterhi.dyndns.org/write_it_in_c/index.html
>
> Hmm, it would look much better for me if you had included Kristof
> Bastiaensen's Curry version
> into the party... Heck, if that code is not smart then nothing is, and
> in a way, it's a much more
> interesting question how a compiled functional language compares to
> compiled imepative ones
> than the thousand time discussed interpreted vs. compiled match-up.
>
> Yes, Curry is anything but mainstream, but you can't say a decent
> compiler is not at your disposal.
> The Munster CC (which was used by Kristof, and AFAIK that's the most
> commonly used implementation) does even have an IDE for OS X.

While I certainly appreciate the efforts that are going into this, I
can't help feeling it's all completely irrelevant.

We can engage in cross-implementation ****ing contests until the cows
come home. None of them help make Ruby any faster.

My question to the community: is there a comprehensive benchmark suite
*for Ruby alone* that we can use to tweak compilation settings, try out
different core algorithms, and improve what is currently an improvable
situation?

If not, would a port of pybench.py be a suitable start?

--
Alex

Thomas E Enebo wrote:
> On Wed, 02 Aug 2006, Charles O Nutter defenestrated me:
> >
> > First, some notes on benchmarking:
> >
> > - NEVER include IO when benchmarking a numeric algorithm; IO speeds vary
> > greatly from system to system and can vary from run to run depending on what
> > else is happening
>
> IO can be noisy. I say avoid it for any benchmarking since it can
> greatly influence timings. Usually the IO is not what you want to
> measure so why add this variable into things?
>
> > - If you're building up a large chunk of strings, write to an internal
> > buffer and then write out at the end; don't write for every little tiny
> > operation. At the very least, use a buffer per-line, rather than a separate
> > write for every element on that line.
>
> I just informally thought I would measure a few things involving IO.
> I only changed the printing and nothing else:
>
> Unaltered test: ~3.8s
> Use of StringBuffer to print out a single row: ~2.1s
> Use of StringBuffer for entire run: ~1.5s
> Preallocated StringBuffer for entire run: ~1.4s
>
> As you can see IO can have a large affect on clock time. I demonstrated
> that in Java's case the IO in the benchmark accounted for over 2/3 of the
> wall clock time (which is interesting because a decent chunk that is
> left over is JVM startup overhead).
>
> Some stack allocated space will likely improve the C run as well (and in
> this case you can output it in a single write system call).
>
> -Tom
>
> --
> + http://www.tc.umn.edu/~enebo +---- private.php?do=newpm&u= ----+
> | Thomas E Enebo, Protagonist | "Luck favors the prepared |
> | | mind." -Louis Pasteur |


As you're having so much fun, let me suggest you try converting the
OutputStrings to byte-arrays, and pre-allocating a byte buffer for
output like the approach taken with this program
http://shootout.alioth.debian.org/gp...lang=java&id=2

Charles O Nutter wrote:
> On 8/1/06, Alex Young <> wrote:
>>
>> While I certainly appreciate the efforts that are going into this, I
>> can't help feeling it's all completely irrelevant.
>
>
> My only purpose in battling these benchmarks is to help dispel the rumors
> that "Java is slow," "VMs are slow," and so on. If Ruby does move to a real
> optimizing VM, it will be a good thing...all those folks who continue to
> think that VMs are inherently bad need to join the 21st century.
>

... Which is extremely funny, since Common Lisp have had wicked fast
virtual machines for the last 15 years (on par with C in performance).

They should catch up with the 20th century first of all. =)


--
Ola Bini (http://ola-bini.blogspot.com)
JvYAML, RbYAML, JRuby and Jatha contributor
System Developer, Karolinska Institutet (http://www.ki.se)
OLogix Consulting (http://www.ologix.com)

"Yields falsehood when quined" yields falsehood when quined.