On Wed, Dec 9, 2009 at 10:23 PM, Nathann Cohen <nathann.co...@gmail.com> wrote: > Just a random thought : wouldn't it be way more efficient to write the > definitions of a Graph ( and perhaps the basic functions too ) > directly in C, then to wrap them through Cython ? > > Nathann
Re: Cython vs C, there isn't a speed difference between C and Cython, so it is advantageous for everything to be written in Cython. There you get Python syntax, object oriented programming, speed and the Cython part of the Sage library all in one place. The c_graph structures themselves are written to entirely use C objects from start to finish, so they're very fast. Some code needs to stay in Python. Think about it: if it's essentially Python anyway, when you change the code would you rather wait one second to compile, or five? Now multiply that one vs. five seconds by the number of files you are thinking about Cythonizing. It could take much longer if your file is long or the code is complicated. In some cases, i.e. functions which themselves are called frequently from other functions, it makes perfect sense to use Cython. But if your function is mainly being called by the user, or takes any real amount of time at all to execute (I mean, e.g. calling other functions), it doesn't hurt to leave it in Python. The graph backends (including c_graph backends) are Python objects. As far as the graph backends are concerned, I can mention a few things which are blocking progress toward pure Cython backends: 1. In order for this to matter, graph.py needs to be split up, into probably more than just generic_graph, graph, and digraph. I'm thinking probably a Python and Cython file for graph and for digraph. So that would be five new files, three Python, two Cython. That way the relevant parts of the Sage graph class could call Cython quickly, and the rest could stay in a .py file. 2. It would really be much more efficient for the backends to make use of genuine iterators. There are two ways to do this, the procrastination way and the hard way. Sooner or later, Cython will support things like yield statements, and if we just wait for this to happen, it will be nearly trivial to switch them over. That's the easy way. The hard way is to create a bunch of new classes, with __iter__ and __next__ methods, for each of the iterator functions in each of the backends. This is sure to introduce new bugs and waste developer time, too. 3. My thesis ;) Given these issues, I should note that these are some obstructions to the *optimal* speed. I still think the switchover at #7634 will be majorly beneficial to speed. -- Robert L. Miller http://www.rlmiller.org/ -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
