From owner-freebsd-hackers@freebsd.org Sun Jan 6 18:24:54 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 142631496620 for ; Sun, 6 Jan 2019 18:24:54 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 31CB088F3F for ; Sun, 6 Jan 2019 18:24:53 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf1-f52.google.com with SMTP id i26so28647043lfc.0 for ; Sun, 06 Jan 2019 10:24:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=IttPdyRJb4AvhTCjI5/KmbHTdodakhVqwyYVlVt9Fno=; b=kjEbZfJH/RGGJ30JOCcBKK+qg14/VXk2XIjUbIGNJXYhQo9a61/F1b4g3tnAvxr3Im 4Q+JgZkgarZX9HlgtHv73MoEhrS/xqbpiMPfczkfn3hitoBKszRaoItOvtvGZjj8wacp 5H7rewGAKSX8vivdNuowGqpGkTO5R0LPSmpkEgRS4fizXrHA/n2c2F4RcXTPLnEqR/UQ eYN2EQchfi7U1nuW0bzXrRlJXEjhkiw34wp+D3O3I9Mi3ki9MLMHWiSuBrcVzparutkw Kt70SeC22DLCo8ErKxX54VVp97TnQZ6HQturYUSI9pg8MoJAD93ta2LUCHbdaiPFXgwo LKSw== X-Gm-Message-State: AA+aEWZFsJaouwFbBhIhJSUA9jBeeRy0wgJux1LN8k0uL2BkEkMBAvnn exCiLXAsO9pzuc4eDgDa55eWu6Ky+QUgqDIRkK7pTg== X-Received: by 2002:a19:660a:: with SMTP id a10mt34472687lfc.146.1546799085954; Sun, 06 Jan 2019 10:24:45 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: From: Alan Somers Date: Sun, 6 Jan 2019 11:24:34 -0700 Message-ID: Subject: Re: Speculative: Rust for base system components Cc: Brian Neal , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 31CB088F3F X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.167.52 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-1.59 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.957,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-0.60)[-0.603,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_SHORT(-0.92)[-0.916,0]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[52.167.85.209.list.dnswl.org : 127.0.5.0]; MISSING_TO(2.00)[]; RCVD_TLS_LAST(0.00)[]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; IP_SCORE(-1.10)[ipnet: 209.85.128.0/17(-3.77), asn: 15169(-1.67), country: US(-0.08)]; 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 18:24:54 -0000 Actually, LTO isn't necessary. I just compiled those examples on my local machine, building them into a binary. Even without LTO, dead code like into_iter and Iterator::sum does not get included in the binary. I'm not sure why it does on godbolt. Perhaps they intentionally disable dead code elimination? -Alan On Sun, Jan 6, 2019 at 11:01 AM Alan Somers wrote: > > But it's not a like-for-like comparison. Rust eliminates dead code at > a later stage. If you want to compare the efficiency of generated > code, you need to exclude the dead code that will be eliminated by > LTO. And you shouldn't be counting the labels for either language, > because they don't affect the machine code. If you want to compare > build times, then you should actually measure build times. > -Alan > > On Sun, Jan 6, 2019 at 10:51 AM Brian Neal wrote: > > > > 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 > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"