Return-Path: X-Original-To: apmail-hadoop-hdfs-user-archive@minotaur.apache.org Delivered-To: apmail-hadoop-hdfs-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E252AD0F5 for ; Thu, 11 Oct 2012 19:04:12 +0000 (UTC) Received: (qmail 55511 invoked by uid 500); 11 Oct 2012 19:04:08 -0000 Delivered-To: apmail-hadoop-hdfs-user-archive@hadoop.apache.org Received: (qmail 55412 invoked by uid 500); 11 Oct 2012 19:04:08 -0000 Mailing-List: contact user-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hadoop.apache.org Delivered-To: mailing list user@hadoop.apache.org Received: (qmail 55405 invoked by uid 99); 11 Oct 2012 19:04:08 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Oct 2012 19:04:08 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of russell.jurney@gmail.com designates 209.85.216.41 as permitted sender) Received: from [209.85.216.41] (HELO mail-qa0-f41.google.com) (209.85.216.41) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Oct 2012 19:04:01 +0000 Received: by mail-qa0-f41.google.com with SMTP id p27so6741089qat.14 for ; Thu, 11 Oct 2012 12:03:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :content-type; bh=0iR08+PTK1TfpYRfoZijZBynLAVl+LqtZwRsXTyJ8xc=; b=DOM4b8RXsJWrOIOr/8Ms8hW1pc2/acWiCzSqYzyvm9huA8GdBSFDx2GEiMtSs24+0i Id2qYJr+Qnpi4M3j3y9EVfYaGMGavcS3wDFVRVUHIYiqiN+S9N9x88o0/TXIZJzh6JNc fUPXg41JiNIT+lIojakHWjrN0O63YK1+igq0eZbcLHsGLasLxMYqKSj4DQs5wdjmXnNB eptwjvW3Nrgwe0JtnLNVr/25bGn/nwN8b+1+OqyV016fPYELSUAsdO9zdLlRNSes/KKF utAxY8tZZ1suVrCJlw4x5wJTfD0xYjbJF49KM1QP4vDMOZ4i1um1mAfEsReX5DI8Fgm7 oB4Q== Received: by 10.224.78.140 with SMTP id l12mr3425925qak.48.1349982220700; Thu, 11 Oct 2012 12:03:40 -0700 (PDT) References: <4215577957656723663@unknownmsgid> From: Russell Jurney In-Reply-To: Mime-Version: 1.0 (1.0) Date: Thu, 11 Oct 2012 12:03:40 -0700 Message-ID: <5658151512625454836@unknownmsgid> Subject: Re: Why they recommend this (CPU) ? To: "user@hadoop.apache.org" Content-Type: multipart/alternative; boundary=20cf3074d876b7cb7a04cbcd3ac5 --20cf3074d876b7cb7a04cbcd3ac5 Content-Type: text/plain; charset=ISO-8859-1 My own clusters are too temporary and virtual for me to notice. I haven't thought of clock speed as having mattered in a long time, so I'm curious what kind of use cases might benefit from faster cores. Is there a category in some way where this sweet spot for faster cores occurs? Russell Jurney http://datasyndrome.com On Oct 11, 2012, at 11:39 AM, Ted Dunning wrote: You should measure your workload. Your experience will vary dramatically with different computations. On Thu, Oct 11, 2012 at 10:56 AM, Russell Jurney wrote: > Anyone got data on this? This is interesting, and somewhat > counter-intuitive. > > Russell Jurney http://datasyndrome.com > > On Oct 11, 2012, at 10:47 AM, Jay Vyas wrote: > > > Presumably, if you have a reasonable number of cores - speeding the > cores up will be better than forking a task into smaller and smaller chunks > - because at some point the overhead of multiple processes would be a > bottleneck - maybe due to streaming reads and writes? I'm sure each and > every problem has a different sweet spot. > --20cf3074d876b7cb7a04cbcd3ac5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
My own clusters are too t= emporary and virtual for me to notice. I haven't thought of clock speed= as having mattered in a long time, so I'm curious what kind of use cas= es might benefit from faster cores. Is there a category in some way where t= his sweet spot for faster cores occurs?

Russell Jurney http://datasyndrome.= com

On Oct 11, 2012, at 11:39 AM, Ted Dunning <tdunning@maprtech.com> wrote:
<= br>
You should measure your wor= kload. =A0Your experience will vary dramatically with different computation= s.

On Thu, Oct 11, 2012 at 10:56 AM, Russ= ell Jurney <russell.jurney@gmail.com> wrote:
Anyone got data on this? This is interesting= , and somewhat counter-intuitive.

Russell Jurney http:/= /datasyndrome.com

On Oct 11, 2012, at 10:47 AM, Jay Vyas <jayunit100@gmail.com> wrote:

> Presumably, if you have a reasonable number of cores - speeding the co= res up will be better than forking a task into smaller and smaller chunks -= because at some point the overhead of multiple processes would be a bottle= neck - maybe due to streaming reads and writes? =A0I'm sure each and ev= ery problem has a different sweet spot.

--20cf3074d876b7cb7a04cbcd3ac5--