... FOR SPEED! For example, you're a company on the
scale of Facebook who has written a large web site in a dynamic language and
suddenly realize you could be saving a lot of money on servers if your app
ran a lot faster. Source translation to C++ is a potential way to go
And in all the world, there are how many companies that have a
web site that large (in traffic)? Maybe not even one other.
And they could afford to rewrite the site in whatever language
they chose, instead of relying on a dodgey translator to give
them an unreadable result.
I can't believe how many people use the old "but what if we
become as large as Facebook?" argument to drive their technology
choices. Like the number of places using NoSQLs to produce sites
that are even less reliable than they used to...
If you get to that scale (and are hopefully making money by then or have very large investments that match your scale of users/ traffic), there is a high chance that you will need to re-architect or rewrite a bunch of stuff - I don't think source translation will solve the problem.
On the other hand, Speed is an objective is something I am very keen on... I think there's a bunch of stuff that we do which is acceptable in Ruby but I would prefer it to run faster in some cases. However, I have often found that Ruby lets me do the first prototype fast and once the system is mature, if the speed is needed (not desired), a rewrite in C++ is not that difficult - it should be noted that I'm not a super-advanced Ruby programmer... what that means is that I tend to write Ruby code that avoids the advanced constructs of Ruby, making translation to C++ easier.
Cheers,
Mohit.
5/10/2010 | 5:10 PM.
···
On 5/10/2010 8:02 AM, Tony Arcieri wrote:
Perhaps the most straightforward answer for wanting a Hiphop or
Starkiller-like compiler is FOR SPEED! For example, you're a company on the
scale of Facebook who has written a large web site in a dynamic language and
suddenly realize you could be saving a lot of money on servers if your app
ran a lot faster. Source translation to C++ is a potential way to go
I don't think that applies to anyone who uses Ruby, though. Maybe Twitter...
Seriously, I believe these questions are not worth asking.
Then why do you bother with this mailing list? You might as well
unsubscribe now.
It is 100% possible in both principle and in practice to convert
Ruby code into another language where the output performs the same
functions as the original code.
I know. I've done it. Twice. See ruby2c for one such example. There
is another, zenobfuscate, (unreleased) that translates ruby to ruby c
internals so that you can compile a ruby c extension and ship a
binary instead of raw source. This may be what the OP wanted, but
since nobody bothered to ask before answering (in volumes), it looks
like they were chased off.
However, the output will have nothing to do with Ruby in any way.
This is entirely false and I see absolutely no justification in the
rest of your mail for such a claim.
OK, I have been lurking but will respond now: I have an actual existing application (C/C++) for population genetics simulations which I would dearly love to convert to Ruby. It was originally all in C and, as a learning exercise, I converted parts of it to C++ - but it was such a pain . . it would have been so pleasant to re-write in Ruby. However I would have to get resulting code converted back to C or compiled somehow to get the performance back to something usable. I looked at ruby2c some time ago but it didn't seem developed enough. I have been watching Vidar Hokstad's progress:
but that still has some way to go and Ocelot development seems to have stopped?
Would ZenObfuscate be able to do what I want? - I just had a look at the website and I see it is an (expensive) commercial product . . pity.
So it appears that there is still no libre software ready for prime time in terms of being able to write code nicely in Ruby and have some sort of converted run time that has near C performance . .
Regards,
Phil.
···
On 2010-10-03 06:53, Ryan Davis wrote:
On Oct 2, 2010, at 05:36 , Ammar Ali wrote:
--
Philip Rhoades
GPO Box 3411
Sydney NSW 2001
Australia
E-mail: phil@pricom.com.au
The lack of reliability is not caused by using a less traditional
database but by programming errors either in the site itself or the
tools it uses.
Some databases not associated with NoSQL such as MySQL tend to be very
unreliable.
Using new and experimental technology is not always a good idea but
using old and known broken technology is never so and many people do
that anyway.
Thanks
Michal
···
On 5 October 2010 07:10, Clifford Heath <no@spam.please.net> wrote:
Tony Arcieri wrote:
... FOR SPEED! For example, you're a company on the
scale of Facebook who has written a large web site in a dynamic language
and
suddenly realize you could be saving a lot of money on servers if your app
ran a lot faster. Source translation to C++ is a potential way to go
And in all the world, there are how many companies that have a
web site that large (in traffic)? Maybe not even one other.
And they could afford to rewrite the site in whatever language
they chose, instead of relying on a dodgey translator to give
them an unreadable result.
I can't believe how many people use the old "but what if we
become as large as Facebook?" argument to drive their technology
choices. Like the number of places using NoSQLs to produce sites
that are even less reliable than they used to...
This is pretty much a staple of static type inferencers for dynamic
languages that output C++... many language features simply cannot be
supported using this approach, most notably eval, and eval is pretty much
the most powerful tool for Ruby metaprogramming. Source translation to C++
would preclude many of the things which make Ruby fun and interesting.
···
On Tue, Oct 5, 2010 at 9:54 PM, Mohit Sindhwani <mo_mail@onghu.com> wrote:
I tend to write Ruby code that avoids the advanced constructs of Ruby,
making translation to C++ easier.
OK, I have been lurking but will respond now: I have an actual existing
application (C/C++) for population genetics simulations which I would dearly
love to convert to Ruby. It was originally all in C and, as a learning
exercise, I converted parts of it to C++ - but it was such a pain . . it
would have been so pleasant to re-write in Ruby. However I would have to
get resulting code converted back to C or compiled somehow to get the
performance back to something usable.
Couldn't you just profile and write the bottlenecks in C? Also, take a
look at OCaml for ruby-like expressiveness with
reasonably-close-to-C++ performance.
So it appears that there is still no libre software ready for prime time in
terms of being able to write code nicely in Ruby and have some sort of
converted run time that has near C performance . .
I believe projects like ruby2c and zenobfuscate wouldn't get you
near-C performance, since they'd still be doing a lot of what the ruby
runtime is doing under the hood.
martin
···
On Sun, Oct 3, 2010 at 1:43 PM, Philip Rhoades <phil@pricom.com.au> wrote:
I thought I'd throw in my 2cents since I've actually done a little bit of profiling.
There are two main reasons for "compilation":
- Faster execution for code that is repeated many times
- Better foreign function interface
Other parts of modern compilers which are separate from compilation include:
- Syntax correctness
- Type checking / program validity
Many problems are algorithmic in nature, and a compiler will only provide a marginal improvement in speed.
If you have a truly dynamic language (like Ruby), it is almost impossible to compile it adequately. This is because compilation is all about making assumptions. A dynamic language makes it very hard to make assumptions (there is quite a bit of research in this area, it is worth reading about it).
From testing code that is either interpreted or compiled, I found that you had to run the code at least 10 times before you saw any kind of parity. For an inner loop on some complex function, this could be beneficial.
Every specific situation is different, and this is my experience.
Kind regards,
Samuel
···
On 5/10/2010, at 9:42 PM, Michal Suchanek wrote:
On 5 October 2010 07:10, Clifford Heath <no@spam.please.net> wrote:
Tony Arcieri wrote:
... FOR SPEED! For example, you're a company on the
scale of Facebook who has written a large web site in a dynamic language
and
suddenly realize you could be saving a lot of money on servers if your app
ran a lot faster. Source translation to C++ is a potential way to go
From my experience, a fast interpreter is better than a compiler in many cases, unless you are optimising an inner loop for code which is pushing the CPU. I found this out from writing an interpreter and compiler and doing the tests for myself. I was surprised by the result.
I tend to write Ruby code that avoids the advanced constructs of Ruby,
making translation to C++ easier.
This is pretty much a staple of static type inferencers for dynamic
languages that output C++... many language features simply cannot be
supported using this approach, most notably eval, and eval is pretty much
the most powerful tool for Ruby metaprogramming. Source translation to C++
would preclude many of the things which make Ruby fun and interesting.
This is very true. Dipping into what seems to have been attempted in
this area reveals lots of attempts which solve a small but easy subset
of the problem, like translating a "hello world" program, or a small
numerical problem with some polymorphic numeric values from Ruby or
Python to C or C++, and then stall out either when the hard problems
arise, or when the requirements to qualify for a Master's degree
project are met.
And Mohit's original observation is also important:
If you get to that scale (and are hopefully making money by then or have very large investments that
match your scale of users/ traffic), there is a high chance that you will need to re-architect
or rewrite a bunch of stuff - I don't think source translation will solve the problem.
Languages differ in much more important and subtle ways than their
syntax and surface-level semantics. Those differences lead to very
different architectures/strategies or whatever you want to call it.
Converting an OO program written in, say Ruby, requires adaptation of
not only the language syntax, but the underlying class library, if you
are converting to C++, you need to figure out what to do about the
usage in the Ruby program of base classes, you do probably have
several choices of C++ libraries providing things like collection
classes, all of which will mismatch the interfaces of their Ruby
equivalents, probably in frightening ways.
Replace Smalltalk/Ruby message send semantics with C++ virtual
function calls, and the constraints change. Move the burden of
accounting for and reclaiming the memory used by objects from a GC to
the programmer and things get complicated, and often the performance
of the hand-written memory management (copy constructors, reference
counts ...) starts making the performance 'win' of switching horses
much less certain.
Ruby can be dynamically translated ( = jitted ) as Smalltalk is.
A project "Rubinius" exists which goes in that direction.
The problem with ruby is that it is not so easy ( = lot of work ) to write a
ruby to bytecode translator.
Smalltalk & List style languages are almost syntax free - the contrary is
the case for Ruby.
Or Smalltalk VM ( LSW-GVM ) runs Smalltalk at the speed of C/C++ and we plan
to do that also for other dynamic languages ( e.g Haskell, JavaScript also
Ruby ) in the nearest future. The LSW-GVM is currently available for Win32
( deep GUI integration, multithreading ). We are working on a 64 Bit
version.
Frank Lesser
"Tony Arcieri" <tony.arcieri@medioh.com> schrieb im Newsbeitrag
news:AANLkTinzm=ch-Vz8T6zFAa_xMoZq=4qavqYpQAqvm-n7@mail.gmail.com...
···
[Note: parts of this message were removed to make it a legal post.]
On Tue, Oct 5, 2010 at 9:54 PM, Mohit Sindhwani <mo_mail@onghu.com> wrote:
I tend to write Ruby code that avoids the advanced constructs of Ruby,
making translation to C++ easier.
This is pretty much a staple of static type inferencers for dynamic
languages that output C++... many language features simply cannot be
supported using this approach, most notably eval, and eval is pretty much
the most powerful tool for Ruby metaprogramming. Source translation to C++
would preclude many of the things which make Ruby fun and interesting.
That's true of zenobfuscate but not true of ruby2c.
···
On Oct 3, 2010, at 10:30 , Martin DeMello wrote:
I believe projects like ruby2c and zenobfuscate wouldn't get you
near-C performance, since they'd still be doing a lot of what the ruby
runtime is doing under the hood.
Well this just isn't true (or is overly vague and my tired brain is reading more into it than it should). Look at anything written by David Ungar, or the research done on self, smalltalk, the latest javascript engines, etc...
···
On Oct 5, 2010, at 02:49 , Samuel Williams wrote:
If you have a truly dynamic language (like Ruby), it is almost impossible to compile it adequately. This is because compilation is all about making assumptions. A dynamic language makes it very hard to make assumptions (there is quite a bit of research in this area, it is worth reading about it).
Funnily enough this is one of the inspirations behind my golightly[0] project: if every significant program I write will end up with an ad hoc implementation of Lisp (or more often than not Lisp and several other languages) then why not just use an abstract platform that allows me to plug together Lisp machines, Forth machines, Ruby machines etc. and have them all operate on the same underlying type space?
This is subtly different to the traditional virtual machine approach as by taking seriously the notion of language agnosticism you end up with less a single machine and more a set of components that can be plugged together to build an infinite variety of machines that are each better suited to the particular tasks they're used for than a general-purpose VM. I suspect it's probably similar to the software IC concept you mentioned over on Core recently, but with the added wrinkle that I'm interested in building in generalised type space transformations if I can get my head around them. These would effectively provide a means of JIT translation between different language type models, including assembler-level type expression where practical. I suspect a big chunk of the winter is likely to be spent researching current developments in compiler theory in hopes someone else has already solved this problem... and if they haven't perhaps it's time I went back to Uni and got my Doctorate
Languages differ in much more important and subtle ways than their
syntax and surface-level semantics. Those differences lead to very
different architectures/strategies or whatever you want to call it.
Converting an OO program written in, say Ruby, requires adaptation of
not only the language syntax, but the underlying class library, if you
are converting to C++, you need to figure out what to do about the
usage in the Ruby program of base classes, you do probably have
several choices of C++ libraries providing things like collection
classes, all of which will mismatch the interfaces of their Ruby
equivalents, probably in frightening ways.
Replace Smalltalk/Ruby message send semantics with C++ virtual
function calls, and the constraints change. Move the burden of
accounting for and reclaiming the memory used by objects from a GC to
the programmer and things get complicated, and often the performance
of the hand-written memory management (copy constructors, reference
counts ...) starts making the performance 'win' of switching horses
much less certain.
Thanks for your comments. In this discussion there are many opinions, so please keep in mind this is simply my perspective based on my experience.
If you have a truly dynamic language (like Ruby), it is almost impossible to compile it adequately. This is because compilation is all about making assumptions. A dynamic language makes it very hard to make assumptions (there is quite a bit of research in this area, it is worth reading about it).
Well this just isn't true (or is overly vague and my tired brain is reading more into it than it should). Look at anything written by David Ungar, or the research done on self, smalltalk, the latest javascript engines, etc...
I'm aware of most of this work, however I don't consider many of these languages to be completely dynamic. By dynamic, I mean that it is not possible to make an assumption about the result of an expression unless it is executed. If you can make an assumption about an expression, I don't consider it to be dynamic.
For example, in most of those languages, the name of a function is specified explicitly and can't change due to the environment or scope of execution. We also know that all arguments to a function will be evaluated in the current scope. We can do some analysis and determine that an expression won't change in a loop, and then optimise for this case. Many of these languages provide some semantic models which allow the interpreter to make assumptions.
A good indication of a non-dynamic programming language is the presence of semantically meaningful keywords, especially those that have fixed behaviour. Examples include "def", "if", "while", "switch" and "try". These expressions can all be analysed with the knowledge of a given semantic model. A truly dynamic language has no such luxury...
In the case of a dynamic language we are reduced to statistical analysis at run time. Compilation becomes a method of speeding up the interpreter execution rather than optimising based on assumptions in the code itself. Few, if any, programming languages are completely dynamic. Scheme would be one language that I would consider very dynamic, as an example.
An interpreter is simply a high level processor (i.e. CPU). However, there are intrinsic semantic structures which cannot be lowered. "Sufficiently smart compilers", and all that. Programming languages range from completely dynamic to completely static, depending on the semantic and execution model.
Sounds a bit like several historic efforts like Uncol, IBM's SOM, and
Microsoft's (D)CLR.
Also sounds for a great topic for a Ruby Conf version of the kind of
semi-inebriated late night discussions I used to enjoy at OOPSLA with
the likes of Kent Beck, Ward Cunningham, George Bosworth of Digitalk
(who went on to work on DCLR at MS before giving up on them) and
others back in the heyday.
···
On Wed, Oct 6, 2010 at 9:56 AM, Eleanor McHugh <eleanor@games-with-brains.com> wrote:
Funnily enough this is one of the inspirations behind my golightly[0] project: if every significant program I write will end up with an ad hoc implementation of Lisp (or more often than not Lisp and several other languages) then why not just use an abstract platform that allows me to plug together Lisp machines, Forth machines, Ruby machines etc. and have them all operate on the same underlying type space?
This is subtly different to the traditional virtual machine approach as by taking seriously the notion of language agnosticism you end up with less a single machine and more a set of components that can be plugged together to build an infinite variety of machines that are each better suited to the particular tasks they're used for than a general-purpose VM. I suspect it's probably similar to the software IC concept you mentioned over on Core recently, but with the added wrinkle that I'm interested in building in generalised type space transformations if I can get my head around them. These would effectively provide a means of JIT translation between different language type models, including assembler-level type expression where practical. I suspect a big chunk of the winter is likely to be spent researching current developments in compiler theory in hopes someone else has already solved this problem... and if they haven't perhaps it's time I went back to Uni and got my Doctorate
Thanks for your comments. In this discussion there are many opinions, so please keep in mind this is simply my perspective based on my experience.
If you have a truly dynamic language (like Ruby), it is almost impossible to compile it adequately. This is because compilation is all about making assumptions. A dynamic language makes it very hard to make assumptions (there is quite a bit of research in this area, it is worth reading about it).
Well this just isn't true (or is overly vague and my tired brain is reading more into it than it should). Look at anything written by David Ungar, or the research done on self, smalltalk, the latest javascript engines, etc...
I'm aware of most of this work, however I don't consider many of these languages to be completely dynamic. By dynamic, I mean that it is not possible to make an assumption about the result of an expression unless it is executed. If you can make an assumption about an expression, I don't consider it to be dynamic.
What assumptions can you make about the result of an expression in any
of these languages without running it?
The result of a method send in Smalltalk, Ruby, or Self depends on the
runtime state of the receiver of the message, and in the case of Ruby
and Self, where compile time is the same as run-time methods can
change as the program runs.
In Ruby this evolution happens as the program requires new code, mixes
in new modules, defines singleton methods, redefines methods, uses
meta-programming techniques, such as the alias_method_chain found in
Rails ...
In Self static analysis of a method can't even determine if the
reference to an 'instance variable' is really just a value reference
or a method call.
For example, in most of those languages, the name of a function is specified explicitly and can't change due to the environment or scope of execution. We also know that all arguments to a function will be evaluated in the current scope. We can do some analysis and determine that an expression won't change in a loop, and then optimise for this case.
No I don't think we can. Not for Ruby, nor Smalltalk, nor Self, nor
as Shyouhei-san has pointed out, for JavaScript.
Smalltalk is a bit more static than Ruby, Self, or JavaScript, in
that, although run-time and development take place in the same
environment, code changes happen mostly when a programmer changes a
method/class definition in the IDE, which causes an incremental
compilation of the affected methods. Smalltalk classes are
'statically' defined in this sense.
Many of these languages provide some semantic models which allow the interpreter to make assumptions.
A good indication of a non-dynamic programming language is the presence of semantically meaningful keywords, especially those that have fixed behaviour. Examples include "def", "if", "while", "switch" and "try". These expressions can all be analysed with the knowledge of a given semantic model. A truly dynamic language has no such luxury...
Smalltalk at the language level has no such keywords, control flow is
defined in terms of method sends.
For example if is implemented by ifTrue:, ifFalse:, and
ifTrue:ifFalse: messages, and boolean classes define these methods to
evaluate one of (or none) of the block arguments.
One could model this in Ruby with something like:
class Object
# define the if methods for truthy values
def if_true(eval_if_true)
eval_if_true.call
end
def if_true_else(eval_if_true, eval_if_false)
eval_if_true.call
end
def if_false(eval_if_false)
nil
end
end
module FalsyIfMethods
# define the if methods for falsy values
def if_true(eval_if_true)
nil
end
def if_true_else(eval_if_true, eval_if_false)
eval_if_false.call
end
def if_false(eval_if_false)
eval_if_false.call
end
end
Now most Smalltalk implementations do cheat on things like this and
treat methods like ifTrue: and its brethren as special cases and
compile them to test and branch bytecodes, with or without an escape
if the receiver turns out not to be a boolean. But Self came about
primarily because Dave Ungar, whose PhD dissertation was on Smalltalk
performance, wanted to explore doing away with such cheats, as well as
statically determination of whether something was an iv or a method,
as well as relying on the 'static' class definitions in Smalltalk and
see if dynamic runtime techniques could achieve equivalent if not
better performance.
And that work led to things like the JIT implementations in the Java
hotspot VM, and Self appears to have been an strong influence on
JavaScript, which uses the same kind of prototype technique for
implementation sharing, rather than a class hierarchy.
In the case of a dynamic language we are reduced to statistical analysis at run time. Compilation becomes a method of speeding up the interpreter execution rather than optimising based on assumptions in the code itself. Few, if any, programming languages are completely dynamic. Scheme would be one language that I would consider very dynamic, as an example.
Which you later correct to say 'Sorry, I meant to say "Scheme would be
one language that I would consider very close to being completely
dynamic".'
Which I interpret to mean that you put Scheme as being even more
dynamic than Smalltalk, Ruby, Self or JavaScript
An interpreter is simply a high level processor (i.e. CPU). However, there are intrinsic semantic structures which cannot be lowered. "Sufficiently smart compilers", and all that. Programming languages range from completely dynamic to completely static, depending on the semantic and execution model.
I'm confused by your argument at this point, because there are quite a
few compilers for Scheme http://en.wikipedia.org/wiki/Category:Scheme_compilers some of these
compile to an intermediate 'language' like C or JVM bytecodes, others
directly to some machine language.
And, Guy Steele, one the inventors of Scheme wrote his PhD
dissertation on a Scheme compiler "Rabbit"
So it's not impossible to write a compiler for a dynamic language, but
it takes more thought and techniques than most introductory compiler
texts/courses teach.
And Scheme was a seminal influence on those who have tackled the task.
Particularly in the form of the "Lambda Papers" a series of M.I.T.
A.I. lab memos by Guy Steele and Gerald Sussman as they explored usage
and implementation around various issues such as the lambda calculus,
continuations and a few other things leading up to and including
Steele's dissertation on Rabbit.
And Gerald Sussman went on to write, with Julie Sussman and Harold
Abelson, "The Structure and Interpretation of Computer Programs" which
should be an eye-opener to anyone who has thought of C as the
prototypical programming language.
···
On Tue, Oct 5, 2010 at 8:31 AM, Samuel Williams <space.ship.traveller@gmail.com> wrote:
Sounds a bit like several historic efforts like Uncol, IBM's SOM, and
Microsoft's (D)CLR.
I don't think anyone's done this particularly well to date, in large part because it's a ferociously difficult problem domain to get a decent handle on. But I guess that's part of the attraction lol
Also sounds for a great topic for a Ruby Conf version of the kind of
semi-inebriated late night discussions I used to enjoy at OOPSLA with
the likes of Kent Beck, Ward Cunningham, George Bosworth of Digitalk
(who went on to work on DCLR at MS before giving up on them) and
others back in the heyday.
Well I've never been backward in geeking when there's beer on tap, though finding anyone who can understand what the hell I'm on about is always a bit of a sticking point. They just don't make young geeks like they used to...
