f# - 如果目标是 x64，为什么 Seq.iter 比 for 循环快 2 倍？

Question

免责声明:这是微基准测试，如果您对主题不满意，请不要评论诸如“过早优化是邪恶的”之类的引用。

示例是针对 x64、.Net4.5 Visual Studio 2012 F# 3.0 的发布，并在 Windows 7 x64 中运行

在分析之后，我缩小了我的一个应用程序的瓶颈，所以我想提出这个问题:

观察

如果内部没有循环 for in循环或 Seq.iter ，那么很明显它们的速度相似。 (更新 2 与更新 4)

如果内部有循环 for in循环或 Seq.iter ，好像Seq.iter比 for in 快 2 倍. (更新与更新3)奇怪吗？ (如果在 fsi 中运行，它们将是相似的)

如果是针对anycpu，运行在x64，时间上没有区别。所以问题变成了:如果目标是 x64 ，Seq.iter (update3) 将提高 2 倍速度

花的时间:

update:   00:00:11.4250483 // 2x as much as update3, why?
updatae2: 00:00:01.4447233
updatae3: 00:00:06.0863791
updatae4: 00:00:01.4939535

源代码:

open System.Diagnostics
open System

[<EntryPoint>]
let main argv = 
    let pool = seq {1 .. 1000000}

    let ret = Array.zeroCreate 100

    let update pool =
        for x in pool do
            for y in 1 .. 200 do
                ret.[2] <- x + y

    let update2 pool =
        for x in pool do
            //for y in 1 .. 100 do
                ret.[2] <- x


    let update3 pool =
        pool
            |> Seq.iter (fun x ->
                                  for y in 1 .. 200 do
                                      ret.[2] <- x + y)

    let update4 pool =
        pool
            |> Seq.iter (fun x ->
                                  //for y in 1 .. 100 do
                                      ret.[2] <- x)


    let test n =
        let run = match n with
                  | 1 -> update
                  | 2 -> update2
                  | 3 -> update3
                  | 4 -> update4
        for i in 1 .. 50 do
            run pool

    let sw = new Stopwatch()
    sw.Start()
    test(1)
    sw.Stop()
    Console.WriteLine(sw.Elapsed);

    sw.Restart()
    test(2)
    sw.Stop()
    Console.WriteLine(sw.Elapsed)

    sw.Restart()
    test(3)
    sw.Stop()
    Console.WriteLine(sw.Elapsed)

    sw.Restart()
    test(4)
    sw.Stop()
    Console.WriteLine(sw.Elapsed)
    0 // return an integer exit code

Answer 1

这不是一个完整的答案，但希望它可以帮助您走得更远。

我可以使用相同的配置重现该行为。这是一个更简单的分析示例:

open System

let test1() =
    let ret = Array.zeroCreate 100
    let pool = {1 .. 1000000}    
    for x in pool do
        for _ in 1..50 do
            for y in 1..200 do
                ret.[2] <- x + y

let test2() =
    let ret = Array.zeroCreate 100
    let pool = {1 .. 1000000}    
    Seq.iter (fun x -> 
        for _ in 1..50 do
            for y in 1..200 do
                ret.[2] <- x + y) pool

let time f =
    let sw = new Diagnostics.Stopwatch()
    sw.Start()
    let result = f() 
    sw.Stop()
    Console.WriteLine(sw.Elapsed)
    result

[<EntryPoint>]
let main argv =
    time test1
    time test2
    0

在本例中， Seq.iter和 for x in pool执行一次但 test1 之间仍有 2 倍的时间差和 test2 :

00:00:06.9264843
00:00:03.6834886

它们的 IL 非常相似，因此编译器优化不是问题。看来x64 jitter 优化失败 test1尽管它可以通过 test2 做到这一点.有趣的是，如果我重构 test1 中的嵌套 for 循环作为一个函数，JIT 优化再次成功:

let body (ret: _ []) x =
    for _ in 1..50 do
        for y in 1..200 do
            ret.[2] <- x + y

let test3() =
    let ret = Array.zeroCreate 100
    let pool = {1..1000000}    
    for x in pool do
        body ret x

// 00:00:03.7012302

当我使用技术 described here 禁用 JIT 优化时，这些函数的执行时间是可比的。

为什么 x64 抖动在特定示例中失败，我不知道。您可以 disassemble optimized jitted code逐行比较 ASM 指令。也许具有良好 ASM 知识的人可以找出它们之间的差异。