I am curious, in what ways does Cython not meet your needs? I think it would be beneficial to know, in order to identify areas which Cython needs to be improved in order to be more useful in real world projects.
I have not done a great deal of work in Cython yet, but my perception is that with Cython, you should be able to write in Python, modify the Python with augmenting .pxd files, and get close to the equivalent speed of C code. So I am curious if: 1. My theoretical view of Cython is flawed. Or... 2. Practice currently has not caught up to theory. Or... 3. Cython is not intended to address your specific situation, and I have misunderstood your intentions and goals. On Jul 2, 2010, at 8:57 AM, Luiji Maryo <[email protected]> wrote: > Responses to Stefan Behnel: > > I do know the goal is ambitious, but less then you probably think. > Let me clarify and say that I am only optimizing modules that will > benefit, such as the mathematical libraries. Libraries such as Tk can > be left alone, since they are simply wrappers for the Tk native > library (IIRC). > > As for project background, this has to do with an argument with > colleges of mine. We wanted to make a game, and I brought up the > greatness of Python, but they said that it would be too slow for game > development. Even though it is sufficiently fast, the game we were > working on was very graphics intensive and when comparing a C version > to a Python version of basic design philosophy C was noticably faster. > > However, I brought up the fact that Python is much quicker to code and > outputs smaller files, and is much more cross-platformable. They > argued that development speed could be sacraficed for game speed, and > in the end I suggested to solve the issue by making a faster Python. > They were quickly discouraged, and desided to pause the project for > awhile so that I can get Python closer to C speed while they work on > other games. > > Unladen Swallow seems to have the same project goal as me: to make a > noticably faster Python implementation. I will look more into that > project. Thanks for the information! > > Responses to Sturla Molden: > > Yes, CPython does seem to avoid very great concepts such as > register-based memory management, garbage collection over reference > counting, and JIT, which is why I decided as part of the optimized > Python to use Pysco, Unladen Swallow, or another optimized Python > interpreter. > > Thank you for your comments (and for adding the title that I > moronically forgot), and I will start doing some optimizations. Any > further development on this will be found at http://luiji.github.com/, > but for now you probably will not see much development. If anybody is > interested in the project, then you can subscribe to my GitHub account > to a notification when I create a new repository for the optimized > Python Standard Library (PSL as I will call it in further e-mails, > since stdlib sounds too much like the C Stdlib). > > Thanks, > - Luiji Maryo > > On Thu, Jul 1, 2010 at 1:17 PM, Sturla Molden <[email protected]> > wrote: >> Stefan Behnel skrev: >>> Good luck. I don't mean to discourage you, but this is a pretty >>> ambitious goal. >>> >> >> Python's VM is slow, indeed. It uses a stack-based VM instead of >> registers; it is implemented in the worst possible way, as code and >> data >> form a three of hash tables; it has reference counting instead of >> garbage collection (produces high cache traffic); it has no JIT >> compilation. It's doomed to be slow. >> >> Many implementations of Common Lisp and Scheme can compete with C >> (e.g. >> SBCL, CMUCL, Allegro, Clozure, Ikarus). None of the billion dollar >> investment that was made into making Lisp fast (during the AI hype >> 20-30 >> years ago) has made it into Python. There were even hardware >> processors >> (aka 'Lisp machines') that could run Lisp natively. We can sometimes >> read on Python lists that Lisp's performance comes from optional >> static >> typic. That is not the whole story. For example, enourmous efforsts >> were >> made for making memory mangement efficient (cons is very effcient, >> lists >> are transformed to contiguous arrays internally, tail-recursion is >> inlined, etc). Lot of this technology is now forgotten, as those who >> worked on it are retired or has lost interest. >> >> Python's memory management (reference counts and malloc/free) is the >> least efficient ever invented by man. Nothing is stored >> contiguously (a >> list of int is not a buffer of int, but an array of pointers). And >> what >> data traffic does it take to keep refcounts synchronized in the >> cache of >> multiple processors? It's almost a wonder that the computer does not >> burst into flames. >> >> LuaJIT is one or two orders of magnitude faster than Python. It is >> not >> just JIT and a proper GC that gives it a performance boost, it also >> uses >> a register-based VM (like Parrot and Dalvik). Lua is a dynamic >> language >> very similar to Python. There is nothing in the Python language that >> keeps it from performing like Lua. >> >> StrongTalk VM for Smalltalk performs close to C. Smalltalk is also a >> dynamic language like Python. Sun actually purchased StrongTalk to >> use >> the VM for Java -- it is Java's Hotspot JIT compiler. Many claim that >> Java's performance comes from static typing, but the VM was actually >> designed for a dynamic language. We all know how Java performes >> compared >> to Python, or even compared to C. Why the discrepancy when the VM was >> designed for Smalltalk? One thing is that much of the experience from >> boosting Lisp actually made it into StrongTalk, unlike CPython. >> Reinventing the wheel is not a good thing, as it implies discaring >> modern tiers. >> >> It's not rocket science to make a fast Python. We can make a compiler >> that runs Python on any of the VMs above (e.g. Android's Dalvik >> engine >> or Lua JIT). A Python front-end for LuaJIT would be nearly 100 times >> faster than the current CPython, with very little investment. It's >> just >> that nobody has bothered... >> >> However: The main strength of Python is the magnitude of extension >> libraries available. A completely new Python will be nearly useless >> on >> its own. That's the big discouragement. And it is easier to write >> some >> C++ or Cython than fixing CPython. >> >> Sturla >> >> _______________________________________________ >> Cython-dev mailing list >> [email protected] >> http://codespeak.net/mailman/listinfo/cython-dev >> > > > > -- > - Luiji Maryo (a.k.a. Brain Boy) > Visit me at http://brainboyblogger.blogspot.com/. > _______________________________________________ > Cython-dev mailing list > [email protected] > http://codespeak.net/mailman/listinfo/cython-dev _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
