From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 BBB39BBAF for ; Tue, 22 Dec 2009 05:40:47 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0CALTcL0vRVdnai2dsb2JhbACECowEhA2Gez8BAQEKCwoHEQWrASkKgSiFBIhjAQIDBYEqgi1SBIpn X-IronPort-AV: E=Sophos;i="4.47,434,1257116400"; d="scan'208";a="40396389" Received: from mail-gx0-f218.google.com ([209.85.217.218]) by mail3-smtp-sop.national.inria.fr with ESMTP; 22 Dec 2009 05:40:47 +0100 Received: by gxk10 with SMTP id 10so5650609gxk.3 for ; Mon, 21 Dec 2009 20:40:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IGLJO86Ax91OBThYTP92piUuupRFtc9/8JaXXxozWlM=; b=S8QUVcGV5R6Ab8e6rbtJqAzNAIWClhfNVwFyMcfhsHYxCnY/ssfT19eUvF0hPNiAC6 BrLfwmUw/VDllOcM5EaxX7OMUAZr954NwGETS1+THSabaY+0jFLalB/HrFMkrVwCbiSl ykAV8TYE6ghg1W222Hzj9x+GJUs/FpFIuUfEw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=XffZTQ30CclKUR/NkTHPxNUSXfEnBwWQmrq29/t1kZ1n9yk0piG2uyGMnhOv/atE/l bgRXUfG0Hv/Rx7tsgND7KdP2HMhFmxpPIUHlxT0ykeNDTCPfqcRr0z4Lb1b1b8DTk/t/ UNt8b5akXRh+5y/6oQaYF+99BoOmQzG7LrgeA= MIME-Version: 1.0 Received: by 10.101.130.8 with SMTP id h8mr13351ann.168.1261456846027; Mon, 21 Dec 2009 20:40:46 -0800 (PST) Reply-To: linasvepstas@gmail.com In-Reply-To: <4a708d20912200638q5e7d72acu9cae3b564ada085d@mail.gmail.com> References: <3d13dcfc0911250305i43a684e4u5a96ec420b6ce350@mail.gmail.com> <200911292311.29580.jon@ffconsultancy.com> <4a708d20911291416x2be905f7p93f559543a77d97f@mail.gmail.com> <3ae3aa420911300830h63a04b21r2e09fb4e34cdb7f7@mail.gmail.com> <4a708d20912200638q5e7d72acu9cae3b564ada085d@mail.gmail.com> Date: Mon, 21 Dec 2009 22:40:46 -0600 Message-ID: <3ae3aa420912212040i23309f7cw4485db33352c1853@mail.gmail.com> Subject: Re: [Caml-list] Looking for information regarding use of OCaml in scientific computing and simulation From: Linas Vepstas To: Lukasz Stafiniak Cc: Dario Teixeira , Erik Rigtorp , caml-list Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam: no; 0.00; ocaml:01 lukasz:01 lukasz:01 ocaml:01 bug:01 bug:01 non-uniform:01 locality:01 yikes:98 2009:98 20,:98 2009:98 closures:01 homogeneous:01 caml-list:01 Hi Lukasz, Yikes! Care to start an argument on my behalf? 2009/12/20 Lukasz Stafiniak : > ---------- Forwarded message ---------- > From: Dario Teixeira > Date: Sun, Dec 20, 2009 at 3:27 PM > Subject: Re: [Caml-list] Re: OCaml is =C2=A0broken > To: Erik Rigtorp > Cc: caml-list > > > Hi, > >> It's too bad that INRIA is not interested in fixing this bug. No >> matter what people say I consider this a bug. Two cores is standard by >> now, I'm used to 8, next year 32 and so on. OCaml will only become >> more and more irrelevant. I hate to see that happening. Hear, hear! > This is a perennial topic in this list. =C2=A0Without meaning to dwell to= o > long on old arguments, I simply ask you to consider the following: > > - Do you really think a concurrent GC with shared memory will scale neatl= y > =C2=A0to those 32 cores? Time to start funding GC research? Is concurrent GC really that bad? > - Will memory access remain homogeneous for all cores as soon as we get i= nto > =C2=A0the dozens of cores? Yes, NUMA (non-uniform memory access) is well-known to be painful to optimize for, due to the difficulty of predicting locality of reference. But is tuning for NUMA harder than creating/using message-passing code? Not by a long-shot. Anyway, CPU designers understand that NUMA is unpopular with software types, and is trying hard to to make mem access as homogenous as possible. Look at 'blue waters' for an extreme example. > - Have you considered that many Ocaml users prefer a GC that offers maxim= um > =C2=A0single core performance, because their application is parallelised = via > =C2=A0multiple processes communicating via message passing? Have you ever tried writing a significant or complex algo using message passing? Its fun if you have nothing better to to -- its a good intellectual challenge. You can even learn some interesting computer science while you do it. However, if you are interested in merely using the system to do your "real" work, then writing message-passing code is an utter waste of time -- its difficult, time-consuming, error prone, hard to balance and optimize & tune, works well only for "embarrasingly parallel" code, etc. Even the evil slow-down of NUMA is often better than trying to performance-tune a message-passing system. Let me put it this way: suggesting that programmers can write their own message-passing system is kind of like telling them that they can write their own garbage-collection system, or design their own closures, or they can go create their own type system. Of course they can ... and if they wanted to do that, they would be programming in C or assembly, and would probably be designing new languages. Cause by the time you get done with message passing, you've created a significant and rich programming system that resembles a poorly-designed language... been there, done that. > In this context, > =C2=A0your "bug" is actually a "feature". Why not give people the choice? --linas disclaimer: I don't (currently) use caml, -- this is an outsiders viewpoint.