On Sat, Feb 23, 2008 at 9:39 AM, alex clemesha <[EMAIL PROTECTED]> wrote:
>
>
>
> On Sat, Feb 23, 2008 at 12:02 AM, didier deshommes <[EMAIL PROTECTED]>
> wrote:
> >
> >
> > On Fri, Feb 22, 2008 at 5:57 PM, alex clemesha <[EMAIL PROTECTED]> wrote:
> > > In Knoboo we *decouple* the idea of a kernel, it could be another
> > > Python (Sage) process, with communication through Pexpect
> > >
> > > ... but it also couple be another Python (Sage) process running a very
> > > minimal XML-RPC server, and all communication occurs through
> > > *** HTTP instead of Pexpect ***.
> >
> > I personally am not too familiar with web development, so it's always
> > great to hear from someone who has (which is exactly why this
> > discussion was started). Regarding XML-RPC vs Pexpect:
> > - how slow is one compared to the other? I expect xml-rpc to be
> > slower, but not so slow to render it unusable.
>
> I would say that it is even faster than how the current Sage notebook
> does its process of compiling scripts to be passed back and forth with
> Pexpect.
>
> But in reality, both methods of communication, in most cases,
> are sub-second and constant, so this is mostly a complete non-issue.
I'm actually pretty curious about how pexpect and XMLRPC both
done locally compare speedwise. I've done some simple benchmarks
below. The short answer is that pexpect is between several hundred
to several thousand times faster than XMLRPC, depending on the
platform.
Here's a good pexpect benchmark to do in sage-2.10.2:
sage: gp('2+2')
4
sage: timeit("gp.eval('2+2')")
625 loops, best of 3: 136 µs per loop
This benchmarks adding 2 and 2 over the pexpect interface
to pari and getting back the result. It takes 136 microseconds
to do that on my OS X 10.5 intel 2.6Ghz computer. On sage.math
it's about 500 times faster, only 303 nanoseconds:
sage: timeit(gp.eval('2+2'))
625 loops, best of 3: 303 ns per loop
Pexpect may have a reputation for being "dog slow", but on small
transactions it's actually surprisingly fast. Seriously. It's only bad
when the input is large.
Now let's try xmlrpc (with Yi's help). Copy in the setup from
http://docs.python.org/lib/simple-xmlrpc-servers.html
then time adding two integers (we put an r after them below
so that they are *Python* integers, which avoid preparsing):
On my 2.6Ghz Intel OS X computer:
sage: timeit('s.add(2r,3r)')
25 loops, best of 3: 43.7 ms per loop
On sage.math:
sage: timeit('s.add(2r,3r)')
625 loops, best of 3: 1.38 ms per loop
So let's compare:
On OS X 2.6Ghz machine pexpect is 321 times faster
than XMLRPC:
sage: 43.7 / (136 * 10^(-3))
321.323529411765
On sage.math pexpect is 4554 times faster than XMLRPC:
sage: 1.38 / (303 * 10^(-6))
4554.45544554455
Obviously there may be tricks for speeding up XMLRPC (and
for speeding up pexpect), and I would really love for an expert
in XMLRPC to retry the above benchmarks but with their tricks.
However, XMLRPC is using the TCP/IP networking stack, and
probably will have to use encryption if we're to do this seriously,
whereas pexpect is just all happening in RAM (vis unix named
pipes), so it's maybe not surprising that pexpect would
have a big advantage speedwise.
>
>
> >
> > - I understand xml-rpc working for inter-communication, ie SAGE ->
> > outside world, but I don't see how it would work for
> > intra-communication, SAGE -> maxima. Maxima would have to be already
> > running in the background, right? If that is the case, then every sage
> > session would have to spawn singular, maxima, maple, etc sessions at
> > start-up. I don't like that. Is there something I'm not getting here?
>
> Sage intra-communication would stay exactly the same. The way that
> works (pseudo-tty) won't be changing any time soon (ever?).
It may change for MS Windows; I don't know. Windows doesn't suppose
pseudo-tty's so well (?), so we may have to come up with a new approach
there, since now we're serious about fully porting Sage to Windows.
> It's fundamental to how Sage encapsulates all it's external programs.
>
> Behind the scenes, when you use a function that requires,
> for example, singular or maxima to be used, then that new process
> would start only when you call that function, not at startup,
> which is already a working, built in part of Sage.
Yep.
> The method of using some light-weight RPC server,
> (could be Python's built in XML-RPC server, could be a DSage instance, etc)
> to act as the running namespace for a notebook is almost identical
> to how the Sage notebook uses it's separate processes for each notebook,
> it's just that communication to the *outside world* is done with
> standard RPC methods instead of with a psuedo-tty (Pexpect). This is the
> key point.
Very clear explanation. And yes, I think XML-RPC is a good
external API for Python to talk to other programs. And it's already
done -- we don't have to write anything -- it's been done for years.
And it's completely "industry standard".
> By using standard RPC methods,
> (which by the way is the bread and butter of most web services, regardless
> of programming language)
> to communicate with the running Sage process,
> you can then support some API which others can use too.
>
Yep. So basically Sage (because of Python) already has *the*
standard API. Very cool.
-- William
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
