ben-schaaf

Rust already has this, it's called editions. The tricky part is it needs to stay ABI compatible to be able to link dependencies from other editions.

Neat! Hopefully these new architectures can beat the Pi5, though even that's still far away from Zen 1 let alone Zen 3.

> and even substantially faster than a Pi 5 for multi-core and vector stuff

I'll push back a little on this. It can be faster under certain workloads, but is not universally. It's behind in geekbench https://browser.geekbench.com/v7/cpu/compare/146501?baseline..., and in compilation workloads: https://www.phoronix.com/review/spacemit-k3-pico-itx/3

I've seen this claimed before, and just going by SiFive's specint claims the P870 at 2.6GHz should match Zen 3.

But for SiFive's last silicon, the HiFive Premier P550, they claimed a specint2006 of 8.65/GHz. That should put the silicon only about 20% slower than an intel i5-6400. But if you look at geekbench scores it's about an order of magnitude slower.

Correct me if I'm wrong, but Tenstorrent has yet to ship any of their own cores? They do make very similar claims to SiFive.

Personally I'm very skeptical that these cores will be anywhere near Zen 3. I recon their performance claims are based on best-case CPU simulation, rather than a real measurement. I'd expect Raspberry Pi 4 levels of performance, a bit over double SiFive's current state of the art. An impressive improvement, but nowhere near Zen 3.

Given how appalling the thermal throttling behaviour is on the Neo - sustained workloads can lose up to 50% performance, making it substantially slower than an M1 Air - you should instead be asking for a fan in the Neo.

> How do they implement it?

In firmware.

To add to the long list of caveats: This also breaks assumptions GUI toolkit and applications make about only one of their windows being focused at a time: `gtk_application_get_active_window`, `QApplication::activeWindow`, etc.

> Consider you were implementing drawing a button. Your UI framework calls your draw method with some interface to draw with and gives you a rectangle specifying the region to draw. Your button is probably some form of rounded rectangle which will be complicated to draw a subsection of if the rectangle intersects a corner. If it intersects the button's text then you probably need to figure out which characters intersect the text and only render those. It's a non-trivial amount of work to cull the draw commands to an arbitrary region.

The way this is done everywhere is to invalidate the entire area of the button. Buttons usually change background on hover/click anyway, so it just doesn't make sense to do more. Text input is special because these widgets can be very large, sometimes spanning the whole screen, so you want fine-grained dirty regions.

> Also, if you stop passing dirty regions around then the widget drawing method is closer to being a pure function meaning the UI framework can cache the draw instructions instead of calling it over and over for different regions.

I've never heard of anyone adding a general Widget-Level cache, considering that most UI elements don't change position that would be quite expensive. In any case the rendering is still a "pure" function regardless of whether you're using dirty regions or not, so not sure what you're trying to say here.

> Looks like it but it doesn't show any renders for the cursor flashing so I don't fully trust it.

That is definitely weird, but it still clearly shows that the regions are being tracked.

> That doesn't mean that the process stops, it runs indefinitely because it has to.

The processes don't stop, no, but they do pause and go idle, waiting for the next event to come in. Not sure what that has to do with this.

> The DOM does this. React does this.

What does react have to do with any of this discussion, and what do you mean by "this"?

> Did you know CSS even invokes the GPU for certain tasks?

Whether the GPU or CPU does work is unrelated to how frequently and how much of the screen is rendered. Damage regions work just fine for GPU-based rendering.

> You guys really need more experience. I can't believe how many people apparently know nothing at all about web dev and computers.

Part of my job is maintaining a retained mode UI library. I've literally written some of the parts that handle damage regions, as well as the GPU-based rendering. But do go on about how I don't know how any of this works.

Wow, that's quite silly - and might partially explain some of the worsening battery life on Android. GTK4 also removes such an API, but just like those docs say, dirty rects are still calculated internally. You can enable the same visual debugging in GTK4 and see that dirty rects are done the same as they always have been.

Chrome on desktop has an option for flashing whenever it paints and it only highlights the line of text you're typing on. So clearly chrome still tracks dirty rects properly.

This is just plain false. Retained UIs like the DOM and what your OS uses only ever render when something changes, so the vast majority of the time they sit idle. There's extensive effort throughout the entire stack to do as little work as possible.

For instance, the mouse cursor is composited on the GPU during scanout. That means simply moving your cursor requires zero rendering.

Another example: When typing only the newly typed character and caret are rendered. The rest of your entire screen is reused.

Blender has multiple options for emulating a middle mouse button. I can use blender just fine on my laptop with a touchpad.

