To GC or to Recycle?
Locked
 
|
For completeness another big reason for traffic accidents is socializing. One can get so distracted by other people in the car or on cell phones that they pay too much attention to their social interaction and not enough to the road resulting in an accident. That is an illustration of what we are talking about with Garbage Collection. We have the dynamic of GC to clean up after playing to develop something in Smalltalk. What if instead we ask the VM builder, Elliot, to add a switch to go from dynamic GC mode to static or compiled mode where all objects do not get GC'd but recycled? So for example, if an application drags lots of data from disk into memory, the new data objects reuse the same object pointer headers as before? In other words, in compiler mode there would be no new objects.
This switch would allow Smalltalkers to play all they want creating new objects like now but when they want to deploy a time sensitive end user application like a self-driving car, they flip the switch and the VM treats the code as another language would treat .exe's. This could in effect supply all the advantages Python, Java, and other .exe producing languages have without a lot of work except one primitive call. Plus the Smalltalk playground could become available again with another flip of the switch.
Kirk W. Fraser _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
Sorry, I don't understand. Not sure what the advantages of Java and Python really are. I mean, Java is painfully limiting but well documented. It has what's probably the most strongly invested-in VM in history. Python, on the other hand, has a totally decent VM and is also very well documented.
We aren't. I think that's our big weak point. But I don't think that the supposed real-time advantages of these systems exist. If they do, a cursory examination of how they're done should provide insight into how to do the same thing (with less code!) using the Squeak infrastructure. It's already possible to incorporate manual or "unmanaged" code with the Cog infrastructure. You can do it with the interpreter, and you can do it with the stack VM too. You can do that with C code, Slang, or assembler via Igor Stasenko's NativeBoost. You can do it with FFI. You can even kick it off with OSProcess at the OS level. What's the problem you're actually trying to solve? Is it possible that you see things missing that really aren't missing at all? Are you certain that you've researched the things you're interested in enough such that you don't end up reinventing the wheel? Because it really sounds to me like -- if you spent a bit more time reading -- you'd find that most of the obstacles you perceive between you and your goal are either a) already solved, b) non-existent, or c) the same problems everyone has, regardless of language, VM, or anything else. I don't mean to be cruel here, not at all, in fact I mean to be as kind, welcoming, and supportive as I can be, but you have to actually read and try to understand the things people point you at before continuing to make arguments in debt of the information contained therein, unless you want people to write you off. I don't want to write you off. Please at least read the Back to the Future article, Tim Rowledge's tour of the object system, and David Ungar's paper about garbage collection. Then come back, understanding the material, and we can talk about other things worth reading, given the goals you're expressing. Otherwise we're just going to waste the list's time with me repeating that I've *already* told you where to start looking for the answers to your questions. You don't want to be hit with the Andreas Stick, which involves reading a longish essay about what constitutes a smart question and why. Trust me :D Casey > On Dec 19, 2013, at 4:26 AM, Kirk Fraser <[hidden email]> wrote: > > For completeness another big reason for traffic accidents is socializing. One can get so distracted by other people in the car or on cell phones that they pay too much attention to their social interaction and not enough to the road resulting in an accident. That is an illustration of what we are talking about with Garbage Collection. We have the dynamic of GC to clean up after playing to develop something in Smalltalk. What if instead we ask the VM builder, Elliot, to add a switch to go from dynamic GC mode to static or compiled mode where all objects do not get GC'd but recycled? So for example, if an application drags lots of data from disk into memory, the new data objects reuse the same object pointer headers as before? In other words, in compiler mode there would be no new objects. > > This switch would allow Smalltalkers to play all they want creating new objects like now but when they want to deploy a time sensitive end user application like a self-driving car, they flip the switch and the VM treats the code as another language would treat .exe's. This could in effect supply all the advantages Python, Java, and other .exe producing languages have without a lot of work except one primitive call. Plus the Smalltalk playground could become available again with another flip of the switch. > > Kirk W. Fraser > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
On 19 December 2013 14:08, Casey Ransberger <[hidden email]> wrote:
> Sorry, I don't understand. Not sure what the advantages of Java and Python really are. I mean, Java is painfully limiting but well documented. It has what's probably the most strongly invested-in VM in history. Python, on the other hand, has a totally decent VM and is also very well documented. > > We aren't. I think that's our big weak point. > > But I don't think that the supposed real-time advantages of these systems exist. If they do, a cursory examination of how they're done should provide insight into how to do the same thing (with less code!) using the Squeak infrastructure. Azul implemented a soft real-time GC for their JVM. It _can_ be done, it's just expensive. The more important question is: why bother? You're not implementing a rocket engine control module, you're automating a car. In other words, we're talking about human reaction times, and a 100 ms total complete shutdown of all processing is still _twice as fast_ as a human's _mental_ reaction, never mind the latencies involved in depressing brake pedals. It's not even worth thinking about GC until you have a working prototype that you can measure. (Because, if it turned out that Smalltalk's GC wasn't fast enough (or Eliot's Spur, because that might well be ready before the first prototype), your code base would be high level and clean enough to automatically translate to something else.) > Because it really sounds to me like -- if you spent a bit more time reading -- you'd find that most of the obstacles you perceive between you and your goal are either a) already solved, b) non-existent, or c) the same problems everyone has, regardless of language, VM, or anything else. This. > Casey > >> On Dec 19, 2013, at 4:26 AM, Kirk Fraser <[hidden email]> wrote: >> >> For completeness another big reason for traffic accidents is socializing. One can get so distracted by other people in the car or on cell phones that they pay too much attention to their social interaction and not enough to the road resulting in an accident. That is an illustration of what we are talking about with Garbage Collection. We have the dynamic of GC to clean up after playing to develop something in Smalltalk. What if instead we ask the VM builder, Elliot, to add a switch to go from dynamic GC mode to static or compiled mode where all objects do not get GC'd but recycled? So for example, if an application drags lots of data from disk into memory, the new data objects reuse the same object pointer headers as before? In other words, in compiler mode there would be no new objects. >> >> This switch would allow Smalltalkers to play all they want creating new objects like now but when they want to deploy a time sensitive end user application like a self-driving car, they flip the switch and the VM treats the code as another language would treat .exe's. This could in effect supply all the advantages Python, Java, and other .exe producing languages have without a lot of work except one primitive call. Plus the Smalltalk playground could become available again with another flip of the switch. >> >> Kirk W. Fraser _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
I think the real lesson here is: you really need a prototype that fails in some respect in order to discern what technologies are inappropriate to a fully realized product. If we take this as a given, it would seem that the solution which provides the prototype most quickly is the prototyping tool to use, would it not? In many, many cases, Smalltalk will leave you with a prototype in less time than anything else on the market, assuming you've learned to use its tools to their effect. In most cases, it will even be performant enough to deliver a final product based on the prototype. If it doesn't? Oh well? The automotive industry usually needs to go to task a decade in advance of a new idea because *so much* testing must be done in order to ensure good safety for consumers. If you're Google, you can get away with Python because you can throw an army of engineers at the problem. If you're Kirk Fraser? I bet the advantages provided by the interactive programming environment will be an asset that few other languages can provide. Given that you've already expressed a preference for working with the language, why not get started with building that dream car?
If you haven't got a prototype yet, build one, as quickly as you can. Drive a remote-controlled car with it. I don't mean to be patronizing at all when I say that NXT Talk coupled with Lego's robotics prototyping kit is absolutely appropriate to proving ideas in this space! Prove the concept. If you can prove the concept, *then* you'll be in a position to choose the correct implementation vehicle for the final product, and you'll have funding to get it done, because you'll have *proof,* which is SO much more powerful than speculation.
Casey On Thu, Dec 19, 2013 at 6:13 AM, Frank Shearar <[hidden email]> wrote:
_______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
«
Return to Cuis Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |