[HN Gopher] AMD and Valve Working on New Linux CPU Performance S...
___________________________________________________________________
AMD and Valve Working on New Linux CPU Performance Scaling Design
Author : bpierre
Score : 114 points
Date : 2021-08-02 18:23 UTC (4 hours ago)
(HTM) web link (www.phoronix.com)
(TXT) w3m dump (www.phoronix.com)
| zamalek wrote:
| One of the great successes of Intel has definitely been
| establishing their processors as the default optimization status
| quo. Beyond the scheduler, compilers also optimize (by default)
| for Intel instruction latencies and pipelines.
|
| One way to remedy this would be to ship more distros with
| march=native as the default. You only need to specify the
| architecture when you are building binaries for distribution
| (which mostly happens on CI servers these days). This would
| result in better perf on not only AMD chips, but also newer Intel
| chips.
| hyperman1 wrote:
| I wonder if it is worth it to select a few core libraries like
| glibc, and get the distro to install multiple variants, each
| optimized for a different CPU.
| jcranmer wrote:
| Recently (in the last year or so), the platform ABI for
| x86-64 has been augmented with 4 levels of variants: base
| x86-64 (i.e., up to SSE2), and then assume up to SSE4.2,
| assume up to AVX2, and then a base AVX-512 level. (Not
| mentioned in each of these levels is the random other
| instructions, such as BMI/BMI2 that get sprinkled
| throughout.)
| fsaintjacques wrote:
| glibc already does dynamic dispatch for the memcpy family of
| functions.
| scns wrote:
| Intels Clear Linux does this IIRC. Wins most comparisons on
| Phoronix. Works on AMD CPUs too.
|
| (edit) Even though i'm a sucker for efficiency/performance, i
| prefer Tumbleweed myself. Since i like KDE, whose integration
| is as good as it gets on SUSE but left a lot to be desired on
| Clear which ships with GNOME by default. Both are rolling
| releases. SUSE has automatic btrfs snapshots on updates for
| easy rollback. But Clear has the performance edge.
|
| https://www.phoronix.com/scan.php?page=article&item=ubuntu-2.
| ..
|
| https://www.phoronix.com/scan.php?page=article&item=cascade-.
| ..
|
| https://www.phoronix.com/scan.php?page=article&item=icelake-.
| ..
|
| Oh nice this one shows Tumbleweed is not far behind:
|
| https://www.phoronix.com/scan.php?page=article&item=amd-
| epyc...
| 10000truths wrote:
| For x64, you don't need to distribute multiple binaries. You
| can have one binary with variants of a function each
| optimized for a particular CPU, and resolve which variant to
| use at runtime using the CPUID instruction. gcc already does
| this for you with function multiversioning, and glibc makes
| use of it for its string routines.
| oscardssmith wrote:
| Imo, the solution is to stop using C/C++ for high performance
| applications. Today's computers are diverse enough that
| distributing compiled binaries leaves a ton of performance on
| the table.
| jeffbee wrote:
| I don't think it's even slightly true that compilers default to
| Intel-specific optimizations. All the Linux compilers default
| to k8-generic, an obsolete AMD platform.
| 2bitencryption wrote:
| If Steam Deck reaches even a moderate level of success, it will
| be a _huge_ incentive for developers to make games target Linux
| (or, more likely, the Proton compatibility layer).
| babypuncher wrote:
| I actually prefer for devs to target Wine/Proton compatibility
| instead of providing native builds.
|
| Native games can break over time. I have lots of older
| proprietary Linux games that aren't super straightforward to
| get running on modern Linux distros, usually because they rely
| on libraries that aren't included by default anymore (and
| sometimes not even maintained). The Steam runtime smooths this
| over a bit, but I still run into native games from only 4 or 5
| years ago that are now broken out of the box.
|
| Proton has the benefit of being a "framework" that isn't likely
| to be abandoned anytime soon. It is essentially a re-
| implementation of a platform whose primary selling point is
| long-term backwards compatibility and API stability. It
| abstracts (or outright eliminates) most of the variability
| between Linux distros.
|
| Plus, games running in it can run mods that rely on DLL
| injection.
| some-guy wrote:
| Ironically, many games I install on Steam run better in Linux
| under Proton than Windows 10 (especially from the 98/XP era)
| babypuncher wrote:
| I think this usually boils down to incomplete or buggy
| support for older 3D apis in modern graphics cards, as the
| fixes for these games almost always boil down to using a
| wrapper that translates them to modern Vulkan or DirectX
| like dgvoodoo or nGlide, similar to what Proton already has
| to do for these games.
| KiranRao0 wrote:
| I remember a Linus Torvalds video on this exact problem. I
| found it both blunt at insightful:
|
| Linus Torvalds on why desktop Linux sucks :
| https://www.youtube.com/watch?v=Pzl1B7nB9Kc
| AussieWog93 wrote:
| Oh my God, Linus hit the nail on the head there. Prior to
| stabilising on a policy of "AppImage or GTFO", this was by
| far the biggest headache when it came to supporting Linux.
| schmorptron wrote:
| Steam uses flatpak-like runtimes now that should hopefully
| make backwards compatibility a non-issue going forward.
|
| https://gitlab.steamos.cloud/steamrt/steamrt/-/wikis/Soldier.
| ..
| WhatIsDukkha wrote:
| On reflection I'm very OK with targeting Proton.
|
| I actually don't want a closed source commercial blob TOOOOO
| comfortable on my linux box.
|
| I want a heavily sandboxed but performant package that runs
| reliably.
|
| That said, if those requirements are met and there is more
| performance etc on the table by doing a native/or partially
| native port that's great.
| yissp wrote:
| I don't know, wine kinda just barely works as it is.
| Introducing another layer of complexity through sandboxing
| would be opening a can of worms. Like I know Chromium's GPU
| sandbox has caused weird bugs in the past because it
| prevented the graphics driver from doing something it needed
| to do.
| hn8788 wrote:
| Proton is a bit of a double-edged sword for gaming on Linux. On
| the one hand, it makes a lot of games playable on Linux that
| weren't previously. On the other hand, some developers have
| said that since Proton works well enough, they're going to stop
| officially supporting Linux versions of their games.
| _flux wrote:
| Think however what happens if developers start actually
| targeting Proton, instead of Windows. Suddenly Microsoft
| isn't the one holding the reins :).
| MayeulC wrote:
| Yeah, well. Not as long as developers use Microsoft's
| headers for development.
|
| OTOH, if there was a Proton SDK...
___________________________________________________________________
(page generated 2021-08-02 23:01 UTC)