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.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 4BB14BC69 for ; Wed, 22 Aug 2007 13:33:43 +0200 (CEST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.174]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l7MBXgbt024258 for ; Wed, 22 Aug 2007 13:33:43 +0200 Received: from babylon.cip.physik.uni-muenchen.de [141.84.136.30] (helo=[152.78.96.56]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML31I-1INoSW1MaI-0001bT; Wed, 22 Aug 2007 13:33:36 +0200 Message-ID: <46CC1F19.9020409@functionality.de> Date: Wed, 22 Aug 2007 12:33:45 +0100 From: Thomas Fischbacher User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060607 Debian/1.7.12-1.2 X-Accept-Language: en MIME-Version: 1.0 To: skaller Cc: Richard Jones , Oliver Bandel , Caml-list List Subject: Re: [Caml-list] If OCaml were a car References: <20070818192157.GA11789@furbychan.cocan.org> <6806cf750708181324l724823c6w304f9088980c3316@mail.gmail.com> <46C76557.5050308@cs.caltech.edu> <56864F61-40F3-4F03-9823-6D510AD5320B@epfl.ch> <1187639685.46c9f1859d769@webmail.in-berlin.de> <1187657274.18344.9.camel@rosella.wigram> <1187689892.46cab5a45112e@webmail.in-berlin.de> <1187692228.7354.21.camel@rosella.wigram> <20070821185720.GC32626@furbychan.cocan.org> <1187750976.9072.39.camel@rosella.wigram> In-Reply-To: <1187750976.9072.39.camel@rosella.wigram> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX19q0weAckwTu9KwTWXc2GIZC6nop2Iv3AIcVBP M4S5QTgqgWgn4mVClfzdhPc2+b7uwF6NU62aTSc8DHOhj+kvw3 Ee8njW0SeRtqUNvjHtC5Q== X-Miltered: at concorde with ID 46CC1F16.005 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 nodes:01 organic:98 imho:01 wrote:01 caml-list:01 behaviour:01 theoretical:03 acknowledged:03 acknowledged:03 programming:03 programming:03 debian:04 processors:04 size:95 John Skaller wrote: >>This might come back and bite you in a couple of years you've got 16- >>and 32-core processors and you find your parallel GC / operating >>system really don't scale. > > Wrong approach IMHO. There are physical limits on localisation: > the speed of light and Heisenberg's constant. We know from > simple observation of organic systems, that systems clump > at various levels. If one look e.g. at the distribution function of something like the size of debian packages, one will find that it follows a power law (dN/N(size) ~ a*size^b) remarkably well over multiple orders of magnitude. Similar distributions can be observed for many systems. There are deep fundamental reasons that tell us that we should expect something like this on very general grounds whenever three things come together: (1) We have "frustration" in the system in the sense that there are multiple stable configurations, and lots of them. (2) The system's constituents are linked up in such a way that reducing the "internal stress" in one place increases the internal stress in its neighbourhood, and (3) The individual components are networked in an effectively more-than-one-dimensional way. (So, the number of nodes reached increases with the number of hops.) These are very general properties that come together in many different systems. Now, in 1987 a bunch of theoretical physicists (Bak, Tang, and Weisenfeld) had a deep insight that whenever this happens, then all the interesting distributions one can derive from such a system should turn out to follow power-law behaviour. (The key idea is to look at the weakest condition that gives stability, which will determine the system's structure, as every stronger condition would constrain configuration space too much.) In essence, Perl did two things right: (1) It properly acknowledged that most problems are small problems that should be resolvable as a one-line job (unlike C++ which believes all problems to be huge tasks - if they are not, they first have to be turned into one so that one then can use C++ to solve them), and (2) it also acknowledged that human language is irregular in some funny but far from chaotic way, and tried to mimick some of that irregularity in order to make programming more natural and hence less tiring. Quite in general, what deeply worries me (in programming as well as in a much broader context concerning how our present-day society works) is that we do not pay proper respect to these fundamental mechanisms that always cause activity on a variety of different scales. When making decisions, our reasoning all too often starts out from false assumptions on scale distributions of system sizes. In particular, we often design our systems based on assumptions of extreme scales (say, extreme centralization or extreme decentralization) rather than "reasonable assumptions about natural distributions". That is fundamentally wrong, and Thermodynamics/statistical mechanics can even prove this. :-) -- best regards, Thomas Fischbacher tf@functionality.de