On 19 November 2010 15:11, Dima Pasechnik <dimp...@gmail.com> wrote: > > > On Nov 19, 10:12 pm, Willem Jan Palenstijn <w...@usecode.org> wrote: >> On Thu, Nov 18, 2010 at 11:47:38PM -0800, Simon King wrote: >> > On 19 Nov., 07:28, Simon King <simon.k...@uni-jena.de> wrote: >> > > So, now the question is what all the machines have in common. I notice >> > > that it is Ubuntu in many (or all?) cases. One of the machines at my >> > > university used to *not* show the big overhead when it was running >> > > Scientific Linux. Now it is (if I understood correctly what the >> > > sysadminn said) Ubuntu. >> >> > Small correction: One of the problematic machines runs Debian 6.0, not >> > Ubuntu. But according to our sysadmin, Ubuntu is based on Debian, so >> > that one might conjecture that the problem occurs on machines that in >> > some way are based on Debian. >> >> Could you try to download, compile and run a small test program on a >> problematic machine? It times how fast a pseudo-terminal responds, which >> might >> be the problem judging by a few quick tests I ran. >> >> wgethttp://www.usecode.org/misc/timeptmx.c >> gcc -o timeptmx timeptmx.c >> strace -o timeptmx.log -f -ttt ./timeptmx >> grep aaa timeptmx.log >> >> That should output something like this: >> >> 16095 1290175675.065705 write(3, "aaa", 3) = 3 >> 16096 1290175675.065749 <... read resumed> "aaa", 256) = 3 >> >> The difference between these two timestamps seems to determine how fast >> pexpect >> responds. In this case it's fast (1290175675.065705 to 1290175675.065749 is >> only 44 microseconds), but I've seen 1.8ms on other machines with newer >> kernels. >> > > it seems that on my pair of Linux machines (see my post in the thread) > I see exactly this happening: > > Debian (testing), kernel 2.6.32, 6105 microseconds > d...@banana:/tmp/pexpect$ gcc -o timeptmx timeptmx.c > d...@banana:/tmp/pexpect$ strace -o timeptmx.log -f -ttt ./timeptmx > d...@banana:/tmp/pexpect$ grep aaa timeptmx.log > 17157 1290178717.172903 write(3, "aaa", 3) = 3 > 17158 1290178717.179008 <... read resumed> "aaa", 256) = 3 > d...@banana:/tmp/pexpect$ uname -a > Linux banana 2.6.32-5-amd64 #1 SMP Sat Oct 30 14:18:21 UTC 2010 x86_64 > GNU/Linux > > Centos, kernel 2.6.18, 109 microseconds > [d...@grapefruit pexpect]$ gcc -o timeptmx timeptmx.c > [d...@grapefruit pexpect]$ strace -o timeptmx.log -f -ttt ./timeptmx > [d...@grapefruit pexpect]$ grep aaa timeptmx.log > 17650 1290178940.664300 write(3, "aaa", 3) = 3 > 17651 1290178940.664409 <... read resumed> "aaa", 256) = 3 > [d...@grapefruit pexpect]$ uname -a > Linux grapefruit.local.spms.ntu.edu.sg 2.6.18-194.17.4.el5.centos.plus > #1 SMP Tue Oct 26 04:07:11 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux > > > Dima > > >> Something similar to this is run twice for every singular.eval() call, and >> seems to be the major factor in execution (wall) time. >> >> -Willem Jan
If there is no trac ticket for this, which i believe is the case, then one should be created. This could be real mess if updates of the kernal are going to cause this slowdown. it must be worth trying the latst pexpect source code - we are several revisions out of date. Dave -- 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
