Open GoogleCodeExporter opened 9 years ago
Original comment by collinw
on 21 Jan 2010 at 5:39
Memory usage numbers for -b django:
CPython 2.6.4: 8508 kb
Unladen Swallow -j whenhot: 26768 kb
Unladen Swallow -j never: 15144 kb
It occurs to me that we're doing a lot of unnecessary LLVM-side setup under -j
never.
We should fix that.
Original comment by collinw
on 21 Jan 2010 at 11:32
We also need to stop collecting runtime feedback under -j never.
Original comment by collinw
on 21 Jan 2010 at 11:34
r1027 makes it so that we only collect runtime feedback when run under -j
whenhot. See that commit message for full benchmarking,
including impact on -j whenhot.
Benchmarking CPython 2.6.4 against Unladen@r1027 with `-j never`:
./perf.py -r -b nbody,django,spambayes,html5lib --args ",-j never"
/tmp/cpy26/bin/python /tmp/unladen/bin/python
### django ###
Min: 1.081044 -> 1.078953: 1.0019x faster
Avg: 1.084816 -> 1.085373: 1.0005x slower
Not significant
Stddev: 0.00233 -> 0.00635: 2.7255x larger
Timeline: http://tinyurl.com/yzc9v6h
### html5lib ###
Min: 13.744751 -> 14.863341: 1.0814x slower
Avg: 14.036593 -> 14.965478: 1.0662x slower
Significant (t=-19.700390, a=0.95)
Stddev: 0.12308 -> 0.08417: 1.4623x smaller
Timeline: http://tinyurl.com/yjmnskd
### nbody ###
Min: 0.502919 -> 0.615699: 1.2243x slower
Avg: 0.511181 -> 0.635652: 1.2435x slower
Significant (t=-54.535748, a=0.95)
Stddev: 0.00465 -> 0.02234: 4.8001x larger
Timeline: http://tinyurl.com/yhwarv8
### spambayes ###
Min: 0.310886 -> 0.344835: 1.1092x slower
Avg: 0.312013 -> 0.345739: 1.1081x slower
Significant (t=-291.499720, a=0.95)
Stddev: 0.00089 -> 0.00074: 1.1916x smaller
Timeline: http://tinyurl.com/yl3nsms
Unladen with -j never is now doing much better than previously (see r1027 for
the old Unladen numbers).
Original comment by collinw
on 22 Jan 2010 at 2:38
r1034 lazily initializes the runtime feedback DenseMaps, which turns out to be
a nice win under -j never:
$ ./perf.py -f -m -a '-j never' ../unladen-trunk/python ../unladen-
swallow/python
Report on Linux muikyl 2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10 17:01:44 UTC
2009 x86_64
Total CPU cores: 8
### 2to3 ###
Mem max: 24436.000 -> 21640.000: 1.1292x smaller
Usage over time: http://tinyurl.com/ybksp27
### django ###
Mem max: 19684.000 -> 16696.000: 1.1790x smaller
Usage over time: http://tinyurl.com/yf2cgoo
### nbody ###
Mem max: 9156.000 -> 8052.000: 1.1371x smaller
Usage over time: http://tinyurl.com/y9fj8td
### slowpickle ###
Mem max: 10180.000 -> 8724.000: 1.1669x smaller
Usage over time: http://tinyurl.com/ybwnxj8
### slowspitfire ###
Mem max: 141304.000 -> 159360.000: 1.1278x larger
Usage over time: http://tinyurl.com/yjxq9gn
### slowunpickle ###
Mem max: 10176.000 -> 8708.000: 1.1686x smaller
Usage over time: http://tinyurl.com/yb4rtsq
### spambayes ###
Mem max: 19412.000 -> 14788.000: 1.3127x smaller
Usage over time: http://tinyurl.com/ycwkts4
I need to look into what's going on with slowspitfire.
rnk++!
Original comment by collinw
on 25 Jan 2010 at 6:43
Rough status report of -j never memory usage vs CPython 2.6.4:
$ ./perf.py --track_memory --fast -b default,apps --args=",-j never"
/tmp/cpy26/bin/python
/tmp/unladen/bin/python
### 2to3 ###
Mem max: 9672.000 -> 14172.000: 1.4653x larger
Usage over time: http://tinyurl.com/yasnaoy
### django ###
Mem max: 8452.000 -> 12660.000: 1.4979x larger
Usage over time: http://tinyurl.com/yb5alyg
### html5lib ###
Mem max: 124460.000 -> 133484.000: 1.0725x larger
Usage over time: http://tinyurl.com/yjlxwxo
### nbody ###
Mem max: 2936.000 -> 7116.000: 2.4237x larger
Usage over time: http://tinyurl.com/yfwzels
### rietveld ###
Mem max: 14956.000 -> 19424.000: 1.2987x larger
Usage over time: http://tinyurl.com/yaaz8jv
### slowpickle ###
Mem max: 3320.000 -> 7660.000: 2.3072x larger
Usage over time: http://tinyurl.com/yamyjyb
### slowspitfire ###
Mem max: 85664.000 -> 89856.000: 1.0489x larger
Usage over time: http://tinyurl.com/yeuvrwq
### slowunpickle ###
Mem max: 3332.000 -> 7668.000: 2.3013x larger
Usage over time: http://tinyurl.com/yb99xu5
### spambayes ###
Mem max: 7284.000 -> 11564.000: 1.5876x larger
Usage over time: http://tinyurl.com/ykfz4lz
Original comment by collinw
on 25 Jan 2010 at 7:42
r1044 shaved another ~350kb off memory usage across the board. There's more low-
hanging fruit yet to be picked.
Original comment by collinw
on 27 Jan 2010 at 1:54
Original issue reported on code.google.com by
jyass...@gmail.com
on 21 Jan 2010 at 2:28