Return-Path: X-Original-To: apmail-incubator-hama-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-hama-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6C2469B1C for ; Fri, 25 Nov 2011 02:17:21 +0000 (UTC) Received: (qmail 88349 invoked by uid 500); 25 Nov 2011 02:17:21 -0000 Delivered-To: apmail-incubator-hama-dev-archive@incubator.apache.org Received: (qmail 88316 invoked by uid 500); 25 Nov 2011 02:17:21 -0000 Mailing-List: contact hama-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hama-dev@incubator.apache.org Delivered-To: mailing list hama-dev@incubator.apache.org Received: (qmail 88308 invoked by uid 99); 25 Nov 2011 02:17:21 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 25 Nov 2011 02:17:21 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of clin4j@googlemail.com designates 209.85.213.175 as permitted sender) Received: from [209.85.213.175] (HELO mail-yx0-f175.google.com) (209.85.213.175) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 25 Nov 2011 02:17:16 +0000 Received: by yenm2 with SMTP id m2so3092005yen.6 for ; Thu, 24 Nov 2011 18:16:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=NcPKCV1hVr00UkJoR0Oy2HAPFzYIT6Rphvcu7kY7TjE=; b=oFL0n8EtM2UYo62Tf9emmmrCqBXNZbOrjjYR2Q4mPkgHsmDqSASY2+XzcxIP7+u0In 6FQcf9JAD5HvYIU2NEbVeaMkYzKUS+zEzokPjRUi0M0NbxOZY9TAYjEyhrrEXaCYczeu FBAgj7crh8l/CE9xD2psVHO7iCvGdBdABaIII= MIME-Version: 1.0 Received: by 10.182.77.164 with SMTP id t4mr9948983obw.9.1322187415370; Thu, 24 Nov 2011 18:16:55 -0800 (PST) Received: by 10.182.53.201 with HTTP; Thu, 24 Nov 2011 18:16:55 -0800 (PST) In-Reply-To: References: Date: Fri, 25 Nov 2011 10:16:55 +0800 Message-ID: Subject: Re: Add counting feature to get the total number of message exchanges From: Chia-Hung Lin To: hama-dev@incubator.apache.org Content-Type: text/plain; charset=ISO-8859-1 +1 for pluggable feature/ hadoop's counter arch On 25 November 2011 01:05, Thomas Jungblut wrote: > Great, I open an issue for this counter stuff. > > 2011/11/24 Edward J. Yoon > >> >> I think it would be good as a 'pluggable' feature as this counting >> could>> impact performances. >> and >> >> > It is difficult to say whether we actually need this.* >> > *In case of SSSP it is useful, but as Tommaso says it can degrade >> >> I agree with you. If possible, let's provide as a optional feature. >> >> > What do you think of a similar architecture of Counters like in Hadoop? >> >> Good. >> >> Currently, our Job client reports only shows the total number of >> supersteps. I think that the Job reports needs to be strengthened. :-) >> >> On Thu, Nov 24, 2011 at 11:05 PM, Thomas Jungblut >> wrote: >> > It is difficult to say whether we actually need this.* >> > *In case of SSSP it is useful, but as Tommaso says it can degrade >> > performance for every other BSP by increasing the cost of the sync. >> > >> > What do you think of a similar architecture of Counters like in Hadoop? >> > This could contain even more information, e.G. the number of bytes >> > transferred etc. >> > >> > 2011/11/24 Tommaso Teofili >> > >> >> Hello Edward, >> >> >> >> I think it would be good as a 'pluggable' feature as this counting could >> >> impact performances. >> >> So it'd be useful when explicitly "debugging" while it should be, in my >> >> opinion, disabled by default. >> >> >> >> My 2 cents. >> >> Tommaso >> >> >> >> >> >> 2011/11/24 Edward J. Yoon >> >> >> >> > Hi all, >> >> > >> >> > I'd like to add counting feature to get the total number of message >> >> > exchanges during one synchronization among BSP tasks. Before leave >> >> > barrier in sync() method, each task can report their counts. >> >> > >> >> > This information will be useful to user and, some applications (for >> >> > example, the sync cost of current SSSP example can be reduced to 1/3). >> >> > Should we add this feature? >> >> > >> >> > -- >> >> > Best Regards, Edward J. Yoon >> >> > @eddieyoon >> >> > >> >> >> > >> > >> > >> > -- >> > Thomas Jungblut >> > Berlin >> > >> >> >> >> -- >> Best Regards, Edward J. Yoon >> @eddieyoon >> > > > > -- > Thomas Jungblut > Berlin >