From owner-freebsd-hackers@freebsd.org Sun Jan 6 17:50:39 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D858E1495810 for ; Sun, 6 Jan 2019 17:50:38 +0000 (UTC) (envelope-from brian@aceshardware.com) Received: from mail.aceshardware.com (mail.aceshardware.com [52.52.37.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0BA338795C for ; Sun, 6 Jan 2019 17:50:37 +0000 (UTC) (envelope-from brian@aceshardware.com) Received: from [10.0.0.102] (unknown [71.145.208.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.aceshardware.com (Postfix) with ESMTPSA id 1FAFC201313 for ; Sun, 6 Jan 2019 17:50:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aceshardware.com; s=dkim; t=1546797036; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZJ3B9hv+LWs9hXY5LKbX8JtBHhQ6vXQzBm0Ug4YQa1g=; b=Wmt+7w1Ka5PxspbBEqnkeNH1YvX2fQgb+OAR4LngagWRE0IQJdUyoCQjrWPrT/JvGkhGFt blJPOrdWAVsufsCQ59x35JCBQJKI9mYV2aHNgfQvOHkGI7qJ2w7vfog8L1yMZYzxOE+wFt 9sH2GX+Yq1N2WMbsLB1MR0o1ghC4+347/JCvDtVkqBREIr/qbLeiQnh+8v9JdZmVpu43SN f5lWkAqYK9/DRs8Zp7en6978Am3yasZPMfLF0QsOKwKaEDGhUyeWnbv+RjwM/KTCpz+I0U 2XBXk9Qf/dx5U6+UW896VxGKZqzoPJrS2ymzR38Jk5iTt4ONsKjaCkDdmVcjAw== Subject: Re: Speculative: Rust for base system components To: freebsd-hackers@freebsd.org References: <7d7bc47d-04cf-2f9b-00a3-e3d9d92b3623@aceshardware.com> <72922F2C-9D27-47AA-BB1C-2DA8589CF008@rpi.edu> <92bd5362-d898-aa12-8f3d-9fbe23f38e0c@aceshardware.com> <26325c0b-4960-7739-72aa-c31c4e0638d3@aceshardware.com> From: Brian Neal Message-ID: Date: Sun, 6 Jan 2019 09:50:32 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:65.0) Gecko/20100101 Thunderbird/65.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 0BA338795C X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=aceshardware.com header.s=dkim header.b=Wmt+7w1K; dmarc=pass (policy=none) header.from=aceshardware.com X-Spamd-Result: default: False [-4.15 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[aceshardware.com:s=dkim]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MX_GOOD(-0.01)[cached: mail.aceshardware.com]; DKIM_TRACE(0.00)[aceshardware.com:+]; DMARC_POLICY_ALLOW(-0.50)[aceshardware.com,none]; NEURAL_HAM_SHORT(-0.78)[-0.782,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-0.56)[ipnet: 52.52.0.0/15(-1.48), asn: 16509(-1.25), country: US(-0.08)]; ASN(0.00)[asn:16509, ipnet:52.52.0.0/15, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2019 17:50:39 -0000 Of course. But I'm counting like for like. So labels are counted for all languages. And I definitely don't rely on LTO when comparing the efficacy of compiler, especially since the linker can spend lots of time eliminating dead-code (usually single-threaded), which means longer build times. On 1/6/2019 9:17 AM, Alan Somers wrote: > Those 21 lines aren't 21 instructions; you're counting labels. Also, > the first three instructions aren't actually part of the function. > They're dead code, and should be eliminate by LTO. However, Rust > doesn't do LTO when compiling libraries; only when linking > executables. The unwrap logic, etc is also not part of the function. > So in this example, Rust produces only a few more instructions than C. > Also, FYI the Rust expression "0..num" is exclusive on the right. > It's equivalent to C's "for (int i = 0; i < num; i++)", though that > doesn't change the instruction count. > > -Alan