From nobody Tue Sep 13 09:54:47 2022 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MRf2q5rZhz4bs3p for ; Tue, 13 Sep 2022 09:54:59 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MRf2q5QLLz3cVS; Tue, 13 Sep 2022 09:54:59 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1663062899; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=quoz62je9KM44IXEuGPl2uXFhdPTIvySnwK7tRyl9dA=; b=HVkcCa0QHsWoB96ysoSh6Pj0cIRViUukEdY/7fJL+mqfQRKnUcU1subGAo0k89mMT3AlTq 8pGTqw6XEDc+9kAKqPAdSrqQE7UFwxrF0lqAufK46MEC1uRmdwhEmlx4yRyRKpMmYrtMUQ uKAOdLaHQhlFVQuVCd/2fr/Q8gKDQRN4x7J+FFw2K+94hdioEkbrC4WRlhxSd7VfQkBid2 ph8Qg0Iqcuxl69qU711WRQrof02k8ynZ5hsd9iL8bpk38Cz4COA3ljCmLxufpYtQ6rtmAd fW4OOPzZcAhlDQLcjL83cI5CbivMHP6GarYx3DOB0ZqTYsIwmyb6ZIuBRPLi9A== Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4MRf2q4PBdzYsn; Tue, 13 Sep 2022 09:54:59 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-vs1-f48.google.com with SMTP id a129so11827803vsc.0; Tue, 13 Sep 2022 02:54:59 -0700 (PDT) X-Gm-Message-State: ACgBeo0HbIx7qrxejqTF8Sc60IKEV+esuCNzTMwooweWnGxWtVjIm6w3 bF8QzqYiV5BRMdUWdGZBxfqLTJkG7A21XMje3ic= X-Google-Smtp-Source: AA6agR4itqAiYkENkM+O0pm/BNIOvTAUUIPo0mBVvxKuwEcyyKPadUPGFUv61lg8BigCSvAidNFXFLUoF31J0D+NnIE= X-Received: by 2002:a05:6102:f97:b0:398:6771:c9b1 with SMTP id e23-20020a0561020f9700b003986771c9b1mr5190547vsv.53.1663062899123; Tue, 13 Sep 2022 02:54:59 -0700 (PDT) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 References: <64978B1B-B01A-4145-996D-27F0A87E994E.ref@yahoo.com> <64978B1B-B01A-4145-996D-27F0A87E994E@yahoo.com> In-Reply-To: <64978B1B-B01A-4145-996D-27F0A87E994E@yahoo.com> From: Nuno Teixeira Date: Tue, 13 Sep 2022 10:54:47 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Default optimization of rust ports To: Mark Millard Cc: "diizzy@freebsd.org" , FreeBSD Mailing List Content-Type: multipart/alternative; boundary="000000000000576adc05e88c019d" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1663062899; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=quoz62je9KM44IXEuGPl2uXFhdPTIvySnwK7tRyl9dA=; b=u/qdmxt0VpsYW5MKtitx2ZHzmTFly05YcFYXon/fCKq8vLKRS2lNZE2hScd57LvyCIqEjJ zXblw2k2s+eCLXKDxETrEj6cpMbIIa6Q5TYPGkeh5JzjWkx/qK9skeqG+UMkw7v0ISsVv7 A8XVGWJX8qyPBPIWKrdIJPI5vafK0q17GpCRAt1ztGeV6uFp5Y4tP/qCCWidcqPrd0ohBs oyTlWjO+Ksz0av4DHFkyarGFfTokLhXUmUrUfUxP1Wv37GOsnnKY5+yAzQpXUJImpa25mz h08Z/Emb3Sktxl6zbxMQ4L1+u4kej5qzlPIgfGqCVpZ+dO+5MpXLyoqsXoRQRw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1663062899; a=rsa-sha256; cv=none; b=JWlIiIag87HuUuG+4raj7Fo0w/nQu64EmiGDeVNxeTck8amM0JMOZa+Z5aNNVrXBteQRT5 7OyheX2cCNDJ4hhrIaZGy2jqbYOCBXUUWzQYLPHeGFOq+I/W24TQsSU8jHKcR5+/1c4fGB /E4R3vsR0BWY/H1MCcultLNFBj01wur1527UBddqp1ljqOTBSZ2Iqose1HqIPdoUs/J9TB 4KR/MbwCS1n1zPhjJZy7+OXCdT7GEt/Ln3Hv9quMzQA4EDZ7o062qSyzOp9IG1tSrcoC8q T44zdBDZisjUiUeDxfUJXYgi9QLke4c9pNHmjxJcVfEhw3/IAZ+fn0ECQzhDoA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --000000000000576adc05e88c019d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I think this issue is related to what happened in terms of optimizations in go 1.18.3_1: --- Add amd64 microarchitecture level knobs for the Go compiler. Note that this will affect only the compiler itself, port users will still need to set GOAMD64 in the environment to adjust the microarchitecture of the compiled code --- I've found this optimizations interesting, e.g.: --- The current high level steps to reduce binary size are: 1. Use Rust 1.32.0 or newer (which doesn't include jemalloc by default) 2. Add the following to Cargo.toml : [profile.release] opt-level =3D 'z' # Optimize for size. lto =3D true # Enable Link Time Optimization codegen-units =3D 1 # Reduce number of codegen units to increase optimizations. panic =3D 'abort' # Abort on panic strip =3D true # Strip symbols from binary* *strip =3D true requires Rust 1.59+. On older Rust versions, run strip manually on the resulting binary. --- I was searching for cargo stripping instead of using STRIP_CMD and I found this but this means that we have to hack ports Cargo.toml's or should be upstream to implement a [profile.release]? Cheers, Mark Millard escreveu no dia s=C3=A1bado, 10/09/2022 = =C3=A0(s) 12:53: > Daniel Engberg wrote on > Date: Sat, 10 Sep 2022 09:45:21 UTC : > > > Since there is work and general interest regarding optimization would i= t > > make sense to make LTO and possibly CODEGEN_UNITS=3D1 opt-out while we > > still have a fairly manageable amount of ports using Rust? > > > Just making sure I understand the wording: > > So, in part, you are requesting that the FreeBSD build servers build > using LTO and CODEGEN_UNITS=3D1? (Those build servers always use the > defaults as I understand. Thus, the defaults are set to what is > desired for use on the build servers, if I understand right. Other > contexts that happen to want something different override some > default(s): opt out of the defaults.) > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > > > --=20 Nuno Teixeira FreeBSD Committer (ports) --000000000000576adc05e88c019d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I think this issue is re= lated to what happened in terms of optimizations in go 1.18.3_1:
---
Add amd64 microarchitecture level = knobs for the Go compiler. Note that
this will affect only the compiler = itself, port users will still need to
set GOAMD64 in the environment to = adjust the microarchitecture of the
compiled code
---
I've found this optimizations interesting, = e.g.:
---
The current high level steps to reduce bi= nary size are:
  1. Use Rust 1.32.0 or newer (which doesn't include jemalloc<= /code> by default)
  2. Add the following to Cargo.tom= l:
[profile.release]
opt-level =3D 'z' =C2= =A0 =C2=A0 # Optimize for size.
lto =3D true =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0# Enable Link Time Optimization
codegen-units =3D 1 =C2=A0 # Redu= ce number of codegen units to increase optimizations.
panic =3D 'abo= rt' =C2=A0 =C2=A0 # Abort on panic
strip =3D true =C2=A0 =C2=A0 =C2= =A0 =C2=A0# Strip symbols from binary*

*strip =3D true requires Rust= 1.59+. On older Rust versions, run strip manually on the resulting binary.=
---

I was searching for cargo stripping= instead of using STRIP_CMD and I found this but this means that we have to= hack ports Cargo.toml's or should be upstream to implement a [profile.= release]?

Cheers,

Mark Millard <marklmi@yahoo.com> escreveu no dia s= =C3=A1bado, 10/09/2022 =C3=A0(s) 12:53:
Daniel Engberg <diizzy_at_FreeBSD.org> wrote = on
Date: Sat, 10 Sep 2022 09:45:21 UTC :

> Since there is work and general interest regarding optimization would = it
> make sense to make LTO and possibly CODEGEN_UNITS=3D1 opt-out while we=
> still have a fairly manageable amount of ports using Rust?


Just making sure I understand the wording:

So, in part, you are requesting that the FreeBSD build servers build
using LTO and CODEGEN_UNITS=3D1? (Those build servers always use the
defaults as I understand. Thus, the defaults are set to what is
desired for use on the build servers, if I understand right. Other
contexts that happen to want something different override some
default(s): opt out of the defaults.)

=3D=3D=3D
Mark Millard
marklmi at yahoo.com




--
Nun= o Teixeira
FreeBSD Committer (ports)
--000000000000576adc05e88c019d--