Displaying 3 results from an estimated 3 matches for "kimwituregular".
2008 Apr 23
0
[LLVMdev] PATCH: Use size reduction -- wave2
...(kimwitu++).
I have 20 measurements regading trunk LLVM and 5 with my changes
merged in:
###### TRUNK + DIET
pixxi:~ ggreif$ cat kimwituFastDiet50147.scatter|grep user|sort
user 1m25.404s
user 1m25.453s
user 1m25.454s
user 1m25.526s
user 1m25.973s
###### TRUNK
pixxi:~ ggreif$ cat kimwituRegular.scatter.backup|grep user|sort
user 1m25.127s
user 1m25.132s
user 1m25.147s
user 1m25.160s
user 1m25.169s
user 1m25.179s
user 1m25.179s
user 1m25.184s
user 1m25.189s
user 1m25.199s
user 1m25.204s
user 1m25.207s
user 1m25.212s
user 1m25.217s
user 1m25.219s...
2008 Apr 24
2
[LLVMdev] Status of use-diet so far (NO API CHANGES)
...e constrained setups (when swapping
occurs) the use-diet approach is probably producing
even better results.
So here are my values when doing a
cd ~/test-suite/MultiSource/Applications/kimwitu++
time make --always
in the regular trunk and with my changes merged in:
grep "^real" < kimwituRegular.scatter.backup2 | sort
real 1m34.002s
real 1m34.084s
real 1m34.092s
real 1m34.398s
real 1m34.468s
real 1m34.508s
real 1m34.733s
real 1m34.849s
real 1m35.057s
real 1m35.109s
real 1m35.160s
real 1m35.236s
real 1m36.005s
real 1m36.667s
real 1m38.071s
real...
2008 Apr 17
2
[LLVMdev] PATCH: Use size reduction -- wave2
On Apr 16, 2008, at 11:25 AM, Dan Gohman wrote:
>> So, my idea is that these changes are performance neutral.
I strongly agree with Dan that we need to measure performance to
ensure there is no significant performance regression.
>> I hope that this is interesting, but I'd like to ask anybody who is
>> comfortable with performance testing to help provide some hard