ColonelPhantom

Yeah, I agree fully on the "pandemic brain" thing. One interesting observation I made is that usually mainstream midrange cards seem to hover just over 200mm². That includes for example cards like the HD 7850, but extends all the way to the likes of the RX 580, RX 5700 XT, but also the GTX 1060 or GTX 660. Those cards are all 256 bit if AMD and 192 bit otherwise, funnily enough.

It seems die sizes are on the rise though! The 6600 XT is a similar size to the 5700 XT despite having much less hardware (except cache), although I guess RDNA2's better clocks also ate some die space. The RTX 3060 is also reasonable large at 276 mm², which seems more like what's usually 60 Ti territory. And the 3070 is even bigger than the 1080!

Even in that context though, the 4060 Ti looks fairly anemic at 188 mm². The 4060 is even smaller at 159 mm², which almost equals the RX 5500 XT that debuted at $170, just over half the cost of the 4060.

Intel's current GPUs are meanwhile comically large seeing as the 400 mm² or so ACM-G10 competes with N23/N33 and GA106 which are much smaller, and even the tiny 4060. I think that's mostly because of the way too fine grained EUs which also makes the architecture very complex with slices and subslices. But at least for Battlemage they seem to be planning to grow the EUs, rather than throwing on more.

It's also worth noting that if Nvidia decided to "double up" the memory on the 3070 in a similar way to the 4060 Ti, they could have made a 32 GB version of it. Intel could also decide to do something like that for Battlemage, or of course AMD could do it with the 7900 XTX or similar. Despite AMDs weaker AI performance (no real matrix multiplication acceleration, unlike Nvidia or Intel) it would at least get AI developers to likely care about their cards as it means they have the best flagship in one important metric.

> (and a fair number of people (including reviewers!) actively propagandize about these cards, like complaining the 4060 or 4060 Ti is actually slower than its predecessor - they're absolutely not, even at 4K (tough for a 6600XT tier card!) the 4060 Ti is still faster on average. And as a general statement, AMD made the same switch to 128b memory bus last gen already without catastrophic issues, like the aforementioned 6600XT. A card can still be a mediocre step without making shit up about it, and the 3060 Ti was the absolute peak of the 30-series value so it's understandable the 40-series struggles to drastically outpace it. But it's not slower, either.)

Yeah, the 3060 Ti was probably the best 30-series card, but the 4060 Ti being 128 bit is a much bigger issue than the 6600 XT or 4060 being 128 bit. You see, the 6600 XT succeeded the 192-bit 5600 XT, and the 4060 succeeded the also 192-bit 3060. But the 3060 Ti was a 256 bit card.

I'm also pretty sure that the 3070, which is only a small step up from the 3060 Ti, often outpacing the 4060 Ti and it becomes a much worse thing, also considering that the 3060 Ti and 4060 Ti both launched for $400. (The 6600 XT also launched for an MSRP of $380, but this was amidst the huge pricing bubble and AMD didn't want to hand over all of that to scalpers.)

To add insult to injury, the 4060 Ti is available in a 16 GB variant, which has so much memory relative to its bit width that Nvidia has to put the chips both front and back. GA104 cards which wouldn't need such tricks did not get one.

The 4070 and 7800 XT are fine from a value perspective, but it's above the price range that most people are in. But the value proposition drops off quite hard there. GPUs like the 7600 or 4060 Ti offer almost nothing over their predecessor in terms of gaming performance, so it makes sense why nobody buys them. But those are the segments that are supposed to sell well.

This is also what I did when I used PRISM for my thesis. Honestly also not the greatest experience, but I think it does show that the limitations of the PRISM language are not inherent to the problem domain.

Fractional scaling on X is also broken beyond repair; it (usually) only scales fonts (so not icons and other elements). Wayland does have true fractional scaling, but it's supported neither by GTK4 nor by Qt5. Qt6 is the first toolkit with true fractional scaling on Wayland.

I mean, when coding memory management by hand in C or C++ (although C++ of course has things like RAII and smart pointers which simplify life a lot), you do need to have similar mechanisms within your own head. Otherwise you'll get all sorts of fun stuff like pointer aliasing, use-after-free, or what-have-you.

This feels a bit strawmanny. "If you're doing err=nil in typescript, it sucks worse than Go!" Yeah, but nobody does err=nil in typescript, you just re-throw or something similar. At least that's what happens in Python land, which I'm more familiar with and also uses exceptions for error handling.

I also think most of the criticism of Go error handling is that it's a clunky and noisy implementation of the "error values" idea. Rust does the same, but instead of a (value, error) tuple they use enums that clearly discriminate between the two, and aren't afraid of providing more concise syntax for the common 're-throw' case.

Intel Meteor Lake and AMD Phoenix also introduced dedicated AI acceleration hardware.

Oh, I'm not using it to excuse the issues! All I'm saying is that if AMD implemented SYCL instead they'd probably turn it into an equally big mess.

That's implementation details. SYCL and HIP are programming languages (more specifically C++ dialects), ROCm is an implementation of HIP that uses machine code. Intel DPCPP/icpx is an implementation of SYCL that uses SPIR-V.

There exists a HIP implementation that also compiles to SPIR-V, chipStar. And one can in theory write a SYCL compiler that generates machine code (maybe with openSYCL's HIP/ROCm backend?)

They presumably mean "pure GNU toolchain", not "pre".

I think (but I'm not sure) that in Zig you can just @cInclude("header.h") or something like that? So your C types are automatically imported/converted to Zig types.

Well, rustc is the canonical Rust compiler. mrustc mostly just exists to aid in bootstrapping and really not much else.

>This is not an apples-to-apples comparison.

Neither is FLOPS. RDNA3 FLOPS numbers are greatly inflated, because they are only applicable to fairly specific VOPD and WMMA instructions, the former being for two MADs at the same time, and the latter being applicable in the same cases as tensor cores.

Besides, it should be possible to use the tensor cores combined with the codec: you can use vector hardware to decode matrix values to fp16/fp32, then yeet those into the tensor cores. Although most of the time will probably be spent on the decoding part, assuming you're doing matrix-vector multiplication and not matrix-matrix (which might be different with MoE models like Mixtral 8x7B?)

It looks like offload is mostly about generic abstractions for accelerator devices. XeGPU on the other hand seems to be a way of encoding Xe-specific hardware features/instructions, so pretty different? I don't see how these are anything but orthogonal.

You mean for CPUs? Check out ISPC, it's essentially a lightweight data-parallel C for CPUs (that has been ported to Intel GPUs too!), and I think also works fine on even some non-x86 architectures. I'm not sure if there's any mature CPU OpenCL runtimes.

Intel also still supports OpenCL as a first-class target on their GPUs, which is more than I can say for Nvidia or AMD.

GPUs do deal with memory in other ways than parallelism! That's why GPUs tend to offer huge register files (up to 256 architectural registers per thread on RDNA1!) and local memories (up to 64KB LDS per workgroup on RDNA1). This means lots of work can be done purely in registers and LDS, and trips to global memory are way rarer compared to CPUs where global memory contain everything except 16 or so architectural registers.

Even then, global memory is an issue. And not just because of latency, but also bandwidth! That's why RDNA2 and Ada both added a ton of last-level cache, not to better hide latency (although it's a welcome addition), but mostly as a 'bandwidth amplifier'.

I'd really not call the Radeon VII a "fantastic card" by any stretch of the imagination, outside of specialized use cases like FP64 compute. Its only selling point is that and the enormous 1 TB/s memory bandwidth with the for the time large 16 GB, which a friend summarized as "I can push 1 TB/s of garbage to nowhere!".

Sure, if those things are relevant to you, it was a killer card, but most consumers judge GPUs first and foremost by their gaming performance, in which the VII was a total dud. The 5700 XT was nearly as fast in those with far less hardware because getting proper utilization on GCN/CDNA is a pain compared to RDNA.

RDNA2 completed the gaming oriented flip with Infinity Cache (which is also useful outside of games, but still has limited application in GPGPU) which allowed them to offer competitive gaming performance to Nvidia with far less hardware, a big difference from the Vega era.

In ML workloads, usually the FP16 operations are matrix operations. On RDNA3, these execute at the same rate as normal shader/vector operations, but on Nvidia RTX cards there are Tensor cores which accelerate them. The Ada whitepaper lists 48.7 shader TFlops (not 43 because boost vs base clock), and 195 TFlops for FP16 Tensor with FP16 Accumulate. That's 4 times faster than regular, and almost double what the XTX lists!

Ampere and newer also have native sparsity support which means that you can skip over the zeroes 'for free', which Nvidia uses to market double the TFlops, which is kind of misleading imo. But the 195 TFlops are even before sparsity is included!

I'm not sure if the 93 TFlops (120 with boost clocks) on AMD are with FP16 or FP32 accumulation, as with FP32 accumulation the 4080 slows down significantly and gets much closer with 97.5 TFlops.

Intel Xe-HPG (used in the Arc A cards) also offers very aggressive matrix acceleration via XMX, with 137.6 FP16 TFlops at base clock, vs. 17.2 FP32 TFlops.

> Ooooh, is that why the consumer cards don't do compute?

No, not really. Sure, the consumer cards are based on a less suitable architecture, so they won't be as good, but it's not like it's not a general purpose GPU architecture anymore.

The real problem is that ROCm has made the very weird technical decision of shipping GPU machine code, rather than bytecode. Nvidia has their own bytecode NVPTX, and Intel just uses SPIR-V for oneAPI.

This means that ROCm support for a GPU architecture requires shipping binaries of all the libraries (such as rocBLAS, rocDNN, rocsparse, rocFFT) for all architectures.

As the cherry on top, on paper one GPU family consists of different architectures! The RX 6700 XT identifies as a different 'architecture' (gfx1031) than the RX 6800 XT (gfx1030). These are 'close enough' that you can tell ROCm to use gfx1030 binaries on gfx1031 and it'll usually just work, but still.

I feel like this is a large part of the reason AMD is so bad about supporting older GPUs in ROCm. It'd cost a bit of effort, sure, but I feel like the enormous packages you'd get are a bigger issue. (This is another factor that kills hobbyist ROCm, because anyone with a Pascal+ GPU can do CUDA, but ROCm support is usually limited to newer and higher end cards.)

It's such a shame Google decided to block adoption of JPEG XL: it's a strict improvement over classic JPEG (you can losslessly reencode JPEG to JXL and reduce the size, due to a better entropy coder in JXL!) and JXL has various other upgrades compared to 'classic' JPEG.

In the meantime, let's hope AVIF or whatever manages to pick up the slack, and/or other browsers decide en masse to support JPEG XL anyway; that would be a bad look for Google, especially if even Apple decides to join in on the JXL party.

Well, in Vim, "switching to normal mode" can be thought of as "ending an insert command" instead of "switching modes", which makes sense as soon as you realize that normal mode is, well, normal.

So when you press "o", I don't think "switch to insert mode". I think "insert a line with the following text:", which can then be undone with u, repeated with ., or whatever else you want.

At least that's my mental model of Vim, I don't know which is closer to reality.

Did you actually read the parent comment? They consider a worse chat experience with Android users a feature, because God forbid someone prefers Android, or shudders doesn't want to spend $1000 on a phone.

What's an A-expression? I tried looking it up but didn't find anything.

I have heard of M-expressions but never of an actual implementation. Scheme also seems to have some SRFIs involving alternate syntax that's whitespace dependent, like SRFI 119 (wisp), SRFI 110 (sweet-expressions or T-expressions), or SRFI 49.

Rust spent its entire innovation budget on zero-cost memory safety! Basically, instead of you tracking lifetimes (like in C with malloc/free) or the runtime tracking lifetimes (like in a GC'd language), Rust lets the compiler do this with a 'borrowing' system.

Borrowing in Rust means objects exist in two states: owned (which get dropped when they fall out of scope, like in C++), and borrowed, which means some other scope owns the object and we only have a reference to it. The compiler verifies that a borrow cannot outlive the actual object, so it statically prevents use-after-free errors.

Rust also has a distinction between constant and mutable values, and statically checks that any mutable references are exclusive, and that immutable references are only shared with other immutable references. With this it helps prevent race conditions or other such mistakes.

Finally, Rust also actually has smart pointers in case you truly don't know when an object won't be needed anymore, although the names are a bit different than in C++; there's Rc/Arc for reference counting (like shared_ptr), Box for owning pointers (like unique_ptr?), and RefCell, that's like a runtime borrow checker.

Apart from these features that prevent use-after-free and aliasing, Rust also has a feature called 'unsafe' with which you can bypass all these and e.g. work with raw pointers. Unsafe is generally used sparingly (and if not, attracts a lot of criticism, like happened to actix-web), and the safe abstractions on top also provide more pedestrian safety features like bounds checking. You can skip bounds checking on e.g. a Vec, but doing so actually requires you to drop into unsafe yourself, since the get_unchecked function is marked unsafe in the stdlib.

Small interesting side note: I'm pretty sure Rust is actually doing very little new things, PL-design wise. It's more of a realization of theory that has been around for years if not decades.

Huh, why is being cacheable unique to HTML? What's stopping an SPA app from using a cached JSON response?

You can run the SSR server in the same process, and the main benefit is that the client is a lot thinner (only needs to swap in HTML, no need to render anything).

Depending on the server framework, it should be perfectly possible to e.g. have uniform routes for JSON data and HTML hypermedia, although you do need to be careful with churn in such cases; you don't want a website redesign to break your native app. The HTMX author has an essay describing a solution: https://htmx.org/essays/splitting-your-apis/. Essentially, just implement two APIs! Since you can do this in a single backend (e.g. Django project) the amount of duplicate code should remain fairly limited anyway.

Also, many modern SPAs are highly complex in order to do things that don't require any work in a hypermedia application. For example, if you want JS-disabled clients to be able to view your page, you need to run a copy of the client on the server, necessitating a full JS runtime there (bad if you're not using server-side JS already!). And then you also need complex hydration logic so that it gracefully transitions to a full SPA. Plus this solution sucks if you want to use something other than JS on the backend.

With hypermedia tools like HTMX it is generally way easier to achieve progressive enhancement (although it will still require some thought, see e.g. https://htmx.org/docs/#progressive_enhancement)

GIMP does have search, just hit / and you can find any action.

The problem with search and discoverability is that search requires input from me, whereas discoverability means that the program explicitly offers its features to me. With search, I would never discover some handy new feature I wouldn't think of myself, or something that is named differently than I expect.

Hunting through a menu, while not optimal, allows me to view a 'catalog' of all the features.

OBS works fine via xdg-desktop-portal. I think Firefox (which you can use for Meet and Zoom?) also works, but it's been ages since I tried. Not sure about Chrome and Electron apps, but for those you'll at least need a pretty new version (which Discord for example refuses to ship iirc).

KDE doesn't have this problem, actually. At least it's not uglier than X11, since by default (since 5.27 or so) it uses X11's DPI scaling for Xwayland apps by default. You can change that under Display settings if it doesn't work for your apps and you need to revert to ugly blurry upscaling like GNOME and sway do.

FTFY: GNOME Shell/Mutter and wlroots don't fractionally scale chrome, discord, vscode, spotify, beeper and other Xwayland applications.

KDE Plasma Wayland by default applies Xwayland fractional scaling for X11 apps, which while less good than Wayland-native scaling mostly works. (If it's broken for you/an app you use, you can toggle it to let the DE scale up from 100%.)