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.
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.
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.
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
(allegedly) faster development speed and algorithmic improvements of
Python. Garbage management is a real issue in C++. You can't use Sympy
in Jython if parts of it are coded up in C++. You have a higher barrier
for turning users into contributors.
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 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)
--
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.
