Comments on: Something In the Make [UPDATED] http://umageller.wordpress.com/2006/12/18/something-in-the-make/ Uma Geller dreams by day and types by night Thu, 28 Aug 2008 04:49:27 +0000 http://wordpress.com/ hourly 1 By: Uma http://umageller.wordpress.com/2006/12/18/something-in-the-make/#comment-20 Uma Mon, 01 Jan 2007 20:59:58 +0000 http://umageller.wordpress.com/2006/12/18/something-in-the-make/#comment-20 by the way... _why is posting this, as we speak... http://redhanded.hobix.com/cult/yarvIsRubyItIsItReallyIs.html speedup charts and all... by the way… _why is posting this, as we speak…

http://redhanded.hobix.com/cult/yarvIsRubyItIsItReallyIs.html

speedup charts and all…

]]> By: Ulluru http://umageller.wordpress.com/2006/12/18/something-in-the-make/#comment-19 Ulluru Mon, 01 Jan 2007 20:02:10 +0000 http://umageller.wordpress.com/2006/12/18/something-in-the-make/#comment-19 No worries, I should keep my comments on topic. I'm loving the new YARV benchmarks though. This is really an awesome new year's present! link: http://www.rubychan.de/share/yarv_speedups.html No worries, I should keep my comments on topic. I’m loving the new YARV benchmarks though. This is really an awesome new year’s present!

link: http://www.rubychan.de/share/yarv_speedups.html

]]> By: umageller http://umageller.wordpress.com/2006/12/18/something-in-the-make/#comment-17 umageller Thu, 28 Dec 2006 18:24:18 +0000 http://umageller.wordpress.com/2006/12/18/something-in-the-make/#comment-17 Thanks Ulluru for joining the conversation, hope my comment didn't come across too harshly. I'm watching with interest the state of the art of all implementations, not just the MRI. (or YARV, for that matter, which is currently being merged with MRI, so eventually the MRI *will be* YARV, as _why reports: http://redhanded.hobix.com/cult/yarvMergedMatz.html ) Rubinius and XRuby are very interesting projects to watch, and as I said elsewhere, the Ruby implementation(s) that run atop the JVM are very welcome as a counterbalance for the crop of other implementations that run on the .NET CLR. Will the Ruby+JVM implementations be the faster and better performant ? Too soon to say. My take is that VMs more Smalltalk-ish or more Self-ish have better chances to succeed in the performance deparment. The JVM, very obviously, has the advantage of widespread deployment, and binary lingua franca, but I don't discount we shall see the day when Ruby is also used as a systems language for certain tasks where you would have used C++ in the past. A girl can only dream so much :-) Thanks Ulluru for joining the conversation, hope my comment didn’t come across too harshly.

I’m watching with interest the state of the art of all implementations, not just the MRI. (or YARV, for that matter, which is currently being merged with MRI, so eventually the MRI *will be* YARV, as _why reports:
http://redhanded.hobix.com/cult/yarvMergedMatz.html )
Rubinius and XRuby are very interesting projects to watch, and as I said elsewhere, the Ruby implementation(s) that run atop the JVM are very welcome as a counterbalance for the crop of other implementations that run on the .NET CLR.
Will the Ruby+JVM implementations be the faster and better performant ? Too soon to say.

My take is that VMs more Smalltalk-ish or more Self-ish have better chances to succeed in the performance deparment. The JVM, very obviously, has the advantage of widespread deployment, and binary lingua franca, but I don’t discount we shall see the day when Ruby is also used as a systems language for certain tasks where you would have used C++ in the past.
A girl can only dream so much :-)

]]> By: Ulluru http://umageller.wordpress.com/2006/12/18/something-in-the-make/#comment-16 Ulluru Wed, 27 Dec 2006 17:19:36 +0000 http://umageller.wordpress.com/2006/12/18/something-in-the-make/#comment-16 I can't wait till YARV or whatever will bridge that gap. Don't get me wrong by way of my O.T. comment. I like rake. I am just a bit frustrated by all this effort being concentrated on all these great tools being created when you can't really use them for large data sets. I just play with If I have to use ruby as glue with data crunching in the RDBMS/Warehouse back-end then sure, but then we're back to square one. That one's been flogged to death already so my apologies for bringing it up again. I would love to see Ruby (my Favorite) at least as fast as Lua (not my favorite) I think Matz' "bikeshed" comment extends to this part of Ruby as well. I am not a compiler/VM expert (I'm not even a proper Rubyist)and most Rubyists aren't , This is why we see a lot of tools being created _in_ Ruby, but not significant improvements in Ruby's speed which requires a lower level understanding of compilers/interpreters etc. (I hate to say this because it is going to start a flamewar) Even the speed-up initiatives are sort of staying within the "familiar" which is to try to write something in Ruby or in Java. Again, I'm not a compiler expert (did a toy one during comp-sci days) but from a lay person's perspective, if we are going to go through the trouble of x-lating Ruby to JVM bytecodes, why not just do it for the X86? or why not a proper Ruby compiler for the X86 instruction set? I don't think Ruby is just so exotic that it's idioms cannot be translated to a compiled paradigm. It would be nice to know that when you're done prototyping, you can always compile it and benefit from a much higher speed boost. I'd like that solution even better than the whole byte-code thingy because VM's just bother me for some reason. My simplistic conclusion is that there just aren't that many domain experts (Matz, ko1 and maybe a few others) in the Ruby community. So, everyone keeps building the cool bikeshed using ruby, but very few (Koichi etc.) look at the reactor next door I am really looking forward to your prediction becoming true re: Ruby and its execution speeds and hope my nagging is proven wrong. Sometimes, it is good to be wrong :) I can’t wait till YARV or whatever will bridge that gap. Don’t get me wrong by way of my O.T. comment. I like rake. I am just a bit frustrated by all this effort being concentrated on all these great tools being created when you can’t really use them for large data sets. I just play with

