From: Brian Candler Date: 2005-04-01T18:37:32+09:00 Subject: Re: Ruby Weekly News 21st - 27th March 2005 On Fri, Apr 01, 2005 at 07:09:46AM +0900, gabriele renzi wrote: > >But perhaps also: > > > >- The Ruby source code will be bigger and slower to build > > Sorry, I'm not sure I grok this: it could be probably slower to build, > but why should it become bigger? Well, you have to understand I know nothing about YARV other than what is in English on the home site - i.e. the RubyConf 2004 presentation at http://www.atdot.net/yarv/RubyConf2004_YARV_pub.pdf and the "architecture" which is little more than a list of VM opcodes. And I've not attempted to install the current code, which I believe is a "work in progress" anyway, so conclusions taken from that would be invalid. So I can only really talk about what *might* be the case if you rip out the existing VM - remember that Ruby *does* have a VM, it's one which uses the syntax tree as its "machine code" - and replace it with something else. I can't see that simply replacing one straightforward VM interpreter with another is likely to make much of a speed improvement in itself; so I'm assuming the new VM will be performing optimisations (peephole? loop unrolling? polymorphic inline caches / dynamic rewriting of the byte code sequences?) Or, the speed improvements will be obtained by the VM compiling sequences of code into native machine code (which the diagram in the Rubyconf presentation implies will happen). That might be quite a hard thing to achieve, especially allowing for the various different environments it might run in. I would assume that this whole environment will be quite a lot more complex and bigger than the existing evaluator; especially if the old evaluator is kept as well (e.g. if there are some things that the new VM can't do) > >- Scripts will be slower to start up > > I think the process of compiling ruby in bytecode is quite fast. At > least, I could not notice the slowdown when running scripts with yarv. I agree that building bytecode from text is not going to be significantly slower than building a syntax tree. But if you start making external calls to a C compiler and linker then I would expect startup to be pretty slow, and the more libraries written in Ruby you pull in, the slower it would be. > >- Ruby applications may be less reliable initially and/or harder to debug > > why? Is Squeak harder to debug since it's written in > Smalltalk-subset-compilable-in-c ? I'm thinking of compiling-to-native-machine-code issues. If a piece of machine code generates a SEGV violation, all you get is a core dump. Of course, once the whole system is bug-free, this should not happen :-) > >- Ruby may run on fewer platforms [especially if the VM writes machine-code > > directly, or has dependencies on external C compilers, linkers etc] > > well, the 'main' yarv can use direct threading when compiled with gcc > wich is available almost everywhere, but it seem to run faster than > currwent ruby even if compiled withouth it. Ah, so YARV *links* to the C compiler rather than fork/exec? That could be quite fast (although the C compiler will still be maintaining its own symbol tables etc). But then it would be very gcc-specific. > OTOH, I think AOT compiling can tuned as to work with any C compiler as > a backend, I don't think there is a real problem with it, though IANAVG[1] > And, on even another hand, many compilers scream when compiling the > current cvs with warnings enabled, but people feel happy anyway :) Yeah, but there's a difference between the ./configure && make && make install cycle of a standalone C program, and writing a program which dynamically writes C programs and runs them in real time; especially when it's not building a single executable but a pile of small object modules which must be dynamically loaded in, destroyed and recompiled on demand, and all work together seamlessly. Besides, if it takes 1 second to compile a C program into an executable, normally you don't care. But I wouldn't want a 1-second startup overhead on a Ruby script. > >One of the big advantages of Ruby for me is that it's one-third of the size > >of Perl, whilst still being much more feature-complete (e.g. I get OpenSSL, > >MD5 and base64 encoding without having to install additional libraries) > > Yup, but why would this become worst with a new vm, since it already > supports the standard ruby dynamic libraries? Well, if the new VM supports the old C API, so that things like ext/openssl.so continue to work, that's excellent. I guess it implies that the main 'VALUE' data structures are unchanged. I'm just thinking that the whole package *could* end up a lot bigger, because it's more complex. But please feel free to prove me wrong. How big is the ruby-1.9 tarball? How big is ruby-1.9 with YARV? Cheers, Brian.