From nobody Mon Feb 5 03:52:21 2024 X-Original-To: ports-bugs@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 4TSss15Y9qz591GR for ; Mon, 5 Feb 2024 03:52:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TSss12sp6z42cr for ; Mon, 5 Feb 2024 03:52:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1707105141; h=from:from: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=zjRl163jXAXbM6GVz4ACYffmdXBrpalzvKEu8qC/trg=; b=sseQxe6+ELi045wBosmfGFyS7WaXghzXQbTLKNlDgm8Nvjzhh1c078JWTMwaEraQFupvhW PmeDjhGLCgLLXKB/7EOx8JRfWJpxIwgF1g3N94DuSxeVlRscr46qqy9ZTgeFFHdSh35Cro SqMXYfr5q5QAJjouoUYOM8zpLoBSHUAoFO8mBVES6e1uRdNAj1NpVEYPBNkf6sV4Dbr37+ 0UYw9stRZxaAuppuVQ0rlsq7fdQi4mC99wA9/ocy+xUd2q3CBirBGyQ7HwFiNCWgQuSoF3 yFrL2ULW0F0+QIDymzcxBCVNUMkd1GfXuieM5ngdbIN8rZIyG1nApx6xtpcIxw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707105141; a=rsa-sha256; cv=none; b=Fv1Upk0BU4l+e8at6gJzjG6O6e2xS3SZvQPy7CRD8+63WF0KT4taggCTPXOHtlbQSUiaNg +ZZkh3ZVZhP090az64VZHR74O56+K9xbKPORZEfGZeIUSvUfgfC/FvxjqBIrJ9LYQ7xGcp vc1lkOsbNGO7rF9EtZlgIudBxaM6yGik1P++Yr2sOig69DVcaVJrwinvzx3HExhJ4v/5CX a/yttoM3UOkIzldYSPFLNZzVmemCwK8B3nl7LEN3G9RiUxOlowV46TJJ/8QIYD+DL0D6cq uHkuwwFPKoFqml7odIMyMNaRp1cjMuIaNRvzlWBnzOnjStRLLnERuGH+pZOOkA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4TSss11zQlzQ7d for ; Mon, 5 Feb 2024 03:52:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4153qL6X014701 for ; Mon, 5 Feb 2024 03:52:21 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4153qLl7014700 for ports-bugs@FreeBSD.org; Mon, 5 Feb 2024 03:52:21 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 276789] math/openblas: Update to 0.3.26 Date: Mon, 05 Feb 2024 03:52:21 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ard_1@mail.ru X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ports-bugs@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Ports bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-ports-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports-bugs@freebsd.org X-BeenThere: freebsd-ports-bugs@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276789 --- Comment #7 from Artyom Davidov --- (In reply to Daniel Engberg from comment #6) It is true that OpenBLAS tries to figure out the most appropriate optimizat= ion options by itself but you should consider some things before trying to "enhance" some things in it or patch it somehow or make some changes to it's build process. 1. There are globally two build paths in the OpenBLAS - one for the DYNAMIC_ARCH =3D 1 and another one for a current host you are building Open= BLAS on (when DYNAMIC_ARCH =3D 1 isn't set) 2. When DYNAMIC_ARCH is unset, then OpenBLAS auto-detects the current CPU = type of a build host and compiles it's library with the code that is optimized o= nly for the CPU of the build host. This leads to a smaller library size, and a faster compilation time. The drawback of a such approach is that the library code will not work on a CPU with a different instructions set or it will perform suboptimal on a newer CPUs (ie with a larger cache sizes). 3. When DYNAMIC_ARCH is set to 1 then OpenBLAS builds all the available CPU modules (except "older" ones) but it will optimize it's common code to the = CPU it is being compiled on. This leads to an increased compilation times and a resulting library size increase significantly. But the resulting code suppo= rts numerous CPU models with the different instructions sets. But the "bottom l= ine" of the common code optimizations is still tied to the host you are building OpenBLAS on. 4. The "upper bound" for the optimizations of the both build paths (with and without DYNAMIC_ARCH) are controlled with the three AVX options. Though the actual behavior is a bit different when DYNAMIC_ARCH is set to disabled, we= can assume this for the sake of simplicity. 5. The "lower bound" of optimizations for the build path with a DYNAMIC_ARCH set to enabled could be controlled with the TARGET OpenBLAS Makefile.rules option. It could (or should) be set to a lowest possible target CPU arch you are planning to run that OpenBLAS library on. 6. The behavior of the TARGET option when DYNAMIC_ARCH is unset is a bit different - it allows you to compile an OpenBLAS library for a specific CPU target family only. Considering an AVX options: Sometimes it is necessary to disable AVX512 or AVX2 instructions due to bug= gy implementation of an optimized code or due to some other reasons (higher po= wer consumption, or suboptimal performance or performance testing) so it's bett= er to leave all those three PORTOPTIONS in the ports Makefile. Another thing to consider is that when the DYNAMIC_ARCH is set to enabled, = an AVX options not only control the "upper bounds" of optimizations but and a "lower bounds" too. You can check the summary section of the build logs attached to this bug to get familiar with this behavior.=20 So you wouldn't be able to compile a SANDYBRIDGE optimized code if you enab= le all AVX options all together or disable them at all. But you can accomplish this using TARGET option, but since there is no mapping of FreeBSD CPUTYPE make.conf option to an OpenBLAS TARGET Makefile.rules options it is not a trivial task to do. To summarize all of the above - there is no need to patch OpenBLAS or someh= ow manually interfere with it's build process - there are existing knobs in a Makefile.rules file that could be used to get the needed compilation (and optimization) results. And setting those options via Makefile.rules is the = way that is expected to be used by the OpenBLAS developers. Considering the post-patch section in the current ports Makefile - if there= is a better way to make changes to an OpenBLAS Makefile.rules file, I guess it= can be modified to use it. --=20 You are receiving this mail because: You are the assignee for the bug.=