[Webkit-unassigned] [Bug 144001] Make FunctionRareData allocation thread-safe

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=144001

Basile Clement <basile_clement at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #251361|0                           |1
        is obsolete|                            |
 Attachment #251478|                            |review?, commit-queue?
              Flags|                            |

--- Comment #7 from Basile Clement <basile_clement at apple.com> ---
Created attachment 251478
  --> https://bugs.webkit.org/attachment.cgi?id=251478&action=review
Also ObjectAllocationProfile::isNull to private scope

The previous benchmarking issues were apparently present for unrelated reasons.
I am getting weird results:

Basiles-MacBook-Pro:OpenSource elarnon$ JSC_useFTLJIT1=true /Volumes/Data/SVN/Baseline/Internal/Tools/Scripts/run-jsc-benchmarks /Volumes/Data/SVN/Baseline/OpenSource/WebKitBuild/Release/jsc --outer 6 --kraken --benchmark astar
32/32                                        
Generating benchmark report at /Volumes/Data/SVN/Baseline/OpenSource/Kraken_Basiles-MacBook-Pro_20150423_1135_report.txt
And raw data at /Volumes/Data/SVN/Baseline/OpenSource/Kraken_Basiles-MacBook-Pro_20150423_1135.json

Benchmark report for Kraken on Basiles-MacBook-Pro (MacBookPro11,3).

VMs tested:
"Conf#1" at /Volumes/Data/SVN/Baseline/OpenSource/WebKitBuild/Release/jsc (r183152)

Collected 6 samples per benchmark/VM, with 6 VM invocations per benchmark.
Emitted a call to gc() between sample measurements. Used 1 benchmark iteration
per VM invocation for warm-up. Used the jsc-specific preciseTime() function to
get microsecond-level timing. Reporting benchmark execution times with 95%
confidence intervals in milliseconds.

                          Conf#1            

ai-astar             424.889+-7.874     

<arithmetic>         424.889+-7.874     


(note the useFTLJIT1=true, so the option has no effect, just triggers the parsing code) VS

Basiles-MacBook-Pro:OpenSource elarnon$ /Volumes/Data/SVN/Baseline/Internal/Tools/Scripts/run-jsc-benchmarks /Volumes/Data/SVN/Baseline/OpenSource/WebKitBuild/Release/jsc --outer 6 --kraken --benchmark astar
32/32                                        
Generating benchmark report at /Volumes/Data/SVN/Baseline/OpenSource/Kraken_Basiles-MacBook-Pro_20150423_1132_report.txt
And raw data at /Volumes/Data/SVN/Baseline/OpenSource/Kraken_Basiles-MacBook-Pro_20150423_1132.json

Benchmark report for Kraken on Basiles-MacBook-Pro (MacBookPro11,3).

VMs tested:
"Conf#1" at /Volumes/Data/SVN/Baseline/OpenSource/WebKitBuild/Release/jsc (r183152)

Collected 6 samples per benchmark/VM, with 6 VM invocations per benchmark.
Emitted a call to gc() between sample measurements. Used 1 benchmark iteration
per VM invocation for warm-up. Used the jsc-specific preciseTime() function to
get microsecond-level timing. Reporting benchmark execution times with 95%
confidence intervals in milliseconds.

                          Conf#1            

ai-astar             591.127+-5.260     

<arithmetic>         591.127+-5.260     

Note that this is on the *Baseline*, i.e. w/o patches applied (actually the timings are similar w/ the patch applied but reversed, i.e. around 600 w/ options and around 420 w/ no options).
I discussed this with mlam, who thinks this might be memory alignment issues, which are in any case not related to this patch.

I have also run tests for Kraken/ai-astar (which was the only test w/ significant difference) against r183069 :

Benchmark report for Kraken on Basiles-MacBook-Pro (MacBookPro11,3).

VMs tested:
"Conf#1" at /Volumes/Data/BenchTest/ICloudFix/OpenSource/WebKitBuild/Release/jsc
"Conf#2" at /Volumes/Data/BenchTest/RemoveNode/OpenSource/WebKitBuild/Release/jsc
"Conf#3" at /Volumes/Data/BenchTest/NoDeallocate/OpenSource/WebKitBuild/Release/jsc

Collected 6 samples per benchmark/VM, with 6 VM invocations per benchmark. Emitted a call to gc() between sample
measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used the jsc-specific preciseTime() function to
get microsecond-level timing. Reporting benchmark execution times with 95% confidence intervals in milliseconds.

                          Conf#1                    Conf#2                    Conf#3                 Conf#3 v. Conf#1     

ai-astar             399.571+-4.196      ?     400.163+-3.402            399.722+-4.901         ?

<arithmetic>         399.571+-4.196      ?     400.163+-3.402            399.722+-4.901         ? might be 1.0004x slower

(Conf#1 is r183069, Conf#2 is r183069 + https://bugs.webkit.org/show_bug.cgi?id=143999, and Conf#3 is Conf#2 + https://bugs.webkit.org/show_bug.cgi?id=144000 + this patch).

So I think this can safely be considered perf-neutral.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150423/cdc89fe2/attachment.html>