On Wed, Oct 2, 2013 at 5:07 PM, Joachim Durchholz <[email protected]> wrote: > Am 02.10.2013 23:48, schrieb Ondřej Čertík: > >> On Wed, Oct 2, 2013 at 1:47 PM, Joachim Durchholz <[email protected]> >> wrote: >>> >>> Am 02.10.2013 20:26, schrieb Ondřej Čertík: >>> >>>> The reason is that to truly nail the speed, one needs to use special >>>> dictionary implementation, >>>> tweak hashing functions, reference counting, memory allocators etc. >>> >>> >>> >>> Reference counting can improve latency, but it will actually decrease >>> throughput. >>> >>> At best, RC in C++ is faster than what Python does (which has a very >>> crappy >>> garbage collector). >>> A good GC, such as what's available in Java, can beat any RC >>> implementation >>> hands down. Mostly because malloc() and free() do MUCH more work than >>> most >>> people think; it's not unheard of that allocation-intensive programs (and >>> Sympy would certainly qualify) spend 20% of their time in memory >>> management, >>> and a mark-and-sweep collector, even a simplicistic one, simply has a >>> much >>> better throughput. >> >> >> Yes, I have found that malloc, resp. the default new/delete operators >> in C++ can be sped-up >> by 10% or 20% by using custom allocators. > > > Try the Boehm-Demers-Weiser collector and see what that brings. > Use really long-running tasks to benchmark it, it has a relatively high > fixed space overhead.
I'll give it a shot, thanks for the tip. If nothing, it would be good to know the performance of GC compared to reference counting. > > Note that the BDW collector is a lot less efficient than it could be, > because it takes great pains to avoid depending on compiler and language > support. In particular, it cannot be a copying collector because C and C++ > simply cannot work if objects are moved around, and copying would be > essential to combat heap fragmentation (which is a real issue if you have a > task that runs for more than a few hours). > > I'd suggest trying out Java, which has a top-tier GC. Java does have some > performance issues related to run-time class loading and the presence of > introspection facilities, so it might not shine until the GC really starts > to become relevant. I doubt you can beat CSymPy with Java, but I'll be happy to be proven wrong. > > >>>> Besides speed, I came to appreciate having just one language and write >>>> everything in it. Much simpler to maintain >>>> and master. >>> >>> >>> Well sure, but that would be a case for setting up an entirely new SymC++ >>> project, wouldn't it? >> >> >> Right. >> >> The only way to maintain single code base to run both in pure Python and >> compiled in C/C++ for speed that I know of is to use pure Python mode >> in Cython or some kind >> of translation as we discussed. But I don't know how to effectively >> nail the speed >> with either of these approaches, as discussed. >> >> So the other simplest obvious approach is to stick to pure C++. But by >> having >> thin Python wrappers, one can use it complementary together with SymPy, >> and we might be able to incorporate such optional libraries in SymPy >> more tightly >> in the future by using some double dispatch or such. > > > With Python wrappers, you still can't recruit contributors from the user > base. > You'll end with less contributions. Also, algorithmic optimization is > somewhat harder in C++ than in more abstract languages, so you'll want to > keep Python as a testbed even for the stuff you're eventually implementing > in C++; you'll still end with a mixed-language development. I'm reading you > that you think that C++ is common, and while that's true, contributors still > need to know both languages if the ability to translate Python to C++ is > desired, because that will impose design constraints even on the Python code > structure. In my experience, one has to write a clean algorithm in C++ by hand, so the only thing that matters is the algorithm itself. In many cases, we already have a pretty good idea how to implement things in SymPy. Specifically for the reason you mentioned (to avoid mixed language development) I made Python wrappers in CSymPy optional, to ensure a single language development. > > I'm rather sceptical even of mixing in just C++. I'm not convinced that the > linear improvements of C++, however good they may be, can beat the It depends on the benchmark of course, but it can be roughly 100x for the basic symbolics. > (allegedly) faster development speed and algorithmic improvements of Python. Yes, it's much faster to develop new things in Python. But the reason for CSymPy is speed --- so if you don't need speed, it has little benefit. However, if you need speed, then it is awesome, and it is of little use that SymPy is easy to develop, if it is slow for the given application. > Garbage management is a real issue in C++. Currently I use reference counting. I don't see any issue --- can you elaborate on what you mean? > You can't use Sympy in Jython if > parts of it are coded up in C++. Correct. That's why I view CSymPy as complementary, as I mentioned in my previous emails. > You have a higher barrier for turning users > into contributors. Higher than for SymPy, which is in Python. I agree. Also, SymPy list might not be the best place to recruit C++ programmers. But I know that a lot of people don't use SymPy because it was not fast enough for their application. So with CSymPy among the available tools, there would be no reason (in my opinion) not to use SymPy. > That's quite a long list of what-ifs and annoying entanglements, and you can > expect a few of them to actually bite; I'm not sure that the net result will > be worth the effort. Then, of course, whether it's worth it is a value I am convinced it is worth the effort --- as long as you need speed. If you don't need speed, then SymPy works great. > judgement that you might answer differently than me, so by all means make > your own decisions :-) (I guess I'm playing Devil's Advocate here, > enumerating all the counterarguments, just so that they are considered, not > really to shoot the project down) Absolutely, thanks for the discussion. :) Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