As for the numpad you can use the tilde key or alt+drag to switch views. There's also a handy gizmo.

Arc Raiders is a great example for why UE5 is the reason games run poorly. It neither uses Nanite nor Lumen. Valorant goes even further and uses a custom forward renderer. The studios that care about performance avoid using the big headline features of UE5.

Benchmarks are easy to find. The basic M1 has double the single core performance over the Ampere Altra Max: https://www.cpubenchmark.net/compare/6915vs4104/Ampere-Altra...

I find it's incredibly helpful to know when someone's using an automated translator, as they usually get details wrong while still reading like a native speaker. Not using a translator at all, or disclosing that one was used means I can make a better educated guess as to what they mean. It also changes how I reply.

Compared to that Toyota the sightlines are objectively worse with the longer hood. Using the comparison cars the hood stands at 1.12m before the sloped part; a 6 year old could easily stand in front of that and you'd never see them.

Compared to a Toyota corolla, there's at least a 50% higher fatality risk in pedestrian accidents solely from the higher hood. That's for the general population. Given how these fatalities usually work, the risk to children is exponentially higher. There are dozens of studies on this.

No, this car isn't the worse offender, but lets not forget the important part here: This hood design is exclusively done for aesthetics.

Yet it still has a relatively tall, straight hood that tends to drag people underneath the car. These designs are terrible in pedestrian accidents; to a significantly greater degree when children are involved.

Every iphone, ipad, playstation, xbox, android phone (though there are ways of unlocking), smart TV, smart Fridge. These are all devices that run a full web browser, these aren't appliances they're full personal computers. You can write and run software on them, even if arbitrarily limited in hardware access.

Funneling means opening up the device for the entire internet to access, not just to those with my public key like in iroh. It's limited to 3 ports. It requires setup for each device. It's not peer-to-peer. It has throttled bandwidth.

No, this does not do the same thing as iroh. Not even close.

Dynamic DNS takes setup for every single device, and obviously doesn't work for devices that switch networks frequently. It also doesn't help you if the IP is behind a NAT.

> We built & continually check that iroh can compile to WASM & run in the browser

DNS doesn't work with constantly changing IPs, like you have on mobile networks. DNS also doesn't help when the IP is behind a NAT. So I really don't see how the two are similar at all.

Everyone I'd like to connect to isn't on my tailscale, nor do I want them to be.

Your phone and laptop don't have stable IPs, let alone DNS entries pointing to them.

From reading that, it lets you establish connections within your tailscale vpn. Iroh let's you establish connections between devices regardless of their network.

Not an expert but this is how I understand it. Yggdrasil is a P2P mesh network. You configure peers to join the network and your computer becomes a relay node for everyone else to use. It doesn't work behind a NAT without port forwarding.

Iroh is kinda just a connection protocol. If you get given a public key for another computer, you can establish a connection. Like you would an IP address. The magic is in being able to establish that connection regardless of where either device is, and keeping that connection alive through changing network conditions.

Run gitlab or gitea.

BG3 is actually a perfect counterexample here. It doesn't have DRM, doesn't require an online account to play and uses direct connections for multiplayer. Nothing needs to be done to preserve it.

> The way to manufacture more efficient compute now is do things like put DRAM closer to the chip and even closer integration between CPU and GPU. The fact that Apple can co-design their silicon such that the CPU and GPU can pull from the same pooled RAM is a major advantage over competitors.

> When you have CPU, GPU, and even DRAM sitting on the same "die

Apple has been really successful convincing people they've done something special here. Given how many people are so horribly misinformed about this I'd go so far as to call it false advertising.

No, the DRAM is not on the same die. It's on package. They're literally standard SK Hynix memory chips.

Yes technically there's a latency advantage, but comparing M1 to DDR5 desktop chips Apple actually has worse overall memory latency.

Every integrated graphics chip from Intel and AMD has had unified memory for the last 10+ years.

Compute itself is also not what makes the Apple chips get long battery life. Looking at tests under full load the M1 is significantly worse than the latest Intel or AMD, yet it still gets better battery life under normal usage. The efficiency does not come from compute but from a whole host of idle consumption optimisations Apple brought over from their phone chips.

If the returned value is still valid despite an error, then the function would return (u32, Option<Error>), perfectly valid rust. If the value is meaningless in case of an error then using it is incorrect code; you wouldn't want to do that in either language and rust makes that assumption explicit with unwrap. If you want a default value in case of error just use unwrap_or_default.

Significantly less so than before, but it's unfortunately still the case. It's also just now getting features that people have been asking for for over a decade, and of course due to the nature of Wayland the implementations of these features are sporadic and inconsistent.