[HN Gopher] Gentoo x86-64-v3 binary packages available
___________________________________________________________________
Gentoo x86-64-v3 binary packages available
Author : laserstrahl
Score : 64 points
Date : 2024-02-04 14:53 UTC (8 hours ago)
(HTM) web link (www.gentoo.org)
(TXT) w3m dump (www.gentoo.org)
| dtech wrote:
| If like me you were unaware of the "x86-64-v.." classification,
| here is an overview:
| https://developers.redhat.com/blog/2021/01/05/building-red-h...
| throw0101a wrote:
| See also:
|
| > _In 2020, through a collaboration between AMD, Intel, Red
| Hat, and SUSE, three microarchitecture levels (or feature
| levels) on top of the x86-64 baseline were defined: x86-64-v2,
| x86-64-v3, and x86-64-v4.[41][42] These levels define specific
| features that can be targeted by programmers to provide
| compile-time optimizations. The features exposed by each level
| are as follows:[43]_
|
| *
| https://en.wikipedia.org/wiki/X86-64#Microarchitecture_level...
| o11c wrote:
| Assuming APX[1] actually becomes a thing, that will be an
| even more significant feature level.
|
| [1]: https://en.wikipedia.org/wiki/Draft:Advanced_Performance
| _Ext...
| snvzz wrote:
| I wonder what happened to Arch Linux's sub-architecture support.
|
| There was talk years ago about this. Pacman supposedly got
| updates, and it was just a matter of kicking the building
| infrastructure into gear.
|
| But years passed, and still nothing.
| GrayShade wrote:
| There's a repo at https://wiki.archlinux.org/title/unofficial_u
| ser_repositorie..., but nothing new as far as I know.
|
| I've used it for a while, ran into some minor issues from time
| to time, but nothing critical.
| jiripospisil wrote:
| The newest status update I could find is this [0] but that's
| over a year old too. Honestly I would rather if they worked on
| providing ARM64 packages. I know about and use Arch Linux ARM
| but that's a completely different project with different people
| and even fewer resources, which often manifests in broken
| packages (right now generating initramfs fails without manual
| intervention [1]). I remember for a long time Arch Linux didn't
| have any build servers and packagers mostly used their own
| machines to build packages. Not sure what's the current state
| of things but if that's still the case, then it's quite
| understandable that not everybody has an ARM64 machine to build
| on.
|
| [0] https://lists.archlinux.org/hyperkitty/list/arch-dev-
| public@...
|
| [1] https://archlinuxarm.org/forum/viewtopic.php?f=15&t=16672
| Foxboron wrote:
| It's all part of the same problem domain; How do we
| rearchitecture the release process of Arch so we can support
| multiple architectures.
|
| The amount of people that understand this problem domain,
| have the time+energy to work on it and is _actually_ able to
| see it too completion is.. well. Not many.
|
| I tried to hack on buildbot, as I wrote in that email, but I
| have been questioning the maintainability of trying to fit
| what we need on top of buildbot. In constrast to writing
| _something_ from scratch.
| jiripospisil wrote:
| I wonder if something like that should be built on top of
| GitLab now that you have migrated to it. GitLab CI supports
| multiple runners for a single job, so the workflow might be
| that you merge a merge request which modifies
| PKGBUILD/.SRCINFO, the CI picks it up and based on
| labels/tags dispatches it to different runners running
| possibly on a completely different architecture for
| building. The runners then send the artifacts back and the
| job publishes them. The nice thing about this is that most
| of the parts are already there handled by GitLab itself,
| you just have to draw the rest of the owl.
| Foxboron wrote:
| This doesn't help at all as you need to coordinate so-
| name rebuilds across multiple architectures. This implies
| you need to some way to orchestrate a staging repository
| and have building do rebuilds towards this repo
| interactively until all issues are solved.
|
| Retrofitting this ontop of gitlab sounds painfull. I
| don't even know if we would like to be _that_ tied to a
| singular forge.
| orf wrote:
| Lack of -v3 binaries are common in Docker containers. Most, if
| not all of development, CI and deployment targets support -v3.
| And yet images like Postgres or Redis are built with the absolute
| lowest common denominator in mind.
|
| How many CPU cycles are wasted globally because of this? It's
| nuts
| rahilarious wrote:
| There are containers which are based on Gentoo and optimized
| for x86-64-v2 and x86-64-v3.
| https://github.com/rahilarious/gentoo-containers
| orf wrote:
| Sure there are, but it doesn't matter because everyone uses
| the stock images.
|
| The issue is there is no concept of a -v2 or -v3 Intel
| architecture in the OCI spec. which is a shame.
| dataflow wrote:
| > That said, in some processor lines (i.e. Atom), support for
| this instruction set was introduced rather late (2021).
|
| Just one little sentence at the end but quoting it since it feels
| important.
| neonsunset wrote:
| These are _bad_ processors born out of ridiculous market
| segmentation done by Intel for which we pay for dearly (also
| worth calling out making ECC server-only feature, because
| profit, exabytes of user data corrupted be damned).
|
| Not only they are not worth targeting, it is a moral imperative
| not to consider them for pieces of software like PostgreSQL. If
| the push comes to shove, a "-compat" or "-legacy" flavour of
| binaries can be offered to select few users which use older
| systems with CPUs made before 2011 (pre-Sandy-Bride and Jaguar
| respectively), which would allow the overall ecosystem get
| healthier while not leaving affected people behind.
| wtallis wrote:
| The Atom-based processors are bad not because of market
| segmentation but because Intel is perennially unable to make
| more than one good architecture at a time. The ones that are
| bad because of market segmentation are the processors with a
| Core family microarchitecture lobotomized down to the i3,
| Pentium or Celeron product lines, leaving them years behind
| on feature support that's physically present but fused off.
| p1mrx wrote:
| !!! The following binary packages have been ignored due to non
| matching USE: =sys-libs/glibc-2.38-r10 -multilib
| -stack-realign =sys-libs/glibc-2.38-r10 systemd
|
| So in order to use binary packages, I either need to switch to
| systemd, or switch to no-multilib and manually enable all the
| desktop-related USE flags. Seems too tedious to bother right now.
___________________________________________________________________
(page generated 2024-02-04 23:02 UTC)