Является ли F # Interactive более медленным, чем скомпилировано?

Question

Я использую F # почти шесть месяцев и был настолько уверен, что F # Interactive должен иметь такую ​​же производительность, как и скомпилированный, что, когда я потрудился сравнить его, я убедился, что это какая-то ошибка компилятора. Хотя теперь мне кажется, что я должен был проверить здесь сначала, прежде чем открывать проблему.

Для меня это примерно в 3 раза медленнее, и переключатель оптимизации, похоже, ничего не делает.

Должно ли это быть стандартным поведением? Если это так, меня действительно тронула директива #time. У меня есть время на то, сколько времени потребуется, чтобы суммировать 100M элементов на этом Reddit thread.

Update:

Благодаря FuleSnabel, я обнаружил некоторые вещи.

Я попытался запустить сценарий примера из fsianycpu.exe (который является F # Interactive по умолчанию) и fsi.exe, и я получаю разные тайминги для двух прогонов. 134ms для первого и 78ms для более позднего. Эти два тайминга также соответствуют таймингам из неоптимизированных и оптимизированных бинарных файлов соответственно.

Что еще более сбивает с толку, так это то, что первый проект, который я использовал для компиляции вещи, является частью игровой библиотеки (в форме скрипта), которую я делаю, и отказывается скомпилировать оптимизированный двоичный файл, вместо этого переключается на неоптимизированный, не сообщив мне. Я должен был начать новый проект, чтобы он мог правильно компилироваться. Удивительно, что другой тест был составлен правильно.

Так что в принципе, что-то фанки происходит здесь, и я должен пересмотреть fsianycpu.exe на fsi.exe в качестве интерпретатора по умолчанию.

Answer 1

Я попробовал код примера в pastebin. Я не вижу описываемого вами поведения. Это результат моего бега производительности:

.\bin\Release\ConsoleApplication3.exe 
Total iterations: 300000000, Outer: 10000, Inner: 30000 
reduce sequence of list, result 450015000, time 2836 ms 
reduce array, result 450015000, time 594 ms 
for loop array, result 450015000, time 180 ms 
reduce list, result 450015000, time 593 ms 
fsi -O --exec .\Interactive.fsx 
Total iterations: 300000000, Outer: 10000, Inner: 30000 
reduce sequence of list, result 450015000, time 2617 ms 
reduce array, result 450015000, time 589 ms 
for loop array, result 450015000, time 168 ms 
reduce list, result 450015000, time 603 ms 

Ожидается, что Seq.reduce будет самым медленным, для цикла быстрее, и что сократить в списке/массив примерно одинаков (это предполагает, что расположение элементов списка что не гарантируется).

Я переписал ваш код, чтобы разрешить более длительные прогоны без исчерпания памяти и улучшить локальность данных в кэш. При коротких пробегах неопределенность измерений затрудняет сравнение данных.

Program.fs:

module fs 

let stopWatch = 
    let sw = new System.Diagnostics.Stopwatch() 
    sw.Start() 
    sw 

let total = 300000000 
let outer = 10000 
let inner = total/outer 

let timeIt (name : string) (a : unit -> 'T) : unit = 
    let t = stopWatch.ElapsedMilliseconds 
    let v = a() 
    for i = 2 to outer do 
    a() |> ignore 
    let d = stopWatch.ElapsedMilliseconds - t 
    printfn "%s, result %A, time %d ms" name v d 

[<EntryPoint>] 
let sumTest(args) = 
    let numsList = [1..inner] 
    let numsArray = [|1..inner|] 

    printfn "Total iterations: %d, Outer: %d, Inner: %d" total outer inner 

    let sumsSeqReduce() = Seq.reduce (+) numsList 
    timeIt "reduce sequence of list" sumsSeqReduce 

    let sumsArray() = Array.reduce (+) numsArray 
    timeIt "reduce array" sumsArray 

    let sumsLoop() = 
    let mutable total = 0 
    for i in 0 .. inner - 1 do 
     total <- total + numsArray.[i] 
    total 

    timeIt "for loop array" sumsLoop 

    let sumsListReduce() = List.reduce (+) numsList 

    timeIt "reduce list" sumsListReduce 

    0 

Interactive.fsx:

#load "Program.fs" 
fs.sumTest [||] 

PS. Я работаю на Windows с Visual Studio 2015. 32bit или 64bit, казалось, делали только предельные различия