4 ms·

Neat! I'll probably be around for the alumni week in May at Recurse Center, and maybe we could get to chat then. For optimization I guess it comes down to maki

Neat! I'll probably be around for the alumni week in May at Recurse Center, and maybe we could get to chat then. For optimization I guess it comes down to making productive restrictions on the Python dialect to rule out some of the extreme dynamism. This sounds like a really cool project, one that's too big for me to have much idea what'd help without investing more time. What you're doing in stripping down CPython reminds me a little of how Luke Gorrie's started adapting LuaJIT to his own purposes: https://github.com/raptorjit/raptorjit https://github.com/raptorjit/raptorjit

chubot 9y ago
I'm going to the summer batch from May 21st to August 8th, and hopefully by then I will have made more progress. Definitely let me know if you are around then! Yeah I agree that you want to remove dynamism. For something like BINARY_ADD, the operands will only be strings or numbers in a parser. You can cheat and just assume there is no operator overloading. Although I don't know how much that will actually speed things up! I should make a profile at the C level. I have profiled at the Python level and sped things up 6-7x already. The other thing I think will help is using something like spans/slices instead of strings. Parsing creates all these tiny string objects. And also as I mentioned changing the representations of the nodes, which is a fairly naive Python representation now. Python objects are huge! ----- I didn't know about raptorjit, but I had heard of Snabb Switch awhile ago on Hacker News. It looks interesting! It reminds me of the Dart language being inspired by v8. The problem with v8 is that you can change one line in JS and your performance will just fall off a cliff. It's hard to detect unless you write benchmarks, which most people don't. So Lars Bak started Dart to remedy that problem, designing the language around stable JIT performance!
- abecedarius 9y ago
  The size of Python objects is kind of shocking, yeah. I wonder how hard it'd be to at least get rid of the refcount. I like your idea of using slices. So, a new PyObject subtype that pretends to be a string but holds a couple of indices and a pointer to the 'real' string? I guess you could leave the latter implicit, hopefully. There's a good chance I'll still be around in late May. See you then!
  - chubot 9y ago
    OK great, looking forward to it! I mapped out the work the other day and it looks fun. It's just at the edge of my knowledge.
yorwba 9y ago
In my experience, most uses for dynamism in Python are concentrated at initialization time. Features that make dynamic changes like namedtuple or decorators are usually only executed once when a module is imported and essentially implement a kind of code-generation that directly creates the intended objects. I wonder whether it might be feasible to import a Python module (running all the initialization code) and then walk the reachable object graph to serialize it into code in a more static subset.
- chubot 9y ago
  Yes absolutely! I've long been interested in multi-stage programming for this reason. Oil is filled with this pattern: do a bunch of metaprogramming at startup to make some data. Then use that immutable data for the rest of the program. There are very much two stages. I think Lua-Terra might be closest to the thing I want, although I haven't had a chance to play with it: http://terralang.org/ http://terralang.org/ I mention Bob Nystrom's language Magpie, which has an interesting model. Do the type checking at main(), not after parsing! But everything that happens before main(), at import time, is metaprogramming! A Problem with Type Checking http://www.oilshell.org/blog/2016/11/30.html http://www.oilshell.org/blog/2016/11/30.html I think I want to do compilation/optimization right before main(), not just type checking. It's all a bit vague right now, but I think OPy can go in this direction. Having the compiler written in its own language facilitates this. You can run code first, and then compile. This post is also related: Type Checking vs. Metaprogramming; ML vs. Lisp http://www.oilshell.org/blog/2016/12/05.html http://www.oilshell.org/blog/2016/12/05.html Also note that C++ is a two-stage language too. In fact Herb Sutter just proposed that they unify the two languages. Like you can use STL with constexpr at compile time. Link on this page: https://github.com/oilshell/oil/wiki/Metaprogramming https://github.com/oilshell/oil/wiki/Metaprogramming I think your suggestion is exactly what I've been thinking, so if you want to talk more about it / work on it, feel free to mail me :) The code needs a bit of work but I think it's a promising direction.

chubot 9y ago

I'm going to the summer batch from May 21st to August 8th, and hopefully by then I will have made more progress. Definitely let me know if you are around then! Yeah I agree that you want to remove dynamism. For something like BINARY_ADD, the operands will only be strings or numbers in a parser. You can cheat and just assume there is no operator overloading. Although I don't know how much that will actually speed things up! I should make a profile at the C level. I have profiled at the Python level and sped things up 6-7x already. The other thing I think will help is using something like spans/slices instead of strings. Parsing creates all these tiny string objects. And also as I mentioned changing the representations of the nodes, which is a fairly naive Python representation now. Python objects are huge! ----- I didn't know about raptorjit, but I had heard of Snabb Switch awhile ago on Hacker News. It looks interesting! It reminds me of the Dart language being inspired by v8. The problem with v8 is that you can change one line in JS and your performance will just fall off a cliff. It's hard to detect unless you write benchmarks, which most people don't. So Lars Bak started Dart to remedy that problem, designing the language around stable JIT performance!

abecedarius 9y ago
The size of Python objects is kind of shocking, yeah. I wonder how hard it'd be to at least get rid of the refcount. I like your idea of using slices. So, a new PyObject subtype that pretends to be a string but holds a couple of indices and a pointer to the 'real' string? I guess you could leave the latter implicit, hopefully. There's a good chance I'll still be around in late May. See you then!
- chubot 9y ago
  OK great, looking forward to it! I mapped out the work the other day and it looks fun. It's just at the edge of my knowledge.

yorwba 9y ago

In my experience, most uses for dynamism in Python are concentrated at initialization time. Features that make dynamic changes like namedtuple or decorators are usually only executed once when a module is imported and essentially implement a kind of code-generation that directly creates the intended objects. I wonder whether it might be feasible to import a Python module (running all the initialization code) and then walk the reachable object graph to serialize it into code in a more static subset.

chubot 9y ago
Yes absolutely! I've long been interested in multi-stage programming for this reason. Oil is filled with this pattern: do a bunch of metaprogramming at startup to make some data. Then use that immutable data for the rest of the program. There are very much two stages. I think Lua-Terra might be closest to the thing I want, although I haven't had a chance to play with it: http://terralang.org/ http://terralang.org/ I mention Bob Nystrom's language Magpie, which has an interesting model. Do the type checking at main(), not after parsing! But everything that happens before main(), at import time, is metaprogramming! A Problem with Type Checking http://www.oilshell.org/blog/2016/11/30.html http://www.oilshell.org/blog/2016/11/30.html I think I want to do compilation/optimization right before main(), not just type checking. It's all a bit vague right now, but I think OPy can go in this direction. Having the compiler written in its own language facilitates this. You can run code first, and then compile. This post is also related: Type Checking vs. Metaprogramming; ML vs. Lisp http://www.oilshell.org/blog/2016/12/05.html http://www.oilshell.org/blog/2016/12/05.html Also note that C++ is a two-stage language too. In fact Herb Sutter just proposed that they unify the two languages. Like you can use STL with constexpr at compile time. Link on this page: https://github.com/oilshell/oil/wiki/Metaprogramming https://github.com/oilshell/oil/wiki/Metaprogramming I think your suggestion is exactly what I've been thinking, so if you want to talk more about it / work on it, feel free to mail me :) The code needs a bit of work but I think it's a promising direction.