Back to Questions
3.6k
views2
comments
ocaml vs F# printf implementation question
f#ocaml

Hello All,

This is my first post to the forum. I have been a avid reader of the forums for sometime now but have not had anything worthy of asking (I hope) until now.

I am working on translating the The Computer Language Shootout [link:shootout.alioth.debian.org] pidigits benchmark from ocaml to F# and came accross some differences in the implemetation of printf.

The original line 28 of the source code is as follows;

1

if n == 0 then printf "%*s\t:%i\n" (10-col) "" (row+col) else

My translation is as follows;

1

if n = 0 then printf "%10s\t:%i\n" (string_of_int(10-col)) (row+col) else

The F# implementation does not seem to support the * width specificier in printf. My work around is to fix the width to 10. Clearly as basic hack. Is their a more elegant way to do this? Am I correct about the lack of F# support for the use of the * specificer?

Secondly the line has two separate type mismatches and one overload operator error which I have worked arounf. Again is there a more elegant way to do this? I am lacking the conextual knowledge about why the changes are nesseary.

I would like to see if I can get The Computer Language Shootout [link:shootout.alioth.debian.org] to provide F# coverage. This is the place that started my ocaml and F# journey so it would be a full circle thing for me. The pidigits benchmark is of interest as it is the worst ocaml benchmark compared to C gcc. I would be interested to see how F# compares.


Regards
Miles Athea

.

The original line 28 of the source code is as follows;

1

if n == 0 then printf "%*s\t:%i\n" (10-col) "" (row+col) else

My translation is as follows;

1

if n = 0 then printf "%10s\t:%i\n" (string_of_int(10-col)) (row+col) else

A workaround would be to format explicitely the strings:

1

if n = 0 then print_string (String.concat "" [String.make (10 - col) ' '; "\t:"; string_of_int (row+col); "\n"])

It is probably better to use a StringBuilder explicitely:

1
2
3
4
5
6
7
8
9
10
11

let blanks = String.make 10 ' '
and buf = new System.Text.StringBuilder() in
(* ... *)
if n = 0 then begin
    buf.Length <- 0;
    buf.Append(blanks, 0, 10 - col);
    buf.Append("\t:");
    buf.Append(row+col);
    buf.Append('\n');
    print_string (buf.ToString())
end else (* ... *)

The idea is to allocate the string with padding blanks and the buffer globally at the start of the program, and to reuse the buffer in each iteration of the printing loop.

Regards,
Matías.

By on 1/26/2007 11:53 AM ()

Hi guys,

No, we don't support the * modifier, though we will look into doing so. It's nifty.

It's great to see you looking at the benchmarks - please do work with us whenever you find issues - there's nothing like finding a benchmark case where we do noticably worse to spur us into action.

FWIW we tend to profile and tune on Windows/.NET 2.0, but I believe the benchmark is run on Mono. I don't think it will make so much difference. It's nice to know the Mono guys are working hard to improve our performance :-)

I've asked James Margetson to look at the performance of the F# BigNum package on pidigits (he wrote the BigNum package originally). At a first glance on Windows we do approximately as well as OCaml (we're a little slower on N < ~1000, faster on large N > ~10000), which is fine considering we first optimized the bignum package to make sure it used the most recent algorithms to help it scale to truly massive numbers (I think that's why we're faster on large N). I think there's room for us to make micro-improvements from here for the small N cases.

Since you will be running on Mono you should alternatively be able to simply copy and tweak the C# code that uses the Mono bignum package. In all cases you would minimally expect the F# benchmark performance to match that of the C# performance, though the "elegant" functional programming (or F#-specific) solution may have a different performance profile (soemtimes better, sometimes worse).

One final thing: I do know our printf implementation is slower than OCaml's, so don't use that in inner loops. However I think no benchmarks use it in that way.

By on 1/26/2007 12:58 PM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper