kllrnohj

so a single 3 year old errata for the n100 that was long since patched?

An iPhone will absolutely draw more than 2.5w under load.

I used Uber for the first time in like 8 years recently, and near as I can tell it's the exact same thing it was. What features are they even adding at all much less that anyone cares about? You ask for a ride to a place, a driver shows up, money is exchanged - the end?

Sometimes things are actually just finished. They don't need to treadmill.

> Now they are about 4-5 years behind Intel/AMD. [..] the LA664 almost entirely fixed that issue. I think a big part of performance issues is that they are working domestic 5 to 7nm processes, so a good 5-7 years behind.

I'm not finding many benchmarks but looking at this https://chipsandcheese.com/p/loongson-3a6000-a-star-among-ch...

it looks like it's right around Zen 1 class performance. Which I hate to tell you is 10 years old already...

> Of course, like literally every other time this has played out in computing history, the companies focused on price performance will end up with more economic resources, and get to turn the upgrade crank more often and for longer.

Eh? The entire CPU & GPU wars for the last 30 years consistently rewarded the top performer above all else. Price/performance has always been the consolation prize of the loser of any given generation, and sitting in the price/performance pit for several generations in a row results in being essentially out of money in a fringe position. Like, for example, AMD's GPU division currently but also AMD's CPU division before Athlon 64 and also Phenom up through Ryzen.

That thumbnail is for grid-size, it's generally 50kb or less in size which ends up being around 300x240 or up to 500x500 on newer codecs.

It'll be visibly low-res and blurry until the full size decodes for full screen. Hence why I said "when tapping on a thumbnail"

> I think that's sufficiently fast. (Keep in mind that a 4k screen is about 8.5mp.) How fast do you want your slideshow to be?

A modern iPhone can capture at up to 48MP. If the performance scales linearly with pixel count, that would put tapping on a thumbnail to the full size being ready at over half a second. That's going to feel laggy. Now you can throw storage at the problem and pre-compute a downscaled intermediate, sure, but that doesn't fix it when you send the photo to someone else or whatever.

And competitive phones are doing 200mp captures (which is stupid in its own right but phone manufacturers and doing stupid things, name a more iconic duo)

> Why is the NN-only portion almost as fast on an iPhone 17 compared to a V100 when the V100 has 4x the FP throughput?

Might have some sequential section or a block size that struggles to fill a V100 or a large chunk of CPU-only work or any number of things like that.

I find it very curious that their new image codec did not really compare itself against other image codecs, but instead primarily video codecs pretending to do images. As in, no JPEG or JPEG-XL.

150ms to decode 12mp is also incredibly slow. That's like PNG territory of slow. A more flagship 50mp image would be... oof.

No, not really. Mythos found 3 CVEs, not 271.

https://www.flyingpenguin.com/mythos-mystery-in-mozilla-numb...

> Great, tell me again who put the Transformer into LLMs?

Google did, as they already said.

OpenAI was better at marketing and a lot more willing to cannibalize the search market as a newcomer. So Google blew their lead in research by not recognizing the product value quickly enough, or failing to win an internal political war on it anyway

Closed source IDEs are if anything the norm: Visual Studio, Android Studio, XCode, IntelliJ, CLion, PyCharm, etc... Even in the "fancy text editor" category things like Sublime were always popular enough.

Because right now humans do have a magical ability machines don't. LLMs are a fuzzy reflection of what they've seen hundreds of times already, they don't have originality or intelligence (yet).

As a much more immediate practical matter, LLMs trained on LLM output makes them worse overall, they degrade from doing that. So the more LLM-prodoced content fills the web, the less useful it is as a data source for future LLM training. In addition to just being increasingly boring and vapid.

I love most of what Rust does, but this is something they just got wrong. The + operator should always trap on overflow. Which Rust kinda wanted to do (hence why it does that in debug builds), but then they chickened out about the performance risk for release builds, undermining the entire thing. The result is just weak lip service to "no UB!", since debug and release still have very different behavior

I think Zig has the most interesting approach here with 3 different "+" operators (+ aborts on overflow, +& wraps, and +| saturates) along with addWithOverflow builtin. It'd probably be a challenge for Rust to adopt that at this point, but it'd be a great improvement

> At some project scale the language really stops being any limiting factor

That's not entirely true. At a certain scale, some languages start becoming increasingly more of a factor. Memory issues in C/C++ codebases, for example. This is pretty well established at this point, which is why there's a push to move away from memory-unsafe languages. Which likely would include Zig, for better or worse.

> written in C [..] tooling and game engines (which you said are a poor fit for manual memory management)

Game engines moved to C++ over 20 years ago.

Most major compilers are also in C++, including GCC (it switched over a decade ago). Which means the two largest C compilers are themselves not written in C. They have un-bootstrapped.

> That all said, I do agree that manual memory management is really hard to do if you are used to just sweeping gigabytes of memory under rug, hoping the GC vacuum cleaner slurps it afterwards. It takes a mindset and a set of practice. But once you internalized it, it becomes second nature.

Sorry, but no, you cannot internalize this. Nobody can. Once a program grows past some point, purely manual memory management & "git gud" are simply not practical. The amount of evidence against this is beyond any doubt.

Zig's emphasis on cross compilation seems like it's a better fit for embedded than anything else, which is where things shouldn't realistically grow to be huge projects, but with how coding efficiency (or lack thereof) works today along with microcontrollers getting ever more powerful... who knows.

> Bambu totally delivers there. They really commoditised 3D printing and brought the price down.

