4 ms·

There are NOT SmallTalk libraries out there that are 70x faster than Ruby - that would be faster than raw C (Ruby is about 30x slower). Are you trying to say th

by sho 18y ago

There are NOT SmallTalk libraries out there that are 70x faster than Ruby - that would be faster than raw C (Ruby is about 30x slower). Are you trying to say that SmallTalk is faster on average than raw C? So why isn't everything written in SmallTalk? And I'll believe Maglev's outlandish performance claims if and when I ever see them realised. If they are anything like those claimed at RailsConf 2008 (50x or thereabouts), I'll eat my hat and any other hats anyone cares to send me. I say this as someone who would probably seriously consider murder if it would make my Rails apps run 10x faster. I want it to be true. I just don't think it is, unfortunately. And one could probably take just about any Lisp and give it the power of the other 10% (like Erlang) with moderate effort. I keep hearing things like this, but no-one ever does it.

swannodette 18y ago
ever heard of Lisp Flavored Erlang? Ever heard of the Common Lisp Object System (inspired originally by Smalltalk)? Ever heard of Clojure (Haskell inspired STM, and lazy data structures)? ever heard of GOAL (Lisp assembly)? etc., etc. etc., etc., etc.
- sho 18y ago
  Like above I didn't make myself clear at all. Let me try again, by your leave. I wasn't claiming you can't tack feature X onto lisp, of course you can, you can implement anything in anything. The point I wanted to make was that "power" is not just some object feature bullet points, it's about ease of use and syntax and libraries as well. "If you add Traits (library for Mixins) to Smalltalk, it is equivalent to Ruby in power. (1)" Only for your definition of "power". Yes, everyone loves Ruby's super-flexible objects and mixins etc but that is only the start of the story. Its syntax is terse, intuitive and good-looking. The rubygems packaging system is effective and ubiquitous. Irb is excellent and "live coding" techniques are invaluable. To me, these are very much part of the real "power" and the main reason I prefer it over, say, Python. You might be able to emulate the object behaviour but it's still "incomprehensible mess of brackets" Lisp. You might be able to claim that Lisp is 90% "homomorphically equivalent", a phrase I don't think I've heard since Mathematics 2, but who gives a shit? Go ahead and add the last 10% of whatever it is that Ruby has and Lisp doesn't. Now you have just as much power as Ruby? So go ahead and type "require activerecord" (don't forget to compile!) and just try to tap into that power. Oops. "Language power" is not just some reductive theoretical idea of what features a language has, or could implement. It's the whole package, and how you use it. Sure you can add Ruby's features to C. But a better way is to implement Ruby in it. Lisp might well be the infinitely flexible meta-language which can be used to describe all others, but that isn't actually useful in itself, as used today. Lisp may be an incredibly powerful tool for something, but it has little advantage for conventional end-user code, not any more anyway. It's pretty exciting to think where it might end up, though. "And one could probably take just about any Lisp and give it the power of the other 10% (like Erlang) with moderate effort." Again, only for your definition of "power", which is not what the average programmer who is just interested in getting stuff done is thinking about.
  - swannodette 18y ago
    In Ruby can you connect to the running web application and debug it on the fly via a REPL? You can do this with Common Lisp and Clojure (PLT Scheme?). It definitely helps with "getting stuff done."
    - jasonwatkinspdx 18y ago
      Yes.
      - swannodette 18y ago
        You're right, I stand corrected. Interesting that this aspect hasn't been hyped up more when people mention Rails.
  - deleted 18y ago
    [deleted]
  - stcredzero 18y ago
    You might be able to claim that Lisp is 90% "homomorphically equivalent", a phrase I don't think I've heard since Mathematics 2, but who gives a shit? Well, for those who actually have a little intellectual curiosity, the implications are: 1) Not only can you do anything in langauges X and Y that you do in Ruby, you can express it about as concisely 2) Any libraries in Ruby could be just as beautifully expressed in languages X and Y 3) There's no reason something that closely resembles Ruby but runs *a lot faster* shouldn't exist 4) Speed is just one factor among many. There are lots of other things Ruby could learn from. Sho, there are some who have enormous cognitive dissonance at the thought that their pet language is not the ultimate in the universe. Then there are others that are actually curious about what else is out there, and how the languages they know the most about fit into that continuum. Therein is some valuable and useful information for those who are forward looking. (For the others, Ruby is awesome, it is the ultimate, there shall be nothing better, yada yada. Now you can rest easy.) There has been a bajillion hours of awesome work that's gone into Ruby and Rails. There are ways that Ruby and Rails can be changed such that the next bajillion can be several times more awesome. All I'm saying is -- look around and be curious. There's a lot out there to learn!
