Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 91470200BC5 for ; Tue, 22 Nov 2016 19:54:37 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 8FEA5160B0C; Tue, 22 Nov 2016 18:54:37 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id D8387160AF1 for ; Tue, 22 Nov 2016 19:54:36 +0100 (CET) Received: (qmail 58588 invoked by uid 500); 22 Nov 2016 18:54:36 -0000 Mailing-List: contact dev-help@systemml.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@systemml.incubator.apache.org Delivered-To: mailing list dev@systemml.incubator.apache.org Received: (qmail 58573 invoked by uid 99); 22 Nov 2016 18:54:35 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Nov 2016 18:54:35 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 4CC551A9AE9 for ; Tue, 22 Nov 2016 18:54:35 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -3.7 X-Spam-Level: X-Spam-Status: No, score=-3.7 tagged_above=-999 required=6.31 tests=[RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.999, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id Ky7RvXWNMYp2 for ; Tue, 22 Nov 2016 18:54:33 +0000 (UTC) Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.66]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 661495F39A for ; Tue, 22 Nov 2016 18:54:33 +0000 (UTC) Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 6211D2097C for ; Tue, 22 Nov 2016 19:54:22 +0100 (CET) Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 3tNZQ60lCpz105f for ; Tue, 22 Nov 2016 19:54:22 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 22 Nov 2016 19:54:22 +0100 From: fschueler@posteo.de To: dev@systemml.incubator.apache.org Subject: Re: Parfor semantics In-Reply-To: <577b77b8-8a66-620b-ceca-ff24a04041ef@gmail.com> References: <4f097e10a8e5734af4494daaa138b17d@posteo.de> <577b77b8-8a66-620b-ceca-ff24a04041ef@gmail.com> Message-ID: <460842a0fdc82e9bb327b7fb0689d8fb@posteo.de> X-Sender: fschueler@posteo.de User-Agent: Posteo Webmail archived-at: Tue, 22 Nov 2016 18:54:37 -0000 The constrained optimizer doesn't seem to know about a REMOTE_SPARK execution mode and either sets CP or REMOTE_MR. I can open a jira for that and provide a fix. Felix Am 22.11.2016 02:07 schrieb Matthias Boehm: > yes, this came up several times - initially we only supported opt=NONE > where users had to specify all other parameters. Meanwhile, there is a > so-called "constrained optimizer" that does the same as the rule-based > optimizer but respects any given parameters. Please try something like > this: > > parfor (i in 1:10, opt=CONSTRAINED, par=10, mode=REMOTE_SPARK) { > // some code here > } > > > Regards, > Matthias > > On 11/22/2016 12:33 AM, fschueler@posteo.de wrote: >> While debugging some ParFor code it became clear that the parameters >> for >> parfor can be easily overwritten by the optimizer. >> One example is when I write: >> >> ``` >> parfor (i in 1:10, par=10, mode=REMOTE_SPARK) { >> // some code here >> } >> ``` >> >> Depending on the data size and cluster resources, the optimizer >> (OptimizerRuleBased.java, line 844) will recognize that the work can >> be >> done locally and overwrite it to local execution. This might be valid >> and definitely works (in my case) but kind of contradicts what I want >> SystemML to do. >> I wonder if we should disable this optimization in case a concrete >> execution mode is given and go with the mode that is provided. >> >> Felix >> >>