Rite/Ruby2.0 & Ruby vs OCaml

[MikkelFJ]

"Andreas Hauser" <[email protected]> skrev i en meddelelse

[snip OCaml not as fast as Bagley claims]

FWIW, i tried some of the shoutout benchmarks
and i have very different results.

For example, he claims ocaml to be faster than gcc in
the Fibonacci test (0.18 vs. 0.24), while
on any sytem that i tested C is much faster (e.g. 1.8 to 0.19).

Did you use ocamlopt instead of ocamlc and did you repeat the tests a few
times to eliminate the load overhead?

Mikkel

 

[MikkelFJ]

"Andreas Hauser" <[email protected]> skrev i en meddelelse

[snip OCaml not as fast as Bagley claims]

FWIW, i tried some of the shoutout benchmarks
and i have very different results.

For example, he claims ocaml to be faster than gcc in
the Fibonacci test (0.18 vs. 0.24), while
on any sytem that i tested C is much faster (e.g. 1.8 to 0.19).

Did you use ocamlopt instead of ocamlc and did you repeat the tests a few
times to eliminate the load overhead?

Mikkel

 

[Richard Zidlicky]

FWIW, i tried some of the shoutout benchmarks
and i have very different results.

For example, he claims ocaml to be faster than gcc in
the Fibonacci test (0.18 vs. 0.24), while
on any sytem that i tested C is much faster (e.g. 1.8 to 0.19).

on those systems I tried (x86, m68k) the ocaml version is faster.
The margin is small but I am still surprised something is faster
than gcc

Richard

 

[Martin Weber]

C != gcc.

on those systems I tried (x86, m68k) the ocaml version is faster.
The margin is small but I am still surprised something is faster
than gcc

You talk as if gcc was a good compiler just try the bloated 3.3
against intel's compiler on x86 or the fine 2.95 on the x86 against
the intel compiler and you'll approach what is a good compiler (at
least on x86). Yes I know gcc is portable (and thus fine) but it's
basically the worst-choice-common-denominator you have available for
most platforms...

I'm not surprised stuff is faster than gcc. I'm surprised so many
things build on gcc really.

-Martin

 

[Jason Watkins]

OCaml is a fine language, but it certainly is not as fun as ruby... unless
you're a functional languages geek .

I would suggest you just go out and try Ruby. Trying to reason about weither
it's slow or not based on some tables in a webpage is really just stumbling
in the dark. Unless you're doing high performance systems, I doubt you'll
notice ruby's speed. If you're doing high performance systems, you likely
would just be using c or c++ and it wouldn't even occur to you to use ruby
.

Just give up and learn to love ruby, slow as it might be in benchmarks. In
the times and tasks I've used it, it's speed has never been an issue.

Meanwhile the C++ template lovers praise snippets that can
calculate something trivial like factorials or logarithms
in base 2 .

Typically I just lurk here. However, I'd like to point out that typelists,
traits, enforcements, and many other c++ template metaprogramming techniques
are practical and likely will become widely used idioms. It is awkward,
ugly, and broken in many compilers. But it's also useful. Many people
criticise what Alexandrescu and others are doing because at first pass it
seems like stupid programmer tricks. If instead you take the optimistic
point of view and begin to see that if you use them appropriatly... I think
you'll get excited at the implications it has.

Of you can just go back to ruby, forget the uglyness and have fun .

 

[Brian Candler]

OCaml is a fine language, but it certainly is not as fun as ruby... unless
you're a functional languages geek .

I'm not sure that even functional languages geeks would approve of OCaml. I
just installed it and tried writing:

let rec sum n =
if n < 1 then 0 else n + sum(n-1);;

print_int(sum 1000000);;

and all I got was:

Stack overflow during evaluation (looping recursion?).

So unless I've missed something, it doesn't seem to support tail-recursion,
in which case functional programmers aren't going to be happy at all...

Regards,

Brian.

 

[Martin Weber]