If I have to use ruby as glue with data crunching in the RDBMS/Warehouse back-end then sure, but then we’re back to square one. That one’s been flogged to death already so my apologies for bringing it up again.

I would love to see Ruby (my Favorite) at least as fast as Lua (not my favorite) I think Matz’ “bikeshed” comment extends to this part of Ruby as well. I am not a compiler/VM expert (I’m not even a proper Rubyist)and most Rubyists aren’t , This is why we see a lot of tools being created _in_ Ruby, but not significant improvements in Ruby’s speed which requires a lower level understanding of compilers/interpreters etc. (I hate to say this because it is going to start a flamewar)

Even the speed-up initiatives are sort of staying within the “familiar” which is to try to write something in Ruby or in Java. Again, I’m not a compiler expert (did a toy one during comp-sci days) but from a lay person’s perspective, if we are going to go through the trouble of x-lating Ruby to JVM bytecodes, why not just do it for the X86? or why not a proper Ruby compiler for the X86 instruction set? I don’t think Ruby is just so exotic that it’s idioms cannot be translated to a compiled paradigm.

It would be nice to know that when you’re done prototyping, you can always compile it and benefit from a much higher speed boost. I’d like that solution even better than the whole byte-code thingy because VM’s just bother me for some reason.

My simplistic conclusion is that there just aren’t that many domain experts (Matz, ko1 and maybe a few others) in the Ruby community. So, everyone keeps building the cool bikeshed using ruby, but very few (Koichi etc.) look at the reactor next door

I am really looking forward to your prediction becoming true re: Ruby and its execution speeds and hope my nagging is proven wrong. Sometimes, it is good to be wrong :)

]]> By: Uma http://umageller.wordpress.com/2006/12/18/something-in-the-make/#comment-15 Uma Wed, 27 Dec 2006 04:00:20 +0000 http://umageller.wordpress.com/2006/12/18/something-in-the-make/#comment-15 Ulluru: All publications, newspapers, books, even blogs have a target audience. You don't seem to fall within the boundaries of this audience: leading edge Ruby programmers. As you can see from the text, what I talk about is mostly about Ruby implementations, coverage, identification and reporting of interesting/disruptive trends mainly about Ruby. It's okay if you don't fall within the boundaries of this target public, I wouldn't dare to suggest you should change that, I just can't see the reason why you're not posting in some other blog about the other 40% of the programming languages you are fond of, or start a blog, I will surely read it with great pleasure. I don't agree that any non-trivial codebase eventually becomes spaghetti code, you are implying and extrapolating too much from possibly not the best data sample Another thing: I am among the tiny group of people who really care about performance, so you really have chosen the wrong person to nag, I will be reporting soon (as Pat Eyler has done) about the state of the art in Ruby implementations. I dare to predict you will have to erase that commonplace notion (Ruby = slow), hopefully in 1 or 2 years from now. Ulluru: All publications, newspapers, books, even blogs have a target audience. You don’t seem to fall within the boundaries of this audience: leading edge Ruby programmers. As you can see from the text, what I talk about is mostly about Ruby implementations,
coverage, identification and reporting of interesting/disruptive trends mainly about Ruby.

It’s okay if you don’t fall within the boundaries of this target public, I wouldn’t dare to suggest you should change that, I just can’t see the reason why you’re not posting in some other blog about the other 40% of the programming languages you are fond of, or start a blog, I will surely read it with great pleasure.

I don’t agree that any non-trivial codebase eventually becomes spaghetti code, you are implying and extrapolating too much from possibly not the best data sample