stcredzero 18y ago
That's strange, I never said anything about the speed of Smalltalk libraries. And actually, I know that some Smalltalk routines have run faster than the same routine implemented in C. By 3% actually. This was over 5 years ago, and it was a block cipher -- yes, low-level bit slinging. The DLL was the RSA reference implementation. (1) Also, you should be careful about reasoning about benchmarks as if they applied the same across the board. Anyone who knows a little about them knows that they are very contextual. BTW, in the Smalltalk community, spelling the language name with a capital T is considered a mark of the PHB. But if you want a Smalltalk library that's much faster than Ruby 1.8, there are a variety of benchmarks around. Just take some of that code, and declare it to be a library. QED. (1) - This is the magic of generational GC. if you know what you're doing, this is like getting a Buffer Cache you didn't even have to implement. Also, the implementor got the help of the VM engineer, who provided primitives for handling 32 and 64 bit arrays.
- sho 18y ago
  Oops, sorry for the faux pas - I thought that it had a capital T - and no idea why I wrote libraries either. I meant VM, or even better, implementation. Sorry, I was tired, and now I've wasted your time defending against something I didn't even mean to say. I was also trying to agree with you about the unreliability of specific benchmarks. I'll try to restate. You said this: "There are Lisp and Smalltalk VMs out there that are something like 70X as fast as Ruby 1.8!" That is what I was trying to argue with. I have never seen any proof, beyond a few cherry-picked examples of Ruby at its worst and Smalltalk at its (presumable) best, where anything like a 70x speed difference is observable. On average, ST (is that ok?) seems to be a mere 5x as fast (or so), coming in at somewhere between 5 and 10 times slower than C. Ruby 1.8 is in the average case around 30x slower than C. So if Smalltalk can be 70x faster than that, then it is generally twice as fast as C, on average, in everyday use. This is not the case, as far as I am aware. I see this "Smalltalk is SO fast" meme again and again but it just doesn't seem to be grounded in reality. Sorry for my idiotic error earlier, and for sounding like a PHB ..
  - stcredzero 18y ago
    True, 70X as fast as in benchmarks doesn't mean that much in the real world, because in real world apps, you are bound by memory use, network, DB backends, disk access, etc. The real gain for Ruby, once there are reliable VMs that have good JIT capabilities is the following: A dynamic web page can then be compiled into a JIT-ed method, with static HTML as data in arrays interspersed function/procedure calls. At this point, you can increase the JIT memory cache so that it can contain your entire web site, and at that point your web pages are machine language routines! VisualWorks has a framework that does this. It's called Smalltalk Server Pages. ST is kosher.

by sho 18y ago

swannodette 18y ago

ever heard of Lisp Flavored Erlang? Ever heard of the Common Lisp Object System (inspired originally by Smalltalk)? Ever heard of Clojure (Haskell inspired STM, and lazy data structures)? ever heard of GOAL (Lisp assembly)? etc., etc. etc., etc., etc.

sho 18y ago
Like above I didn't make myself clear at all. Let me try again, by your leave. I wasn't claiming you can't tack feature X onto lisp, of course you can, you can implement anything in anything. The point I wanted to make was that "power" is not just some object feature bullet points, it's about ease of use and syntax and libraries as well. "If you add Traits (library for Mixins) to Smalltalk, it is equivalent to Ruby in power. (1)" Only for your definition of "power". Yes, everyone loves Ruby's super-flexible objects and mixins etc but that is only the start of the story. Its syntax is terse, intuitive and good-looking. The rubygems packaging system is effective and ubiquitous. Irb is excellent and "live coding" techniques are invaluable. To me, these are very much part of the real "power" and the main reason I prefer it over, say, Python. You might be able to emulate the object behaviour but it's still "incomprehensible mess of brackets" Lisp. You might be able to claim that Lisp is 90% "homomorphically equivalent", a phrase I don't think I've heard since Mathematics 2, but who gives a shit? Go ahead and add the last 10% of whatever it is that Ruby has and Lisp doesn't. Now you have just as much power as Ruby? So go ahead and type "require activerecord" (don't forget to compile!) and just try to tap into that power. Oops. "Language power" is not just some reductive theoretical idea of what features a language has, or could implement. It's the whole package, and how you use it. Sure you can add Ruby's features to C. But a better way is to implement Ruby in it. Lisp might well be the infinitely flexible meta-language which can be used to describe all others, but that isn't actually useful in itself, as used today. Lisp may be an incredibly powerful tool for something, but it has little advantage for conventional end-user code, not any more anyway. It's pretty exciting to think where it might end up, though. "And one could probably take just about any Lisp and give it the power of the other 10% (like Erlang) with moderate effort." Again, only for your definition of "power", which is not what the average programmer who is just interested in getting stuff done is thinking about.
- swannodette 18y ago
  In Ruby can you connect to the running web application and debug it on the fly via a REPL? You can do this with Common Lisp and Clojure (PLT Scheme?). It definitely helps with "getting stuff done."
  - jasonwatkinspdx 18y ago
    Yes.
    - swannodette 18y ago
      You're right, I stand corrected. Interesting that this aspect hasn't been hyped up more when people mention Rails.