I'm not sure that even functional languages geeks would approve of OCaml. I
just installed it and tried writing:

let rec sum n =
if n < 1 then 0 else n + sum(n-1);;

print_int(sum 1000000);;

let sum n =
let rec aux n acc =
if n < 1 then acc else aux (n-1) (acc+n)
in aux n 0;;

print_int(sum 100);;

Note: native ints are native ints in Ocaml. For sum 1000000 you'll want
to use the bignum lib.

and all I got was:

Stack overflow during evaluation (looping recursion?).

So unless I've missed something, it doesn't seem to support tail-recursion,

Your function isn't tail-recursive (it needs the n when returning).

in which case functional programmers aren't going to be happy at all...

Not only functional programmers are happy with ocaml

Regards,

-Martin

 

[Brian Candler]

Unless I'm mistaken n + sum(n-1) isn't a tail call since it has to add n to
the result of sum(n-1) which prevents it from optimizing the call.

The following code runs without any errors, though it prints the wrong answer
(probably due to overflow)

let rec sum n total =
if n < 1 then total else sum (n-1) (total + n);;

print_int(sum 1000000 0);;

Ah, thank you, and sorry for exposing my ignorance!

I was actually just trying to get some timings out. It seems ocaml is
astoundingly fast for that test: 0.51s uncompiled, 0.37s compiled with
ocamlc, versus 11.6s for the Ruby equivalent:

def sum(n)
total = 0
n.times { |x| total += x }
total
end

puts sum(1000000)

OTOH, the Ruby version gives the right answer

Cheers,

Brian.

 

[Martin Weber]

)
def sum(n)
total = 0
n.times { |x| total += x }
total
end

puts sum(1000000)

OTOH, the Ruby version gives the right answer

1+2+3+4 = 10.
sum(4) = 6.
ocaml-sum(4) = 10.



ruby: time -p ruby sum.rb
499999500000
real 11.96
user 11.35
sys 0.00

ocaml1: time -p ./sum1
500000500000
real 19.19
user 17.79
sys 0.04

ocaml2: time -p ./sum2
500000500000
real 3.89
user 3.62
sys 0.00

(check other mail for what is sum1/2)


Regards,

-Martin

 

[Brian Candler]

*sigh* sorry. I've changed that to

print_string(string_of_num(sum 1000000));

before I ran the tests of course.

Cheers. And sorry I posted a buggy Ruby version too

$ ocamlc -o sum1 nums.cma sum.ml
$ time ./sum1
500000500000
..
user 0m18.084s
sys 0m0.025s

$ ocamlopt -o sum2 nums.cmxa sum.ml
$ time ./sum2
500000500000
..
user 0m5.672s
sys 0m0.008s

$ cat sum.rb
def sum(n)
total = 0
(1..n).each { |x| total += x }
total
end

puts sum(1000000)
$ time ruby sum.rb
500000500000

..
user 0m12.044s
sys 0m0.055s

So it seems Ruby's bignums are in the same ballpark performance-wise as
Ocaml; and with the benefit of the code being far easier to write.

Cheers,

Brian.

 

[Robert Cowham]

OCaml is a fine language, but it certainly is not as fun as ruby...
unless you're a functional languages geek .

I would suggest you just go out and try Ruby. Trying to reason about
weither it's slow or not based on some tables in a webpage is really
just stumbling in the dark. Unless you're doing high performance
systems, I doubt you'll notice ruby's speed. If you're doing high
performance systems, you likely would just be using c or c++ and it
wouldn't even occur to you to use ruby
.

Just give up and learn to love ruby, slow as it might be in
benchmarks. In the times and tasks I've used it, it's speed has never
been an issue.


Typically I just lurk here. However, I'd like to point out that
typelists, traits, enforcements, and many other c++ template
metaprogramming techniques are practical and likely will become widely
used idioms. It is awkward, ugly, and broken in many compilers. But
it's also useful. Many people criticise what Alexandrescu and others
are doing because at first pass it seems like stupid programmer
tricks. If instead you take the optimistic point of view and begin to
see that if you use them appropriatly... I think you'll get excited at
the implications it has.

