> 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.
> 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.
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.
JPEG-XL is designed for archive-grade images. It hasn't been optimized (maybe not even designed?) for low bpp settings (less than 1 bit per pixel), and is awful below that, let alone 0.3 bpp or so. Plain old JPEG is much worse. Video codecs (and the image formats derived from them) have optimized for quality at low settings.
> 150ms to decode 12mp is also incredibly slow.
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?
> 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)
At least JPEG contains downscaled thumbnails embedded into it as part of the EXIF stream. There's no need for the receiving device to rescale it again.
we're in 2026, 240hz screens are becoming common. Nothing in the end-user experience should take more than 3-4ms. My personal goal when developing is keeping things at at least 60FPS and ideally 120 when building the whole stack with ASAN / UBSAN / stdlib's debug modes.
For instance when looking at this the first thing I thought was to try to make an installation which permanently recurses the codec's application on itself at each frame, to give the impression of a constantly moving landscape. Impossible on a smaller machine if computing a single frame takes 150ms.
That's fine reasoning for video, but if someone is actually looking at a still picture for more than 1/240th of a second, the fine detail matters a bit more. These are different applications, with different sweet spots in the time/quality trade-off.
Think about the scenarios where people are viewing slideshows. If you're on a mobile device, that 150ms spent decoding each image is time where the CPU and/or GPU of the mobile device are running at full tilt, draining the battery. Suddenly applications that would normally be fast and efficient like a photo gallery app become laggy and drain your battery. Not great.
I think you're confusing CVEs and vulnerabilities here? Mozilla (per their longstanding practice) grouped multiple vulnerabilities found internally under a small number of CVEs.
> 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.
I've filed bugs with JetBrains before and had them take months getting to my ticket, often with multiple hand-offs between team members; being able to provide a potential fix should make the process much faster.
Do all of those installed on my various machines for the express purpose of a last resort of building some obscure crap about once a couple years count? Because of course I have them installed.. somewhere. And of course I wouldn't imagine using that crap daily.
You can't expect the average person on HN to admit to using a JVM-based language. That would mean they write boring business software rather than cool ad surveillance tech.
I'm always taken aback a little when I read through HN and see how little mind share Kotlin and its ecosystem has here. JetBrains has done a pretty good job of creating something that can fill many different niches (especially considering they're not one of the giant tech companies with virtually unlimited budgets), but it seems people don't even realize it exists, for whatever reason. It doesn't even need to run on a JVM in many cases, if that's some sort of barrier.
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.
The intelligence is an emergent property of their ability to predict how a statement will proceed, therefore it is inevitably a reiteration or transformation at best. Lots of intelligent things can be produced from that, but nothing truly novel.
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.
I agree that new software should avoid memory unsafe languages, but I would disagree that rewriting existing projects in a memory safe language at all cost is a universally good idea.
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...
reply