Hi Maciej, It seems you are right, my patch can afford some tweaks. As you can see, the gain is doubled compared to the original one.
By the way, I was thinking another issue. In the current build, every JS object stores its own string lookup table. Is it possible to merge these string tables into a global one? I hope it will decrease both the memory consumption and the runtime, since we only need pointer comparison instead of string comparison. Regards, Zoltan > > On Jun 26, 2008, at 5:20 AM, Zoltan Herczeg wrote: > >> Hi Maciej >> >> Thank you for your reply. >> The algorithm itself is very simple. Think about the following >> expression: >> a = b + c + d. The result of (b+c) is just a temporay value, which >> is not >> used anymore after this expression is evaluated. From technical >> viewpoint, >> a shadow register file tracks those numbers cells, which reference >> counter >> is exatly one. If a reference counter increases (caused by >> instructions >> like mov, put_by_id, call...), we remove the particular number cell >> from >> this shadow register file. However, if a new value is stored in a >> register, and a number cell is pointed by its shadow register, we can >> safely reclaim that number cell. The perfromance drawback is that we >> always perfrom this check after some selected instructions (like >> add, sub, >> mul, div, mod, ...) even if the current benchmark never allocates a >> number cell. > > Is it possible to skip the check in the fast path for immediate > numbers that these instructions have? That would probably remove the > drawback. > >> >> Your idea of 64 bit VM registers are interesting. That makes this >> patch a >> complete waste. Since most of our systems are 64 bit systems, we >> already >> have 64 bit VM registers :) That makes me wondering, how do you plan >> to >> store a 64 bit pointer using a 64 bit VM register? > > The only pointers that have to be stored will be into the JavaScript > heap, and we can use VM allocation tricks to ensure that it is limited > to 48 bits or so of real address information in the 64-bit case. > (Collector memory already uses low-level mechanisms to allocate > directly from the VM subsystem.) > > - Maciej >
Starting sunspider-compare-results with DYLD_FRAMEWORK_PATH set to point to
built JavaScriptCore in
/home/hzoli/Webkit/WebKit/WebKitBuild/Release/JavaScriptCore.
TEST COMPARISON FROM TO
DETAILS
=============================================================================
** TOTAL **: 1.030x as fast 3234.7ms +/- 0.3% 3141.3ms +/- 0.3%
significant
=============================================================================
3d: 1.109x as fast 445.7ms +/- 0.5% 402.0ms +/- 0.6%
significant
cube: 1.26x as fast 122.7ms +/- 0.6% 97.6ms +/- 0.5%
significant
morph: 1.051x as fast 188.1ms +/- 0.6% 178.9ms +/- 0.7%
significant
raytrace: 1.075x as fast 134.9ms +/- 0.8% 125.5ms +/- 1.0%
significant
access: 1.085x as fast 441.5ms +/- 0.6% 406.9ms +/- 0.3%
significant
binary-trees: *1.029x as slow* 62.5ms +/- 1.0% 64.3ms +/- 0.8%
significant
fannkuch: 1.008x as fast 150.7ms +/- 0.2% 149.5ms +/- 0.3%
significant
nbody: 1.21x as fast 189.6ms +/- 1.3% 156.2ms +/- 0.7%
significant
nsieve: 1.049x as fast 38.7ms +/- 0.9% 36.9ms +/- 1.4%
significant
bitops: *1.016x as slow* 274.9ms +/- 0.5% 279.4ms +/- 0.4%
significant
3bit-bits-in-byte: *1.041x as slow* 43.4ms +/- 2.1% 45.2ms +/- 1.0%
significant
bits-in-byte: *1.043x as slow* 48.8ms +/- 1.2% 50.9ms +/- 1.2%
significant
bitwise-and: *1.015x as slow* 79.8ms +/- 0.8% 81.0ms +/- 0.7%
significant
nsieve-bits: - 102.9ms +/- 0.7% 102.3ms +/- 0.5%
controlflow: *1.197x as slow* 29.4ms +/- 1.3% 35.2ms +/- 1.6%
significant
recursive: *1.197x as slow* 29.4ms +/- 1.3% 35.2ms +/- 1.6%
significant
crypto: *1.026x as slow* 197.2ms +/- 0.7% 202.3ms +/- 0.9%
significant
aes: - 72.4ms +/- 0.5% 72.4ms +/- 0.5%
md5: *1.039x as slow* 64.7ms +/- 1.0% 67.2ms +/- 1.5%
significant
sha1: *1.043x as slow* 60.1ms +/- 1.2% 62.7ms +/- 0.9%
significant
date: - 342.0ms +/- 0.5% 341.0ms +/- 0.5%
format-tofte: 1.011x as fast 213.8ms +/- 0.5% 211.5ms +/- 0.5%
significant
format-xparb: ?? 128.2ms +/- 1.1% 129.5ms +/- 0.7%
not conclusive: might be *1.010x as slow*
math: 1.063x as fast 338.2ms +/- 1.2% 318.3ms +/- 0.5%
significant
cordic: 1.036x as fast 100.8ms +/- 1.1% 97.3ms +/- 0.9%
significant
partial-sums: 1.070x as fast 167.9ms +/- 1.1% 156.9ms +/- 0.5%
significant
spectral-norm: 1.084x as fast 69.5ms +/- 3.2% 64.1ms +/- 0.4%
significant
regexp: - 324.8ms +/- 0.1% 325.1ms +/- 0.4%
dna: - 324.8ms +/- 0.1% 325.1ms +/- 0.4%
string: 1.012x as fast 841.0ms +/- 0.5% 831.1ms +/- 0.7%
significant
base64: *1.037x as slow* 116.9ms +/- 1.3% 121.2ms +/- 2.3%
significant
fasta: 1.034x as fast 140.0ms +/- 0.9% 135.4ms +/- 1.3%
significant
tagcloud: - 216.6ms +/- 0.4% 216.1ms +/- 0.3%
unpack-code: 1.064x as fast 238.7ms +/- 2.4% 224.3ms +/- 1.2%
significant
validate-input: *1.041x as slow* 128.8ms +/- 0.5% 134.1ms +/- 1.7%
significant
gc-improve-34737-2.patch
Description: Binary data
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
