Timings of devel/sage/sage/sandpiles/sandpile.py
Jeroen Demeyer
For all those whose installed sage-4.7.alpha2 or later (on a reasonably
fast machine): please provide the timing of
$ ./sage -t -long "devel/sage/sage/sandpiles/sandpile.py"
On sage.math.washington.edu:
Total time for all tests: 23.7 seconds
But on my laptop (Gentoo Linux, Intel Core 2 Duo 2.00 GHz, gcc 4.4.3):
Total time for all tests: 519.9 seconds
It is not clear to me why there is this huge difference in timing. See
also #10618.
Jeroen.
Simon King
On 18 Apr., 18:18, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:
> On sage.math.washington.edu:
> Total time for all tests: 23.7 seconds
> But on my laptop (Gentoo Linux, Intel Core 2 Duo 2.00 GHz, gcc 4.4.3):
> Total time for all tests: 519.9 seconds
Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz
However, I have my patch from #11115 applied - if the sandpile code
does a lot of caching, it could easily explain the good timing.
Cheers,
Simon
David Kirkby
The first time I run the test, it took 47.4. Subsequent times were
much faster (25.0, 24.3 25.3 s).
OpenSolaris 06/2009 with an Intel Xeon W3580 (quad core 3.33 GHz).
Dave
amaseam
2011/4/18 Jeroen Demeyer <jdem...@cage.ugent.be>:
On sage-4.7.alpha4, on a 2008 iMac with 3.06 GHz Intel Core 2 Duo,
with 2 GB RAM.
$ ./sage -t -long "devel/sage/sage/sandpiles/sandpile.py"
sage -t -long "4.7.alpha4/devel/sage/sage/sandpiles/sandpile.py"
[69.4 s]
----------------------------------------------------------------------
All tests passed!
Total time for all tests: 69.6 seconds
$ uname -a
Darwin iMac 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16
PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386
$
Cheers,
amaseam
Jeroen Demeyer
> Hello all,
>
> For all those whose installed sage-4.7.alpha2 or later (on a reasonably
> fast machine): please provide the timing of
>
> $ ./sage -t -long "devel/sage/sage/sandpiles/sandpile.py"
>
> On sage.math.washington.edu:
> Total time for all tests: 23.7 seconds
>
> But on my laptop (Gentoo Linux, Intel Core 2 Duo 2.00 GHz, gcc 4.4.3):
> Total time for all tests: 519.9 seconds
Some data points from the buildbot from sage-4.7.alpha4:
* Ubuntu 10-64 (redhawk): 1349.2 s
* Fedora 14-64 (eno): 192.4 s
* RHEL 5.3-64 (cleo): 79.5 s
* RHEL 5.5-64 (rosemary): 27.0 s
* OpenSolaris 06.2009-32 (hawk): 65.0 s
* OSX 10.6-32 (bsd): 101.3 s
Note that redhawk is completely out of proportion, this is otherwise a
very fast machine.
Dima Pasechnik
kernels shipped with Ubuntu and Debian, but
not with RHEL.
We had a discussion about this here a while ago.
(Just in case, I also tried this test on a very fast Debian system,
and saw same slowness...)
(you might see that CPU isn't very active during this run --- that's a
sure sign of it).
Dima
Rob Beezer
> Hello all,
>
> For all those whose installed sage-4.7.alpha2 or later (on a reasonably
> fast machine): please provide the timing of
>
> $ ./sage -t -long "devel/sage/sage/sandpiles/sandpile.py"
to finish with parallel testing. This is a new machine in the past
few months, which should be reasonably fast.
$ ./sage -t -long "devel/sage/sage/sandpiles/sandpile.py"
[1275.2 s]
64-bit Ubuntu 10.10 on Intel i7-2600, details follow.
Rob
----------------------------------------
$ uname -a
Linux lava 2.6.35-25-generic #44-Ubuntu SMP Fri Jan 21 17:40:44 UTC
2011 x86_64 GNU/Linux
$ cat /etc/issue
Ubuntu 10.10 \n \l
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
stepping : 7
cpu MHz : 1600.000
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good
xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl
vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 x2apic popcnt aes
xsave avx lahf_lm ida arat pln pts dts tpr_shadow vnmi flexpriority
ept vpid
bogomips : 6821.58
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
<snip 7 more similar>
$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.4.4-14ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/
README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/
usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-
linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-
included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/
include/c++/4.4 --libdir=/usr/lib --enable-nls --with-sysroot=/ --
enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --disable-
werror --with-arch-32=i686 --with-tune=generic --enable-
checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --
target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)
Simon King
On 18 Apr., 19:21, Dima Pasechnik <dimp...@gmail.com> wrote:
> I think it's the pexpect problem that manifests itself on Linux
> kernels shipped with Ubuntu and Debian, but
> not with RHEL.
on my machine.
As I stated above, it is 20.6 seconds on x86_64 GNU/Linux, Intel(R)
*should* be slow, according to what you report. But...
> We had a discussion about this here a while ago.
kernel. So, the pexpect slowness has disappeared.
Cheers,
Simon
Jeroen Demeyer
> I think it's the pexpect problem that manifests itself on Linux
> kernels shipped with Ubuntu and Debian, but
> not with RHEL.
> We had a discussion about this here a while ago.
> (Just in case, I also tried this test on a very fast Debian system,
> and saw same slowness...)
>
> (you might see that CPU isn't very active during this run --- that's a
> sure sign of it).
Nice find!
Indeed, on this machine:
$ uname -a
Linux arcanis 2.6.34-gentoo-r12 #2 SMP Mon Dec 6 17:16:04 CET 2010
x86_64 Intel(R) Core(TM)2 Duo CPU T5870 @ 2.00GHz GenuineIntel GNU/Linux
$ time ./sage -t -long "devel/sage/sage/sandpiles/sandpile.py"
sage -t -long "devel/sage/sage/sandpiles/sandpile.py"
[517.0 s]
----------------------------------------------------------------------
All tests passed!
Total time for all tests: 517.0 seconds
real 8m37.080s
user 0m30.042s
sys 0m3.420s
Jeroen Demeyer
>> We had a discussion about this here a while ago.
>
> ... as a result of that discussion, our sysadmin has patched the Linux
> kernel. So, the pexpect slowness has disappeared.
You don't happen to have more information, i.e. which patch, which kernel?
Rob Beezer
> You don't happen to have more information, i.e. which patch, which kernel?
and
http://groups.google.com/group/sage-devel/msg/89183d8b4fbaca4b
both cite linux kernel discussion:
http://groups.google.com/group/linux.kernel/browse_thread/thread/5a2b00e35b0864a7
Dan Drake
> For all those whose installed sage-4.7.alpha2 or later (on a
> reasonably fast machine): please provide the timing of
>
> $ ./sage -t -long "devel/sage/sage/sandpiles/sandpile.py"
I get 1464.6 seconds, and 1319 when run again.
This is with an 8-core Ubuntu machine (only the first core shown):
drake@sagenb:~/s/sage-4.7.alpha4$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 10.04.2 LTS
Release: 10.04
Codename: lucid
drake@sagenb:~/s/sage-4.7.alpha4$ uname -a
Linux sagenb 2.6.32-30-server #59-Ubuntu SMP Tue Mar 1 22:46:09 UTC 2011 x86_64 GNU/Linux
drake@sagenb:~/s/sage-4.7.alpha4$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU E5504 @ 2.00GHz
stepping : 5
cpu MHz : 2000.210
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid
bogomips : 4000.42
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
Dan
--
--- Dan Drake
----- http://mathsci.kaist.ac.kr/~drake
-------
Dan Drake
> I think it's the pexpect problem that manifests itself on Linux
> kernels shipped with Ubuntu and Debian, but not with RHEL.
It would be nice to test this problem with the beta of Ubuntu 11.04,
which ships with kernel 2.6.38 (I think). I wonder if the problem still
exists with the kernel they're using.
Simon King
On 18 Apr., 21:54, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:
> You don't happen to have more information, i.e. which patch, which kernel?
The patch cited there is:
--- drivers/char/pty.c.orig 2010-01-11 13:00:58.000000000 +0100
+++ drivers/char/pty.c 2010-01-11 13:01:04.000000000 +0100
@@ -200,6 +200,8 @@ static int pty_open(struct tty_struct *t
if (tty->link->count != 1)
goto out;
+ tty->low_latency = 1;
+
clear_bit(TTY_OTHER_CLOSED, &tty->link->flags);
set_bit(TTY_THROTTLED, &tty->flags);
retval = 0;
Cheers,
Simon
Justin C. Walker
On Apr 18, 2011, at 09:18 , Jeroen Demeyer wrote:
I ran a couple of tests with Mac OS X, 10.6.7, on a Dual 6-Core Xeon processor (2.93GHz) with 24GBytes of RAM.
Using a full build of sage-4.7.alpha4, after a couple of tests to get Sage "hot",
./sage -t -long "devel/sage/sage/sandpiles/sandpile.py"
Total time for all tests: 18.9 seconds
Using an upgrade to sage-4.7.alpha3 from a full build of sage-4.7.alpha2, again after a couple of tests to heat up this version,
./sage -t -long "devel/sage/sage/sandpiles/sandpile.py"
Total time for all tests: 16.2 seconds
Not sure why the time difference between the two versions, but I did this several times and it's quite repeatable.
Justin
--
Justin C. Walker, Curmudgeon at Large
Institute for the Absorption of Federal Funds
-----------
If it weren't for carbon-14, I wouldn't date at all.
-----------
Justin C. Walker
This issue is just due to a "cold" application. It takes time to load all the depended-upon libraries and possibly page in a lot of application code. The second time you run the app, it's noticeably faster (this relates to a previously-discussed issue with slow startup for sage).
You can get a clear picture of the startup slowness by running (something like)
$ time sage < /dev/null
first on a freshly booted system (to really assure that the sage bits are "cold"); and then right away repeating this command. On my system, the time to a shell prompt drops by a factor of 10 or more.
Justin
--
Justin C. Walker, Curmudgeon at Large
Institute for the Absorption of Federal Funds
-----------
Like the ski resort full of girls hunting for husbands
and husbands hunting for girls, the situation is not
as symmetrical as it might seem.
- Alan MacKay
--