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=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 8E5D1BBAF for ; Fri, 11 Jul 2008 01:33:25 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYCABA5dkjAbSoIiGdsb2JhbACSIQEBAQ8gny4 X-IronPort-AV: E=Sophos;i="4.30,341,1212357600"; d="scan'208";a="27219848" Received: from einhorn.in-berlin.de ([192.109.42.8]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Jul 2008 01:33:25 +0200 X-Envelope-From: oliver@first.in-berlin.de X-Envelope-To: Received: from einhorn.in-berlin.de (localhost [127.0.0.1]) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id m6ANXN3X027514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 11 Jul 2008 01:33:23 +0200 Received: (from www-data@localhost) by einhorn.in-berlin.de (8.13.6/8.13.6/Submit) id m6ANXNaG027512 for caml-list@yquem.inria.fr; Fri, 11 Jul 2008 01:33:23 +0200 X-Authentication-Warning: einhorn.in-berlin.de: www-data set sender to oliver@first.in-berlin.de using -f Received: from dslb-088-073-112-087.pools.arcor-ip.net (dslb-088-073-112-087.pools.arcor-ip.net [88.73.112.87]) by webmail.in-berlin.de (IMP) with HTTP for ; Fri, 11 Jul 2008 01:33:22 +0200 Message-ID: <1215732802.48769c4277e80@webmail.in-berlin.de> Date: Fri, 11 Jul 2008 01:33:22 +0200 From: Oliver Bandel To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] thousands of CPU cores References: <1215717356.24773.17.camel@flake.lan.gerd-stolpmann.de> In-Reply-To: <1215717356.24773.17.camel@flake.lan.gerd-stolpmann.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 X-Spam: no; 0.00; bandel:01 in-berlin:01 gerd:01 stolpmann:01 haskell:01 becuase:01 parallelism:01 ocaml:01 parallelism:01 ocaml:01 cnet:98 monster:98 propaganda:98 threads:01 threads:01 Zitat von Gerd Stolpmann : > > Am Mittwoch, den 09.07.2008, 22:57 -0700 schrieb J C: > > I know that Caml team wanted to see if many-core shared-memory > systems > > were going to stick around before bothering with Caml development > that > > takes advantage of them. > > > > Well, it looks like they are here to stay, after all: > > > > http://news.cnet.com/8301-13924_3-9981760-64.html > > > > As much as I hate to look a gift horse in the mouth, and I think > Caml > > has been a great and grossly underappreciated product, I need to > see > > if writing Caml is a viable code investment for the coming years or > > something like Haskell, SML, F# or even Ada will be a better > long-term > > alternative. > > > > Are there plans to make Caml threads OS-native threads, or add > > OpenMP-style primitives, or otherwise support multiple CPU cores? > And > > if so, roughly in what time frame? > > I wouldn't take this article too seriously. It's just speculation. > Actually, the whole multi-core technology is a challenge for software > development. You cannot simply take a program that runs well on 4 > cores > and expect that it scales up to 400. Software must be designed from > grounds up differently for such architectures. > > Just open up your mind to this perspective: It's a big risk for the > CPU > vendors to haven taken the direction to multi-core. [...] Well Sun has machines with a lot of processors and cores and their machines are really workhorses. :) I had worked on such a monster, if I remember correctly, they had 8 cores, and later had upgraded the system to use 32 (?!). I'm not quite sure on the numbers. So, if we talk about Intel, they now tell us about 1000 cores... ...a while ago they didn't wanted to go into the multicore dirction and had only seen a higher cpu-frequency up into the many-GHz as a solution. There are better architectures. Some DSPs had made more instructions per second with some hundred MHz than some GHz-Intel CPU's, becuase if you only need one cycle to load (more than none) new instructions while working at the current one, this means you are much faster. Now Intel has decided to try more than one Core and their marketing was good.... there already were multicore processors from other technology companies. OK, and while they slept for a while, now they talk about 100'ds, when they have just a few... and who want's this old 32-Bit bullshit? 32 Bit's technology was available on workstations in the middle of the eighties. It's about 20 years old. And Intel processors are good to use, when the winter is cold ;-) But in general multicore machines are a good idea. And also other architectures are a good idea. I mean, there are many ways in which technology can progress, and only selecting one mostly seems to be a marketing thing, IMHO. > Except for some > standard components and some specially-adapted programs multi-core is > more or less not exploited today. Well, on systems like Sun's stations or other high-end servers, there is a lot of parallelism exploited since a while. But not on our small-budget home PCs. > So these vendors are trying to push > the software developers into this direction, and hope they find new > ideas for designing multi-core-capable programs. This article is just > propaganda for this hidden agenda. It can also happen that multi-core > with too many cores turns out as failure - in the sense that the mass > market is not ready for it. OK, mass market is the key-word here! > > In Ocaml you can exploit multi-core currently only by using > multi-processing parallel programs that communicate over message > passing > (and only on Unix). Using multi-processes instead of multi-threads is the usual way on Unix, and it has a lot of advantages. Threads-apologetes often say, threads are the ultimative technology... but processes have the advantage of encapsulation of the wohole environment of the program. This means a higher degree of saveness/security. If there would be processes on Windows like on Unix/Linux, they also would be more interesting to the people. And since Threads are the only thing to make parallelism on Windows, it's the only way, most people know of. Again this is marketing and influence of the marketing leader. Shell was nothing one would mention under Windows, and now M$ created a PowerShell, and then people on Windows one day will ask, if there is something like a shell on Linux. Didn't M$ invented shells? The same with threads... they are heavy in use on Windows, so it seems they must be used. But Processes also can be used - at least on Linux and Unix. On the above mentioned Sun machines there was paralellism used a lot. It's their business. They do it. For them it's normal business. And they heavily use processes. (This does not mean that there are no multithreaded programs... if you have both, it's even better, of course, but the processes can be swapt much easier from processor to processor than threads.) > Actually, it's an excellent language for this > style. Yes. > http://wink.com). Ocaml is an excellent choice because you can > quickly > develop working programs that run 24/7. In the distributed world > stability is quite important. Hehe, stability is important also in non-distributed software. But on the systems that are main stream, this is not the main issue ;-) And threads btw. make programming stable programs quite harder, especially if using C or C++. Ocaml ihas it's advantage here, because it's quite safe/stable. Ciao, Oliver