- deleted 18y ago
  [deleted]
- stcredzero 18y ago
  You might be able to claim that Lisp is 90% "homomorphically equivalent", a phrase I don't think I've heard since Mathematics 2, but who gives a shit? Well, for those who actually have a little intellectual curiosity, the implications are: 1) Not only can you do anything in langauges X and Y that you do in Ruby, you can express it about as concisely 2) Any libraries in Ruby could be just as beautifully expressed in languages X and Y 3) There's no reason something that closely resembles Ruby but runs *a lot faster* shouldn't exist 4) Speed is just one factor among many. There are lots of other things Ruby could learn from. Sho, there are some who have enormous cognitive dissonance at the thought that their pet language is not the ultimate in the universe. Then there are others that are actually curious about what else is out there, and how the languages they know the most about fit into that continuum. Therein is some valuable and useful information for those who are forward looking. (For the others, Ruby is awesome, it is the ultimate, there shall be nothing better, yada yada. Now you can rest easy.) There has been a bajillion hours of awesome work that's gone into Ruby and Rails. There are ways that Ruby and Rails can be changed such that the next bajillion can be several times more awesome. All I'm saying is -- look around and be curious. There's a lot out there to learn!

stcredzero 18y ago

That's strange, I never said anything about the speed of Smalltalk libraries. And actually, I know that some Smalltalk routines have run faster than the same routine implemented in C. By 3% actually. This was over 5 years ago, and it was a block cipher -- yes, low-level bit slinging. The DLL was the RSA reference implementation. (1) Also, you should be careful about reasoning about benchmarks as if they applied the same across the board. Anyone who knows a little about them knows that they are very contextual. BTW, in the Smalltalk community, spelling the language name with a capital T is considered a mark of the PHB. But if you want a Smalltalk library that's much faster than Ruby 1.8, there are a variety of benchmarks around. Just take some of that code, and declare it to be a library. QED. (1) - This is the magic of generational GC. if you know what you're doing, this is like getting a Buffer Cache you didn't even have to implement. Also, the implementor got the help of the VM engineer, who provided primitives for handling 32 and 64 bit arrays.

sho 18y ago
Oops, sorry for the faux pas - I thought that it had a capital T - and no idea why I wrote libraries either. I meant VM, or even better, implementation. Sorry, I was tired, and now I've wasted your time defending against something I didn't even mean to say. I was also trying to agree with you about the unreliability of specific benchmarks. I'll try to restate. You said this: "There are Lisp and Smalltalk VMs out there that are something like 70X as fast as Ruby 1.8!" That is what I was trying to argue with. I have never seen any proof, beyond a few cherry-picked examples of Ruby at its worst and Smalltalk at its (presumable) best, where anything like a 70x speed difference is observable. On average, ST (is that ok?) seems to be a mere 5x as fast (or so), coming in at somewhere between 5 and 10 times slower than C. Ruby 1.8 is in the average case around 30x slower than C. So if Smalltalk can be 70x faster than that, then it is generally twice as fast as C, on average, in everyday use. This is not the case, as far as I am aware. I see this "Smalltalk is SO fast" meme again and again but it just doesn't seem to be grounded in reality. Sorry for my idiotic error earlier, and for sounding like a PHB ..
- stcredzero 18y ago
  True, 70X as fast as in benchmarks doesn't mean that much in the real world, because in real world apps, you are bound by memory use, network, DB backends, disk access, etc. The real gain for Ruby, once there are reliable VMs that have good JIT capabilities is the following: A dynamic web page can then be compiled into a JIT-ed method, with static HTML as data in arrays interspersed function/procedure calls. At this point, you can increase the JIT memory cache so that it can contain your entire web site, and at that point your web pages are machine language routines! VisualWorks has a framework that does this. It's called Smalltalk Server Pages. ST is kosher.