Have you looked at D - http://www.digitalmars.com/d/

It provides templates as well as many other things (C++ without all the
baggage in some ways).

 

[Hannu Kankaanpää]

Typically I just lurk here. However, I'd like to point out that typelists,
traits, enforcements, and many other c++ template metaprogramming techniques
are practical and likely will become widely used idioms. It is awkward,
ugly, and broken in many compilers. But it's also useful. Many people
criticise what Alexandrescu and others are doing because at first pass it
seems like stupid programmer tricks. If instead you take the optimistic
point of view and begin to see that if you use them appropriatly... I think
you'll get excited at the implications it has.

I didn't really mean to say that template metaprogramming is useless.
I just said it's clumsy, awkward, slow et cetera. Template metaprogramming
tricks do help create C++ programs with less effort (for the one
who uses them) such as with expression templates or Alexandrescu's
object factories. But it's definitely not a feature that should be
admired like some do. Lisp and AFAIK Dylan handle metaprogramming
much much more neatly. So much that it's hard for me to like
template metaprogramming, no matter what it's implications are to
some broken language.

(I have to admit that it was just a year ago when I thought
template metaprogramming was wicked cool)

 

[Richard Zidlicky]

You talk as if gcc was a good compiler just try the bloated 3.3
against intel's compiler on x86 or the fine 2.95 on the x86 against
the intel compiler and you'll approach what is a good compiler (at
least on x86). Yes I know gcc is portable (and thus fine) but it's
basically the worst-choice-common-denominator you have available for
most platforms...

just for the record, the speed diff is due to use of registers for
parameter passing. Using __attribute__ ((regparm(...))) in gcc
yields exactly same speed for this simple example, but generally
strictly typed languages (which plain 'c' isnt) will allways win
because they don't need to take into account broken fn declarations.

Btw can you send me 686-linux-elf -O3 -fomit-frame-pointer output of
Intel-cc of this code?

int __attribute__ ((regparm(3))) fib (int x)
{
if (x<2) return 1;
return fib(x-1)+fib(x-2);
}

main(int argc, char **argv)
{
int x;

if (argc!=2){
printf("requires integer argument\n");
exit(2);
}
x=atoi(argv[1]);
printf("fib(%d)=%d\n",x,fib(x));
}

 

[Brian Candler]

Hmm, I'm sitting here with a Sun box and a Linux box and
thought I'd try this myself. Here are the results:

Ruby:
time ruby tail
499999500000
1.250u 0.000s 0:01.23 101.6% 0+0k 0+0io 212pf+0w

Sun:
time ruby tail
499999500000
11.36u 0.05s 0:11.50 99.2%

BTW, both were built with the latest 1.8.0.

Should the first one read "Linux" not "Ruby" ?

Suns have always appeared incredibly slow to me - in particular when
compiling applications (a compiler seems to be a pretty good processor
workout). Unless gcc has to do a *lot* more work to generate and optimise
Sparc code than Intel code (which I doubt), then the conclusion seems to be
that Sparcs are slow. Possibly also that Solaris is slow.

Regards,

Brian.

 

[Jim Freeze]

Should the first one read "Linux" not "Ruby" ?

Yeah, duh. #sub(/Ruby/,"Linux")

Suns have always appeared incredibly slow to me - in particular when
compiling applications (a compiler seems to be a pretty good processor
workout). Unless gcc has to do a *lot* more work to generate and optimise
Sparc code than Intel code (which I doubt), then the conclusion seems to be
that Sparcs are slow. Possibly also that Solaris is slow.

Yes, Sun is very slow. Also, you showed a time of about 11.36 for Ruby.
I assume that was on a Sun box.
Is the ratio between OCaml and Ruby the same on Linux, or does
Ruby improve?