Mauricio Fernández wrote:
IIRC the “interpreter” (AST based) will be dumped.
Hmm, will this affect the startup time? My understanding is that one of
the reasons Java is so slow to start up is the VM setup.
Ben
IIRC the “interpreter” (AST based) will be dumped.
I like the interpreter.
Does this mean we’re going to have to run some compiler on our code to
compile it to bytecode? That would be annoying.
:o(
-Kurt
MikkelFJ wrote:
You cannot avoid C when intergrating languages unless you go to a
wireprotocol such as XML-RPC (supported by OCaml and Ruby) or you use a
component technology like COM (not sufficiently supported in both Ruby or
OCaml).
This always confuses me a bit. Is the reason for needing to use C that
both OCaml and Ruby are
written in C? For example, I can understand that you can’t interface
Java and Ruby without either
writing Ruby in something that compiles to JVM bytecode, or using JNI to
link to native code.
But OCaml compiles to machine code, doesn’t it? Would it only be
possible to interface with
OCaml directly if you wrote Ruby in OCaml (I assume that’s the main
problem)?
I guess that’s a good reason for keeping Ruby written in C (that is, if
we somehow got a
compiler from Ruby to machine code, and were able to write Ruby in
Ruby), because if all
languages are implemented in C, or can interface with C easily, they can
all be linked together.
I guess I’ve answered my own question to some degree. 
If I’m wrong anywhere, feel free to correct me.
- Dan
You talk as if gcc was a good compiler
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
This has me thinking… would ruby programs run faster if ruby was
compiled with the Intel compiler?
-joe
OCaml is a fine language, but it certainly is not as fun as ruby… unless
you’re a functional languages geek :P.
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 :).
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));
}
···
On Mon, Aug 25, 2003 at 06:56:15AM +0900, Martin Weber wrote:
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 gccYou talk as if gcc was a good compiler
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…
Thanks!
Now I’ve found the original page as well:
Florian Frank wrote:
···
On 2003-08-18 17:20:23 +0900, Erik Terpstra wrote:
I spent 2.5 months reading and re-reading the OCaml OReilly book… and
Is there an OCaml O’Reilly book? I can not find it. Can you provide a
link?The book has only been published in French so far, the title is
“D�veloppement d’applications avec Objective Caml”. However, there is a
preliminary translation online:
http://caml.inria.fr/oreilly-book/
Ben Giddings wrote:
Mauricio Fernández wrote:
IIRC the “interpreter” (AST based) will be dumped.
Hmm, will this affect the startup time? My understanding is that one
of the reasons Java is so slow to start up is the VM setup.Ben
I think the main reason Java startup is slow is that it has to load
several megabytes of standard library classes.
The ruby standard library is quite a bit smaller, I think, so the hit
shouldn’t be the same. It shouldn’t really
take any more time to start up a virtual machine than an interpreter, as
the only difference is that the VM
runs bytecode (more like machine code), while the interpreter runs the
source more-or-less directly (yes,
that’s a bit of a simplification).
- Dan
think it this way: you code in the usual way, cause your code can be
interpreted.
When you release you compile to bytecode, to get a performance
enhancement and (possibly) some code obfuscation…
···
il Fri, 22 Aug 2003 02:38:48 +0900, “Kurt M. Dresner” kdresner@cs.utexas.edu ha scritto::
IIRC the “interpreter” (AST based) will be dumped.
I like the interpreter.
Does this mean we’re going to have to run some compiler on our code to
compile it to bytecode? That would be annoying.
Kurt M. Dresner wrote:
IIRC the “interpreter” (AST based) will be dumped.
I like the interpreter.
Does this mean we’re going to have to run some compiler on our code to
compile it to bytecode? That would be annoying.
Not sure, but I suspect that what batsman meant is that the current
AST-based interpreter will be replaced with a ‘ruby’ that first compiles
your Ruby source code to bytecode and then feeds that to a virtual
machine (VM) for interpretation. But no explicit compilation step on
your part (unlike traditionally compiled languages like C/C++).
Dan Doel wrote:
MikkelFJ wrote:
You cannot avoid C when intergrating languages unless you go to a
This always confuses me a bit. Is the reason for needing to use C that
both OCaml and Ruby are
written in C?
Not at all. The reason is that any other language (almost) that somehow link
with object modules do so in a restricted way. That is, Ruby requires
special datatypes when calling C. So does OCaml. But Ruby and OCaml
datatypes are different. Only C is flexible enough to mediate between the
two datatypes. You could use some other language than C but there are very
few offering the required features and headers for interfacing C to Ruby
and OCaml are provided in C.
For example, I can understand that you can’t interface
Java and Ruby without either
writing Ruby in something that compiles to JVM bytecode, or using JNI to
link to native code.
Right - but you can move up on the abstraction layer. Instead of using
object module linkage (dll, or static), you can use marshalling. This is
where SOAP, XML-RPC, DCOM, Corba etc. comes into place. So it really
depends on what you mean by interfacing.
You can frequently call DLL’s from other languages. For instance C# and
Visual Basic 6.0 allow you to call DLL’s and I think someone recently made
this possible in Ruby. This is actually some sort of lightweight
marshalling as there is a thin interpreter layer translating datatypes
before calling into the DLL. Exposing things as DLL’s is a bit more tricky
I think, but this has also been done for OCaml more or less automatically.
There are also two variants of marshalling: those the generate a lot of
bulky code and those that has a lot of runtime interpration - and some
lands in between.
But OCaml compiles to machine code, doesn’t it? Would it only be
possible to interface with
OCaml directly if you wrote Ruby in OCaml (I assume that’s the main
problem)?
No because there are langauge specific macroes and functions that are needed
to interpret input and return arguments. These are not compatible. To some
extend the Ruby and OCaml call interfaces are very similar and you could
almost write C libraries that could be called from both languages - but not
quite. Datatypes dealing with gargage collection complicates matters
greatly.
It is good to pivot around C or a marshalling layer - otherwise each
language would specifically have to interface all other languages. This
quickly becomes very complex.
I guess that’s a good reason for keeping Ruby written in C (that is, if
we somehow got a
compiler from Ruby to machine code, and were able to write Ruby in
Ruby), because if all
languages are implemented in C, or can interface with C easily, they can
all be linked together.
You could write Ruby in another language and still expose its API in a DLL
much as it is now.
Indeed I have many times though of implementing Ruby or a subset of Ruby in
OCaml - it is the perfect language for the job.
To create the DLL with API you would link OCaml with some C code to create
the proper interface functions.
Mikkel
Ben Giddings wrote:
Mauricio Fernández wrote:
IIRC the “interpreter” (AST based) will be dumped.
Hmm, will this affect the startup time? My understanding is that one of
the reasons Java is so slow to start up is the VM setup.
No bytecode should not slow things down. Ruby har a decent sized runtime
library - this must be loaded no matter how you execute the code. An
efficient bytecode interpreter may speed up startup time because you can
skip the parsing. However, Ruby is currently loading Ruby source files on
demand. In a bytecode interpreter it might load more code than it would
have done in the current interpreter - this could affect startup time.
OCamls bytecode is very fast, its runtime engine is comparatively small and
there is no noticable startup overhead at all. I think Parrots non-stack
based VM might also be very fast but it is difficult to predict - it also
depends on the quality of the byte code generating compiler (affects
runtime not startup time). OCaml bytecode has 10 years of development
behind it or so.
Java is well … Java. I guess they load 100-200 class libraries
unnecessarily - my guess is that recent Java implementations have improved
significantly although I’m not using Java that much. I’m trying out the
Jakarta FOP XSL-FO processor written in Java, and it starts up fast enough.
Mikkel
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.
···
On Mon, Aug 25, 2003 at 02:23:56PM +0900, Jason Watkins wrote:
OCaml is a fine language, but it certainly is not as fun as ruby… unless
you’re a functional languages geek :P.
“Jason Watkins” jason_watkins@pobox.com wrote in
news:bic62r$qp7$1@nnrp.atgi.net:
OCaml is a fine language, but it certainly is not as fun as ruby…
unless you’re a functional languages geek :P.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.
Have you looked at D - D Runtime Library
It provides templates as well as many other things (C++ without all the
baggage in some ways).
···
–
Robert Cowham
“Jason Watkins” jason_watkins@pobox.com wrote in message news:bic62r$qp7$1@nnrp.atgi.net…
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.
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)
think it this way: you code in the usual way, cause your code can be
interpreted.
But I thought that the interpreter was being dumped…
-Kurt
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);;
best regards
Mark Sparshatt
···
On Monday 25 Aug 2003 4:10 pm, Brian Candler wrote:
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…
OCaml is a fine language, but it certainly is not as fun as ruby… unless
you’re a functional languages geek :P.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
···
On Tue, Aug 26, 2003 at 12:10:21AM +0900, Brian Candler wrote:
On Mon, Aug 25, 2003 at 02:23:56PM +0900, Jason Watkins wrote:
Not sure. I’d like to think bytecode compilation will
be optional.
In any case, there’ll be some kind of interpreter, of course,
for the bytecodes if nothing else.
Hal
···
----- Original Message -----
From: “Kurt M. Dresner” kdresner@cs.utexas.edu
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Thursday, August 21, 2003 4:18 PM
Subject: Re: Rite/Ruby2.0 & Ruby vs OCaml
think it this way: you code in the usual way, cause your code can be
interpreted.But I thought that the interpreter was being dumped…
–
Hal Fulton
hal9000@hypermetrics.com
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.
···
On Tue, Aug 26, 2003 at 12:40:45AM +0900, mark wrote:
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);;