#10296: Singular interface wasting time by waiting for the prompt too often
-----------------------------------------------------------------------+----
Reporter: SimonKing |
Owner: was
Type: enhancement |
Status: needs_review
Priority: major |
Milestone: sage-4.7.1
Component: interfaces |
Resolution:
Keywords: Singular, _eval_line, synchronization, synchronisation |
Work_issues:
Upstream: N/A |
Reviewer: Martin Albrecht
Author: Simon King |
Merged:
Dependencies: |
-----------------------------------------------------------------------+----
Changes (by SimonKing):
* status: needs_work => needs_review
Old description:
> There are two fundamental differences between the Singular and the Gap
> interfaces:
>
> 1. The Singular interface uses a synchronisation method in each call to
> its eval method. Gap doesn't.
> 2. The Gap interface deletes variables by declaring that their name may
> be overwritten. This is not possible in Singular, since Singular
> variables are statically typed. Thus, the Singular interface explicitly
> kills the underlying variable in Singular, which requires one call to
> _eval_line for each variable that is to be deleted.
>
> Unfortunately, waiting for the prompt to appear in a pseudo terminal may
> be very costly on some systems, since select.select() may be very slow -
> see #10294. So, additional calls to _eval_line should be strictly
> avoided!
>
> The first point makes me wonder: Why has the synchronisation method
> become necessary for Singular but not for Gap?
>
> The second point makes me wonder whether it is really necessary to use
> one _eval_line for each single deletion.
>
> Moreover, I wonder whether the two points are actually related: I could
> imagine that synchronisation became necessary when garbage collection,
> accidentally performed inside an _eval_line, and thus sending an
> _eval_line inside an outer _eval_line, caused a dead lock in the outer
> _eval_line. Was that the case, historically?
>
> Suggestions:
>
> 1. {{{singular.eval(cmd)}}} is currently simply passing {{{cmd}}} to
> _eval_line, after synchronisation and after killing unused variables. I
> suggest to add the code for killing unused variables to {{{cmd}}}, thus
> using _eval_line only once.
> 2. If my above guess on the role of synchronisation is correct, then one
> could simply drop synchronisation after implementing my first suggestion.
>
> This is related with #10294 and perhaps with #10295. Cc to William and
> Willem-Jan, since they wrote the synchronisation code.
>
> Depends on #7377.
New description:
There are two fundamental differences between the Singular and the Gap
interfaces:
1. The Singular interface uses a synchronisation method in each call to
its eval method. Gap doesn't.
2. The Gap interface deletes variables by declaring that their name may
be overwritten. This is not possible in Singular, since Singular variables
are statically typed. Thus, the Singular interface explicitly kills the
underlying variable in Singular, which requires one call to _eval_line for
each variable that is to be deleted.
Unfortunately, waiting for the prompt to appear in a pseudo terminal may
be very costly on some systems, since select.select() may be very slow -
see #10294. So, additional calls to _eval_line should be strictly avoided!
The first point makes me wonder: Why has the synchronisation method become
necessary for Singular but not for Gap?
The second point makes me wonder whether it is really necessary to use one
_eval_line for each single deletion.
Moreover, I wonder whether the two points are actually related: I could
imagine that synchronisation became necessary when garbage collection,
accidentally performed inside an _eval_line, and thus sending an
_eval_line inside an outer _eval_line, caused a dead lock in the outer
_eval_line. Was that the case, historically?
Suggestions:
1. {{{singular.eval(cmd)}}} is currently simply passing {{{cmd}}} to
_eval_line, after synchronisation and after killing unused variables. I
suggest to add the code for killing unused variables to {{{cmd}}}, thus
using _eval_line only once.
2. If my above guess on the role of synchronisation is correct, then one
could simply drop synchronisation after implementing my first suggestion.
This is related with #10294 and perhaps with #10295. Cc to William and
Willem-Jan, since they wrote the synchronisation code.
Depends on #7377.
For the release manager:
Apply
- [attachment:trac10296_singular_overhead.patch]
- [attachment:trac10296_expect_on_nonlinux.patch]
--
Comment:
I have updated the first patch, which should now apply against
sage-4.7.1.rc2. I have changed the doctest in question, so that now it is
only tested that interrupting gap has worked.
For the patchbot:
Apply trac10296_singular_overhead.patch trac10296_expect_on_nonlinux.patch
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10296#comment:49>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
