From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8313 invoked by alias); 13 Dec 2012 21:07:07 -0000 Received: (qmail 8304 invoked by uid 22791); 13 Dec 2012 21:07:06 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-vc0-f169.google.com (HELO mail-vc0-f169.google.com) (209.85.220.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 13 Dec 2012 21:07:02 +0000 Received: by mail-vc0-f169.google.com with SMTP id gb23so3042019vcb.0 for ; Thu, 13 Dec 2012 13:07:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=wvuN4mF0mlUoAYfJTG4gXo0As9exTnyoYTf2GqcuPuQ=; b=okvBc1EQCPdZwrX96bLPWDqM+k4+XL8XM0WgyOHxtjG+6YuXDL5X7AMf1B9mzTX77F Kr1FKP5DVZ37TgtltCXQW0T69uMgNRnCkYBQ7q0iYB/mCsnOwZG8hhA0Hbcks+AfLcXW MHGgj1WoZ1MC7uaM0wBG6pt2xKsYyFNvyVTBAzwGQg/mQKo9P6GCV3Nudu3mQfrxLy8H SKSfmsWkaZ6JWsefm6T+0YH8rdKjO6LVZDOrjm7ECaATot27v/vUgjqjJnaLfJLTTJBC 2xun9zXDLS9CKODQaTfzvVzRvgIoO+Lxb9AP+X0ZjDVidcVjz52OJWAxHFGKC5+2e6Z4 8J6Q== Received: by 10.52.20.50 with SMTP id k18mr5072619vde.91.1355432821213; Thu, 13 Dec 2012 13:07:01 -0800 (PST) Received: from MacBook-Pro-de-Maxime.local (modemcable184.28-176-173.mc.videotron.ca. [173.176.28.184]) by mx.google.com with ESMTPS id ey7sm1816268ved.0.2012.12.13.13.06.59 (version=SSLv3 cipher=OTHER); Thu, 13 Dec 2012 13:07:00 -0800 (PST) Message-ID: <50CA4378.6090204@calculquebec.ca> Date: Thu, 13 Dec 2012 21:07:00 -0000 From: Maxime Boissonneault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Rhys Ulerich CC: gsl-discuss@sourceware.org Subject: Re: Adding OpenMP support for some of the GSL functions References: <50C791BB.4060303@calculquebec.ca> <50C8F364.2010109@calculquebec.ca> <50C914C4.2060102@calculquebec.ca> <50C9D68A.1050903@calculquebec.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQm8EVSORr9LMSy9jsEoUptMHBVZxoieJgBW+cwAFORnTVVM3iadbsTN2njX10UHwa32eY2o Mailing-List: contact gsl-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gsl-discuss-owner@sourceware.org X-SW-Source: 2012-q4/txt/msg00014.txt.bz2 Hi Rhys, While that is true in theory, it is not applicable in practice, since there can be no "return" within parallel sections. We need one parallel section for each loop in this case. Maxime Le 2012-12-13 11:44, Rhys Ulerich a écrit : >> This feels like you're getting a small >> memory/cache bandwidth increase for the rkf45_apply level-1-BLAS-like >> operations by using multiple cores but the cores are otherwise not >> being used effectively. I say this because a state vector 1e6 doubles >> long will not generally fit in cache. Adding more cores increases the >> amount of cache available. > Hmm... I tentatively take this back on re-thinking how you've added > the #pragma omp lines to the rkf45.c file you attached elsewhere in > this thread. Try using a single > #pragma omp parallel > and then individual lines like > #pragma omp for > at each for loop. Using > #pragma omp parallel for > repeatedly as you've done can introduce excess overhead, depending on > your compiler, because it may incur unnecessary overhead. > > - Rhys