Which version of svt-av1 are you using? Neon optimisations were added quite recently in svt-av1, and are still a bit incomplete, so it might make a difference.
Running something with "Wine" doesn't usually mean "porting", "porting" means making a native binary that doesn't run through an emulation layer.
Anyway, probably you are trying to run a 32-bit executable with Rosetta, that won't be fast, because Rosetta was never meant to run 32-bit things and has got a lot of pitfalls.
The software identifies the hardware, performs the benchmarks, and sends the heading and results to the Geekbench DB. Somebody who had the machine at hand must have run it.
Internal leaks, these happen frequently. Employees have access to these devices for months prior to launch. Someone ran a benchmark and uploaded it on a machine they weren't supposed to.
I find that hard to believe at Apple. Not even possible that it’s accidental. They have their own internal tools, all packets leaving the network will be interrogated, leaking data is a sackable offence… if it’s in the geekbench database then it’s there because they put it there.
> Not even possible that it’s accidental. They have their own internal tools, all packets leaving the network will be interrogated, leaking data is a sackable offence
This is a story that folks like to tell, but it's not really how things work - at least since they stopped letting Steve Jobs lock all his engineers in the conference venue.
Leaks are a sackable offence at every tech firm, deep packet inspection firewalls are used all over the place, information leaks like this still happen pretty much every single product cycle.
Just recently there was the OpenAI vs Apple trial, where it came out that employees that left the company still had access to their internal net, sooo super plausible
No I think Apple employees run geekbench for fun and don't care the stats get uploaded (you know just like other normal careless humans rather than demigods)
Apple's Weather app has an animated background, glassy views, and nice animations like water droplets on the glassy views when it's raining. So rendering all that on a 4k or more display at 10bit depth is going to consume a bit of RAM. However I guess it can surely be improved to make it consume less RAM.
Snow Leopard shipped a new 64-bit Cocoa Finder too, but no one noticed because it was almost a pixel perfect and behaviour perfect copy of the previous one.
Of course, but that works only if the files are already in the same partition. A dmg is a virtual image, even if it's stored in the same partition, once mounted it acts like another partition.
SteamOS leverages namespaces via pressure-vessel already. The problem exists exclusively on Windows. Paravirtualized drivers introduce API incompatibility issues and decades of cumulative engine infrastructure made for Windows using the Win32 API means nobody wants to swap over to using UWP and thus AppContainers are a non-starter (and that's without getting to sacrificing Wine/Proton compatibility).
The native isolation mechanisms like silos are things that require wrangling by professional sysadmins, I didn't even know they existed until I started writing this post. The real question to be asking is why is sandboxing so bad on Windows? Despite some searching, I still have no conclusive answer as to how to go about filesystem isolation in Win32-space, or if it's even possible.
Sandboxing is quite easy (user-wise), once you install the sandbox system. By default it allows only a single sandbox, and with small `.wsb` file you can drive what's visible from the host, whether the GPU should be active, etc. - https://learn.microsoft.com/en-us/windows/security/applicati...
It's great for testing, and Sandbox is just the tip of the iceberg of what Windows Containers support
- e.g. maybe someone can come up with "launcher" that goes through it (somehow).
Ummm, yeah, but Windows Containers is windows Pro and Enterprise only (security is an optional, paid extra on windows), and only for these using Hyper-V (meaning Virtual Box users are excluded).
They are? Games need pretty much all the performance they can possibly get. Can you sandbox them without having a performance impact?
Consider that people pay a $300 premium to get ~10% better performance (buying an RTX 5080 instead of a 5070 Ti).
Personally I know that sometimes closing the web browser in the background makes my game run better - that web browser doesn't even interact with the game! Would a sandbox have a smaller impact?
Buying a better GPU improves your graphics performance and that's basically unrelated to the area where a sandbox impacts performance.
Killing your web browser is probably just lowering memory pressure?
Sandboxes add overhead to syscalls. It's kind of similar to running under Wine, which also adds significant syscalls overhead. Wine also has a much more impactful DirectX translation layer, so your sandbox performance would be probably be much better than the Wine performance.
PC games tend to be the reverse: they demand control over the machine, in order to try to detect or prevent being run alongside various forms of cheating software.
They also need low-latency access to the GPU, which I suspect is a fertile vector for privilege escape exploits.
Only a relatively small (but popular) subset of games use anticheat. Most games -- including the one in this article -- could theoretically run in a sandbox.
Even games with strong anticheat could benefit from sandboxing, as the anticheat mechanisms that need access outside the sandbox represent a much smaller surface area for exploits than the entire game.
In theory, sandboxing mechanisms could even be used to improve anticheat.
What I always sort of assume the endgame could be for highly competitive Windows games is something akin to cartridge or bootable floppy games from the 8-bit era, where games would install into or be supplied as disk images containing locked-down Windows installations that only permit signed (and possibly whitelisted) drivers and whitelisted applications, which would include the game and a small number of other approved applications like Discord, MS Edge and possibly selected third-party browsers, and support software for hardware like GPUs and gaming input devices, which Windows would then boot to run the game, either on bare metal or in an isolated VM.
Proton is just emulation, and it will happily expose the underlying host system to the running game software. In particular the filesystem and some peripheral devices. However, Valve is moving towards sandboxing in Steam. You can already run the whole thing with a flatpak sandbox, and valve themselves are using ostree. With srvio is possible to run the whole thing in a throwaway windows vm while the graphics card is passed through
Anything that wants to traverse your filesystem could do so trivially from a wineprefix, but stuff like sniffing your browser extensions might be harder depending on the technique.
I've formally studied gamedev, but haven't done anything in over a decade, but even before you get to the thorny issue of anti-cheat sustems, games rely on running at a(n often very) low level and doing unconventional things. I imagine they're one of the hardest things there are to sandbox without causing massive levels of breakage. But someone more knowledgeable about either side of the equation (sandboxing and/or game development) might be able to shed more light.
Windows has a lot of powerful sandboxes. A lot of them Windows maybe made too easy to opt-out from and/or defaulted them to opt-in rather than opt-out which makes them things that developers need to learn or developers try to avoid or developers don't think they need.
reply