I never said Cython doesn't meet my needs, I said it met my needs so much that I wanted to optimized the PSL with it.
On Friday, July 2, 2010, Russell Reagan <[email protected]> wrote: > 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. >>> > -- - 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
