From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id B344FBBAF for ; Fri, 25 Sep 2009 06:07:32 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABbfu0qCNhAB/2dsb2JhbADXE4QcBYI9 X-IronPort-AV: E=Sophos;i="4.44,449,1249250400"; d="scan'208";a="34945661" Received: from kurims.kurims.kyoto-u.ac.jp ([130.54.16.1]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Sep 2009 06:07:31 +0200 Received: from localhost (orion [130.54.16.5]) by kurims.kurims.kyoto-u.ac.jp (8.13.8/8.13.8) with ESMTP id n8P47L3E013348; Fri, 25 Sep 2009 13:07:22 +0900 (JST) Date: Fri, 25 Sep 2009 13:07:21 +0900 (JST) Message-Id: <20090925.130721.70227045.garrigue@math.nagoya-u.ac.jp> To: jon@ffconsultancy.com Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] OC4MC : OCaml for Multicore architectures From: Jacques Garrigue In-Reply-To: <200909242209.50565.jon@ffconsultancy.com> References: <200909241409.56894.jon@ffconsultancy.com> <20090924164933.GA5637@annexia.org> <200909242209.50565.jon@ffconsultancy.com> X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; ocaml:01 ocaml:01 iirc:01 hashtables:01 hashing:01 hashing:01 touted:01 hpc:01 gcc:01 speedup:01 speedup:01 bounded:01 blas:01 computations:01 integers:01 First, like everybody else, I'd like very much to try this out. Is there any chance it could compile on Snow Leopard :-) (I suppose it's near impossible, but still ask...) From: Jon Harrop > Visual Basic has been a *lot* faster than OCaml for several years now, not > least because it makes efficient multicore programming easy. Even Python is > beating OCaml on benchmarks now: > > http://flyingfrogblog.blogspot.com/2009/04/f-vs-ocaml-vs-haskell-hash-table.html IIRC, currently Visual Basic is just a "skin" for C#. You have to write all the types, so it's rather hard to call it "Basic". And yes, MS has invested a lot in the CLR, and that pays. Your benchmark seems strange to me, as you are comparing apples with oranges. Hashtables in Python are a basic feature of the language, and they are of course implemented in C. In ocaml, they are implemented in ocaml (except the hashing function, which has to be polymorphic), using an array of association lists! (Actually the pairs are flattened for better performance, but still) What is impressive is that you don't need any special optimization to get reasonably good performance. Actually the only tuning you need is to start from a reasonable table size, which you didn't (never start from 1, you will have to redo all the hashing every time the table needs to be grown). > Even if that were not the case, the idea of cherry picking interpreted > scripting languages to compete with because OCaml has fallen so far behind > mainstream languages (let alone modern languages) is embarrassing. What's > next, OCaml vs Bash for your high performance needs? OCaml was never touted as an HPC language! The only claim I've seen is that it intends to stay within 2x of C for most applications. (Which is not so easy these days, gcc getting much faster.) Actually, I believe that Philippe's point is rather different. Making a functional language work well on multicores is difficult. If I tell you that you just have to modify a bit your program to get a near linear speedup, then it looks great. But in practice it is rather having to rethink completely your algorithm, to eventually get a speedup bounded by bandwidth, and starting from a point lower than the original single thread program. There are applications for that (ray tracing is one), but this is not the kind of needs most people have. By the way, I was discussing with numerical computation people working on BLAS the other day, and their answer was clear: if you need high performance, better use a grid than SMP, since bandwidth is paramount. And you have to write in C or FORTRAN (or asm), because the timing of instructions matter. The funniest part was that those people were working on integer computations, but had to stick to floating point, because timing on integers is unpredictable, making synchronization harder. Cheers, Jacques