RE: [Camllist] Interactive technical computing

Robert Fischer
 skaller
 Jon Harrop
 Jon Harrop
[
Home
]
[ Index:
by date

by threads
]
[ Message by date: previous  next ] [ Message in thread: previous  next ] [ Thread: previous  next ]
[ Message by date: previous  next ] [ Message in thread: previous  next ] [ Thread: previous  next ]
Date:  20070309 (18:56) 
From:  Jon Harrop <jon@f...> 
Subject:  Re: [Camllist] Interactive technical computing 
On Friday 09 March 2007 14:13, Robert Fischer wrote: > Performance of Ocaml's bytecode is slower than F#? Really? Sum 1/x for x in [1 .. 10^6]. In OCaml: time (Array.fold_left (+.) 0.) (Array.init 1000000 (fun i > 1. /. float(i+1)));; In F#: time (Array.fold_left (+) 0.) (Array.map ((/) 1.) [1. .. 1000000.]);; OCaml takes 0.256s, F# takes only 0.047s => F# more than 5x faster than OCaml bytecode. On numerical code, F# can be faster than nativecode compiled OCaml. For example, a naive 2^n FFT: let fft a = let n = Array.length a in let j = ref 0 in for i = 0 to n2 do if i < !j then (let t = a.(!j) in a.(!j) < a.(i); a.(i) < t); let m = ref (n/2) in while !m <= !j do j := !j  !m; m := !m/2 done; j := !j + !m done; let j = ref 1 in let b = ref (neg c1) in while !j<n do let w = ref c1 in for m = 0 to !j1 do let i = ref m in while !i < n do let t = !w *@ a.(!i + !j) in a.(!i + !j) < a.(!i) @ t; a.(!i) < a.(!i) +@ t; w := !w *@ !b; i := !i + !j + !j done done; j := !j + !j; b := sqrt !b done; a;; n=1<<15 ocamlopt: 0.164s F#: 0.134s F# is 22% faster, probably thanks to complex numbers in the language. Discrete wavelet transform (4tap Daubechies, n=2^20), OCaml is 25% faster: ocamlopt: 2.03s F#: 2.53s Note that this is apples and oranges because my Windows environment is still only 32 bit. If .NET shows the same performance improvement moving from > From what I understand, F# has a major performance issue resulting from the > way the .Net VM handles allocation. Is that old info? Allocation is slower in F# for two main reasons: 1. The runtime is optimised for C# code that has quite different expected value lifetimes (far fewer very shortlived objects compared to F#). 2. F# supports concurrency, which incurs a big performance cost in allocation and GC. but the consequence of this is that very allocationheavy code (e.g. symbolic rewriting) is up to 4x slower in F#. Lists are also more heavyweight in F#. However, F# regains a lot of performance by having a much faster stdlib. For example, creating a 2^16element set is an allocationintensive task. In OCaml: # module Int = struct type t = int let compare = compare end;; # module IntSet = Set.Make(Int);; ... # time (Array.fold_right IntSet.add (Array.init 65536 (fun i > i))) IntSet.empty;; 0.744047s Compiled with ocamlopt I get 0.065s. For F# I get 0.240s. That's 3.7x slower than nativecode OCaml. However, it is worth noting that the F# equivalent is much more concise, just: time (Array.fold_right Set.add [0 .. 65535]) Set.empty;; primarily because no functors are involved when making a set. The comparison function is taken from the element type. > > I've got a killer highperformance 2D and 3D visualization library > > written in OCaml and I'd like to sell it, but I don't want to sell the > > source code because I value it too much. What can I do? Well, I can port > > it to F# and sell it there. In the mean time, OCaml users are stuck with > > GNUPlot. > > Do you have metrics showing that performance is better with F# than OCaml > in these two cases? In theory, performance should be very close because so much work is done by the graphics card and not the CPU. In practice, I only just figured out how to render static geometry optimally from DirectX, so my F# version still sucks. Once I've integrated that into my purelyfunctional scene graph I'll let you know what the performance is like. I expect F# to win because I'm exploiting concurrency and the application is more numerical than allocation intensive.  Dr Jon D Harrop, Flying Frog Consultancy Ltd. OCaml for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists