At a glance, I think the author used S&P sector categorizations. They were set in 2018 and intentionally split the mega caps/FAANG/MAG7 across multiple sectors based on some hand waving about “primary” revenue source at that time.
From a finance perspective I think they’re a _little_ weird but functional (NVDA moves with semis, MSFT with software, etc) whereas from a tech perspective I’d say very weird until you learn about the backstory and what motivated it.
I think you’re responding to “gaming” and thinking of AAA titles which are flashy and splashy but are a smaller market than mobile games. I guess gp might have been thinking of mobile or casual where Apple does have a significant stake and interest but no appreciable focus.
I'm thinking of gaming as in Steam, including indies, AA and AAA.
Of course Apple is doing perfectly fine for mobile gaming, and is giving more than enough tools to developers to implement mobile games perfectly well.
I am talking about PC gaming, and more specifically modern DXVK/Wine support. There's no need for ports, as the Steam Deck showed.
Apple Silicon GPUs are all capable of supporting Vulkan 1.3 and translating DirectX code. Proton 11 supports ARM/FEX natively, which would make Apple Silicon a first-class citizen if you use Asahi drivers. macOS users will be stuck with Game Porting Toolkit and it's lackluster support; iPad/AppleTV/iPhone users have no options whatsoever, presumably to redirect their attention to the App Store that Apple profits from so handsomely.
This is entirely a misleading point. DXVK, Wine and Proton are full of patches that exist to support individual games.
It is not just a translation layer, as much as a great effort of the open source community to force-port every game in existence to Linux. The effort also includes stuff like ntsync that gives the Linux kernel Windows-y APIs for performance.
I doubt Apple has any interest in any of that. I don't really blame them.
And purely in principle, why are we all going through so much effort to save game devs from writing good OS-independent arch-independent code?
That is the point. Valve is maintaining the patches; Apple has to do nothing besides support compliant Vulkan 1.2+ drivers (which their community already does).
Apple doesn't need to implement ntsync to support Proton or DXVK, either. macOS' synchronization primitives do the job just as well as esync or fsync does.
> why are we all going through so much effort to save game devs from writing good OS-independent arch-independent code?
Because Apple doesn't support OS-independent APIs. They also don't support old runtimes, so users will inevitably have to run the Windows version once the native code breaks.
Valve ported several of their games natively to macOS, and almost every single one of them is broken on modern Macs. Valve didn't change the game tech, it's all runtime breakage.
From what I understand you're saying that Apple should provide 2 things: (1) Vulkan drivers and (2) backwards compatibility forever.
I don't really know enough about graphics to discuss point (1). From what I understand, Apple GPUs don't really fit the Vulkan model too cleanly, and the Asahi Vulkan drivers are significantly less performant than Metal (how much of that is due to beta/community status vs. architectural bottleneck I have no idea).
But let's say they provide (1).
Providing (2) would simply be a big mistake. It is a huge mistake of Windows, of the C++ programming language and of the x86 ISA (none of which are very good). Linux distros do not provide this either, beyond the core kernel syscalls and glibc. It is certainly a very big ask and not something trivial.
I'm only asking for (1); Apple can keep breaking APIs forever as long as they support the libraries that enable Proton.
(2) is precisely the reason why nobody can port games to macOS anymore, and largely why ARM is a second-class citizen in PC gaming too. You cannot depreciate things like AVX or 32-bit library execution modes, and then demand native builds get made to 20-year-old games. Apple Silicon's ISA extensions like AMX are not a replacement for x86's SIMD extensions, it's not standardized through Arm or supported in Asahi either. Native Mac games need to incorporate Apple's proprietary and unstable tech like Metal and the Apple Silicon microarchitecture, which makes their games unstable and difficult to support in the long term. Translation is Apple Silicon's only choice for game preservation and mainstream game support.
> Apple GPUs don't really fit the Vulkan model too cleanly
This is a misconception that stems from Metal's preference for tile-based deferred rendering pipelines. Vulkan 1.3 is fully viable on the M1 onward, which is enough to support DirectX 12 translation in Proton. The performance of Asahi's drivers are not any worse than the official Vulkan drivers that Arm provides for TBDR-optimized GPUs like the Mali line.
Games should simply not be written for a particular architecture. The rendering part of the game engine should already be abstracted away from the particular rendering API (there are other significant platforms which do not support Vulkan: PS5 and Xbox, which your game should be capable of targeting). And the math library should have fallbacks to standard C (or standard C++ etc.) and then specialized implementations for AVX, NEON, SVE, etc.
Nothing else needs to be architecture specific.
Now, sure, NEON is slower than AVX-256/512. But backending to NEON or even standard C is certainly going to be faster than running stuff over an x86-to-ARM translation layer.
Sooner or later the Steam Deck 2 will release, probably on an ARM platform (if the Steam Frame compatibility layers go well), and millions upon millions upon millions of dollars of electricity will simply be wasted running x86-to-ARM, Win32-to-Linux and Direct3D-to-Vulkan dynamic compatibility layers when, if the games were well written in the first place, they could simply be trivially recompiled.
> 32-bit library execution modes
If your application assumes pointers are 32-bits, or any particular size, or even any set of particular sizes, it's completely broken.
As for (1), if Asahi Vulkan drivers are really good, that just goes to show why Apple isn't supporting Vulkan. Metal applications seem to be faster, and Apple wants to push devs to make their apps for the faster API.
You're welcome to disagree with me about (2), I don't care what macOS picks in this regard. It's not going to help games get ported to macOS or Apple Silicon any faster. There are hundreds of thousands of video games that will never be updated again, macOS will never support these games without translation. Your ideal world where programmers support and recompile games 3 decades after release does not exist in reality. This is why efforts like WoW64 and FEX exist in the first place; you will never recompile the majority of Windows games. Ever.
(1) is just common sense. Go ask your favorite LLM; does hardware-level TBDR optimization degrade basic Vulkan support? No, it doesn't, and we have dozens of mobile GPUs that support Vulkan to prove it. Metal is not "faster" and it's architecture does not preclude high-performance Vulkan drivers in any way. If you don't believe me, ask anyone else.
> millions upon millions upon millions of dollars of electricity will simply be wasted running x86-to-ARM, Win32-to-Linux and Direct3D-to-Vulkan dynamic compatibility layers when
x86-to-ARM doesn't have to be slow. Accelerators like Apple's AMX can leverage autovectorization during translation, which is significantly faster than NEON and potentially more efficient than x86 SIMD.
D3D-to-Vulkan and Win32-to-Linux is almost always more power-efficient for most GPUs/games. Wine is much thinner than a full-fat Windows runtime, and DXVK can translate DirectX code into batched calls with a shader cache even if the game itself doesn't support it. Do you think the Steam Deck runs games better on Windows, somehow?
Why are you deltaing to windows? You should be deltaing to native.
Obviously an IBM 704 program will run faster on an IBM 704 emulator than on a hardware IBM 704. That's not an argument to keep writing apps for the IBM 704 and "just translate them".
> Your ideal world where programmers support and recompile games 3 decades after release does not exist in reality.
Happens in literally every other programming industry though.
The reason this cannot happen in the games industry is that game developers are not good software developers. They are much more akin to physics-numerical-methods people who can write some magic spaghetti-Fortran that runs really fast and does black magic, but no one can maintain, debug or integrate.
you most likely have an Abe in your contacts, I don’t have an Abe but have a similar issue with a last name from mine. the behavior sort of makes sense if I squint and crane my neck around a bit but I have no idea how the weightings are so bad.
Not that he got it all right or anything like that but it’s amazing how much of the current macro discussion around AI capabilities is covered in the Foundation series which was published over many years, 1942 to 1993.
> I thought for sure you were going to mention USPS “media” rates which allowed Amazon to ship books very cheaply.
Can you share any articles talking about that? Looks like Amazon had so many tricks up its sleeves/loopholes in its arsenal. I'd be curious to read more about it!
Interop standards for this like Open19 are not widely deployed and without interoperability it’s a dead
end since you need the hosting provider to give you the drop to your rack or cage. Hyperscalers I don’t know, but I’d guess they don’t deploy rack density that calls for liquid cooling yet.
It is precisely what the video says. Ben has discussed this multiple times as well, not just in this video. If you have better behavioral tolerance for volatility (as in you're not the type to panic sell), total market equities will outperform and lead to less failure in retirement.
While partially true, that "If you have better behavioral tolerance for volatility" is HUGE. Most people can not do this. Once they see their net worth go from $x to $x/2 or worse, they panic sell. People are emotional beings and it's very very hard to not let your emotions dictate what's going on.
If you haven't lived through a market panic and crash(last one in the US was 2008/2009), then chances are you shouldn't count yourself as being able to do it.
Also, their 100% equity time frames are measured in many lifetimes, not in a single lifetime.
If the goal is to have the biggest $ balance, then sure 100% equities for the win, but if the goal is to survive your retirement with little worry, 100% equities is a terrible idea.
Bonds provide stable cash flow. Equities provide growth/return. Use both in the appropriate amounts for your situation.
> Bonds provide stable cash flow. Equities provide growth/return. Use both in the appropriate amounts for your situation.
This is sound advice. I want to add some nuance about "bonds": Consider some broad categories: (1) regular gov't bonds, (2) inflation protected gov't bonds, (3) investment grade corporate bonds, and (4) high yield corporate bonds. In category (4), it is possible to get both cash flow and capital appreciation. It is the bond-equivalent of "stock picking".
Indeed. Category #4 "high yield corporate bonds" are also known as "Junk bonds" because they kind of suck at the stable cashflow part, since they tend to go to $0 sometimes, much like stocks.
Technically when bonds "go to $0", you actually get priority over any corporate assets vs stock ownership, but if the bond went to $0, there is likely not a lot of assets left either. So you can't expect to get saved completely from whatever asset sale happens.
Credit events (late payments, bankruptcy, etc.) for junk bonds are much less rare than people think. If there is bankruptcy, usually it is Chapter 11 which allows for re-org.
> Technically when bonds "go to $0"
Extremely unlikely, unless there is massive accounting fraud. Recovery rates are on average about 45-55% (since 1987 according to research by S&P).
Phone numbers have become the unique identifier used to build profiles of people and the providers can still claim “security” when they change it to pursue that revenue stream.
reply