From dev-return-6195-archive-asf-public=cust-asf.ponee.io@mxnet.incubator.apache.org Tue Jun 4 00:21:26 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id B1CF918062F for ; Tue, 4 Jun 2019 02:21:25 +0200 (CEST) Received: (qmail 89232 invoked by uid 500); 4 Jun 2019 00:21:24 -0000 Mailing-List: contact dev-help@mxnet.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@mxnet.incubator.apache.org Delivered-To: mailing list dev@mxnet.incubator.apache.org Received: (qmail 89221 invoked by uid 99); 4 Jun 2019 00:21:24 -0000 Received: from ui-eu-01.ponee.io (HELO localhost) (176.9.59.70) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Jun 2019 00:21:24 +0000 Subject: Context-specific operator parameters References: Date: Tue, 04 Jun 2019 00:21:19 -0000 From: Dick Carter X-Mailer: LuaSocket 3.0-rc1 Content-Type: text/plain; charset=utf-8 To: MIME-Version: 1.0 In-Reply-To: x-ponymail-agent: PonyMail Composer/0.3 x-ponymail-sender: 058662bba17b95dfd8237b2c35f97629d95dc247 Message-ID: MXNet has a number of context-specific operator parameters: 'cudnn_tune', 'cudnn_off' and 'workspace' are parameters that control the behavior of Convolution on gpu contexts with NVIDIA gpus. Even with these, there would be benefits to having additional parameters, e.g. to set Convolution algos by number, or force the compute precision to float16. With the desire to support multiple backends and a growing number of operators, it's time to ask the question, "Is this scalable?" I propose that, rather than adding a new parameter at the Python level for each new backend-specific parameter 'knob', all context-specific parameters be swept into a single dictionary, called e.g. 'ctx_params': Convolution(..., ctx_params= {'cudnn_tune': 2, 'cudnn_off': False, 'workspace': 2000}, ...) I'll stop short of working out all the details to hopefully generate more discussion. Some open questions: Do all backends share the same namespace, or do we have separate 'gpu_ctx_params', 'cpu_ctx_params', etc.? Is there a clean extension to the general parameter parsing facility of dmlc to handle this dictionary, and what form do these extension params take in the backend, Map? And while this proposes to organize and consolidate these context-specific parameters at the Python level, we'd need to tolerate (and auto-create) documentation for these new parameters. Other approaches welcome.