Prusa's MK3S delivered consistently good, zero fuss, straight out of the box prints with auto bed leveling for $999 before Bambu labs even existed at all.

Bambu brought Core XY & multi-filament to the "mainstream" (for however mainstream 3D printing is at all), absolutely, but if you just wanted a 3D printer that consistently worked for an affordable price? Prusa beat them to that by years. They just didn't advertise the shit out of it on YouTube like Bambu did.

Prusa unfortunately then kinda just... relaxed? Not sure what happened, but MK3 -> MK4 was pretty meh, the XL was delayed, the Core One a good response but still lacking on the multi-material front, etc...

> Zig doesn't have explicit annotations for it, but the concept of ownership and lifetime doesn't go away. It's not enforced by the compiler, which is an intentional tradeoff to let the programmer have more control and freedom.

Right, it's exactly like C, and we kinda all know how that worked out in practice already...

Hence why I called Zig a "love letter to C". If all you want is C with a dash of zest, that's Zig. If you want a modern language that has learned from the many hard lessons the industry has dealt with over the years... well, Zig ain't it. Which is a perfectly fine thing for Zig to be, it doesn't have to be a good general purpose language. We have plenty of those already from Rust to Go to Java/C#/Kotlin to etc...

> arenas are useful for temporary allocations with poorly defined intermediate scope or lifetime (think functions directly or indirectly called by the arena owner).

Arenas are not good for that because the arena as a whole has to outlive all of those poorly defined scopes & lifetimes, which is hard to do. Especially if you later go add on something like an retry-with-backoff or asynchronous metrics/tracing or caching or whatever. Then suddenly you're either fighting use-after-frees or doing deep-copying of data.

Arena allocators are not some grand new concept. They're already commonly used in C++ in the places it makes sense to use them. Which is really not that many places, it's a fast but rather niche optimization. There's not a whole lot of scenarios where lots of temporary memory is needed for one well defined scope.

Video games are large and have lots of state and lots of threads. Zig's lack of ownership here with fully manual memory management is overall a poor fit.

C also has only explicit memory allocators...

Zig is a love letter to C. It does not do much of anything to address memory management. Doesn't even have any concept of ownership like C++ does (ergo, no equivalent of unique_ptr / shared_ptr). All you get over C is the addition of defer, and even that isn't really that different if you're using GCC or Clang and thus have __attribute__((cleanup)).

HDR has problems that aren't the fault of missing color management. Notably, the fact that HDR of the HLG & PQ variety (so HDR10) do not have specified behavior. The specs are wrong in that they basically just don't exist for half the problem. Which also means most content is badly authored, too, almost certainly including your fancy pants Nikon. This is why gainmap images almost immediately dominated the mobile phone capture space, they are actually properly defined. So both viewers and creators know what they're actually intended to do.

The rest of your rant seems mostly anchored around the fact that most things still produce sRGB, which is true, but they still typically map inputs into sRGB appropriately (that is, they get clipped). Which still is being properly color managed.

No, my correction is correct. Colorimeters are physical measurement devices to adjust the display so that it reports an accurate color profile in the first place for which to color manage to. It's required for the monitor itself to be able to display accurate colors at all.

> I remember the days people compared their colorimeters and profiled their own monitors.

That would be calibration and it's still necessary if you want color accuracy. That's about ensuring that what your monitor thinks it's displaying and what it's actually physically emitting are the same. The main thing that's changed here is that factory calibration has become a lot more common and is often more than good enough for anything short of serious professional work. Even for things that aren't professional displays. Like most flagship or even midrange smartphones are factory calibrated with dE values that would make reference monitors from 20 years ago blush. Right up until the OEM shoves a shitty color curve on it intentionally to make it "pop" or be more "vibrant" (Samsung calls this "Vivid", Pixel calls it "Adaptive", etc.. - but they at least usually have a "natural" option that gets you back to the properly calibrated display)

graphic designers don't really see any of this, either. It's going to be photo junkies or people working on image processing systems (either building them or using them) that have to deal with this.

But for the most part this shouldn't really matter much. A huge amount of things these days are properly color managed, so as long as the thing that wrote the profile actually, you know, wrote what it actually wanted then it'll display just fine regardless of how many different "sRGB" profiles there are floating around. We're largely past the days of just hoping that the image and the display happen to agree on roughly the same colors.

I would expect all LLMs are going to be better at Rust than Zig - a strong, thorough compiler will simply prevent more mistakes, and the benefits of a "simple" language decreases the larger the code base gets. The more abstractions exist, the less valuable "no hidden control flow" or "no hidden allocations" from the standard library get, and that's before you add the mother of all abstractions of vibe coding.

To be fair to OP, that follow-up doesn't appear to be mentioned anywhere in the discussion on #310226, either. They probably should have left a note about that change before locking the thread.

The linked revert PR is not from Microsoft (and also isn't merged)

For the codec itself, the majority of it is performance sensitive and often has a significant amount of assembly even, so a memory safe language doesn't change much.

However for the container/extractor... those should absolutely be in a memory safe language, and those are were a lot of the exploits/crashes are, too, as metadata is more fuzzy.

As a practical example of this see something like CrabbyAVIF. All the parser code is rust, but it delegates to dav1d for the actual codec portion

The fan blades deform & vibrate under rotation & airflow. Controlling that deformation is the point of the use of materials like Noctua's Sterrox LCP or other flglass-fiber reinforced LCP materials in other premium fans. So lower clearance isn't just a matter of manufacturing tolerance

Noctua talks about it on this page: https://www.noctua.at/en/expertise/tech/sterroxr-liquid-crys...