> But let me put this straight: as an open-source project, we are hesitant to > accept changes which depend on closed software. Even if your optimization > techniques would result in performance a hundred times better than what is > currently achieved, we would still be wary to accept them. > > Please note that this is not because of lack of trust or better yet greed > for your code. We need to make sure > that under no circumstances our codebase is in danger because something > important was left out along the way. > I am positive that the code generator does not depend on any closed source components, I just juse mako for storing the C code templates that I generate -- everything else I wrote myself. Of course, I'll give the code generator to pydev, too, if necessary. However, I need to strip it down, so that it does not do all the other stuff that you don't need. I just wanted to give you the implementation now, since Benjamin said that he wants to see real code and results first. If you want to integrate the inca-optimization, I am going to start working on this asap.
> Maintenance of generated code is yet another nuissance that should better be > strongly justified. > I agree, but the nice thing is that the technique is very simple: only if you changed a significant part of the interpreter implementation's, you'd need to change the optimized derivatives, too. If one generates the default interpreter implementation, too, then one gets the optimizations almost for free. For maintenance reasons I chose to use a template-based system, too, since this gives you a direct correspondence between the actual code and what's generated, without interfering with the code generator at all. --stefan _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
