(2014/01/06 23:10), Urabe Shyouhei wrote:
> On 01/06/2014 06:11 PM, Urabe Shyouhei wrote:
>> On 01/06/2014 04:52 PM, SASADA Koichi wrote:
>>> Could you try same measurement
>>> https://github.com/ruby/ruby/pull/495#issuecomment-31580604
>>> with only addding dummy padding to RVALUE (and not extend embed area) if
>>> it is easy to try?
>>
>> Wait a moment.  It is not difficult but takes some time.
> 
> Here you are.
> http://www.atdot.net/fp/view/hfgzym
> 
> 2.1.1 and 5-words should be the same, so be sure there are ~1 second error margin.
> 
> I cannot explain why 9 words case is this fast, but it is clear to me
> that prime-number-sized object does have negative impact on performance.
> 

Thank you.

On my environment, I can't measure the improvement with padding.
http://www.atdot.net/fp_store/f.0w30zm/file.copipa-temp-image.png

model name      : Intel(R) Xeon(R) CPU           E5335  @ 2.00GHz
stepping        : 7
cpu MHz         : 1995.013
cache size      : 4096 KB

Effective on recent CPUs?



----
BTW, vm3_gc benchmark results:

$ for i in `seq 5 16`; do LD_PRELOAD=~/tmp/trunk-$i/lib/libruby.so
~/tmp/trunk-$i/bin/ruby -e "p GC::INTERNAL_CONSTANTS[:RVALUE_SIZE]";
time LD_PRELOAD=~/tmp/trunk-$i/lib/libruby.so  ~/tmp/trunk-$i/bin/ruby
../trunk/benchmark/bm_vm3_gc.rb; done
40

real    0m4.020s
user    0m4.008s
sys     0m0.012s
48

real    0m4.409s
user    0m4.408s
sys     0m0.000s
56

real    0m4.918s
user    0m4.916s
sys     0m0.000s
64

real    0m5.178s
user    0m5.176s
sys     0m0.000s
72

real    0m6.059s
user    0m6.048s
sys     0m0.008s
80

real    0m6.498s
user    0m6.488s
sys     0m0.008s
88

real    0m6.700s
user    0m6.696s
sys     0m0.004s
96

real    0m7.513s
user    0m7.508s
sys     0m0.004s
104

real    0m8.049s
user    0m8.029s
sys     0m0.012s
112

real    0m8.033s
user    0m8.025s
sys     0m0.012s
120

real    0m6.644s
user    0m6.632s
sys     0m0.012s
128

real    0m7.643s
user    0m7.628s
sys     0m0.016s



-- 
// SASADA Koichi at atdot dot net