Another thing: I am among the tiny group of people who really care about performance, so you really have chosen the wrong person to nag, I will be reporting soon (as Pat Eyler has done) about the state of the art in Ruby implementations.
I dare to predict you will have to erase that commonplace notion (Ruby = slow), hopefully in 1 or 2 years from now.

]]> By: Ulluru http://umageller.wordpress.com/2006/12/18/something-in-the-make/#comment-14 Ulluru Wed, 27 Dec 2006 00:15:44 +0000 http://umageller.wordpress.com/2006/12/18/something-in-the-make/#comment-14 I am having serious doubts about using ruby for anything these days. It is excellent for productivity, yes, but any language that chews up 60% of my cpu time as it runs a simple script is just not paying attention to the world. I can't believe people keep talking about all these cool tools, yet don't even partially flinch at the excruciatingly slow execution speeds that Ruby has to offer. Rake is a great tool, but most tools which have to deal with any serious amount of data are just too slow to be used without the "ugliness" of C being introduced anyways. I am having serious doubts about using ruby for anything these days. It is excellent for productivity, yes, but any language that chews up 60% of my cpu time as it runs a simple script is just not paying attention to the world.

I can’t believe people keep talking about all these cool tools, yet don’t even partially flinch at the excruciatingly slow execution speeds that Ruby has to offer. Rake is a great tool, but most tools which have to deal with any serious amount of data are just too slow to be used without the “ugliness” of C being introduced anyways.

]]> By: Eugen Minciu http://umageller.wordpress.com/2006/12/18/something-in-the-make/#comment-12 Eugen Minciu Thu, 21 Dec 2006 20:16:23 +0000 http://umageller.wordpress.com/2006/12/18/something-in-the-make/#comment-12 Of course, there scons at http://www.scons.org/. It's written in Python and oriented towards C/C++ development. I haven't used it in a long time but it was decent at the time I used it (maybe three years ago, I don't recall exactly) You didn't mention what I think is another big problem for the GNU autotools. Things like the ./configure scripts are horrifically slow. Of course, there scons at http://www.scons.org/. It’s written in Python and oriented towards C/C++ development. I haven’t used it in a long time but it was decent at the time I used it (maybe three years ago, I don’t recall exactly)

You didn’t mention what I think is another big problem for the GNU autotools. Things like the ./configure scripts are horrifically slow.

]]> By: Sachin http://umageller.wordpress.com/2006/12/18/something-in-the-make/#comment-11 Sachin Thu, 21 Dec 2006 15:18:59 +0000 http://umageller.wordpress.com/2006/12/18/something-in-the-make/#comment-11 Wait for few more days, Eclipse and all leading IDEs will have your said feature included. Now JDK6 comes with Ruby, JavaScript support and a build tool integration is indeed for all types of artifacts. By the way, have you tried Maven to configure for Java + Ruby projects? Wait for few more days, Eclipse and all leading IDEs will have your said feature included. Now JDK6 comes with Ruby, JavaScript support and a build tool integration is indeed for all types of artifacts.

By the way, have you tried Maven to configure for Java + Ruby projects?

]]> By: umageller http://umageller.wordpress.com/2006/12/18/something-in-the-make/#comment-7 umageller Tue, 19 Dec 2006 05:02:49 +0000 http://umageller.wordpress.com/2006/12/18/something-in-the-make/#comment-7 ummmm... attempted to gem install rake, then gem install raven and I get a 404 error. (ruby 1.8.4, openSuse 10.1, Linux 2.6.16) ............... output ------------------------- Successfully installed rake-0.7.1 Installing ri documentation for rake-0.7.1... Installing RDoc documentation for rake-0.7.1... dbext:umagella # gem install raven ERROR: While executing gem ... (OpenURI::HTTPError) 404 Not Found maybe it doesn't find the download url you declared in the gemspec ? ummmm… attempted to gem install rake, then gem install raven and I get a 404 error. (ruby 1.8.4, openSuse 10.1, Linux 2.6.16)

…………… output ————————-
Successfully installed rake-0.7.1
Installing ri documentation for rake-0.7.1…
Installing RDoc documentation for rake-0.7.1…

dbext:umagella # gem install raven
ERROR: While executing gem … (OpenURI::HTTPError)
404 Not Found

maybe it doesn’t find the download url you declared in the gemspec ?

]]> By: mriou http://umageller.wordpress.com/2006/12/18/something-in-the-make/#comment-6 mriou Tue, 19 Dec 2006 04:08:48 +0000 http://umageller.wordpress.com/2006/12/18/something-in-the-make/#comment-6 You might also be interested in Raven (http://raven.rubyforge.org). It's somewhat close to what Matt Foemel is doing (Rake with some Java primitives) and adds some Ruby Gems for dependency management. I've kept it pure Ruby for now and it works with JRuby. Check it out if you have some time. You might also be interested in Raven (http://raven.rubyforge.org). It’s somewhat close to what Matt Foemel is doing (Rake with some Java primitives) and adds some Ruby Gems for dependency management.

I’ve kept it pure Ruby for now and it works with JRuby. Check it out if you have some time.

]]>