Yes, and yes. Also, don’t forget “ease of distribution”. I’d rather slap a
binary on someone’s computer instead of having to install Ruby and any 3rd
party modules for any sort of wide scale distribution.
Regards,
Dan
···
-----Original Message-----
From: Tobias Reif [mailto:tobiasreif@pinkjuice.com]
Hi,
why will Rite feature compilation?
Is it because some people want to close their sources, or is
it because
of speed?
Tobi
From: Tobias Reif [mailto:tobiasreif@pinkjuice.com]
Hi,
why will Rite feature compilation?
Is it because some people want to close their sources, or is
it because
of speed?
Tobi
Yes, and yes. Also, don’t forget “ease of distribution”. I’d rather
slap a binary on someone’s computer instead of having to install Ruby
and any 3rd party modules for any sort of wide scale distribution.
Regards,
Um, you’d still have to install the byte-code interpreter and any
third-party C-based modules. You could wrap things into a single
executable, but you can do that now without byte-code compilation.
Rite’s compilation will be similar to Java compilation - you make the
byte-code archive, and then still have to install the VM to run it all.
···
-----Original Message-----
Dan
Yeah, there’s compile-to-pcode, and compile-to-native. I’d rather have
compile to native; if I’m going to be compiling at all, why stop half-way?
It made sense with Java, because Java sourcecode was never interpretable;
however, with Ruby, I don’t see much advantage to exchanging one VM (the
Ruby interpreter) for another (the Ruby bytecode interpreter).
Java compiles to bytecodes and is then potentially subject to JIT.
Bytecodes make sense because they are portable and consume less memory
that Rubys current AST style execution nodes. I suspect bytecodes
offer an increase in performance from AST also.
GCC has an intermediate form but because Ruby is a dynamically bound
language, it’s non-trivual to produce good native code. Some form of
JIT might be possible tho’.
Justin Johnson