4 ms·

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,

by 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.
- sho 18y ago
  Look, no. I am not talking about "real world" bottlenecks like disks, databases, etc. I am talking about ideal mainstream applications written in community-accepted idiomatic code, no external bottlenecks. Smalltalk will still not be 70x faster, no way, no how. If it was, it would be faster - much faster - than C, and if that was the case, games, graphics drivers, hell, operating systems - would be using Smalltalk. They are not. QED. Smalltalk is great and its VMs are highly advanced. I accept that. I still use Ruby and eat the performance cost because I prefer its syntax and "world". But man, let's keep the performance comparisons grounded in reality. 70x faster is ludicrous.
  - stcredzero 18y ago
    So long we we're saying, "Look, no I am not talking about..." My point is that VMs that have been around for decades capable of supporting languages of equivalent power, and that these are some silly multiplier faster than Ruby 1.8. This is going to be something like halfway to two orders of magnitude for some silly benchmarks, and much less in real life. Really, there's not much of a problem in practice, especially with the embarrassing wealth we have lying around in terms of processing power. The real problem -- the thing I am making a point about -- is people going around saying that, "Oh well, you have to give something up to get the power..." No. You. Do. Not! Ruby is not that advanced. Yes, I would say that it's a lovely language. It has everything I want, but it's not doing anything that hasn't been done before. It's unique in that it combines lots of elements in a way that's really dandy, but there's nothing magic about it. There's certainly nothing so esoteric, that it couldn't be made to run fast. (There are a few things that were just bad design decisions, like making every Object behave like a little hashtable, which could've been left out and made it much easier to run faster without losing power and expressiveness.) Oh, and people did implement OSes in Smalltalk and Lisp way back when. Also, ever hear about something called Singularity? That's a recent OS built on top of a VM. In fact, I think that more people should be doing just that -- building OSes that are "turtles all the way down" and built to not only support a particular VM, but to have every single atom of it available to tweaking by a high-level language. (Lua would be great for this.) But this is a digression. Again, going back to my original point -- the real ludicrous thing is that the programmer community as a whole is still in the thrall of expectations about speed vs. programming language power that date from the 70s. And anyone who thinks you have to give up as much speed as Ruby has to get that power is very much in the thrall of such an idea.

by sho 18y ago

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.

sho 18y ago
Look, no. I am not talking about "real world" bottlenecks like disks, databases, etc. I am talking about ideal mainstream applications written in community-accepted idiomatic code, no external bottlenecks. Smalltalk will still not be 70x faster, no way, no how. If it was, it would be faster - much faster - than C, and if that was the case, games, graphics drivers, hell, operating systems - would be using Smalltalk. They are not. QED. Smalltalk is great and its VMs are highly advanced. I accept that. I still use Ruby and eat the performance cost because I prefer its syntax and "world". But man, let's keep the performance comparisons grounded in reality. 70x faster is ludicrous.
- stcredzero 18y ago
  So long we we're saying, "Look, no I am not talking about..." My point is that VMs that have been around for decades capable of supporting languages of equivalent power, and that these are some silly multiplier faster than Ruby 1.8. This is going to be something like halfway to two orders of magnitude for some silly benchmarks, and much less in real life. Really, there's not much of a problem in practice, especially with the embarrassing wealth we have lying around in terms of processing power. The real problem -- the thing I am making a point about -- is people going around saying that, "Oh well, you have to give something up to get the power..." No. You. Do. Not! Ruby is not that advanced. Yes, I would say that it's a lovely language. It has everything I want, but it's not doing anything that hasn't been done before. It's unique in that it combines lots of elements in a way that's really dandy, but there's nothing magic about it. There's certainly nothing so esoteric, that it couldn't be made to run fast. (There are a few things that were just bad design decisions, like making every Object behave like a little hashtable, which could've been left out and made it much easier to run faster without losing power and expressiveness.) Oh, and people did implement OSes in Smalltalk and Lisp way back when. Also, ever hear about something called Singularity? That's a recent OS built on top of a VM. In fact, I think that more people should be doing just that -- building OSes that are "turtles all the way down" and built to not only support a particular VM, but to have every single atom of it available to tweaking by a high-level language. (Lua would be great for this.) But this is a digression. Again, going back to my original point -- the real ludicrous thing is that the programmer community as a whole is still in the thrall of expectations about speed vs. programming language power that date from the 70s. And anyone who thinks you have to give up as much speed as Ruby has to get that power is very much in the thrall of such an idea.