Re: [fonc] Deoptimization as fallback
When we speak of separating meaning from optimization, I get the impression we want to automate the optimization. In that case, we should validate the optimizer(s). But you seem to be assuming hand-optimized code with a (simplified) reference implementation. That's a pretty good pattern for validation and debugging, and I've seen it used several times (most recently in a library called 'reactive banana', and most systematically in Goguen's BOBJ). But I've never seen it used as a fallback. (I have heard of cases of systematically running multiple implementations and comparing them for agreement, e.g. with airbus.) On Tue, Jul 30, 2013 at 6:08 PM, Casey Ransberger casey.obrie...@gmail.comwrote: Hi David, comments below. On Jul 30, 2013, at 5:46 PM, David Barbour dmbarb...@gmail.com wrote: I'm confused about what you're asking. If you apply an optimizer to an algorithm, it absolutely shouldn't affect the output. When we debug or report errors, it should always be in reference to the original source code. Or do you mean some other form of 'optimized'? I might rephrase your question in terms of 'levels of service' and graceful degradation (e.g. switching from video conferencing to teleconferencing gracefully if it turns out the video uses too much bandwidth), then there's a lot of research there. One course I took - survivable networks and systems - heavily explored that subject, along with resilience. Resilience involves quickly recovering to a better level of service once the cause for the fault is removed (e.g. restoring the video once the bandwidth is available). Achieving ability to fall back gracefully can be a challenge. Things can go wrong many more ways than they can go right. Things can break in many more ways than they can be whole. A major issue is 'partial failure' - because partial failure means partial success. Often some state has been changed before the failure occurs. It can be difficult to undo those changes. So I'm talking about the steps goal around separating meaning from optimization. The reason we don't have to count optimizations as a part of our complexity count is: the system can work flawlessly without them, it might just need a lot of RAM and a crazy fast CPU(s) to do it. The thought I had was just this: complex algs tend to have bugs more often than simple algs. So why not fail over if you have an architecture that always contains the simplest solution to the problem right *beside* the optimal solution that makes it feasible on current hardware? Of course you're right, I can imagine there being lots of practical problems with doing things this way, especially if you've got an e.g. Google sized fleet of machines all switching to a bubble sort at the same time! But it's still an interesting question to my mind, because one of the most fundamental questions I can ask is how do I make these systems less brittle? Does this clarify what I was asking about? Case ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Deoptimization as fallback
On Wed, Jul 31, 2013 at 4:26 PM, David Barbour dmbarb...@gmail.com wrote: When we speak of separating meaning from optimization, I get the impression we want to automate the optimization. In that case, we should validate the optimizer(s). But you seem to be assuming hand-optimized code with a (simplified) reference implementation. That's a pretty good pattern for validation and debugging, and I've seen it used several times (most recently in a library called 'reactive banana', and most systematically in Goguen's BOBJ). True, though IME, the reference implemention is given in a different language (in fact I've never seen it in the same language but I'll check out your examples). I always hated that (it's so simple to do certain things in, say, R or Octave, for example, yet so difficult to port to production code), and I think is the reason the idea has not been used as a fallback but only for validation and debugging. -- Fernando Cacciola SciSoft Consulting, Founder http://www.scisoft-consulting.com ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Deoptimization as fallback
On 30 July 2013 16:22, Casey Ransberger casey.obrie...@gmail.com wrote: I was thinking: if a system happens to be running an optimized version of some algorithm, and hit a crash bug, what if it could fall back to the suboptimal but conceptually simpler Occam's explanation? This is something the Erlang folk have said repeatedly for a long time now. They claim that upon crashing, the idea of backing off and trying something simpler is part of the Erlang way. However, I don't recall seeing any concrete support for this in OTP. The simpler idea of supervisors and hierarchical crashing-and-restarting larger and larger subunits of the system seems to be what's actually predominantly used. Tony -- Tony Garnock-Jones tonygarnockjo...@gmail.com http://homepages.kcbbs.gen.nz/tonyg/ ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Deoptimization as fallback
Fundamentals means the fundamentals, not existing programming languages and paradigms. Fundamentals means the fundamentals, not your troubleshooting for your current job. Use the list for what it's said to be for. On Tue, Jul 30, 2013 at 1:43 PM, Tony Garnock-Jones tonygarnockjo...@gmail.com wrote: On 30 July 2013 16:22, Casey Ransberger casey.obrie...@gmail.com wrote: I was thinking: if a system happens to be running an optimized version of some algorithm, and hit a crash bug, what if it could fall back to the suboptimal but conceptually simpler Occam's explanation? This is something the Erlang folk have said repeatedly for a long time now. They claim that upon crashing, the idea of backing off and trying something simpler is part of the Erlang way. However, I don't recall seeing any concrete support for this in OTP. The simpler idea of supervisors and hierarchical crashing-and-restarting larger and larger subunits of the system seems to be what's actually predominantly used. Tony -- Tony Garnock-Jones tonygarnockjo...@gmail.com http://homepages.kcbbs.gen.nz/tonyg/ ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Deoptimization as fallback
John - that discussion strikes me as perfectly suitable for this list. And your comment doesn't. - Original Message - From: Fundamentals of New Computing To:Fundamentals of New Computing Cc: Sent:Tue, 30 Jul 2013 14:49:35 -0700 Subject:Re: [fonc] Deoptimization as fallback Fundamentals means the fundamentals, not existing programming languages and paradigms. Fundamentals means the fundamentals, not your troubleshooting for your current job. Use the list for what it's said to be for. On Tue, Jul 30, 2013 at 1:43 PM, Tony Garnock-Jones wrote: On 30 July 2013 16:22, Casey Ransberger wrote: I was thinking: if a system happens to be running an optimized version of some algorithm, and hit a crash bug, what if it could fall back to the suboptimal but conceptually simpler Occam's explanation? This is something the Erlang folk have said repeatedly for a long time now. They claim that upon crashing, the idea of backing off and trying something simpler is part of the Erlang way. However, I don't recall seeing any concrete support for this in OTP. The simpler idea of supervisors and hierarchical crashing-and-restarting larger and larger subunits of the system seems to be what's actually predominantly used. Tony -- Tony Garnock-Jones tonygarnockjo...@gmail.com [3] http://homepages.kcbbs.gen.nz/tonyg/ [4] ___ fonc mailing list fonc@vpriorg [5] http://vpri.org/mailman/listinfo/fonc [6] Links: -- [1] mailto:tonygarnockjo...@gmail.com [2] mailto:casey.obrie...@gmail.com [3] mailto:tonygarnockjo...@gmail.com [4] http://homepages.kcbbs.gen.nz/tonyg/ [5] mailto:fonc@vpri.org [6] http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Deoptimization as fallback
This is how Smalltalk has always treated its primitives, etc. Cheers, Alan From: Casey Ransberger casey.obrie...@gmail.com To: Fundamentals of New Computing fonc@vpri.org Sent: Tuesday, July 30, 2013 1:22 PM Subject: [fonc] Deoptimization as fallback Thought I had: when a program hits an unhandled exception, we crash, often there's a hook to log the crash somewhere. I was thinking: if a system happens to be running an optimized version of some algorithm, and hit a crash bug, what if it could fall back to the suboptimal but conceptually simpler Occam's explanation? All other things being equal, the simple implementation is usually more stable than the faster/less-RAM solution. Is anyone aware of research in this direction? ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Deoptimization as fallback
Dick around with kids toys and make ugly crap, Kay. On Jul 30, 2013, at 3:40 PM, Alan Kay wrote: This is how Smalltalk has always treated its primitives, etc. Cheers, Alan From: Casey Ransberger casey.obrie...@gmail.com To: Fundamentals of New Computing fonc@vpri.org Sent: Tuesday, July 30, 2013 1:22 PM Subject: [fonc] Deoptimization as fallback Thought I had: when a program hits an unhandled exception, we crash, often there's a hook to log the crash somewhere. I was thinking: if a system happens to be running an optimized version of some algorithm, and hit a crash bug, what if it could fall back to the suboptimal but conceptually simpler Occam's explanation? All other things being equal, the simple implementation is usually more stable than the faster/less-RAM solution. Is anyone aware of research in this direction? ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Deoptimization as fallback
Your list is utterly useless, you have no chance of doing anything. If there is no Steve Jobs, it is just kids toys and mamby pamby construvist learning bullshit. On Jul 30, 2013, at 3:40 PM, Alan Kay wrote: This is how Smalltalk has always treated its primitives, etc. Cheers, Alan From: Casey Ransberger casey.obrie...@gmail.com To: Fundamentals of New Computing fonc@vpri.org Sent: Tuesday, July 30, 2013 1:22 PM Subject: [fonc] Deoptimization as fallback Thought I had: when a program hits an unhandled exception, we crash, often there's a hook to log the crash somewhere. I was thinking: if a system happens to be running an optimized version of some algorithm, and hit a crash bug, what if it could fall back to the suboptimal but conceptually simpler Occam's explanation? All other things being equal, the simple implementation is usually more stable than the faster/less-RAM solution. Is anyone aware of research in this direction? ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Deoptimization as fallback
I want to expose Alan Kay's cynicism in the statement you'll rule the world with the iPad This is actually his cynicism toward's Steve Jobs' will to power and is not well-intentioned. On Jul 30, 2013, at 3:40 PM, Alan Kay wrote: This is how Smalltalk has always treated its primitives, etc. Cheers, Alan From: Casey Ransberger casey.obrie...@gmail.com To: Fundamentals of New Computing fonc@vpri.org Sent: Tuesday, July 30, 2013 1:22 PM Subject: [fonc] Deoptimization as fallback Thought I had: when a program hits an unhandled exception, we crash, often there's a hook to log the crash somewhere. I was thinking: if a system happens to be running an optimized version of some algorithm, and hit a crash bug, what if it could fall back to the suboptimal but conceptually simpler Occam's explanation? All other things being equal, the simple implementation is usually more stable than the faster/less-RAM solution. Is anyone aware of research in this direction? ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Deoptimization as fallback
John, I really don't think this list is for you. Jason On Tue, Jul 30, 2013 at 4:51 PM, John Pratt jpra...@gmail.com wrote: The problem is that Alan Kay is a passive-aggressive twerp who can't reply directly to people. On Jul 30, 2013, at 3:49 PM, Casey Ransberger wrote: Below. On Jul 30, 2013, at 2:49 PM, John Pratt jpra...@gmail.com wrote: Fundamentals means the fundamentals, not your troubleshooting for your current job. My business card presently says Arranger Session Player, so there's no real threat of that right now:P Anyway I can get off topic at times, just like everyone else, and while I do think this inquiry was right on the money for the list, you've got every right to think it wasn't, so thanks for doing your part to keep the dialogue topical, John. --Casey Ransberger Arranger Session Player ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Deoptimization as fallback
It's true, I actually do things. On Jul 30, 2013, at 4:53 PM, Jason Ives wrote: John, I really don't think this list is for you. Jason On Tue, Jul 30, 2013 at 4:51 PM, John Pratt jpra...@gmail.com wrote: The problem is that Alan Kay is a passive-aggressive twerp who can't reply directly to people. On Jul 30, 2013, at 3:49 PM, Casey Ransberger wrote: Below. On Jul 30, 2013, at 2:49 PM, John Pratt jpra...@gmail.com wrote: Fundamentals means the fundamentals, not your troubleshooting for your current job. My business card presently says Arranger Session Player, so there's no real threat of that right now:P Anyway I can get off topic at times, just like everyone else, and while I do think this inquiry was right on the money for the list, you've got every right to think it wasn't, so thanks for doing your part to keep the dialogue topical, John. --Casey Ransberger Arranger Session Player ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Deoptimization as fallback
I'm confused about what you're asking. If you apply an optimizer to an algorithm, it absolutely shouldn't affect the output. When we debug or report errors, it should always be in reference to the original source code. Or do you mean some other form of 'optimized'? I might rephrase your question in terms of 'levels of service' and graceful degradation (e.g. switching from video conferencing to teleconferencing gracefully if it turns out the video uses too much bandwidth), then there's a lot of research there. One course I took - survivable networks and systems - heavily explored that subject, along with resilience. Resilience involves quickly recovering to a better level of service once the cause for the fault is removed (e.g. restoring the video once the bandwidth is available). Achieving ability to fall back gracefully can be a challenge. Things can go wrong many more ways than they can go right. Things can break in many more ways than they can be whole. A major issue is 'partial failure' - because partial failure means partial success. Often some state has been changed before the failure occurs. It can be difficult to undo those changes. On Tue, Jul 30, 2013 at 1:22 PM, Casey Ransberger casey.obrie...@gmail.comwrote: Thought I had: when a program hits an unhandled exception, we crash, often there's a hook to log the crash somewhere. I was thinking: if a system happens to be running an optimized version of some algorithm, and hit a crash bug, what if it could fall back to the suboptimal but conceptually simpler Occam's explanation? All other things being equal, the simple implementation is usually more stable than the faster/less-RAM solution. Is anyone aware of research in this direction? ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Deoptimization as fallback
On Tue, Jul 30, 2013 at 1:22 PM, Casey Ransberger casey.obrie...@gmail.comwrote: Thought I had: when a program hits an unhandled exception, we crash, often there's a hook to log the crash somewhere. I was thinking: if a system happens to be running an optimized version of some algorithm, and hit a crash bug, what if it could fall back to the suboptimal but conceptually simpler Occam's explanation? All other things being equal, the simple implementation is usually more stable than the faster/less-RAM solution. Is anyone aware of research in this direction? This sounds fairly close to compiler deoptimization, which is fairly common in just-in-time compiler technology (see v8, the self system, probably jvms do it also ...). Perhaps you could start there? http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.4338 http://www.cs.ucsb.edu/~urs/oocsb/self/papers/dynamic-deoptimization.html -- Dirk ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
