24618 1290349603.215559 write(3, "aaa", 3) = 3 24619 1290349603.219923 <... read resumed> "aaa", 256) = 3
in the first case: Wall time: 16.0200681686 Total CPU: 0.862045 in the second one: Wall time: 0.0230610370636 Total CPU: 0.042001 in the third one: Wall time: 8.00897812843 Total CPU: 0.300014 and my config: Linux neo 2.6.32-25-generic #45-Ubuntu SMP Sat Oct 16 19:48:22 UTC 2010 i686 GNU/Linux j_sch...@neo:~$ sage -version | Sage Version 4.6, Release Date: 2010-10-30 hope this helps. greatz Johannes Am 19.11.2010 15:12, schrieb Willem Jan Palenstijn: > 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. > > wget http://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. > > 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 > > -- 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
