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.2 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR 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 2C7C9BB84 for ; Sat, 19 Jul 2008 14:06:49 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtsCALx1gUjAbSoIiGdsb2JhbACSPgEBAQ8gmyg X-IronPort-AV: E=Sophos;i="4.31,214,1215381600"; d="scan'208";a="27484084" Received: from einhorn.in-berlin.de ([192.109.42.8]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jul 2008 14:06:34 +0200 X-Envelope-From: oliver@first.in-berlin.de 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 m6JC6V30007749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 19 Jul 2008 14:06:31 +0200 Received: (from www-data@localhost) by einhorn.in-berlin.de (8.13.6/8.13.6/Submit) id m6JC6U5F007740; Sat, 19 Jul 2008 14:06:30 +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-068-085.pools.arcor-ip.net (dslb-088-073-068-085.pools.arcor-ip.net [88.73.68.85]) by webmail.in-berlin.de (IMP) with HTTP for ; Sat, 19 Jul 2008 14:06:30 +0200 Message-ID: <1216469190.4881d8c656ee5@webmail.in-berlin.de> Date: Sat, 19 Jul 2008 14:06:30 +0200 From: Oliver Bandel To: caml-list@yquem.inria.fr Cc: J C Subject: Re: [Caml-list] thousands of CPU cores References: <1215717356.24773.17.camel@flake.lan.gerd-stolpmann.de> <200807111101.46248.peng.zang@gmail.com> <1215822225.4877f991876d5@webmail.in-berlin.de> In-Reply-To: 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 bandel:01 in-berlin:01 wikipedia:01 wiki:01 avoided:01 jhc:98 0033:98 threads:01 threads:01 wrote:01 oliver:01 oliver:01 caml-list:01 Zitat von J C : > On Fri, Jul 11, 2008 at 5:23 PM, Oliver Bandel > wrote: > > > For example, if you have a non-profit research project, > > you can use the BOINC infrastructure, which provides > > about 580000 PCs to help you :) > > > > > http://en.wikipedia.org/wiki/Berkeley_Open_Infrastructure_for_Network_Computing > > > > There is no Shared-Mem as we know it from our local PCs, there > > is distributed calculation around the whole planet. > > > > Threads will not help there ;-) > > But on each of those PCs there may be 1000 cores in the near future. [...] Yes, maybe. I don't say that global networked computer power substitutes multicore-machines. But on multicore-machines one could use multiple processes. And I don't say that threads will not help sometimes, I just think, they are over estimated. BTW: I've forgotten where the article was, but there was an introductional article on programming of encryption algoritms, and the author said: "don't use multithreaded code", because it's too easy to have weak code that makes the whole system unsafe. I agree with him. But I also think, not only in encryption-programs threads should be avoided, if possible. I don't mean never use threads, I just mean: use only, if really necessary. Multiple processes are less sensitive to programming errors than multithreaded code. processes give you encapsulation. If one process crashes, the others do not. If you crash one thread, the whole application is affected. Ciao, Oliver