<soapbox> Totally opinion and rambling. I am a total newbie to Rails and in fact to Ruby. Here''s what I''ve gleaned from this list and doing partial ports of a couple of apps over to RoR. I don''t mean to offend anyone who has asked about this, but comparisons among platforms are difficult with something like Rails. I''ve implemented lots of sites in ASP, ASP.NET and PHP. I''m of the opinion that the marriage between Ruby and Rails makes RoR a compelling model (again, no offense to those implementing ActiveRecord, et. al., on other platforms). On the other side of the coin, I always feel there "must be a more elegant way" to write whatever code I''m writing..." Creeping elegance is a problem. The fundamental assumption that caused my interest in Rails were that 1) There is a much better (purer, if you will) implementation of MVC than in other frameworks; and 2) I got tired of typing in lots of prototypes For you C# .NET programmers, you''ll remember the fully-qualified names you sometimes have to use to disambiguate namespace conflicts. Database access is one of the worst offenders where to use an Adapter you have to type a string over 50 characters long. Religious issue: A strongly-typed language such as C# or Java can nail many problems at compile time, but I believe the research has been mixed regarding error-to-developer efficiency ratios. For those who think deployment on .NET is a snap, you''re right; it''s simply an xcopy. However, there is a certain fragility introduced when a recompile is necessary. Assume that you''ve written a perfect Web application, tested it, and finally put it in production. Now your client wants a feature change. If this change involves code, it also involves a rebuild. Rebuilds introduce the potential for error. While we all try to encapsulate and all that good stuff, sometimes stuff happens and that simple change that had to be done yesterday (never happens to you, right?) becomes a whole heap of unforeseen bugs. On the flip side, the Visual Studio environment, plainly put, rocks. It is an integrated editor, debugger, source code control driver, and deployment tool. I''m totally impressed. Zend has an environment that is similarly productive for PHP. I''ve been told that ActiveState has some cool Python tools, but was not able to really prove to myself that they were worth the cost. As someone pointed out, when PHP first hit the Web, there was zero expertise in it. It''s easier to get into, but that does not breed professionals on whom an enterprise may rely. A full-featured framework requires a minimum bar of understanding (heck, Ruby is esoteric enough that visually parsing it takes some understanding :). My point is that while there may be fewer Rails experts, those who are implementing Rails apps are likely to have a deeper understanding of software engineering than the average PHP programmer. Religious issue: Scaling seems to be an important issue and .NET is quite strong on this point with fragment caching, page caching, and application state caching. This cache-management relies on the intimate connection between .NET and the underlying OS. In a "shoot-out" of the enterprise development platforms, it was interesting that only Microsoft chose to respond to the challenge of a benchmark; all other vendors declined. Hmmmm. I wonder whether a Ruby compiler is an option? Anyhow, just some thoughts to stimulate more opinion... </soapbox>
Interesting that you mention a ruby compiler. I''ve always thought that ruby''s interpreter implementation was a potential showstopper and have actually declined to use ruby a few times because of it (favoring python). Even interpreted bytecodes are better (and faster!) than interpreted syntax trees. Additionally, the startup time of a large ruby application can get ugly (especially if NFS is involved, which it is in some environments I work in). It''s embarrasing when I''m using ruby at work and go to show someone a demo and it takes 10 seconds for it to start up. A similarly sized python app starts up in less than one since all of the source code has been compiled to .pyc/.pyo already. Sure, some stuff still needs to be pulled over NFS, but we''re not trying to compile 30-60k lines of code at startup. Also, without bytecodes (or something like it), you lack a good level of abstraction in which to stick a compiler, JIT layer, threaded code layer, etc. I really don''t understand matz''s decision to use AST interpretation, since I think that this is increasingly becoming a hangup for the language. I think that serious work needs to be done on performance in dynamic languages before they will be real contenders in large, scalable corporate environments. Sure, ruby on rails is mostly bound by network/db speeds, so the cost of ruby is relatively small in the simple case (one or a handful of PC-like computers serving a website). In contrast, corporate infrastructure architects work very very hard to make sure that the CPU''s are never idle. When you have eighty server machines, and each is a $90,000 sun box, a web frontend server will be spending all its time running rails--massively multithreaded. It''s not busy hitting mysql when rails is waiting, it''s simply idle. This means that you run more rails instances per machine. The end result is that the number of computers you need is directly related to the performance of rails and ultimately ruby. If you''re replacing the machines every few years, and you need five times as many (since ruby is easily five times slower than .net from a strict CPU cycle comparison), ruby suddenly starts to look like a bad business decision for your app. Just some food for thought. I''ve been in a corporate environment like that one, and seen how people think. Yes they often have an irrational fear of the unknown, but Java is scalable and its scalability is tried and tested. it has fast runtime environments and runs well on big sun/ibm/etc. machines. Ruby performs very poorly on these machines compared to my (modest) desktop machine. It just feels slow. It''s almost sad that rails is written in Ruby and not a language with better runtime options. Ruby is a great language from an academic standpoint, but its immaturity is going to ultimately be a difficult road to cross for rails. Rails needs to grow faster than Ruby is willing to. Ok. Enough of that. Brian On 8/5/05, Steve Ross <sross-ju+vs0qJmycyYsO2DCxJlVaTQe2KTcn/@public.gmane.org> wrote:> <soapbox> > Totally opinion and rambling. I am a total newbie to Rails and in fact to > Ruby. Here''s what I''ve gleaned from this list and doing partial ports of a > couple of apps over to RoR. > > I don''t mean to offend anyone who has asked about this, but comparisons > among platforms are difficult with something like Rails. I''ve implemented > lots of sites in ASP, ASP.NET and PHP. I''m of the opinion that the marriage > between Ruby and Rails makes RoR a compelling model (again, no offense to > those implementing ActiveRecord, et. al., on other platforms). On the other > side of the coin, I always feel there "must be a more elegant way" to write > whatever code I''m writing..." Creeping elegance is a problem. > > The fundamental assumption that caused my interest in Rails were that 1) > There is a much better (purer, if you will) implementation of MVC than in > other frameworks; and 2) I got tired of typing in lots of prototypes > > For you C# .NET programmers, you''ll remember the fully-qualified names you > sometimes have to use to disambiguate namespace conflicts. Database access > is one of the worst offenders where to use an Adapter you have to type a > string over 50 characters long. > > Religious issue: A strongly-typed language such as C# or Java can nail many > problems at compile time, but I believe the research has been mixed > regarding error-to-developer efficiency ratios. > > For those who think deployment on .NET is a snap, you''re right; it''s simply > an xcopy. However, there is a certain fragility introduced when a recompile > is necessary. Assume that you''ve written a perfect Web application, tested > it, and finally put it in production. Now your client wants a feature > change. If this change involves code, it also involves a rebuild. Rebuilds > introduce the potential for error. While we all try to encapsulate and all > that good stuff, sometimes stuff happens and that simple change that had to > be done yesterday (never happens to you, right?) becomes a whole heap of > unforeseen bugs. > > On the flip side, the Visual Studio environment, plainly put, rocks. It is > an integrated editor, debugger, source code control driver, and deployment > tool. I''m totally impressed. Zend has an environment that is similarly > productive for PHP. I''ve been told that ActiveState has some cool Python > tools, but was not able to really prove to myself that they were worth the > cost. > > As someone pointed out, when PHP first hit the Web, there was zero expertise > in it. It''s easier to get into, but that does not breed professionals on > whom an enterprise may rely. A full-featured framework requires a minimum > bar of understanding (heck, Ruby is esoteric enough that visually parsing it > takes some understanding :). My point is that while there may be fewer Rails > experts, those who are implementing Rails apps are likely to have a deeper > understanding of software engineering than the average PHP programmer. > > Religious issue: Scaling seems to be an important issue and .NET is quite > strong on this point with fragment caching, page caching, and application > state caching. This cache-management relies on the intimate connection > between .NET and the underlying OS. In a "shoot-out" of the enterprise > development platforms, it was interesting that only Microsoft chose to > respond to the challenge of a benchmark; all other vendors declined. Hmmmm. > I wonder whether a Ruby compiler is an option? > > Anyhow, just some thoughts to stimulate more opinion... > </soapbox> > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- The years ahead pick up their dark bags. They move closer. There''s a slight rise in the silence then nothing. -- (If you''re receiving this in response to mail sent to bluczkie-OM76b2Iv3yLQjUSlxSEPGw@public.gmane.org, don''t be concerned This is my new address, but mail will be forwarded here indefinitely)
Brian L. wrote:>>Anyhow, just some thoughts to stimulate more opinion... >></soapbox> >> >>Wow...what an awesome response. It''s nice to hear an honest assessment from someone who''s not simply a panting Rails fanboy. I wasn''t aware of the majority of the issues you mention. It''s a shame, though, that Python has the quirks that it does...I''m a Java guy (an ex-Perl/PHP guy...<shudder/>) in need of a good scripting language, and Ruby syntax "feels" more right than Python. Guys, any chance a Ruby compiler will materialize sooner than _Duke Nukem Forever_?
The beauty, from my perspective, of a compiled language is that when writing code, you don''t have to think, "do I have an invariant in my loop that should be hoisted out?" or "are there some common subexpressions in this body of code I could factor out to make it slicker?" The compiler just does these things and far more. If you''re an optimizer junkie, you know exactly what I''m talking about: It''s not a license to write crummy code, but it is a way to stop writing code that uses bitwise operators instead of arithmetic ones just because you know it''s faster (on a particular machine). I am an optimizer junkie and its taken a long time to stop worrying about the crappy run-time performance of (Ruby|Python|PHP). But I''m realistic enough to know that the slowest application that ships runs rings around some theoretically fast optimized version. That''s what swayed me toward PHP and the RoR. I''ve done the C/C++ thing. I''ve done the C#.NET thing. I can''t stand Java. I love parts of these environments, but they don''t compel me. C was real cool when K&R was first printed. It was even cooler when the first ports arrived on microcomputers. Rehashes of the same language are not improving my daily working life. Ruby -- if I can get the religion -- my change my mind. Rails would be what might convince me. -----Original Message----- From: Brian L. [mailto:zorander-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] Interesting that you mention a ruby compiler. I''ve always thought that ruby''s interpreter implementation was a potential showstopper and have actually declined to use ruby a few times because of it (favoring python). Even interpreted bytecodes are better (and faster!) than interpreted syntax trees. Additionally, the startup time of a large ruby application can get ugly (especially if NFS is involved, which it is in some environments I work in). It''s embarrasing when I''m using ruby at work and go to show someone a demo and it takes 10 seconds for it to start up. A similarly sized python app starts up in less than one since all of the source code has been compiled to .pyc/.pyo already. Sure, some stuff still needs to be pulled over NFS, but we''re not trying to compile 30-60k lines of code at startup. Also, without bytecodes (or something like it), you lack a good level of abstraction in which to stick a compiler, JIT layer, threaded code layer, etc. I really don''t understand matz''s decision to use AST interpretation, since I think that this is increasingly becoming a hangup for the language. I think that serious work needs to be done on performance in dynamic languages before they will be real contenders in large, scalable corporate environments. Sure, ruby on rails is mostly bound by network/db speeds, so the cost of ruby is relatively small in the simple case (one or a handful of PC-like computers serving a website). In contrast, corporate infrastructure architects work very very hard to make sure that the CPU''s are never idle. When you have eighty server machines, and each is a $90,000 sun box, a web frontend server will be spending all its time running rails--massively multithreaded. It''s not busy hitting mysql when rails is waiting, it''s simply idle. This means that you run more rails instances per machine. The end result is that the number of computers you need is directly related to the performance of rails and ultimately ruby. If you''re replacing the machines every few years, and you need five times as many (since ruby is easily five times slower than .net from a strict CPU cycle comparison), ruby suddenly starts to look like a bad business decision for your app. Just some food for thought. I''ve been in a corporate environment like that one, and seen how people think. Yes they often have an irrational fear of the unknown, but Java is scalable and its scalability is tried and tested. it has fast runtime environments and runs well on big sun/ibm/etc. machines. Ruby performs very poorly on these machines compared to my (modest) desktop machine. It just feels slow. It''s almost sad that rails is written in Ruby and not a language with better runtime options. Ruby is a great language from an academic standpoint, but its immaturity is going to ultimately be a difficult road to cross for rails. Rails needs to grow faster than Ruby is willing to. Ok. Enough of that. Brian On 8/5/05, Steve Ross <sross-ju+vs0qJmycyYsO2DCxJlVaTQe2KTcn/@public.gmane.org> wrote:> <soapbox> > Totally opinion and rambling. I am a total newbie to Rails and in fact to > Ruby. Here''s what I''ve gleaned from this list and doing partial ports of a > couple of apps over to RoR. > > I don''t mean to offend anyone who has asked about this, but comparisons > among platforms are difficult with something like Rails. I''ve implemented > lots of sites in ASP, ASP.NET and PHP. I''m of the opinion that themarriage> between Ruby and Rails makes RoR a compelling model (again, no offense to > those implementing ActiveRecord, et. al., on other platforms). On theother> side of the coin, I always feel there "must be a more elegant way" towrite> whatever code I''m writing..." Creeping elegance is a problem. > > The fundamental assumption that caused my interest in Rails were that 1) > There is a much better (purer, if you will) implementation of MVC than in > other frameworks; and 2) I got tired of typing in lots of prototypes > > For you C# .NET programmers, you''ll remember the fully-qualified names you > sometimes have to use to disambiguate namespace conflicts. Database access > is one of the worst offenders where to use an Adapter you have to type a > string over 50 characters long. > > Religious issue: A strongly-typed language such as C# or Java can nailmany> problems at compile time, but I believe the research has been mixed > regarding error-to-developer efficiency ratios. > > For those who think deployment on .NET is a snap, you''re right; it''ssimply> an xcopy. However, there is a certain fragility introduced when arecompile> is necessary. Assume that you''ve written a perfect Web application, tested > it, and finally put it in production. Now your client wants a feature > change. If this change involves code, it also involves a rebuild. Rebuilds > introduce the potential for error. While we all try to encapsulate and all > that good stuff, sometimes stuff happens and that simple change that hadto> be done yesterday (never happens to you, right?) becomes a whole heap of > unforeseen bugs. > > On the flip side, the Visual Studio environment, plainly put, rocks. It is > an integrated editor, debugger, source code control driver, and deployment > tool. I''m totally impressed. Zend has an environment that is similarly > productive for PHP. I''ve been told that ActiveState has some cool Python > tools, but was not able to really prove to myself that they were worth the > cost. > > As someone pointed out, when PHP first hit the Web, there was zeroexpertise> in it. It''s easier to get into, but that does not breed professionals on > whom an enterprise may rely. A full-featured framework requires a minimum > bar of understanding (heck, Ruby is esoteric enough that visually parsingit> takes some understanding :). My point is that while there may be fewerRails> experts, those who are implementing Rails apps are likely to have a deeper > understanding of software engineering than the average PHP programmer. > > Religious issue: Scaling seems to be an important issue and .NET is quite > strong on this point with fragment caching, page caching, and application > state caching. This cache-management relies on the intimate connection > between .NET and the underlying OS. In a "shoot-out" of the enterprise > development platforms, it was interesting that only Microsoft chose to > respond to the challenge of a benchmark; all other vendors declined.Hmmmm.> I wonder whether a Ruby compiler is an option? > > Anyhow, just some thoughts to stimulate more opinion... > </soapbox> > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- The years ahead pick up their dark bags. They move closer. There''s a slight rise in the silence then nothing. -- (If you''re receiving this in response to mail sent to bluczkie-OM76b2Iv3yLQjUSlxSEPGw@public.gmane.org, don''t be concerned This is my new address, but mail will be forwarded here indefinitely)
I agree with you that ruby''s syntax feels more right than python''s. I tend to fall back on python since I have a lot of experience with it and can be productive immediately in it (i.e. I know the api''s so I''m not constantly looking up library docs). Learning curves aside, I''d say that python and ruby are roughly equivalent from a productivity standpoint. Ruby''s a little harder to read and python''s a little harder to write. This makes sense since python''s explicit syntax causes you to type a little more, and then aids in understanding code you haven''t seen in months when you go to read it. If writing a ruby compiler were simple, it would have been done already. Compilers are tough and compilers for dynamic languages are mostly an unknown. The main issue is that you can''t generate code for low-level operations without knowing the types of the variables which aren''t determined at runtime. Without directly solving this problem, every ''+'' operator turns into some sort of case statement for integers, floats, etc. with a fallback that does a dynamic lookup (or message) for late-bound overloaded operators--yuck. Psyco (a python JIT compiler for x86) solved this problem by looking at code in blocks keyed by type signature. The first time it encounters a type signature when entering that block, it generates machine code for that block with that incoming type signature. This way it only does dynamic lookups once per block rather than once per access or operation. Since most blocks tend to involve the same types repeatedly, this can be a big win. I believe that a block in psyco is 10-20 lines of code and that it makes the decisions as to where the boundaries lie. Really, though, for this to progress in the context of open source scripting languages, we need a common platform on which to explore these ideas. Psyco is cool, but it''s basically a one man show and its code is python specific. Parrot, if it ever gets off the ground, looks promising. At least it''s a place where the optimzation of dynamic languages can be explored. It already does JIT on x86 and ppc, though I don''t know what the performance numbers look like. Static compilation is pretty much a pipe dream, since it would involve whole program optimization to an extent not yet attempted outside of academic circles. I don''t think this is entirely impossible (to use type inference on the whole program, libraries and all, to figure out the set of possible types for each value and then generate code strategically for all possible combinations, using dynamic lookups when it becomes too numerous), but it''s certainly a nontrivial task. As I said before in more words, Rails people need to be immediately concerned with Ruby''s implementation issues. Smart people need to be working on that problem, too. Ruby was a quiet little language that got grasped by rails and flung to a wide public. There will be growing pains. Brian On 8/8/05, John Wells <lists-y8WhZ5XeQqVfbyii3fMa5/Z4XP/Yx64J@public.gmane.org> wrote:> Brian L. wrote: > > >>Anyhow, just some thoughts to stimulate more opinion... > >></soapbox> > >> > >> > Wow...what an awesome response. It''s nice to hear an honest assessment > from someone who''s not simply a panting Rails fanboy. I wasn''t aware of > the majority of the issues you mention. > > It''s a shame, though, that Python has the quirks that it does...I''m a > Java guy (an ex-Perl/PHP guy...<shudder/>) in need of a good scripting > language, and Ruby syntax "feels" more right than Python. > > Guys, any chance a Ruby compiler will materialize sooner than _Duke > Nukem Forever_? > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- The years ahead pick up their dark bags. They move closer. There''s a slight rise in the silence then nothing. -- (If you''re receiving this in response to mail sent to bluczkie-OM76b2Iv3yLQjUSlxSEPGw@public.gmane.org, don''t be concerned This is my new address, but mail will be forwarded here indefinitely)
On Mon, 2005-08-08 at 05:07 +0000, Brian L. wrote:> If writing a ruby compiler were simple, it would have been done > already. Compilers are tough and compilers for dynamic languages are > mostly an unknown. The main issue is that you can''t generate code for > low-level operations without knowing the types of the variables which > aren''t determined at runtime. Without directly solving this problem, > every ''+'' operator turns into some sort of case statement for > integers, floats, etc. with a fallback that does a dynamic lookup (or > message) for late-bound overloaded operators--yuck.Thanks for posting these thoughtful msgs! I agree, this is a hard problem; code hoisting and CSE and induction variable elimination and all that are hard to do in a dynamic language. A good compromise might be to write the speed-intensive stuff in C extensions where GCC can do data flow analysis and whatnot to take care of all that nifty compiler theory stuff. Yours, Tom
Brian L. said:> I agree with you that ruby''s syntax feels more right than python''s. I > tend to fall back on python since I have a lot of experience with it > and can be productive immediately in it (i.e. I know the api''s so I''m > not constantly looking up library docs). Learning curves aside, I''d > say that python and ruby are roughly equivalent from a productivity > standpoint. Ruby''s a little harder to read and python''s a little > harder to write. This makes sense since python''s explicit syntax > causes you to type a little more, and then aids in understanding code > you haven''t seen in months when you go to read it. > > If writing a ruby compiler were simple, it would have been done > already. Compilers are tough and compilers for dynamic languages are > mostly an unknown. The main issue is that you can''t generate code for > low-level operations without knowing the types of the variables which > aren''t determined at runtime. Without directly solving this problem, > every ''+'' operator turns into some sort of case statement for > integers, floats, etc. with a fallback that does a dynamic lookup (or > message) for late-bound overloaded operators--yuck.But what about a bytecode compiler for Ruby, like Python has by default...surely this is a realistic possibility?> As I said before in more words, Rails people need to be immediately > concerned with Ruby''s implementation issues. Smart people need to be > working on that problem, too. Ruby was a quiet little language that > got grasped by rails and flung to a wide public. There will be growing > pains.I agree and wish there was more honest discussion about this. Until there is, RoR will be relegated to very specific applications within our organization, if at all. I''m curious though...how''s Perl5 handle this? There is no Perl->bytecode compilation, and yet every speed assessment I''ve seen shows Perl thumping Python pretty well. Is there another trick from the Perl book Ruby could take advantage of? Thanks, John
On Monday 08 August 2005 14:36, Tom Copeland wrote:> Thanks for posting these thoughtful msgs! I agree, this is a hard > problem; code hoisting and CSE and induction variable elimination and > all that are hard to do in a dynamic language.Hard maybe, impossible definitely not. Common Lisp is no less dynamic than Ruby and -- judging from what I''ve been told repeatedly by Lispers -- compiled to rather fast code. CLisp is not the performance standard, CMUCL/SBCL and the commercial offerings set the mark. Michael -- Michael Schuerig I am the sum total of the parts mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org I control directly. http://www.schuerig.de/michael/ --Daniel C. Dennett, Elbow Room
Michael Schuerig said:> Hard maybe, impossible definitely not. Common Lisp is no less dynamic > than Ruby and -- judging from what I''ve been told repeatedly by Lispers > -- compiled to rather fast code. CLisp is not the performance standard, > CMUCL/SBCL and the commercial offerings set the mark.What''s nice in CL, or Objective-C for that matter, is that you can write code without obsessing over type information, and it''ll run just fine. However, if you want more speed, you can provide type information that will allow the compilers to emit more specific code. As someone else alluded to, there are papers out there that describe systems that do JIT compilation of code and create specialized versions of procedures on demand, as the procedures are called with arguments of different types. H-P''s project Dynamo <http://arstechnica.com/reviews/1q00/dynamo/dynamo-1.html>, probably now defunct due to H-P self-immolation if it wasn''t already ended, dynamically translated machine code to machine code -- using an identical instruction set! The idea was to do runtime, dynamic analysis of program behavior to produce code that beats statically compiled code. I thought Sun''s HotSpot did something similar, but it seems more limited. Regards, Ed -- Transmogrify, LLC * <http://xmog.com>
Michael Schuerig wrote:> On Monday 08 August 2005 14:36, Tom Copeland wrote: > >>Thanks for posting these thoughtful msgs! I agree, this is a hard >>problem; code hoisting and CSE and induction variable elimination and >>all that are hard to do in a dynamic language. > > > Hard maybe, impossible definitely not. Common Lisp is no less dynamic > than Ruby and -- judging from what I''ve been told repeatedly by Lispers > -- compiled to rather fast code. CLisp is not the performance standard, > CMUCL/SBCL and the commercial offerings set the mark. >I''m not a compiler engineer, but there is definitely some truth to Greenspun''s Tenth Rule: (Slightly paraphrased) "Any sufficiently complicated [...] program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp." The idea (which you may or may not agree with) is that when you need the level of introspection and self-modification that Lisp is capable of, your syntax starts to look like Lisp. You can parse the syntax tree for your Lisp program from inside your Lisp program. Here''s a guy writing a Scheme to C compiler in 90 minutes, while the camera rolls: http://www.iro.umontreal.ca/%7Eboucherd/mslug/meetings/20041020/minutes-en.html So, clearly I like Ruby enough to build production apps in it, but as we saw with the generators thing in Python, and the funny limitations of lambda in both languages, sometimes early decisions in the language design can come back to haunt you. Java, with its insanely-crippled ''generics'' implementation in 1.5, is a great example of this.
Ed Watkeys said:> As someone else alluded to, there are papers out there that describe > systems that do JIT compilation of code and create specialized versions of > procedures on demand, as the procedures are called with arguments of > different types.It''s too bad we can''t cross post this thread to ruby-talk...I''d be very interested in hearing some of the heavy weights on that list weigh in on this subject.
Wilson said:>> > I''m not a compiler engineer, but there is definitely some truth to > Greenspun''s > Tenth Rule: (Slightly paraphrased) > "Any sufficiently complicated [...] program contains an ad hoc > informally-specified bug-ridden slow implementation of half of Common > Lisp." > > The idea (which you may or may not agree with) is that when you need the > level > of introspection and self-modification that Lisp is capable of, your > syntax > starts to look like Lisp.The idea isn''t that your language starts to look like ANSI Common Lisp, but that you''re going to simulate useful language features and re-implement already written libraries. Regards, Ed -- Transmogrify, LLC * <http://xmog.com>
This is another reason for optional typed argument lists (and multimethods), but I didn''t bring it up because that would be getting ahead of ourselves. Besides, I am not so much concerned with optimization as I am concerned with clean looking code. The functionalobjects implementation of the Dylan programming language can be optimized like this, it''s not open source though. http://www.functionalobjects.com/ -Jeff ----- Original Message ----- From: "John Wells" <lists-y8WhZ5XeQqVfbyii3fMa5/Z4XP/Yx64J@public.gmane.org> To: <rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org> Cc: <rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org> Sent: Monday, August 08, 2005 8:28 AM Subject: Re: [Rails] Re: My Opinion: Comparing Rails to Other Platforms> Ed Watkeys said: >> As someone else alluded to, there are papers out there that describe >> systems that do JIT compilation of code and create specialized versions >> of >> procedures on demand, as the procedures are called with arguments of >> different types. > > It''s too bad we can''t cross post this thread to ruby-talk...I''d be very > interested in hearing some of the heavy weights on that list weigh in on > this subject. > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails
Many comments on this follow a common thread. I''ll try to summarize: - Dynamic languages are difficult to compile - Languages with introspection are difficult to compile - Ruby''s footprint is big and startup is slow - Other languages (perl, python) seem to have solved some of the problems Given: We are talking about Ruby (hence the posting to *Ruby* on Rails list). Therefore, the goal: Find a way to interpose some kind of faux compiler into the mix that compiles to bytecode in much the same way as the MS compilers compile to MSIL on the .NET platform. I''m not recommending Mono as a foundation for this, but compiling introduces the ability to: 1. Reduce deployed code size 2. Introduce optimizations 3. Reduce the amount of work the runtime interpreter has to do 4. Obfuscate production code 5. Possibly create a smaller footprint runtime interpreter because it doesn''t have to understand much about grammar These are not small projects, but it would be compelling from the perspective of removing the "oh, but Java is compiled and scaleable" objection to RoR. Thoughts? -----Original Message----- From: Brian L. [mailto:zorander-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] Sent: Sunday, August 07, 2005 10:08 PM To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org Subject: Re: [Rails] My Opinion: Comparing Rails to Other Platforms I agree with you that ruby''s syntax feels more right than python''s. I tend to fall back on python since I have a lot of experience with it and can be productive immediately in it (i.e. I know the api''s so I''m not constantly looking up library docs). Learning curves aside, I''d say that python and ruby are roughly equivalent from a productivity standpoint. Ruby''s a little harder to read and python''s a little harder to write. This makes sense since python''s explicit syntax causes you to type a little more, and then aids in understanding code you haven''t seen in months when you go to read it. If writing a ruby compiler were simple, it would have been done already. Compilers are tough and compilers for dynamic languages are mostly an unknown. The main issue is that you can''t generate code for low-level operations without knowing the types of the variables which aren''t determined at runtime. Without directly solving this problem, every ''+'' operator turns into some sort of case statement for integers, floats, etc. with a fallback that does a dynamic lookup (or message) for late-bound overloaded operators--yuck. Psyco (a python JIT compiler for x86) solved this problem by looking at code in blocks keyed by type signature. The first time it encounters a type signature when entering that block, it generates machine code for that block with that incoming type signature. This way it only does dynamic lookups once per block rather than once per access or operation. Since most blocks tend to involve the same types repeatedly, this can be a big win. I believe that a block in psyco is 10-20 lines of code and that it makes the decisions as to where the boundaries lie. Really, though, for this to progress in the context of open source scripting languages, we need a common platform on which to explore these ideas. Psyco is cool, but it''s basically a one man show and its code is python specific. Parrot, if it ever gets off the ground, looks promising. At least it''s a place where the optimzation of dynamic languages can be explored. It already does JIT on x86 and ppc, though I don''t know what the performance numbers look like. Static compilation is pretty much a pipe dream, since it would involve whole program optimization to an extent not yet attempted outside of academic circles. I don''t think this is entirely impossible (to use type inference on the whole program, libraries and all, to figure out the set of possible types for each value and then generate code strategically for all possible combinations, using dynamic lookups when it becomes too numerous), but it''s certainly a nontrivial task. As I said before in more words, Rails people need to be immediately concerned with Ruby''s implementation issues. Smart people need to be working on that problem, too. Ruby was a quiet little language that got grasped by rails and flung to a wide public. There will be growing pains. Brian On 8/8/05, John Wells <lists-y8WhZ5XeQqVfbyii3fMa5/Z4XP/Yx64J@public.gmane.org> wrote:> Brian L. wrote: > > >>Anyhow, just some thoughts to stimulate more opinion... > >></soapbox> > >> > >> > Wow...what an awesome response. It''s nice to hear an honest assessment > from someone who''s not simply a panting Rails fanboy. I wasn''t aware of > the majority of the issues you mention. > > It''s a shame, though, that Python has the quirks that it does...I''m a > Java guy (an ex-Perl/PHP guy...<shudder/>) in need of a good scripting > language, and Ruby syntax "feels" more right than Python. > > Guys, any chance a Ruby compiler will materialize sooner than _Duke > Nukem Forever_? > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- The years ahead pick up their dark bags. They move closer. There''s a slight rise in the silence then nothing. -- (If you''re receiving this in response to mail sent to bluczkie-OM76b2Iv3yLQjUSlxSEPGw@public.gmane.org, don''t be concerned This is my new address, but mail will be forwarded here indefinitely)
Hello Steve,> ..... Therefore, the goal: Find a way to interpose some kind of faux > compiler into the mix that compiles to bytecode .....I''ve seen and heard things of Ruby 2.0 being much like you described. See: http://www.rubygarden.org/ruby?Rite
This discussion should, as was pointed out earlier, be taken out of the RoR
mailing list, but the implications of breakage in 2.0 are huge (ref.
http://www.rubygarden.org/ruby?Rite). If Rails or Rails apps are subject to
breakage resulting from a language evolution, that''s scary.
This isn''t like C++, where you can choose not to rebuild. The execution
engine can be swapped out from under your code and cause quiet failure. I
hope everyone who is on the Rails core team is aware of the plans.
While the presentation and summary on rubygarden do mention a bytecode
compiler and interpreter, they don''t mention optimization -- or if they
do,
I missed it. I''d love to think that:
foo.each {|a| i = 1; a[i] = 3; }
would become (in bytecode)
# would have been loop hoisting, but wound up constant propagation
foo.each{|a| a[1] = 3}
foo.each{|a| collector += a * 4 }
becomes
# strength reduction (ex. 1)
foo.each{|a| collector += a + a + a + a }
# strength reduction (ex. 2)
foo.each{|a| collector += a << 2}
These might seem silly, but writing code as you "intend" the algorithm
to
work is always more maintainable but often less efficient. In many cases
when I write for clarity, I know I am also writing inefficient code because
computers don''t perform certain operations that are the key assumptions
of
the algorithm as efficiently as a combination of other operations (like
shifts and adds). That''s what makes optimization such a key component.
Rails folks: Are you tracking the development of 2.0?
Thanks
-----Original Message-----
From: Kevin Williams [mailto:kevwil-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: Monday, August 08, 2005 12:36 PM
To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
Subject: [Rails] RE: My Opinion: Comparing Rails to Other Platforms
Hello Steve,> ..... Therefore, the goal: Find a way to interpose some kind of faux
> compiler into the mix that compiles to bytecode .....
I''ve seen and heard things of Ruby 2.0 being much like you described.
See:
http://www.rubygarden.org/ruby?Rite
Michael Koziarski
2005-Aug-08 21:59 UTC
Re: RE: My Opinion: Comparing Rails to Other Platforms
> These might seem silly, but writing code as you "intend" the algorithm to > work is always more maintainable but often less efficient. In many cases > when I write for clarity, I know I am also writing inefficient code because > computers don''t perform certain operations that are the key assumptions of > the algorithm as efficiently as a combination of other operations (like > shifts and adds). That''s what makes optimization such a key component.The classes of problem this thread is referring to is almost entirely irrelevant for 99% of optimization problems that 99% of applications will ever face. In my java work I can''t tell you how many times people have had obfuscating optimisations for loop unrolling, fancy bitwise this and that, and other such hints. Despite all this optimisation, they only save 30ms per request. They''re shocked to find out that it''s actually their 10 outer joins, or N+1 SQL queries per row which is killing their performance.> Rails folks: Are you tracking the development of 2.0?I believe the ''official'' policy is that we''re a ruby 1.8.2 framework, if rails doesn''t run on 2.0, we''ll have to address that once it''s released. -- Cheers Koz
Jeremy Kemper
2005-Aug-08 22:11 UTC
Re: RE: My Opinion: Comparing Rails to Other Platforms
On Aug 8, 2005, at 2:59 PM, Michael Koziarski wrote:>> Rails folks: Are you tracking the development of 2.0? > > I believe the ''official'' policy is that we''re a ruby 1.8.2 framework, > if rails doesn''t run on 2.0, we''ll have to address that once it''s > released.I''m tracking 1.9. The language tweaks don''t affect Rails much. There are some changes to the standard library which do, however. No worries. jeremy
John Wells said:> > But what about a bytecode compiler for Ruby, like Python has by > default...surely this is a realistic possibility?Yes, it is being worked on as we speak: http://www.atdot.net/yarv/ Pardon me if this sounds rude, but a lot of the (rather intelligent sounding) people in this thread seem to be quite ignorant of Ruby and what is happening in the Ruby community. All this stuff you are talking about on the Rails list has been hashed over countless times on ruby-talk. Ruby does not exist for the sake of Rails, rather Rails exists because of the power and elegance of Ruby. As nice as Rails is, I''m praying some other extremely popular Ruby application appears so that this Ruby-exists-for-Rails mentality can be lessoned a bit. To get up to speed on the discussions of performance that have occurred in the Ruby community, please search some of the archives here: http://www.ruby-talk.org/> I agree and wish there was more honest discussion about this. Untilthere> is, RoR will be relegated to very specific applications within ourorganization, if at all. Again this has been discussed a lot in the Ruby community, and we all want Ruby to be as fast as possible. But in reality I think this obsession over performance is extremely overblown, and for 99% of cases, Ruby''s performance is more than adequate, especially in the realm of web apps. Network lag and database access will have a greater negative affect on performance than the speed of Ruby.> I''m curious though...how''s Perl5 handle this? There is noPerl->bytecode> compilation, and yet every speed assessment I''ve seen shows Perlthumping> Python pretty well. Is there another trick from the Perl book Rubycould> take advantage of?No you are incorrect here, Perl does do bytecode compilation, it is just done transparently inside the interpreter. Apparently the pyc files produced by Python do not help performance much since as you have indicated here Perl regularly outperforms Python. The point: a Ruby->bytecode compiler that outputs bytecode files (instead of just doing that internally in the interpreter) is of questionable value. Though if it is truly wanted by enough people, I''m sure someone will come along to expose that part of YARV (which is basically assured as being the next Ruby interpreter.) Ryan
> people in this thread seem to be quite ignorant of Ruby and what > is happening in the Ruby community.I am well aware of the current efforts going on in the area of bytecode compilation (since I was the one to bring it up, it seems that you''re referring to me). The fact that it wasn''t here from the beginning is still a lapse, and the fact that Matz is supporting future bytecode compilation doesn''t change that.> Network lag and database access will have a greater negative affect on > performance than the speed of Ruby.Not in enterprise environments. They tend to have dedicated servers for each piece of the process (database, frontend, etc) and run with high concurrency in each cluster. The size of the batch of servers is directly related to the performance of what''s going on in the server. In other words, they try to run them at a fixed idle% at all times. Faster language = more processes per machine = fewer machines to maintain/replace = profit. I''ve seen this kind of thinking firsthand with regard to web apps, with java as the typical solution> No you are incorrect here, Perl does do bytecode compilation, it is just > done transparently inside the interpreter. Apparently the pyc files > produced by Python do not help performance much since as you have > indicated here Perl regularly outperforms Python.At text processing, yes. Python excells in certain areas too, from a performance standpoint (like network concurrency). The compiled bytecode files don''t make the program run faster, they help it to start faster, since you''re not compiling/loading lots of code at startup. Perl programs tend to be rather small and task-oriented, whereas python and ruby are positioning for use in larger applications. I don''t use perl much, so I don''t know what it''s like when you require 50-100k lines of source at startup. I know that it''s painful in ruby (especially over NFS, another staple of enterprise environments) and painless in python (once the .pyc files have been generated, which takes an amount of time comparable to ruby startup).> The point: a Ruby->bytecode compiler that outputs bytecode files (instead > of just doing that internally in the interpreter) is of questionable > value. Though if it is truly wanted by enough people, I''m sure someone > will come along to expose that part of YARV (which is basically assured as > being the next Ruby interpreter.)The point: a ruby->bytecode compiler that outputs bytecode files will decrease startup times for programs in certain (important) environments and is trivial to impliment once you have bytecode compilation going. Why waste cycles every startup compiling the program to bytecodes when you can avoid it? Before you say it has no point, start a rails/webrick instance from your home directory over NFS on a big sun box. Then start a similarly sized python app. The difference is breathtaking. I realize that this is outside of the direct topic of rails. At the same time, it is very, very relevant to rails. Rails and Ruby are inextricably wed and will have to be carfeful not to get in one another''s way as things move forward. I also tend to run at the mouth about this stuff, since I have seen how the performance/design of dynamic language implementations keeps them out of the enterprise. I love working with dynamically typed languages, and I want to see them gain mindshare. Getting over the performance issues will be a key part of this. Brian
On Mon, Aug 08, 2005 at 07:26:43PM -0400, Ryan Leavengood wrote:> John Wells said: > > I''m curious though...how''s Perl5 handle this? There is no > Perl->bytecode > > compilation, and yet every speed assessment I''ve seen shows Perl > thumping > > Python pretty well. Is there another trick from the Perl book Ruby > could > > take advantage of? > > No you are incorrect here, Perl does do bytecode compilation, it is just > done transparently inside the interpreter. Apparently the pyc files > produced by Python do not help performance much since as you have > indicated here Perl regularly outperforms Python.Perl *can* save the internal representation as bytecode too, it''s just that the implementation is buggy and loading the bytecode is usually not faster (probably slower) than recompiling. Also, when speed is a priority, the first thing you do is minimize the impact of compilation or bytecode loading; you''d use mod_python or mod_perl or fast-cgi, load all your code at startup so you can reuse it for multiple requests, and be done with it. Although the perl runtime would probably be the fastest in that case, the speed differences between perl / ruby / python are not very significant for most sites. Cheers, Joost.
Ryan Leavengood wrote:> John Wells said: > >>But what about a bytecode compiler for Ruby, like Python has by >>default...surely this is a realistic possibility? > > > Yes, it is being worked on as we speak: http://www.atdot.net/yarv/ > > Pardon me if this sounds rude, but a lot of the (rather intelligent > sounding) people in this thread seem to be quite ignorant of Ruby and what > is happening in the Ruby community. All this stuff you are talking about > on the Rails list has been hashed over countless times on ruby-talk. Ruby > does not exist for the sake of Rails, rather Rails exists because of the > power and elegance of Ruby. As nice as Rails is, I''m praying some other > extremely popular Ruby application appears so that this > Ruby-exists-for-Rails mentality can be lessoned a bit > > To get up to speed on the discussions of performance that have occurred in > the Ruby community, please search some of the archives here: > http://www.ruby-talk.org/I''ve been skimming through this thread, about to weight in on just this topic; thanks for doing a better job than I would have, Ryan. Indeed, there have been many prior discussion on this, and there is current work on a Ruby byte-code complier, and I believe there will be a presentation on YARV at RubyConf 2005 (so, yet another reason to go). There are years of Ruby mailing list (core, dev, talk) archives just waiting to be read. Also, Koichi''s presentation form RubyConf 2004 is available: http://www.zenspider.com/Languages/Ruby/RubyConf2004.html And YARV has a mailing listL http://news.gmane.org/gmane.comp.lang.ruby.yarv.devel> ...> The point: a Ruby->bytecode compiler that outputs bytecode files (instead > of just doing that internally in the interpreter) is of questionable > value. Though if it is truly wanted by enough people, I''m sure someone > will come along to expose that part of YARV (which is basically assured as > being the next Ruby interpreter.)Wouldn''t having precompiled byte-code speed up launch time for an application? James -- http://www.ruby-doc.org - The Ruby Documentation Site http://www.rubyxml.com - News, Articles, and Listings for Ruby & XML http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://www.jamesbritt.com - Playing with Better Toys