From: Peter Suk Date: 2005-04-09T16:50:55+09:00 Subject: Re: Seven new VMs, all in a row On Apr 8, 2005, at 8:40 PM, Glenn Parker wrote: > Peter Suk wrote: >> On Apr 8, 2005, at 3:04 PM, Glenn Parker wrote: >>> Peter Suk wrote: >>> >>>> VisualWorks can use real threads, but only in the case of calling >>>> out to a DLL, and these contexts are exempt from GC. >>> >>> Well, that's a major hole, isn't it? >> There is clearly some kind of disconnect here. Are you expecting >> that the DLL be subject to Ruby GC & memory management? Are you >> saying it's some kind of "hole" that the context which is doing the >> call-out is not being GC'd for the duration of the call? > > Perhaps there is a disconnect, but I didn't think I was that obtuse. > > You said VW can use real threads, but only in the case of calling out > to a DLL, and no GC. To me, that strongly suggests that the code > executing in the real threads uses some traditional compiled language > with manual memory management, e.g. C. If that is the price for > getting real threads, it's not very attractive to me. If I have > misunderstood, then please explain further. Why is it that you'd want real threads? What can real threads do that Ruby VM threads can't do? The answer is synchronous calls out to OS services. (As well as utilizing multiple processors, but that's another issue.) >>> And I suspect today's Ruby has pretty much the same "feature" as >>> VisualWorks in this regard, that is to say I could create a Ruby DLL >>> that spawned real threads and let them do their own memory >>> management. >> Please re-read my message. Your response doesn't make any sense at >> all, especially with the 2nd sentence -- unless I am missing out on >> something. > > Well, maybe you're missing something, or maybe I need more help > understanding the VW technology. I've read all your messages and I > think I understand the general proposal, which is quite intriguing, or > I wouldn't waste my time on it. In general, DLLs that you call out to are doing their own memory management. At least I hope so, or they're going to be a source of memory leaks. >> And please, stop this stupid "our X is better than yours" nonsense. >> Such pride is misplaced on a particular VM/Language/paradigm. I am >> here to share what the Smalltalk world has been acruing for some >> time, and am prepared to go through a lot of effort to do it. > > Let's get one thing clear, I don't give a fig for language wars. > Smalltalk has obviously solved a lot of problems that Ruby still > struggles with, but it hasn't necessarily solved them in the way that > makes sense for Ruby. So, please pardon me if I "look a gift horse in > the mouth". Your willingness to invest your time and skills is > noteworthy, but it doesn't mean that a Smalltalk VM is the ultimate > answer for Ruby. Goodness knows, I'd love to see you deliver on the > promise of your proposal, because I think Ruby needs a radical > performance upgrade. > > I don't know if I can convince you of this, but I'm trying to ask some > sincere and probing questions about your proposal. This kind of > probing is exactly what you invited by announcing your plans here. > Why act so surprised when you get a bunch of naive Smalltalk questions > from a group of Ruby folk, anyway? I need to get used to the idea that not every implication of everything I post here is going to be fully appreciated. Ruby has some great attributes. But it is not the first to have these! If you look under the covers, Smalltalk and Ruby are very alike. Startlingly alike. Ruby makes some design decisions which sacrifice performance in exchange for implementation & programmer convenience. But these differences are really not that big a deal. At bottom, both environments use the "everything is an object" principle. At bottom, everything is just messages sent to objects. Everything is dynamic, and there is no "compile-time vs. runtime" divide. I appreciate the sincere and probing questions. I must admit to losing patience with questions that are not well informed. Especially those that are not "sincere." (i.e. really motivated by a "language wars" mentality.) However in retrospect, you don't fall into this last category. --Peter -- There's neither heaven nor hell, save what we grant ourselves. There's neither fairness nor justice, save what we grant each other.