From: gabriele renzi Date: 2005-04-01T19:34:45+09:00 Subject: Re: Ruby Weekly News 21st - 27th March 2005 Brian Candler ha scritto: > 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?) well, the first yarv version I tried did not do any of the above, IIRC, but it was quite faster trhan ruby anyway. Now it uses inline caches and does operand unification to avoid dispatching and is even faster. Anyway, I now understand what you meant, I misunderstood the messsage previous to your (I thought it was talking about rewriting some of ruby in ruby itself), so sorry for the noise :) > 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. as I said above, yarv withouth many optimizations was already much faster than ruby. The AOT compiler adds even more speed, but it compiles to C code, so it's not much of a worrying since it is the C compiler wich takes care of the hard stuff > 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) yes, I see what you meant now, please consider my excuse for misunderstanding given above :) > >>>- 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. I don't think this is the case. AFAIK, YARV could rely on an external compiler/linker for aot compiler, but not for normal run. > >>>- 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. no, It is different. What I meant is: when yarv is compiled with gcc, it uses gcc-specific C extensions wich allow the vm to be quite faster than using standard C, since it uses direct jumps to the next instruction instead of a big switch. But the role of the C compile ends there. On the other hand, yarv can be used as a ruby->c compiler, then you can compile the resulting C files with the standard toolchain, and load them at runtime as any other C extension. No tight interaction beetween C toolchain and ruby/yarv at runtime. >>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; here is the point: it is not done at runtime :) >>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. the main interpreter is exactly the same. Yarv is basically just a patch to eval.c, that's why it is cool :) > 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? well, "wc -l" says nearly 10.000 lines of C code for yarv, and 13.000 for eval.c. Yarv has more stuff like script to autogenerate things and is still incomplete, but I think it won't grow too much. Anyway, Let's hope this :)