Hacker News Reader

Comment by fleitz | Hacker News Reader

That's not bad, how about 0.014 milliseconds for 100,000 iterations? On a Core i5 @ 2.6 Ghz

  // Learn more about F# at http://fsharp.net
  open System

  let consume x = ()
  let start = System.Environment.TickCount

  Seq.init 100000 id
  |> Seq.iter (fun x ->  [0..4] |> List.filter (fun y -> (y % 2) = 0) |> consume ) 

  let endTime = System.Environment.TickCount
  printfn "%f milliseconds" (TimeSpan.FromTicks(int64(endTime - start)).TotalMilliseconds)

Output:

  0.014100 milliseconds
  Press any key to continue . . .

I'm sure if I added some java line noise I could get it up to 6 milliseconds. Too bad I didn't need a calendar class to figure out how to get from ticks to milliseconds. It's also really unfortunate that System.Environment.TickCount compiles down to a single assembly instruction. I was really hoping to use a factory pattern in there somewhere. Maybe some IOC containers. What good is a language if you can't write half your code in XML.

View on HN

That is crazy fast... funny, but based on your response I am guessing you don't know why. What could possibly explain such a big difference? Understanding this is what separates a seasoned pro from someone throwing out trollbait comments about XML and assembly instructions.

First off, the resolution of TickCount is not less than 500 milliseconds. Are you sure you are actually timing it right? Maybe you should have used DateTime.Ticks which has a higher resolution. (seriously - I think you need to check your code)

But in any case, let's say your test is actually valid. You mentioned "Java line noise" - not really a real explanation for the difference.

So let me guess for you - maybe your F# runtime knows the function is pure and idempotent, and after running it once it probably just cached the output. So your run doesn't actually execute the filter across the list for every iteration, whereas my Java code did.

I could rewrite my Java code to return the same array over and over after it has been computed once, but it sure won't look as clean as a functional language like F#. I grant you that, and that's one of the reasons I prefer functional languages to Java.

Next time maybe put a little more thought into the response if you actually really have no idea why your program said "0.014100 milliseconds".

TickCount has 1 millisecond accuray and it's actually milliseconds, which is what tipped me off to the low numbers. It actually takes 140 milliseconds to execute. I redid the code to not use Seqs and now it's down to 15 ms.

  // Learn more about F# at http://fsharp.net
  open System

  let consume x = ()
  let start = System.Environment.TickCount
  let arr = [| 1..4 |] 
  for i = 1 to 100000 do
    arr
    |> Array.filter (fun y -> (y % 2) = 0) 
    |> consume 

  let endTime = System.Environment.TickCount
  printf "%d milliseconds" (endTime - start)

Thanks for the follow up.

I do hope to learn more about F#, I am hearing good things about it.

http://flyingfrogblog.blogspot.com/2009/07/ocaml-vs-f-burrow...

Great article about how F# can approach the speed of C with some fancy inlining.

Reply on news.ycombinator.com