From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by sourceware.org (Postfix) with ESMTPS id B35F4386F46E for ; Tue, 12 Jan 2021 22:13:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B35F4386F46E Received: by mail-wr1-x435.google.com with SMTP id 91so49111wrj.7 for ; Tue, 12 Jan 2021 14:13:29 -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:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cpy6OT/8lN7masLX9NpHFJW+BJQ2J2DwIH44wgiPaSM=; b=n8oBojgoDYZtSaPzCbHw60hFn6vI/Kto8R4S5GVqnyGNulTrxKvbKhG0dOBsaXQzOd kZ9+AtSv/+dLRFL+3m29YL0tk+5D382nC8XDlDfrdYeWch9QvMpduQ/fc3ZNB4xx2YHy 3lwyXlzIY2DQjVpapNSLssX+NJ7aTNcYcZhm4lsowaBdy7WVaOMuctGibX9sb0OP9NEy bzAsLprtM9m0Uu7PcmCIAyZAlkqlLBYyk8Mqjum8w1UaGlbmDnhFB2Jn4GNcpbRD6JFC x0xAclzHju19bhACHrbNv1vmPsuo6AzIpCkIgqpjg/cI78IiCgoO2GjKllhpHbW4BG2e 4l2A== X-Gm-Message-State: AOAM532/yqmdPUQIuJ7H7rL7gqE+LMV/02hSfEcpQtvt094d3BRyS12E 0+DfvUZre0BcDaMS2WLL0dQ= X-Google-Smtp-Source: ABdhPJy2AbWGSGti+pl8CcgaWiGyywv0YgVXz5QvRMh/DtyXvFt9fwSEDlTRub1QUS1WmhzOXgJnpg== X-Received: by 2002:a5d:4e89:: with SMTP id e9mr838012wru.201.1610489608699; Tue, 12 Jan 2021 14:13:28 -0800 (PST) Received: from [192.168.1.212] (host81-138-1-83.in-addr.btopenworld.com. [81.138.1.83]) by smtp.googlemail.com with ESMTPSA id r7sm5539233wmh.2.2021.01.12.14.13.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jan 2021 14:13:27 -0800 (PST) Content-Type: text/plain; charset=utf-8; delsp=yes; format=flowed Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: apple silicon fortran From: Iain Sandoe In-Reply-To: Date: Tue, 12 Jan 2021 22:13:26 +0000 Cc: Rosemary Mardling , Fortran List , Thomas Koenig Content-Transfer-Encoding: 8bit Message-Id: <3FFC9C05-CB2C-4DB6-874D-B263EDE04533@googlemail.com> References: <941045F7-9782-408B-BF5A-015E2FAF246A@monash.edu> <7FCF49F0-EA95-44F1-B5B6-01393378783E@gmail.com> <1ED16F62-4E5F-4EC1-9CD6-3E5A59A6C415@googlemail.com> <291F2ED7-BFF4-4F8C-A902-62231FB75425@gmail.com> To: James Secan X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2021 22:13:31 -0000 Hi Folks, Iain Sandoe via Fortran wrote: > James Secan wrote: >>> On Jan 9, 2021, at 11:07 AM, Iain Sandoe via Fortran >>> wrote: > >>> I am testing out the Rosetta 2 alternative (which is, AFAIU, a >>> binary-conversion done at install-time native on macOS). OK so I haven’t yet found a way to trigger the install-time translation, perhaps it only works on a fully packaged and signed app. - however, the “on demand” conversion clearly works. >> I am interested to hear the results of your testing with Rosetta 2. > > I bootstrapped x86_64-apple-darwin20 on aarch64-darwin20.3, and currently > running the Fortran testsuite - it’s not clear to me if some of the > issues (PIE and no-executable stack) will be sidestepped or not. We > shall see. Summary : some pretty good parts, but not enough to be a drop-in replacement. [ disclaimer : the testsuite is somewhat ‘noisy’ at the moment, we have some tidying to do before release…] here’s the native (x86_64-darwin20, on an Intel skylake processor): https://gcc.gnu.org/pipermail/gcc-testresults/2021-January/644184.html here’s the same branch bootstrapped for aarch64 and x86_64 using Rosetta 2 on an A12Z processor (I don’t have access to an actual M1 yet). https://github.com/iains/gcc-darwin-arm64/issues/30#issuecomment-758890255 — inferences and testing: * It seems that Rosetta 2 + whatver sandboxing is in place is allowing diabling PIE (which means that PCH works again) but *NOT* allowing executable stack, which means that [GCC default implementation] nested functions are still broken (and gfortran uses nested functions ‘under the hood’ so to speak) * informal testing on a couple of random Fortran benchmarks I have on that machine suggest that the binary translation gives pretty good performance for numerically intensive stuff (but again, disclaimer - that was [a] on an A12Z and [b] not carried out in any strictly controlled manner). OTOH, I expect it’s not completely misleading. Conclusion. Rosetta 2 + Arm64 is not a drop-in replacement for x86_64 gfortran, we still need an ABI-compliant solution to the nested function issue - I do have an idea - but it isn’t a stage4 kind of thing. If your machine breaks and you have to replace it, or your employer requires you to use an arm64 model, then I would suggest that the native branch is probably a better bet in the short-term - that has a workaround for the nested function issue (but that can give challenges in interworking with C, although those might not be insurmountable) .. We’ll get there, I am sure - but not this week ;) cheers Iain